------- Comment #75 from hp at gcc dot gnu dot org 2008-08-31 20:33 -------
(In reply to comment #74)
> > Patch, take 6.
>
> This one is a significant improvement. In the C testsuite, I'm
> seeing a few failures like this one:
>
> Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
> /te
> st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c -O3
> -fwhole-
> program -combine -fipa-type-escape -fprofile-generate -lm -o
> /test/gnu/gcc/ob
> jdir/gcc/testsuite/gcc/w_prof_global_array.x01 (timeout = 300)
> /usr/ccs/bin/ld: Unsatisfied symbols:
> _GLOBAL__FI_w_prof_global_array_x01 (first referenced in +init option)
> (code)
> _GLOBAL__FD_w_prof_global_array_x01 (first referenced in +fini option)
> (code)
> collect2: ld returned 1 exit status
Is this really a regression?
What unpatched revision did you use as a baseline?
When I compile that testcase, edited because of the stdlib include as follows:
--- w_prof_global_array.c 2008-01-03 16:12:42.000000000 +0100
+++ /home/hp/wp.c 2008-08-31 21:09:44.000000000 +0200
@@ -1,4 +1,4 @@
-#include <stdlib.h>
+extern void abort(void);
typedef struct
{
int a;
I don't see a difference unpatched/patched at revision 139233 in the generated
assembly code, compiling with:
./xgcc -B./ -S ~/wp.c -o wp.s -O3 -fwhole-program -combine -fipa-type-escape
-fprofile-generate
(and no, adding "__attribute__ ((__noreturn__))" still makes no difference.)
> Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
> -B/test/gnu/
> gcc/objdir/gcc/testsuite/g++/../../
> /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja
> /g++.other/static14.C -nostdinc++
> -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/
> libstdc++-v3/include/hppa2.0w-hp-hpux11.11
> -I/test/gnu/gcc/objdir/hppa2.0w-hp-hp
> ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
> -I/test/
> gnu/gcc/gcc/libstdc++-v3/include/backward
> -I/test/gnu/gcc/gcc/libstdc++-v3/tests
> uite/util -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long
> -L/test/
> gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
> -L/test/gnu/gcc/o
> bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
> -L/test/gnu/gcc/objdir/hppa
> 2.0w-hp-hpux11.11/./libiberty -lm -o static14.exe (timeout = 300)
> /usr/ccs/bin/ld: Unsatisfied symbols:
> basic_string::~basic_string() (first referenced in /var/tmp//ccI3Feaf.o)
> (code)
> Side::name()::sname (first referenced in /var/tmp//ccI3Feaf.o) (data)
> collect2: ld returned 1 exit status
> compiler exited with status 1
No difference here either "-ansi -pedantic-errors -Wno-long-long".
Weirdness: I see references in the generated code to
basic_string::~basic_string() and Side::name()::sname, and that generated code
isn't there for cris-elf or native. Ditto static20.C
Maybe I'd see a difference if I force weak support?
Let me check...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
