[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) |
Hi,
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 :)
Ciao,
Michael.