Bug 41684

Confirmed. I've built binutils-2.19.1 and binutils-2.19.92 with gcc-4.3.4 (plus loads of well-tested fixes) and gcc-4.4.1 vanilla on an armv5tel-linux-gnueabi machine, and for both binutils versions using gcc-4.4.1 caused the 7 new testsuite failures you listed.

A binary search through the gcc-4.4 snapshots has identified 4.4-20080822 as the last good(*) snapshot and 4.4-20080829 as the first bad one.

(*) 4.4 snapshots around this time also cause the following failures:

Running /tmp/binutils-2.19.92/ld/testsuite/ld-arm/arm-elf.exp ...
FAIL: BE8 Mapping Symbols
FAIL: Thumb-ARM farcall (BE8)
FAIL: Thumb-ARM farcall (BE)

but they seem to be gone with gcc-4.4.1 so I'm ignoring them.

138206          2008-07-28      OK
                2008-11-16      FAIL (gcc-snapshot build)

that looks consistent with my test builds; with the 2008-07-28 build the ld testsuite passes without failures

> A binary search through the gcc-4.4 snapshots has identified 4.4-20080822 as
> the last good(*) snapshot and 4.4-20080829 as the first bad one.

build in between fail for me with:
/opt/doko/gcc/139572/./gcc/xgcc -B/opt/doko/gcc/139572/./gcc/ -B/opt/doko/gcc/install-139572/arm-linux-gnueabi/bin/ -B/opt/doko/gcc/install-139572/arm-linux-gnueabi/lib/ -isystem /opt/doko/gcc/install-139572/arm-linux-gnueabi/include -isystem /opt/doko/gcc/install-139572/arm-linux-gnueabi/sys-include -c -DHAVE_CONFIG_H -g -O2   -I. -I../../../gcc-4_4-branch/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../../gcc-4_4-branch/libiberty/fibheap.c -o fibheap.o
../../../gcc-4_4-branch/libiberty/fibheap.c:1: warning: target CPU does not support interworking
../../../gcc-4_4-branch/libiberty/fibheap.c: In function 'fibheap_union':
../../../gcc-4_4-branch/libiberty/fibheap.c:151: warning: implicit declaration of function 'free'
../../../gcc-4_4-branch/libiberty/fibheap.c:151: warning: incompatible implicit declaration of built-in function 'free'
../../../gcc-4_4-branch/libiberty/fibheap.c:156: warning: incompatible implicit declaration of built-in function 'free'
../../../gcc-4_4-branch/libiberty/fibheap.c:172: warning: incompatible implicit declaration of built-in function 'free'
../../../gcc-4_4-branch/libiberty/fibheap.c: In function 'fibheap_extract_min':
../../../gcc-4_4-branch/libiberty/fibheap.c:190: warning: incompatible implicit declaration of built-in function 'free'
../../../gcc-4_4-branch/libiberty/fibheap.c: In function 'fibheap_delete_node':
../../../gcc-4_4-branch/libiberty/fibheap.c:258: error: 'LONG_MIN' undeclared (first use in this function)
../../../gcc-4_4-branch/libiberty/fibheap.c:258: error: (Each undeclared identifier is reported only once
../../../gcc-4_4-branch/libiberty/fibheap.c:258: error: for each function it appears in.)
../../../gcc-4_4-branch/libiberty/fibheap.c: In function 'fibheap_delete':
../../../gcc-4_4-branch/libiberty/fibheap.c:269: warning: incompatible implicit declaration of built-in function 'free'
../../../gcc-4_4-branch/libiberty/fibheap.c: In function 'fibheap_consolidate':
../../../gcc-4_4-branch/libiberty/fibheap.c:360: warning: implicit declaration of function 'memset'
../../../gcc-4_4-branch/libiberty/fibheap.c:360: warning: incompatible implicit declaration of built-in function 'memset'
make[2]: *** [fibheap.o] Error 1
make[2]: Leaving directory `/opt/doko/gcc/139572/arm-linux-gnueabi/libiberty'
make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory `/opt/doko/gcc/139572'
make: *** [all] Error 2

