Re: [Tinycc-devel] Array type not promoted within comma operator
On Tue, Jan 2, 2024 at 8:52 AM Herman ten Brugge wrote: > I cannot find a lot of information on this feature. > Is it a gcc/clang extension? > Does it only apply to typeof? I think it is §6.3.2.1.3 of C11. -- Regards, Patrick ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Array type not promoted within comma operator
Hi,
The following program doesn't compile with tinycc:
typedef int T[2];
int f(T t) {
return _Generic(t, __typeof__( ((void)0,(T){0})) : 1 );
}
whereas I was expecting it to compile (like for GCC/CLANG) due to
"promotion" of "array of int" type to "int pointer" type since it uses
the comma operator.
--
Regards,
Patrick
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Preprocessing issue?
Hi, Thanks for the patch. I am not competent to know if it is correct but at least It fixes my issue. -- Regards, Patrick On Sun, Dec 24, 2023 at 8:43 AM Herman ten Brugge wrote: > > On 12/8/23 20:47, Patrick Pelissier wrote: > > Hi, > > > > I think I have found an issue in TCC preprocessing. > > The program below produces the following output when runs with tcc -E: > > > > , USER > > > > , USER_COMP_CORE > > > > whereas I would have expected 1 more line: > > > > , USER > > > > , USER_COMP_CORE > > > > , USER_COMP_CORE > > > > (Tested with GIT 81a32ec305ee871d8129978bf3d57bc108bec46b) > > > > The program is a little bit long so it is available here: > > https://gist.github.com/P-p-H-d/aeb690c7ed396b57a84f9a5fc83e10c0 > I did some debugging can came up with attached patch. > The testcase probably has to go into the tests/pp directory. > > I am not sure this is the correct fix. So I am not committing it yet. > > Herman > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Preprocessing issue?
Hi, I think I have found an issue in TCC preprocessing. The program below produces the following output when runs with tcc -E: , USER , USER_COMP_CORE whereas I would have expected 1 more line: , USER , USER_COMP_CORE , USER_COMP_CORE (Tested with GIT 81a32ec305ee871d8129978bf3d57bc108bec46b) The program is a little bit long so it is available here: https://gist.github.com/P-p-H-d/aeb690c7ed396b57a84f9a5fc83e10c0 -- Regards Patrick ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] It seem I pull code in wrong way. How can I revert it?
Hi! Force pushing is dangerous, make sure to have a copy of the repo backed up! Sometimes it's necessary though. If you need to do it, make sure that each developer re-clones the repository! I had to do it yesterday for https://github.com/opennars/opennars-for-applications as one author pushed with a wrong email address, and this demands a rebase, which changes all commit hashes beginning from the edited commit. Best regards, Patrick Am Fr., 11. Sept. 2020 um 17:25 Uhr schrieb Pursuer <1596067...@qq.com>: > I found a way to remove these empty commit, by use "git rebase -i". But I > can't push these change without -f flag, and I have been told that do NOT > use "git push -f". So I can only give up to revert it. > > > -- Original -- > *From:* "tinycc-devel" ; > *Date:* Fri, Sep 11, 2020 11:35 PM > *To:* "tinycc-devel"; > *Cc:* "Larry Doolittle"; > *Subject:* Re: [Tinycc-devel] It seem I pull code in wrong way. How can I > revert it? > > Pursuer - > > On Fri, Sep 11, 2020 at 11:27:05PM +0800, Pursuer wrote: > > I'm sorry that I pull code in wrong way. > > And now there are many commit like > > Merge branch 'mob' of git://repo.or.cz/tinycc into mob > > How can I remove them. > > Obligatory xkcd: > https://xkcd.com/1597/ > > There are fancier (and arguably more efficient) ways to recover than > "delete the project, and download a fresh copy". > But they're harder to explain and understand. > > - Larry > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] stringify, another simple C program which doesn't compile
Hi!
The second program also works with Clang, gcc etc., but not with tcc.
It tries to use stringification with a backslash, indirectly:
#include
#define PRINT_(X) puts(#X);
#define PRINT(X) PRINT_(X)
int main(void)
{
PRINT(\\)
return 0;
}
Here the workaround is to use no indirection, to use PRINT_(\\) instead of
PRINT(\\) or to change the definition of PRINT to #define PRINT(X)
puts(#X), in which case the program prints the backslash as expected.
However this isn't a good workaround, as avoiding indirections in the
macros can sometimes be very annoying, luckily it worked in my program
though.
In this case it might be an issue with the preprocessor and not the parser.
Best regards,
Patrick
stringify.c
Description: Binary data
stringify_workaround.c
Description: Binary data
stringify_workaround2.c
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] arraystring, a simple C program which doesn't compile
Hi!
First, amazing work with tcc. I however found two issues with it, programs
which work with Clang, gcc etc., but not with tcc. Program1 tries to use a
char from a string defined with #define:
#include
#define abc "abc"
int main(void)
{
char a[2] = { abc[0], 0 };
puts(a);
return 0;
}
Output:
arraystring.c:6: warning: initializer-string for array is too long
arraystring.c:6: error: '}' expected (got "[")
Interestingly this program works when a parenthesis is put around abc[0]:
char a[2] = { (abc[0]), 0 };
Alternatively, it also works if the parenthesis is around the defined
string instead:
#define abc ("abc")
which can also be done at usage level:
char a[2] = { (abc)[0], 0 };
so maybe it's an issue with the parser?
Attached are all variations, of which arraystring.c causes the error.
I will put the second simple program which doesn't compile in an extra
thread.
Best regards,
Patrick
arraystring.c
Description: Binary data
arraystring_workaround.c
Description: Binary data
arraystring_workaround2.c
Description: Binary data
arraystring_workaround3.c
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling to Bare Metal and to Unusual Targets ?
Thanks Michael ! You have another tinycc-disciple now. If I find arm bugs, I will try to study and fix them myself. I will also report back with successes and failures. I work very slowly but I will be back-Patrick On 2019-03-12 01:14 PM, Michael Matz wrote: Hi, On Mon, 11 Mar 2019, Patrick wrote: I have a couple of experiments I want to run. I would like to compile a self hosted executable to run on a BeagleBone or Raspberry Pi without an OS. I built with --enable-cross so I have a Linux to Arm tcc compiler installed. Could I confirm, I use: --oformat,binary -Wl,--oformat,binary, but yes, that will give you a binary blob without any file headers. You might need to set -Wl,-Ttext to the correct address as well, and you need to remember to use -static for linking. I haven't heard of anyone trying this on arm, so you might run into bugs. I also like Minix3. I haven't used it in quite a while but one thing I didn't like was the complex build.sh, borrowed from NetBSD. You can build the kernel and userland all in one go but it's hard to modify as it's so huge and complex. I was thinking that I would use the tcc compiler on Linux but I would use the C libraries/system libraries from Minix. Both are i386 so I am hoping that I will be able to build a cross compiler by simply adding the right libraries and everything will just work. I realize that I will have to build them before I link them. Minix3 seems to use ELF as basic executable and library format, so that's one thing already. But probably there are details that are different between Linux and Minix3 executables that need to be cared for, for instance the dynamic linker (if minix3 supports shared libraries) will be in a different place. So most likely it won't be as simple as just pointing to the right headers and libraries to get a working result. I am a little mixed up, ./configure --help offers these options: Is this how I include a path to an alternative set of headers? "--sysincludepaths=... specify system include paths, colon separated" Is this how I add a path to an alternative set of shared objects or static archives? ? "--libpaths=... specify system library paths, colon separated" Yes, but before doing that I'd try some experiments: when you add '-nostdinc -nostdlib' to you compile/link cmd lines TCC won't look into any standard paths for includes and link with no standard libraries, so you have everything under your control via -I and -L -lfoo options. If you build a hello world with that you most probably will find that you can't just call the so produced executable under minix3. That would need to be fixed first before using the above options makes sense. The following is for libraries already included in the tcc tarball right? If we wanted to compile to Minix or BSD, this is not going to help right? "--config-uClibc,-musl,-mingw32... enable system specific configurations" No, it's rather about how to integrate with different runtime environments like the dynamic linker and which features the C library provides. Minix3 would be another such set, but depending on circumstance it's more like a new operating system, or more like a new runtime environment (the border is blurry between them). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Compiling to Bare Metal and to Unusual Targets ?
Hi Everyone I have a couple of experiments I want to run. I would like to compile a self hosted executable to run on a BeagleBone or Raspberry Pi without an OS. I built with --enable-cross so I have a Linux to Arm tcc compiler installed. Could I confirm, I use: --oformat,binary To create a standalone binary? Could you tell me if you think I am about to fall into a pit? I also like Minix3. I haven't used it in quite a while but one thing I didn't like was the complex build.sh, borrowed from NetBSD. You can build the kernel and userland all in one go but it's hard to modify as it's so huge and complex. I was thinking that I would use the tcc compiler on Linux but I would use the C libraries/system libraries from Minix. Both are i386 so I am hoping that I will be able to build a cross compiler by simply adding the right libraries and everything will just work. I realize that I will have to build them before I link them. I am a little mixed up, ./configure --help offers these options: Is this how I include a path to an alternative set of headers? "--sysincludepaths=... specify system include paths, colon separated" Is this how I add a path to an alternative set of shared objects or static archives? ? "--libpaths=... specify system library paths, colon separated" The following is for libraries already included in the tcc tarball right? If we wanted to compile to Minix or BSD, this is not going to help right? "--config-uClibc,-musl,-mingw32... enable system specific configurations" Thanks for reading-Patrick ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Integer promotion issue?
The following program:
#include
#include
#include
#define N_RESET(n, i) \
(((n) & (~((ONE<< ABA_CPT)-1)) & ~(ONE << (LIMBSIZE - 1 - i))) \
|((aba_cpt_t)((n) + 1)))
#define LIMBSIZE (sizeof(limb_t) * CHAR_BIT)
#define ABA_CPT 32
#define ONE ((limb_t)1)
typedef uint32_t aba_cpt_t;
typedef unsigned long long limb_t;
unsigned long long f(unsigned long long n, int i)
{
return N_RESET(n, i);
}
int main()
{
unsigned long long n = 9223372036854775809ULL;
n = f(n, 0);
printf ("N=%llu\n", n);
}
when compiled with TCC GIT c41caac02d53373b296ccb179b730ada62137cc0
produces the result on an linux/x86-64 platform:
N=9223372036854775810
whereas I was expecting
N=2
--
Regards,
Patrick Pélissier
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] help with windows + tcc
Hi Everyone Sorry for answering my own post. I just want to mention that I retried everything with the 64 bit package on Windows 7 and everything is fine. If you happen to know how to get this to work on Windows 98, that would be nice as it's much lighter weight and easier to run in Qemu. If not, at least I am up and running :) Thanks ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] help with windows + tcc
Hi Everyone I moved to Linux in 2004 and I am not very good with Windows. I setup Windows 98 under Qemu. I downloaded the windows 32 bit version of TCC. I made an iso image and brought it into Qemu. I updated my path in autoexec to: PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\TCC;C:\TCC\LIB;C:\TCC\INCLUDE I am getting two errors: library libtcc-32.a not found and undefined symbol _start Could you tell me what I am doing wrong? Thanks for reading-Patrick ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Documentation Suggestion
On 18-03-12 09:39 AM, Patrick wrote: On 18-03-12 09:27 AM, arn...@skeeve.com wrote: Patrick <patr...@spellingbeewinnars.org> wrote: Last night I tried again but this time I did not alter my bashrc but instead used ./configure disable-shared CC=tcc I guess TCC can't generate position independent code. I am having a lot more luck now and I had a great time last night compiling several projects. I use it on x86_64 Linux to generate shared objects all the time (the extensions in gawk). Is this on Linux or some other OS? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel Hi Arnold I am on Linux 64 bit. I realize that it can create shared code but could there be an issue with PIC ? When I go to compile the projects of others, I am having trouble without the --disable-shared flag but not without it. Could it be that other projects(ncurses for example) that use PIC by default but not when this flag is used? Thanks for responding to my post-Pat ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel Hi again Arnold I gave some false information. I just re-tested ncurses and it compiles fine with and without --disable-shared. However I tried to compile GnuCOBOL and libao and both will fail without --disabled-shared and compile with this flag. Thanks ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Documentation Suggestion
On 18-03-12 09:27 AM, arn...@skeeve.com wrote: Patrick <patr...@spellingbeewinnars.org> wrote: Last night I tried again but this time I did not alter my bashrc but instead used ./configure disable-shared CC=tcc I guess TCC can't generate position independent code. I am having a lot more luck now and I had a great time last night compiling several projects. I use it on x86_64 Linux to generate shared objects all the time (the extensions in gawk). Is this on Linux or some other OS? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel Hi Arnold I am on Linux 64 bit. I realize that it can create shared code but could there be an issue with PIC ? When I go to compile the projects of others, I am having trouble without the --disable-shared flag but not without it. Could it be that other projects(ncurses for example) that use PIC by default but not when this flag is used? Thanks for responding to my post-Pat ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Documentation Suggestion
Hi Everyone I tried TCC a few years ago. If I remember correctly I used something like CC=tcc in my bashrc. I wasn't able to compile anything but toy programs with it and I moved on. Last night I tried again but this time I did not alter my bashrc but instead used ./configure disable-shared CC=tcc I guess TCC can't generate position independent code. I am having a lot more luck now and I had a great time last night compiling several projects. If you think that others will benefit from this approach, perhaps it would be good to have in the documentation. I missed a few years of happiness with TCC ! -Pat ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Preprocessing issue?
Hi, I think I found an issue in the preprocessor of tcc.The following program: #define M_C2I(a, ...) a ## __VA_ARGS__ #define M_C(a, ...) M_C2I(a, __VA_ARGS__) #define M_C3I(a, b, ...)a ## b ## __VA_ARGS__ #define M_C3(a, b, ...) M_C3I(a ,b, __VA_ARGS__) #define M_RETI_ARG2(a, b, ...) b #define M_RET_ARG2(...) M_RETI_ARG2(__VA_ARGS__) #define M_RETI_ARG27(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,aa, ...)aa #define M_RET_ARG27(...)M_RETI_ARG27(__VA_ARGS__) #define M_TOBOOLI_0 1, 0, #define M_BOOL(x) M_RET_ARG2(M_C(M_TOBOOLI_, x), 1, useless) #define M_IFI_0(true_macro, ...)__VA_ARGS__ #define M_IFI_1(true_macro, ...)true_macro #define M_IF(c) M_C(M_IFI_, M_BOOL(c)) #define M_FLAT(...) __VA_ARGS__ #define M_INVI_01 #define M_INVI_10 #define M_INV(x)M_C(M_INVI_, x) #define M_ANDI_00 0 #define M_ANDI_01 0 #define M_ANDI_10 0 #define M_ANDI_11 1 #define M_AND(x,y) M_C3(M_ANDI_, x, y) #define M_ORI_000 #define M_ORI_011 #define M_ORI_101 #define M_ORI_111 #define M_OR(x,y) M_C3(M_ORI_, x, y) #define M_COMMA_P(...) M_RET_ARG27(__VA_ARGS__, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, useless) #define M_EMPTYI_DETECT(...)0, 1, #define M_EMPTYI_P_C1(...) M_COMMA_P(M_EMPTYI_DETECT __VA_ARGS__ () ) #define M_EMPTYI_P_C2(...) M_COMMA_P(M_EMPTYI_DETECT __VA_ARGS__) #define M_EMPTYI_P_C3(...) M_COMMA_P(__VA_ARGS__ () ) #define M_EMPTY_P(...) M_AND(M_EMPTYI_P_C1(__VA_ARGS__), M_INV(M_OR(M_OR(M_EMPTYI_P_C2(__VA_ARGS__), M_COMMA_P(__VA_ARGS__)),M_EMPTYI_P_C3(__VA_ARGS__ #define M_APPLY_FUNC2B(func, arg1, arg2)\ M_IF(M_EMPTY_P(arg2))(,func(arg1, arg2)) #define M_MAP2B_0(func, data, a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z,...) \ M_APPLY_FUNC2B(func, data, a) M_APPLY_FUNC2B(func, data, b) M_APPLY_FUNC2B(func, data, c) \ M_APPLY_FUNC2B(func, data, d) M_APPLY_FUNC2B(func, data, e) M_APPLY_FUNC2B(func, data, f) \ M_APPLY_FUNC2B(func, data, g) M_APPLY_FUNC2B(func, data, h) M_APPLY_FUNC2B(func, data, i) \ M_APPLY_FUNC2B(func, data, j) M_APPLY_FUNC2B(func, data, k) M_APPLY_FUNC2B(func, data, l) \ M_APPLY_FUNC2B(func, data, m) M_APPLY_FUNC2B(func, data, n) M_APPLY_FUNC2B(func, data, o) \ M_APPLY_FUNC2B(func, data, p) M_APPLY_FUNC2B(func, data, q) M_APPLY_FUNC2B(func, data, r) \ M_APPLY_FUNC2B(func, data, s) M_APPLY_FUNC2B(func, data, t) M_APPLY_FUNC2B(func, data, u) \ M_APPLY_FUNC2B(func, data, v) M_APPLY_FUNC2B(func, data, w) M_APPLY_FUNC2B(func, data, x) \ M_APPLY_FUNC2B(func, data, y) M_APPLY_FUNC2B(func, data, z) #define M_MAP2B(f, ...) M_MAP2B_0(f, __VA_ARGS__, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ) #define M_INIT_INIT(a) ,a, #define M_GET_METHOD(method, method_default, ...) \ M_RET_ARG2 (M_MAP2B(M_C, M_C3(M_, method, _), __VA_ARGS__), method_default,) #define M_TEST_METHOD_P(method, oplist) \ M_BOOL(M_GET_METHOD (method, 0, M_FLAT oplist)) #define TRUE 1 #define TEST1(n)\ M_IF(n)(ok,nok) #define TEST2(op) \ M_TEST_METHOD_P(INIT, op) #define TEST3(op) \ M_IF(M_TEST_METHOD_P(INIT, op))(ok, nok) #define KO(a) ((void)1) // test begins TEST1(TRUE) // ==> expect ok, get ok // First test with a token which is not a macro TEST2((INIT(ok)))// ==> expect 1, get 1 TEST3((INIT(ok)))// ==> expect ok, get ok // Then test with a token which is a macro, but should not be expanded. TEST2((INIT(KO)))// ==> expect 1, get 1 TEST3((INIT(KO)))// ==> expect ok, get "error: macro 'KO' used with too many args" produces an error "error: macro 'KO' used with too many args" whereas I don't expect the macro KO to be expanded and so no error reported. tested with tcc 9ed8b54f6cd2ebf1d5dc678ab2296e92ad85cd3e with the option '-E' TEST3 is the expanded concatenation of TEST1 & TEST2 Replacing the definition of TEST3(op) by #define TEST3(op) \ TEST1(TEST2(op)) will output the following code: ok 1 ok 1ok (with no space between the last '1' & 'ok') as if the content of TEST2((INIT(KO))) and TEST3((INIT(KO))) were concatenated, which is not was expected too. I wasn't able to reduce the test case any further. -- Regards, Patrick Pélissier ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Noob Questions about 64 bit systems
Hi Everyone Something is drawing me to TCC ! It has a lot of appeal to me. It was nice to read Charles Lohr's post yesterday with his testimony :) I am on a 64 bit system running Trisquel Linux. I added export CC=tcc in my .bashrc I have tried to compile other applications. Things aren't working. If I run configure, is it perhaps finding 64 bit packages that won't link properly with 32 bit TCC ? Is there a workaround? If I made folders /usr/tcc/include /usr/tcc/libs do you think I could compile dependencies first and then tell configure to look there? Do you think I am better off loading on a 32 bit computer? If you would like the errors I can post but they seem to be integer related such as make check failing with errors about type long etc.. Thanks for reading-Patrick ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc bootstrap
On Sunday 09 March 2014 17:12:11 Christian Jullien wrote: Hi all, This is just a question I'm doing for myself. Currently, when you do a ./configure; make you generate a tcc that is a gcc compiled program implementing a tcc compiler. So far so good. The challenge for a compiler is to compile itself. Long ago, you were able to bootstrap gcc with any decent C compiler. The process was the following: - use alien C to produce a subset of gcc (xgcc if I recall well) - use xgcc to compile a first working gcc - use this interim gcc to produce final gcc. Now the questions: - Why tcc remains a gcc compiled code? Not sure if there's any deep reason behind it - * tcc started as a self-compiling demonstrator * most people don't care (and even gcc often isn't 'properly' bootstrapped) * in between (iirc before the 0.9.26 release) tcc was not well handled and unlearned to build itself. Mostly because of Makefile stupidity calling gcc directly and such funny things * recent tcc can self-compile properly - Corollary, can we use this tcc binary on a machine gcc free? That depends on if it links to the libgcc bits. I think that's a configure option? - Do we want a tcc compiler compiled by tcc (an extra step can easily do that)? Upside: It's a good demonstration that tcc is functional (especially if you do the classical triple bootstrap and run the testsuite) Downside: Increases compile time (up to ... almost 5 seconds! ;) ), adds more complexity to the Makefiles, ... Maybe it would be useful as a Makefile target? Ok, using gcc -O3 you can generate a tcc that compiles faster any program than tcc compiled with itself. That is mildly funny, but not unexpected ... Have fun, Patrick ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
