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.
