[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] building older gcc with tcc?

From: Michael Matz
Subject: Re: [Tinycc-devel] building older gcc with tcc?
Date: Sat, 27 May 2017 19:10:07 +0200 (CEST)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)


On Sat, 27 May 2017, address@hidden wrote:

I would like to build an older version of the gcc compiler using tcc (then use that to build newer gcc's). On this page <https://en.wikipedia.org/wiki/Tiny_C_Compiler#Uses> it says that tcc was used to build gcc in the past.

I did that once in 2012 with gcc 4.x, 5<=x<=7 (don't remember exactly which) on x86_64. At the time I had to fix a couple bugs in tcc to make this work. That obviously regressed since then.

I tried using the latest http://repo.or.cz/tinycc.git to build gcc 4.7.0 (one of the latest C versions before it was rewritten in C++) like so:

MAKEINFO=missing CC=tcc CFLAGS='-I/usr/include/x86_64-linux-gnu/' PCC=tcc ./configure --enable-languages=c,c++ --disable-multilib --prefix=$HOME/gcc-out

but I got an error:

../.././libgcc/libgcc2.c: In function ‘__negti2’:
../.././libgcc/libgcc2.c:73:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

this seems to be a bug in a program 'xgcc' that was built by tcc

Rather it seems that cc1 was miscompiled. Is the above in stage1 or later? If stage1 then tcc miscompiled something in cc1 fairly directly, if later then tcc miscompiled cc1 in a way that it somewhat works but ultimately miscompiles itself. Those miscompiles tend to be difficult to track down; you'll have to basically bisect which .o file is miscompiled (by compiling parts of them with a known-good compiler or known-good options, and the other parts with known-bad compiler/options), and then either doing the same for the individual functions in that file, or by otherwise staring at the disassembly for both variants.

If the above is stage1 then it might be a bit easier, namely when the seg fault above happens near the place where the miscompile occurs (and not somewhere far away just causing some internal data structures to be wrong leading to the segfault much later). So, you'd have to start debugging the segfaulting cc1 (adding -v to the failing command will show you how it's invoked) and see of anything obvious pops up that doesn't match the source code.

A still different way would be to see if any tcc version of the past was behaving correctly. If you find one you can also bisect between that and current mob to find which patch lead to breakage, and from there find the miscompilation easier.

Obviously all of the above requires non-trivial amounts of work :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]