<< Back to previous view

[PCC-420] PCC not working on linux x86_64 Created: 18/Apr/13  Updated: 20/Apr/14

Status: Closed
Project: pcc
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Susi Lehtola Assignee: Anders Magnusson
Resolution: Won't Fix Votes: 0


 Description   
I've already reported this on the mailing list, but I'm opening an official tracker here.

PCC does not produce working binaries on linux. Having compiled pcc with gcc, and trying to recompile pcc using itself results in

$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... pcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs. If you meant to cross compile, use `--host'.
See `config.log' for more details.

The relevant log entry is
configure:2888: checking whether the C compiler works
configure:2898: ./a.out
configure:2901: $? = 96
configure:2910: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

The same return value 96 is also seen for a simple hello world program, returning 0.

Using bisection, I have backtracked the issue. The procedure is:
1. download pcc and pcc-libs tarballs of the chosen date
2. compile pcc and pcc-libs with gcc
3. recompile pcc and pcc-libs with pcc (compiled with gcc)
4. recompile pcc and pcc-libs with pcc (compiled with pcc)

Results:

20120210 works
20120710 works

20120711 major internal compiler error, cc.c line 1422
20120713 major internal compiler error
20120717 major internal compiler error
20120725 major internal compiler error
20120801 major internal compiler error
20120804 major internal compiler error

20120806 ar: softfloat.o: No such file or directory

20120807 configure: error: cannot run C compiled programs.
20120808 fail
20120810 fail

20120910 fail,
pcc -I. -DTARGET_LITTLE_ENDIAN=1 -Dos_linux -isystem ../libpcc/include
-Iamd64 -Ilinux -I. -g -c cmpdi2.c
quad.h, line 134: redeclaration of __ashldi3
quad.h, line 135: redeclaration of __ashrdi3
quad.h, line 147: redeclaration of __lshrdi3
/usr/libexec/ccom terminated with status 1

20120110 fail
20121216 fail

So it would seem that the problem was introduced either in the
rework between 20120710 and 20120711, or in the fix of the resulting
compiler error.

When the compiler starts to work again in 20120807, configure fails
because the binaries produced by pcc (compiled with gcc) give out
the wrong error code.

 Comments   
Comment by Anders Magnusson [ 19/Apr/14 01:54 PM ]
I just installed on Fedora 20 and tested, and everything worked fine:
1: Fetch pcc, configure, make, make install
2: Fetch pcc-libs, configure, make, make install
3: Recompile pcc with itself, install in a new location
4: Recompile pcc once again with previous pcc. No problem.

So, I have no clue how to reproduce this problem...?
Comment by Susi Lehtola [ 19/Apr/14 05:48 PM ]
Well then, looks like this is something that only appears with the Fedora specific compiler flags.

For example, on Fedora 20 x86_64, the default flags are
$ rpm --eval %optflags
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic


which reveals
make[1]: Entering directory `/home/lehtolj5/fedora/pcc/master/pcc-20140419/pcc-libs/libsoftfloat'
gcc -DSOFTFLOAT_FOR_GCC -I. -I./arch/amd64 -isystem ../libpcc/include -Iamd64 -Ilinux -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c bits64/softfloat.c
bits64/softfloat.c: In function 'subFloat32Sigs':
bits64/softfloat.c:1755:56: warning: comparison between 'fp_rnd' and 'enum <anonymous>' [-Wenum-compare]
     return packFloat32( float_rounding_mode == float_round_down, 0, 0 );
                                                        ^
bits64/softfloat.c: In function 'subFloat64Sigs':
bits64/softfloat.c:2721:56: warning: comparison between 'fp_rnd' and 'enum <anonymous>' [-Wenum-compare]
     return packFloat64( float_rounding_mode == float_round_down, 0, 0 );
                                                        ^

and


switches -m64 -mtune=generic -c unwind.c
gcc -I. -DTARGET_LITTLE_ENDIAN=1 -Dos_linux -isystem ../libpcc/include -Iamd64 -Ilinux -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c ssp.c
ssp.c: In function '__stack_chk_fail':
ssp.c:82:7: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
  write(2, __progname, strlen(__progname));
       ^
ssp.c:83:7: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
  write(2, msg, sizeof(msg) - 1);
       ^

and then fails with


gcc -Iamd64 -Ilinux -I. -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o crtbegin.o crtbegin.c
crtbegin.c: In function '__ctors':
crtbegin.c:69:28: warning: array subscript is above array bounds [-Warray-bounds]
   for (i = 1; __CTOR_LIST__[i]; i++)
                            ^
gcc -Iamd64 -Ilinux -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o crtend.o crtend.c
gcc -Iamd64 -Ilinux -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpic -c -o crtbeginS.o crtbegin.c
crtbegin.c: In function '__do_global_ctors_aux':
crtbegin.c:69:28: warning: array subscript is above array bounds [-Warray-bounds]
   for (i = 1; __CTOR_LIST__[i]; i++)
                            ^
{standard input}: Assembler messages:
{standard input}:247: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:651: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:656: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:657: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:658: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:659: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:660: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:661: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:664: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:665: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:666: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:667: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
make[2]: *** [crtbeginS.o] Error 1
make[2]: Leaving directory `/home/lehtolj5/fedora/pcc/master/pcc-20140419/pcc-libs/csu/linux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/lehtolj5/fedora/pcc/master/pcc-20140419/pcc-libs/csu'
make: *** [all] Error 2
Comment by Susi Lehtola [ 19/Apr/14 06:06 PM ]
OK, the above error was the use of the -g flag with crtbegin.c; the makefile seems to have been changed in the recent years, but I was able to adapt the old workaround from 5 years ago.

Now, I have found that with -O0 or -O1 the binary produced by GCC works

$ pcc x.c
$ ./a.out
Hello
$ echo $?
0

but with -O2 it doesn't work:

$ pcc x.c
$ ./a.out
Hello
$ echo $?
96

and so you can't recompile pcc with itself.
Comment by Anders Magnusson [ 20/Apr/14 05:29 AM ]
Ok, if I summarize this:
- Compiling pcc-libs with gcc -O2 will make resulting pcc binaries unusable.

Since the crt files can be very compiler-specific I would not recommend to compile them with something else than their native compiler, but I can take a look at why it fails with gcc. It may be that it is unfixable since we are fiddling around with sections.
Comment by Anders Magnusson [ 20/Apr/14 06:19 PM ]
The problem is that gcc with -O2 inlines a function into the .fini section, which is not OK to do. .fini shall only contain a call to a function.
Comment by Susi Lehtola [ 20/Apr/14 08:48 PM ]
Thanks! Adding -fno-inline to the pcc-libs/csu/linux makefile fixed the problems.

I was able to bootstrap pcc with itself; I checked three sequential compiles, so it seems to work properly.
Comment by Anders Magnusson [ 20/Apr/14 10:20 PM ]
Ok, good, I'll close the ticket.

I would recommend though to use pcc to compile these files in the future, since they are compiler-specific and it is good not to rely on the behaviour on other compilers.
Generated at Sat Dec 20 16:50:55 CET 2014 using JIRA Enterprise Edition, Version: 3.13.1-#333.