looking at the interval there a three arm specific commits:

 2008-08-23  Paolo Carlini  <paolo.carlini@oracle.com>
 2008-08-23  Sebastian Redl <sebastian.redl@getdesigned.at>
  - r139509: exception propagation support

 2008-08-26  Vladimir Makarov  <vmakarov@redhat.com>
  - r139590: IRA merge

 2008-08-26  Paul Brook   <paul@codesourcery.com>
  - r139603, r139599: arm vfp fixes

A bisection has identified revision 139725 as the origin of this regression.

(In reply to comment #6)
> A bisection has identified revision 139725 as the origin of this regression.

That revision added support for -fsection-anchors on arm and enabled it by default at -O1 and above. Compiling with -fno-section-anchors eliminates the regressions in the binutils ld testsuite (tested with 4.4.1 and 4.5-20091008).

I did a test with the range of anchor offsets reduced from [-4088,+4095] to a tiny [-120,+127], which should work with any arm instruction, but that did not eliminate the regressions.

I'm currently bootstrapping and testing a patch which disable section anchors on arm. It will be interesting to see if it fixes any testsuite failures.

Created attachment 18799 [details]
kludge to disable section anchors on arm for gcc-4.4

(In reply to comment #7)
> (In reply to comment #6)
> > A bisection has identified revision 139725 as the origin of this regression.
> 
> That revision added support for -fsection-anchors on arm and enabled it by
> default at -O1 and above. Compiling with -fno-section-anchors eliminates the
> regressions in the binutils ld testsuite (tested with 4.4.1 and 4.5-20091008).
> 
> I did a test with the range of anchor offsets reduced from [-4088,+4095] to a
> tiny [-120,+127], which should work with any arm instruction, but that did not
> eliminate the regressions.
> 
> I'm currently bootstrapping and testing a patch which disable section anchors
> on arm. It will be interesting to see if it fixes any testsuite failures.
> 


I would rather find out why the middle end function use_anchor_for_symbol doesn't reject the symbol for section anchors and fix this appropriately by either specifying appropriate binds_local_p  or the use_anchor_for_symbol handler appropriately. 

(In reply to comment #7)
> I'm currently bootstrapping and testing a patch which disable section anchors
> on arm. It will be interesting to see if it fixes any testsuite failures.

Done. It caused no new failures but fixed several objc ones:

@@ -339,34 +339,14 @@
 Running /home/mikpe/gcc-4.4/gcc/testsuite/objc/compile/compile.exp ...
 Running /home/mikpe/gcc-4.4/gcc/testsuite/objc/execute/exceptions/exceptions.exp ...
 Running /home/mikpe/gcc-4.4/gcc/testsuite/objc/execute/execute.exp ...
-FAIL: objc/execute/class-13.m compilation,  -O1 -fgnu-runtime
-FAIL: objc/execute/class-13.m compilation,  -O2 -fgnu-runtime
-FAIL: objc/execute/class-13.m compilation,  -O3 -fomit-frame-pointer -fgnu-runtime
-FAIL: objc/execute/class-13.m compilation,  -O3 -g -fgnu-runtime
-FAIL: objc/execute/class-13.m compilation,  -Os -fgnu-runtime
-FAIL: objc/execute/class-6.m compilation,  -O1 -fgnu-runtime
-FAIL: objc/execute/class-6.m compilation,  -O2 -fgnu-runtime
-FAIL: objc/execute/class-6.m compilation,  -O3 -fomit-frame-pointer -fgnu-runtime
-FAIL: objc/execute/class-6.m compilation,  -O3 -g -fgnu-runtime
-FAIL: objc/execute/class-6.m compilation,  -Os -fgnu-runtime
 FAIL: objc/execute/forward-1.m execution,  -O0 -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -O1 -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -O2 -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -O3 -fomit-frame-pointer -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -O3 -fomit-frame-pointer -funroll-loops -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -O3 -g -fgnu-runtime
-FAIL: objc/execute/forward-1.m compilation,  -Os -fgnu-runtime
-FAIL: objc/execute/object_is_class.m compilation,  -O1 -fgnu-runtime
-FAIL: objc/execute/object_is_class.m compilation,  -O2 -fgnu-runtime
-FAIL: objc/execute/object_is_class.m compilation,  -O3 -fomit-frame-pointer -fgnu-runtime
-FAIL: objc/execute/object_is_class.m compilation,  -O3 -g -fgnu-runtime
-FAIL: objc/execute/object_is_class.m compilation,  -Os -fgnu-runtime
-FAIL: objc/execute/object_is_meta_class.m compilation,  -O1 -fgnu-runtime
-FAIL: objc/execute/object_is_meta_class.m compilation,  -O2 -fgnu-runtime
-FAIL: objc/execute/object_is_meta_class.m compilation,  -O3 -fomit-frame-pointer -fgnu-runtime
-FAIL: objc/execute/object_is_meta_class.m compilation,  -O3 -g -fgnu-runtime
-FAIL: objc/execute/object_is_meta_class.m compilation,  -Os -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -O1 -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -O2 -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -O3 -fomit-frame-pointer -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -O3 -fomit-frame-pointer -funroll-loops -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -O3 -g -fgnu-runtime
+FAIL: objc/execute/forward-1.m execution,  -Os -fgnu-runtime
 Running /home/mikpe/gcc-4.4/gcc/testsuite/objc.dg/dg.exp ...
 Running /home/mikpe/gcc-4.4/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp ...
 Running /home/mikpe/gcc-4.4/gcc/testsuite/objc.dg/pch/pch.exp ...
@@ -374,10 +354,9 @@
 
                === objc Summary ===
 
-# of expected passes           1819
-# of unexpected failures       28
+# of expected passes           1866
+# of unexpected failures       8
 # of expected failures         7
-# of unresolved testcases      27
 # of unsupported tests         24

I had hoped that it might fix some small C or C++ test case which could then be used for debugging section anchors, but no such luck.

(In reply to comment #10)
> (In reply to comment #7)
> > I'm currently bootstrapping and testing a patch which disable section anchors
> > on arm. It will be interesting to see if it fixes any testsuite failures.
> 
> Done. It caused no new failures but fixed several objc ones:

Did it fix your binutils testsuite failures ? 

(In reply to comment #11)
> Did it fix your binutils testsuite failures ? 

Yes, it did.

(In reply to comment #0)
> when binutils 2.20 branch is built with gcc-4.4 branch or trunk, I see the
> following test failures in the ld testsuite. Checked with gcc-4.4 from
> debian/testing, debian/unstable and ubuntu/karmic, and gcc-snapshot (4.5
> 20091010) from debian/unstable.
> 
> Running
> /home/doko/tmp/binutils-2.19.91.20091006/ld/testsuite/ld-elfvsb/elfvsb.exp ...
> FAIL: visibility (hidden_normal) (non PIC)
> FAIL: visibility (hidden_normal) (non PIC, load offset)
> FAIL: visibility (normal) (non PIC)
> FAIL: visibility (normal) (non PIC, load offset)
> Running
> /home/doko/tmp/binutils-2.19.91.20091006/ld/testsuite/ld-shared/shared.exp ...
> FAIL: shared (non PIC)
> FAIL: shared (non PIC, load offset)
> FAIL: shared (PIC main, non PIC so)

 When generating code that is not position independent, the compiler is entitled to enable optimizations that don't retain the property of symbol pre-emption that is possible with shared libraries and position independent code. Section anchors is one optimization that doesn't retain symbol pre-emptibility in shared libraries and hence is disabled when generating PIC code. All these failures are because the tests are trying to create non-PIC .so's with section anchors turned on.

The tests need to be fixed with respect to section anchors by building them with -fno-section-anchors for the arm-linux-gnueabi port.


The Objective C testsuite failures should be fixed by disabling section anchors in the objective C and C++ frontend and not by disabling this in the backend. 

Look at the mail thread here for reference. 

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02194.html

However that is a subject of a separate bug report, though these failures might be related to PR41617. Hence this is an INVALID bug as far as GCC is concerned and hence marking it so.

cheers
Ramana