Executing on host: /home2/dave/gcc-4.6/objdir/gcc/xgcc -B/home2/dave/gcc-4.6/obj dir/gcc/ /home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20 010124-1.c /home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/ 20010124-1-lib.c /home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/bui ltins/lib/main.c -w -O2 -flto -lm -o /home2/dave/gcc-4.6/objdir/gcc/testsu ite/gcc/20010124-1.x7 (timeout = 300) PASS: gcc.c-torture/execute/builtins/20010124-1.c compilation, -O2 -flto Setting LD_LIBRARY_PATH to :/home2/dave/gcc-4.6/objdir/gcc::/home2/dave/gcc-4.6/ objdir/gcc:/home2/dave/gcc-4.6/objdir/hppa-linux/libstdc++-v3/src/.libs:/home2/d ave/gcc-4.6/objdir/hppa-linux/libmudflap/.libs:/home2/dave/gcc-4.6/objdir/hppa-l inux/libssp/.libs:/home2/dave/gcc-4.6/objdir/hppa-linux/libgomp/.libs:/home2/dav e/gcc-4.6/objdir/./gcc:/home2/dave/gcc-4.6/objdir/./prev-gcc FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution, -O2 -flto This might be a regression. Program fails because main_test function is replaced by millicode function $$dyncall from milli.S: (gdb) r Starting program: /home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/20010124-1.x6g Breakpoint 1, main_test () at ../../../gcc/libgcc/../gcc/config/pa/milli64.S:219 219 bb,>=,n %r22,30,LREF(1) ; branch if not plabel address (gdb) disass Dump of assembler code for function main_test: => 0x00010544 <+0>: bb,>=,n r22,1e,0x10554 <main_test+16> 0x00010548 <+4>: depwi 0,31,2,r22 0x0001054c <+8>: ldw 4(r22),r19 0x00010550 <+12>: ldw 0(r22),r22 0x00010554 <+16>: bv r0(r22) 0x00010558 <+20>: stw rp,-18(sp) End of assembler dump.
Why has main_test disappeared?
dave@gsyprf11:~/gcc-4.6/objdir/gcc/testsuite/gcc$ less 20010124-1.res 3 20010124-1.o 3 70 e5ddcfb3 PREEMPTED_IR main_test 76 e5ddcfb3 PREEMPTED_IR g 101 e5ddcfb3 PREEMPTED_IR f 20010124-1-lib.o 3 104 af7ae83d PREVAILING_DEF_IRONLY f 118 af7ae83d PREVAILING_DEF_IRONLY g 144 af7ae83d PREEMPTED_IR inside_main main.o 3 70 bb83b83f PREVAILING_DEF main 76 bb83b83f PREVAILING_DEF_IRONLY main_test 79 bb83b83f PREVAILING_DEF_IRONLY inside_main
(In reply to comment #2) > dave@gsyprf11:~/gcc-4.6/objdir/gcc/testsuite/gcc$ less 20010124-1.res > 3 > 20010124-1.o 3 > 70 e5ddcfb3 PREEMPTED_IR main_test > 76 e5ddcfb3 PREEMPTED_IR g > 101 e5ddcfb3 PREEMPTED_IR f > 20010124-1-lib.o 3 > 104 af7ae83d PREVAILING_DEF_IRONLY f > 118 af7ae83d PREVAILING_DEF_IRONLY g > 144 af7ae83d PREEMPTED_IR inside_main > main.o 3 > 70 bb83b83f PREVAILING_DEF main > 76 bb83b83f PREVAILING_DEF_IRONLY main_test > 79 bb83b83f PREVAILING_DEF_IRONLY inside_main Hum - it has found a definition of main_test in main.o(!?). Can't see such in its source. It also misses 20010124-1.c memcpy PREVAILING_DEF[_IRONLY]. Maybe that one "shifts" into the other unit as a new function? Weird. I suppose you are using GNU ld, right? On trunk x86_64 with stock binutils 2.21 I get > cat 20010124-1.res 3 20010124-1.o 3 79 2651d4ed PREVAILING_DEF_IRONLY main_test 85 2651d4ed RESOLVED_IR g 110 2651d4ed RESOLVED_IR f 20010124-1-lib.o 3 113 f6a75653 PREVAILING_DEF_IRONLY f 127 f6a75653 PREVAILING_DEF_IRONLY g 153 f6a75653 RESOLVED_IR inside_main main.o 3 79 2cccb08f PREVAILING_DEF main 85 2cccb08f RESOLVED_IR main_test 88 2cccb08f PREVAILING_DEF_IRONLY inside_main thus, memcpy is also missing but at least main_test is correctly used from 20010124-1.o. Thus - can you tell us your exact GNU ld version and maybe debug what is the lto_symtab contents we generate (there is a lto-plugin/lto-symtab.c program, not sure if it still works ...)
> I suppose you are using GNU ld, right? Yes (gold has not been ported). > On trunk x86_64 with stock binutils 2.21 I get > > > cat 20010124-1.res > 3 > 20010124-1.o 3 > 79 2651d4ed PREVAILING_DEF_IRONLY main_test > 85 2651d4ed RESOLVED_IR g > 110 2651d4ed RESOLVED_IR f > 20010124-1-lib.o 3 > 113 f6a75653 PREVAILING_DEF_IRONLY f > 127 f6a75653 PREVAILING_DEF_IRONLY g > 153 f6a75653 RESOLVED_IR inside_main > main.o 3 > 79 2cccb08f PREVAILING_DEF main > 85 2cccb08f RESOLVED_IR main_test > 88 2cccb08f PREVAILING_DEF_IRONLY inside_main > > thus, memcpy is also missing but at least main_test is correctly > used from 20010124-1.o. > > Thus - can you tell us your exact GNU ld version and maybe debug > what is the lto_symtab contents we generate (there is a lto-plugin/lto-symtab.c > program, not sure if it still works ...) It has been rebuilt a number of times recently. Last night's test run still shows the bug and it used: dave@gsyprf11:~/gcc-4.6/objdir$ ld --version GNU ld (GNU Binutils) 2.21.51.20110116 I tried to do a build without plugin support, but it seems there is a ld configure bug and plugin support can't be disabled. With older versions, I think plugin support had to be explicitly enabled (default was no). I'll try to debug the lto_symtab contents tonight. Dave
> thus, memcpy is also missing but at least main_test is correctly > used from 20010124-1.o. memcpy is missing due to hack eliminating all builtins from being output. We discussed this few times. Honza
Is hpux an ELF target? GNU LD plugin implementation contains some hackery to chose proper PREEMPTED/RESOLVED/etc values. Perhaps it is broken on non-elfs. In any case I will prepare patch to turn those aborts into fatal errors with some informative info. We shold not ICE (at least at every occasion) when we are fed with wrong resolution table.
Created attachment 23010 [details] main.c.000i.cgraph The build entry was wrong. hppa-unknown-linux-gnu target is elf and uses standard binutils tools.
Attached .cgraph files.
Created attachment 23011 [details] 20010124-1.c.000i.cgraph
Created attachment 23012 [details] 20010124-1-lib.c.000i.cgraph
Created attachment 23013 [details] 20010124-1.x7.ltrans0.000i.cgraph
I could be wrong (reopen the bug if I turn out to be mistaken), but I'll bet this is the same as PR47274: the IR symtabs are being generated incorrectly in the source .o files. To confirm, run the failing command again with --save-temps, and look for the .gnu.lto_.symtab.* sections; if you see a lot of stuff like this: .stringz "Finside_main" .stringz "" .stringz "" .stringz "" .stringz "" (to be precise, if there are more than two NUL bytes trailing the name), then it's the same bug. *** This bug has been marked as a duplicate of bug 47274 ***