[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

------- 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