This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 10 Nov 2014 08:45:05 +0000
- Subject: [Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
- Auto-submitted: auto-generated
- References: <bug-62018-4 at http dot gcc dot gnu dot org/bugzilla/>
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.