Issue Details (XML | Word | Printable)

Key: PCC-420
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Anders Magnusson
Reporter: Susi Lehtola
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
pcc

PCC not working on linux x86_64

Created: 18/Apr/13 06:38 PM   Updated: 20/Apr/14 10:20 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None


 Description  « Hide
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.

 All   Comments   Change History      Sort Order: Descending order - Click to sort in ascending order
Anders Magnusson added a comment - 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.

Susi Lehtola added a comment - 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.

Anders Magnusson added a comment - 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.

Anders Magnusson added a comment - 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.

Susi Lehtola added a comment - 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.

Susi Lehtola added a comment - 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

Anders Magnusson added a comment - 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...?