This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 9 Nov 2014, fxcoudert at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
> 
> Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Keywords|                            |wrong-code
>              Target|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
>    Last reconfirmed|2014-08-05 00:00:00         |2014-11-9
>           Component|middle-end                  |target
>                Host|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
>               Build|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
> 
> --- Comment #9 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> Some more debugging, and finally a victory: I understand what happens. But I
> don't know how to fix it.
> 
> 0. With my testcase from comment #8, compiling with -static-libgcc makes the
> executable have the desired behavior (abort), but compiling without it (or with
> -shared-libgcc) makes it not abort.
> 
> 1. Yet forcing to compile with the "shared" object file (_addvsi3_s.o) leads to
> correct result (abort). So, it's not a miscomputation.
> 
> 2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows that
> it's loading the correct libgcc_s:
> 
>   dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out
>   dyld: loaded: /usr/lib/libSystem.B.dylib
>   dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib
> 
> 
> 3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does not
> get pulled from libgcc_s.1.dylib, as we'd like, but from the system's
> libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol
> for backward compatibility reasons):
> 
>   dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3,
> *0x10D212010 = 0x7FFF9158BF67
> 
> 
> 
> 
> 4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by
> saying "DYLD_FORCE_FLAT_NAMESPACE=y
> DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib", makes the
> executable have the expected behavior (aborts).
> 
> -----------------------------------
> 
> Conclusion: it's really a darwin bug. We need to have symbols taken from our
> own libgcc override those from the system's libcompiler_rt (which is itself
> pulled from libSystem, if I understand correctly). Any idea how we achieve
> that?

Simply get libcompiler_rt folks to fix their code?  You should be
able to file a bug somewhere.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]