TinyCC is not a suckless project, has no relation to it, and owes it
nothing. I don't see how/why anything suckless should affect TinyCC.
That being said, this whole discussion of what to support first is
mostly moot. Progress is being made by volunteers, with some
maintainers who might revert or
On Saturday, May 24, 2025 at 12:18:34 AM GMT+3, tylo
wrote:
> MingGW-W64 14.2. Message during compilation:
>
> tcc: error: could not open ''
>
> Commit 30c2373c, May 7.
> Still present in the commit of May 22.
I can't reproduce an issue when building tcc with mingw gcc 13.2, and
commit 30c2373
No. long is also 32 bit on Windows.
On Friday, May 16, 2025 at 02:00:54 PM GMT+3, Sun <809935...@qq.com> wrote:
Can I use %lu? My os is windows.
#include
#include
int main(int argc, char **argv)
{
int64_t a=123,b=234;
printf("%lu %lu\n",a,b);
return 0;
}
output:
123 0
-
I can confirm this output on Windows with mob f10ab130
(2025-03-28), but only with tcc 32 bit build.
And, at least on Windows, it also needs #include
However, this program is buggy, because the format %d is for
int (32 bit on Windows), while the values are 64 bit, so
a mismatch and undefined beh
Hi,
Next time, please include at the commit message a description of the
problem, a description of the solution, and an example case which
didn't work before the fix, and does work after the fix.
Otherwise, it's hard to judge by looking at the commit what's actually
broken, affected cases, assess
On Friday, February 14, 2025 at 11:02:35 AM GMT+2, DFP
wrote:
> ... Would you recommend using the mob branch version of the
> compiler to get the fix? Especially seeing the last 'big' release
> was seven years ago.
Yes. The mob branch is generally reasonably stable, which holds also
for this
On Windows, with current tcc mob, both tcc-32 and tcc-64
print 17, as do mingw gcc 32 and 64 on Windows.
On linux (Ubuntu 64), tcc-mob also prints 17 for me, as does gcc.
FYI,
avih
On Thursday, February 13, 2025 at 04:11:18 PM GMT+2, DFP via Tinycc-devel
wrote:
Hello.
va_arg seems to
Note that the indentation in these (and most other) files is 4 spaced - not
tabs.
So you can fix that with a followup push (don't force-push).
Also, next time, try to follow the common convention of commit messages:
:
.
You can check prior commits for the commit message format, or elsewhere,
I think that's OK. Thanks.
Next time no need for "someone should confirm it before merging to mob"
at the commit message, because you already pushed it to mob ;)
On Friday, December 13, 2024 at 04:32:20 AM GMT+2, Keith Thompson
wrote:
I've pushed the fix to the "mob" branch, commit b776
The re-definition of LDBL_MAX_EXP in aarch64/riscv with the same value is
indeed a bug, and your suggested patch does seem correct to me.
Preferably you should first test it with aarch64 and riscv gcc compilers as
described at the comment in this section, to confirm this value in both.
Then you
I didn't notice issues when building in-tree with gcc (32),
but using tcc (native, 32), this previously worked:
./configure --cc=c:/path/to/tcc.exe --cpu=i386
make -j8
make test -j8
But now it fails at "make -j8":
...
c:/path/to/tcc.exe -shared -o libtcc.dll libtcc.o tccpp.o tccgen.o tccdbg.o
tc
> I shouldn't have put `-subsystem=console` because it'd lead to
> confusion in my example. The point is that, when you compile with
> `-subsystem=windows` (which all GUI applications do), you _have_ to
> allocate a console
OK, but you didn't provide a minimal "normal" example program which
doesn
Can we maybe start from the begining again?
If you compile with subsusyem=console, why do you need to allocate a console in
the first place and then reopen stdout? console apps already do that
automatically, like so:
// test.c
#include
int main() {
printf("press enter to exit\n");
fget
You said originally:
> // _MSVCRT_ being defined will cause MinGW's stdio.h to use _iob as
> // opposed to _imp___iob; only the former is defined in msvcrt.dll.
> // However, even though _iob is exported by both the 32- and 64-bit
> // versions of said dll, TinyCC still fails to find _iob in the f
Before I'll respond to your last email, you said in your original email that
even printf doesn't work:
> `_iob` is not the only "unresolved" symbol, either; `printf`,
> `freopen`, `freopen_s`, and basically everything from the CRT will
> fail to link.
But in my minimal example there's only _MSVC
tcc 0.9.27 is few years old now, and hopefully 0.9.28 would be released sooner
rather than later, so you should try the latest version, which is the mob
(default) branch here:
https://repo.or.cz/tinycc.git
You'll need to build it yourself. If you can't build it or can't find a recent
pre-build
On Thursday, November 21, 2024 at 03:39:45 PM GMT+2, Domingo Alvarez Duarte
wrote:
Thanks fo reply !
Again even if it's valid C code it's clear that it has several drawbacks
pointed so far by other comments on this thread and if there is a more
clean/clear/elegant way to expr
Fow what it's worth, when compiling with clang, the "configure" script adds to
the compiler flag:
-Wno-string-plus-int
exactly to suppress this warning, because it's stupid, and it's valid C code,
and the developers of tcc know that string + int is adding to the pointer and
not to the number i
I recently pushed a fix to unbreak the auxiliary unistd.h from:
http://download.savannah.nongnu.org/releases/tinycc/winapi-full-for-0.9.27.zip
I also added a note to win32/tcc-win32.txt about using this
auxiliary headers package.
This package is almost still working nicely with current mob, but i
Personally I don't think this is required, but I don't pretend to
represent the tinycc maintainers' opinion. If it is added, however,
then the following should probably be taken into account:
- This mostly works, but it won't work on all terminals, for instance
the original DEC VT100 has bold bu
On Tuesday, September 12, 2023 at 12:44:45 PM GMT+3, grischka
wrote:
On 12.09.2023 11:01, avih via Tinycc-devel wrote:
>> Tcc does not guarantee to compile pure C code into pure machine code,
>> and any pure-C implementation which the user provides might end up
>> depending
tions involuntarily. The user has no control..
- avih
----- Mail d'origine -
De: avih via Tinycc-devel
À: tinycc-devel@nongnu.org
Cc: avih
Envoyé: Tue, 12 Sep 2023 10:33:01 +0200 (CEST)
Objet: Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol
'memset'
And
when linking with libtcc1?
On Tuesday, September 12, 2023 at 12:11:17 AM GMT+3, avih via Tinycc-devel
wrote:
Thanks. I was going by the official gcc docs. I did not test
what it requires beyond those mem* implementations.
Back to tcc, the current help for nostdlib is:
> -nostdlib do no
aybe even more beyond those?
Should the mem* functions and libtcc1 cover these linking issues, assuming
the user code doesn't use the crt and stdlib?
- avih
On Monday, September 11, 2023 at 10:32:26 PM GMT+3, grischka
wrote:
On 11.09.2023 14:41, avih via Tinycc-devel wrote:
>
The issue is bigger than just memset. I found at least 5 more functions
which are required in some cases, not all of them part of stdlib, and I'm
guessing sure there are more, depending on the platform. For instance:
// test3.c ---
typedef struct { int a, b; } S;
void _start(void) {
I don't think that's a valid argument.
This is plain C code which on its own doesn't require the standard library,
so I don't think the user should provide an alternative standard library
implementation just so that the startup code which tcc uses can be linked.
Today it seems that only `memset`
Correction: the expected name is "_start" - not "_startup".
- avih
On Saturday, September 9, 2023 at 07:19:32 PM GMT+3, avih
wrote:
The following is test.c:
#include
void _start(void) {
char buf[16] = {0};
ExitProcess(42);
}
Try to compile it using:
tcc -Wl,-nostdlib te
The following is test.c:
#include
void _start(void) {
char buf[16] = {0};
ExitProcess(42);
}
Try to compile it using:
tcc -Wl,-nostdlib test.c -lkernel32
Result:
tcc: error: undefined symbol 'memset'
Which I'm guessing is tcc trying to zero buf on startup using memset,
but failing to
What some random script tries or doesn't try to do is irrelevant.
tcc should follow the spec and common practices.
Generally speaking, applications which respect the POSIX syntax
guidelines should treat non-option-argument "--" as an indication
that all further arguments are operands:
- https://
__unaligned is defined as _attribute__((packed))
at win32/include/_mingw.h and pretty much always included, so tcc
shouldn't blindly define it to something else in advance.
The warnings can be observed when compiling tcc on Windows, or
when using the resulting newly built tcc, or when cross-compil
The patch below works for me. If you think it's good, please push it.
Feel free to modify it however you see fit.
The issue with your original patch was that __clang__ is only defined
when compiling the reference using clang, but not when compiling the
test using tcc.
In this patch, preprocessor
On Saturday, March 18, 2023, 02:07:35 PM GMT+2, avih wrote:
> If I use #if 0 instead of #if !defined(__clang__) || GCC_MAJOR >= 11
> then it does pass. Not quite sure what's going on.
Ah, I do get it. When it compiles the reference using clang then
these elements are 0, but when it compile
The patch does not work. The file compiles but there's a diff:
test3
--- test.ref 2023-03-18 14:01:39.0 +0200
+++ test.out3 2023-03-18 14:01:40.0 +0200
@@ -973,9 +973,9 @@
6 1490
7 3010
8 3010
-9 0
-10 0
-11 0
+9 2444
+10 3056
+11 3056
12 16149
13 32
This is a second reply to the same email.
On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge
wrote:
> Can you change the code in 'tests/tcctest.c' on line 3865 to '#if
> GCC_MAJOR >= 40'.
This works. Specifically, only the __builtin_clrsb* are an issue,
while the others are fin
I thought it would be useful to be able to reach from tcc 0.9.27
to the current mob HEAD cleanly, and I've encountered several issues:
1. On Ubuntu 64 22.04 LTS (gcc 11.3), tcc 0.9.27 does not build.
git clean -xfd
git checkout release_0_9_27
./configure --prefix=$PWD/../tcc0927
make
# ends wit
On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge
wrote:
> The config-new-macho=no was the default with commit 62096265.
Right, so that explains why --config-new-macho=no didn't help,
and I'd guess there are no options which would make it work, right?
(I don't have a need for th
On Tuesday, March 14, 2023, 02:53:19 PM GMT+2, Herman ten Brugge via
Tinycc-devel wrote:
> I can only test things on macos 12.6 (aarch64) and macos 10.15.7 (x86_64).
> These 2 platforms work with head.
>
> I applied a lot of fixes since november so head is probably the best version.
>
>
> I do
The offending commit is from November 2022.
Here are test outputs with the offending commit and then current mob.
Below is the output with the offending commit 62096265
of the test part of:
git clean -xfd && ./configure && make && make test
hello-exe
dyld: REBASE_OPCOD
On Wednesday, October 19, 2022, 03:36:59 PM GMT+3, Michael Matz
wrote:
> ...
> "dec %edi" truncates the %rdi register to 32bit by zero-extension,
> so that ... this is now segfault. That only matters if the stack
> (which %rdi points into) is setup such that it's beyond 32bit,
> which ... is in
On Friday, October 14, 2022, 05:27:47 PM GMT+3, grischka
wrote:
>> and indeed, when tcc64 is compiled using tcc64 then on win10
>> s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.
>
> Well, maybe behavior of malloc on Win10 has to do with the image-base
> of the process. (see o
In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html
> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation
On Monday, October 10, 2022, 12:33:48 PM GMT+3, grischka wrote:
>> tcc-busybox is:
>> http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip
>>
>> building this busybox using tcc which was built from mob 20a1ebf
>> or later results in sh.exe which always prints "sh: apple
Hi,
It's the first time I tried building it (cute), and turns out that it's
currently broken.
tcc-busybox is:
http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip
building this busybox using tcc which was built from mob 20a1ebf
or later results in sh.exe which always
Hi,
The following tests fail for me currently (0fd7376 gnu hash) when
building tcc for win32 x86-64 (but pass when building i386)
from tests/:
- test3
- test1b
from tests/tests2/:
- 104_inline.test
I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (
I _think_ the current win32 definitions are from Windows XP.
If we update to newer definitions, then I assume it would compile
successfully programs which use newer APIs, but the question is
what happens at runtime.
mingw has a system to define what to target (I don't recall the
specifics), so u
I also think the hash should be there.
git describe can be useful here too.
On Wednesday, March 31, 2021, 06:44:39 PM GMT+3, Dmitry Selyutin
wrote:
Hi Jullien,
I think this is a really good idea. I'd also consider git hash, not a date, but
this is likely a minor.
> +TCC_GIT_DATE=$(s
local in a sh script is not posix, and while some shells do support it, some
do not,
e.g. ksh 88/93 (frequently used on traditional unix systems), yash, and more.
So portable sh scripts should not use local.
- avih
On Sunday, February 14, 2021, 09:30:48 PM GMT+2, Danny Milosavljevic
wro
There is a CodingStyle file, and the second paragraph clearly
states (rightly) that style-only changes should be avoided.
The instructions at this file are still valid.
- avih
On Wednesday, December 2, 2020, 01:08:33 PM GMT+2, Tyge Løvset
wrote:
I have slowly started to look into t
I already replied to it the last time you asked:
https://lists.nongnu.org/archive/html/tinycc-devel/2020-09/msg00034.html
On Wednesday, September 23, 2020, 10:22:40 PM GMT+3, Thema
wrote:
Dear tcc Development Team;
I have downloaded the latest version of the Tiny C Compiler butwhen I
On Monday, September 14, 2020, 04:18:21 PM GMT+3, Thema
wrote:
> I have downloaded the latest version of the Tiny C Compiler but
> when I try to run a program compiled by it, I get an error message
> about the exec format being invalid. I suppose that the ELF header
> is not compatible with the
08:44, Kyryl Melekhin :
>
> About formatting, what's the preferred vim setting you use? I looked
> through the code and couldn't figure out what it was, it seemed so
> inconsistent so I just thought you guys don't care about that.
>
> сб, 12 сент. 2020 г. в 05:55, gr
While force-pushing is usually possible, I'd argue that at the tcc repo
(and generally elsewhere too, but to each his own practices) no one
should force push except maybe maintainers and maybe other regular
contributors which 100% know what they're doing when force-pushing.
I.e. if you want some
It's now embedded into the tcc binary.
See docs/tcc-win32.txt
On Saturday, August 29, 2020, 12:33:50 PM GMT+3, Vaidas BoQsc
wrote:
I downloaded tcc-0.9.27-win64-bin.zip from
http://download.savannah.gnu.org/releases/tinycc/
And in this release I couldn't find tiny_impdef.exe
that do
I don't have proper gcc installed (via brew or macports), but I think it would
make sense to first check what gcc does and supports.
On the other hand, if it's only aliases to existing options, possibly which are
enabled only on OSX, then I don't think [m]any would object, and it should
be fairly
nycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of avih via Tinycc-devel
Sent: Friday, July 10, 2020 11:42
To: tinycc-devel@nongnu.org
Cc: avih
Subject: [Tinycc-devel] [issue] macos: tcc cannot self-host with
--disable-static
Self-hosting with static linking works fi
Self-hosting with static linking works fine:
[ -e ./conftest.c ] || { echo error: not tcc root; exit 1; }
rm -rf ./bld ./bldself ./dist1 2>/dev/null || :
mkdir bld && cd bld && \
../configure --prefix=$(pwd)/../dist1 && make && make test && make install
cd .. && mkdir bldself && cd bldself && \
I've pushed a fix to mob to support arbitrary libdir (c69290fb).
The relative path is now used during `make test', while the fixed libdir is
used after install.
On Thursday, July 9, 2020, 09:12:06 PM GMT+3, avih via Tinycc-devel
wrote:
Note to self: Make sure to do
on 0.9.27 (x86_64 Darwin)
install: /Users/jullien/tinycc/dist/lib/tcc
…
It work for me. If it also works for you I’ll add this step to macos build
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2
you I’ll add this step to macos build
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2020 18:23
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: avih
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no l
Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
compile programs successfully, and -run works as well.
So it seems that install target doesn't take everything into account.
On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih
wrote:
Oh, I missed the commits f
Oh, I missed the commits from today.
Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test
However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make
install
Then it succeeds,
What's the fix? I tried looking at the earlier messages, but didn't
see a diff/patch.
For me on osx 10.13 (real MBA) I also have the same issue when
using --disable-static, but it seems fine without it, including -run.
On Thursday, July 9, 2020, 06:38:10 PM GMT+3, Michael Matz
wrote:
I've built mpv with tcc on both Ubuntu and Alpine linux, though not
recently. It did require patching waf (the build system) because it's
very picky with compiler identification, as well as some minor patches
in mpv to replace few #pragma once with normal include guards.
tcc builds st ( http://st
For me, with current tcc mob (but also with version at least 6 months
old) this does work: tcc hello.c -l c
Which version did you try?
As for -O, it seems that the option-argument is optional - in both
tcc and gcc. The posix syntax for optional arguments is that the
value must follow at the same
תודה. זה מגיע לתיבת הדואר שלך? או שהם משאירים את זה במקום כללי ואת לוקחת את זה?
On Wednesday, August 7, 2019, 10:14:29 AM GMT+3, Mai Aylon
wrote:
היי אבימצרפת לך את החשבון של ועד הביתיום נעיםמאי ___
Tinycc-devel mailing list
Tinycc-devel@n
x,double y,double z){printf("f(%4.1f,%4.1f,%4.1f)\n",x,y,z);}
int main(int argc,char **argv){double u=0.0;f(u*1.0,7.0,8.0);return 0;}
> tcc -o test test.c
> ./test
f( 0.0, 7.0, 8.0)
Fra: Tinycc-devel [tinycc-devel-bounces+grue=di.ku...@nongnu.org] på vegne af
avih via Tin
You're right, and I can confirm that the win64 version downloaded the
same as you exhibits the same issue, and the issue also exists if
I build 0.27 for win64 myself (git d348a9a).
However, it was apparently fixed shortly after tcc 0.27 was released,
at the following commit:
commit 8f6fcb709ae7b
> On Wednesday, July 31, 2019, 8:55:18 PM GMT+3, Christian JULLIEN
> wrote:
>
> This my THIRD attempt to reply to this thread since Jul, 26. The
> two prev. attempts never reached the list. Hope this one will work
> and go to the list!
It did, at least to me (but I was addressed). FWIW, I don
Hi Michael,
> > Patch is attached. If there are no objections, I'll push it in few days.
>
> But why? TCC is a compiler, it doesn't generally provide a C library.
> Use newlib or musl or the like for that.
You know as well as anyone that the Windows build of tcc is more than
that. It's a self
Patch is attached. If there are no objections, I'll push it in few days.
>From the commit message:
This is a POSIX compliant implementation of getopt (short options).
It passes all tests of gnu getopt in posixly-correct mode, with
additional safeguards against out-of-bounds access (optind, optpo
70 matches
Mail list logo
