[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

["fxcoudert at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #11 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #10)
> ld64 should pull the symbol from the first place that mentions it on the
> link line.  It should place the two-level namespace information in the exe
> so that the symbol is resolved from the correct place at runtime.
> 
> Can you confirm this?

Linking simply with "gcc a.c -ftrapv" calls collect2 with (removed the -L
options for clarity):

  collect2 -dynamic -arch x86_64 -macosx_version_min 10.10.0
-weak_reference_mismatches non-weak -o a.out a.o -no_compact_unwind -lSystem
-lgcc_ext.10.5 -lgcc -lSystem -v

and in turn ld with:

  ld -dynamic -arch x86_64 -macosx_version_min 10.10.0
-weak_reference_mismatches non-weak -o a.out a.o -no_compact_unwind -lSystem
-lgcc_ext.10.5 -lgcc -lSystem -v

If I manually call collect2 with "-lgcc_ext.10.5 -lgcc -lSystem" instead of
"-lSystem -lgcc_ext.10.5 -lgcc -lSystem" (removing the first "-lSystem"), then
the executable aborts it should.


So:

> (a) more fiddling with library ordering in the specs

It so happens that gcc/config/darwin10.h says: "Fix PR47558 by linking against
libSystem ahead of libgcc_ext."
So it looks like this is going to be fun!