[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 #28 from howarth at bromo dot med.uc.edu --- (In reply to Iain Sandoe from comment #27) > 10.7+ - (albeit 10.7 is somewhat transitionary) > here we need to stop building the eh stuff into libgcc, we probably need to > split the emultls stuff into a crt. We might want to consider not having a > shared lib for the gcc crt at all here (i.e. do much like clang does with > the compiler-rt and just append a libgcc.a). The only reason we *need* a > dylib at present is the EH (which is unused for these systems) and emults > bits (which could be dealt with differently). I don't think that the > argument that the exes might grow by a few kb is terribly significant on > modern systems. > We should also consider what to do about the compact unwinder (which we currently disable by passing -no_compact_unwind to the LINK_GCC_C_SEQUENCE_SPEC in gcc/config/darwin10.h). I assume at some point, perhaps when the legacy libstdc++ support is removed from OS X, that the compatibility unwinder, which we currently use, will be fully deprecated.
[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 #27 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #25) > (In reply to Iain Sandoe from comment #23) > > 2. we have so many versions, different layouts and version-specific issues, > > that I think it's time to reorganise our GCC extensions library to meet > > these different requirements than to limp along with kludge after kludge. > > As a first step to achieving this, we should decide what targets we support > (building on, and compiling for via -mmacosx-version-min). Given the current > state of OS X versions, I see two options: > > a) We keep PowerPC, and thus drop support for 10.4 and earlier (since 10.5 > is the last OS X version to support ppc). This helps remove some old stuff > (I'll attach a work-in-progress patch). I have a patch in my Q that moves the only ppc-specific 10.4 stuff to a separate target fragment in libgcc/config/rs6000 - at that point, it becomes academic to the discussion on supporting old versions since it has 0 impact on work going forward. > b) We drop PowerPC, then it makes sense to drop support for 10.5 too. This > would really simplify things in term of specs and those various support/ext > libraries. > > Given that 10.5 and PowerPC have been vendor-unsupported for more than 3 > years at this point, that we don't have regular testing (and bootstrap on > those machines is quite slow), I'd say we should focus our energy on > providing newer compilers for the newer machines/OSes. I think we are (realistically) focussed on the newer versions - since we all have limited hardware resources. However, there's a bunch of perfectly function hardware out there that is more usable with older system installs. So I would suggest we > mark powerpc-darwin as obsolete in GCC 5, and remove it for GCC 6. (Or > maybe, we even skip the obsolete part and simply drop it?) The general approach here (as recommended by Mike) has been that we don't kill versions intentionally; having said that when stuff stops getting tested one can assume it's quite quickly broken. There's no work involved in "supporting" 10.2..10.4 since none of us making any attempt to keep them going (David Fang does still test releases on 10.4, for fink, but that's the only thing I know of). As for 10.5 - I have personally both ppc and x86 10.5 hardware in daily use ( and not just for compiler building ;) ) - these are machines which just don't have enough resources (or are ppc) to update further. I will continue to test (at a lower level) and fix stuff on ppc-darwin9 so long as the QuadG5 is still in use. Going forward - there are kind of three groupings: <= 10.4 [this possibly requires support for stubs etc.] It's highly debatable whether 10.4 is supportable without using odcctools (i.e. 10.5's assembler and linker) - so, again, I'm not going to worry about it. Someone sufficiently interested in making it work can put the effort in. 10.5/10.6 - These are the remaining two "gcc-based" systems and we can deal with them with existing procedures. Likely we should emulate the way that the system libgcc_s does the forwarding of EH stuff to libSystem as well (10.6). 10.5 has EH hassles that can only realistically be solved by replacing the /usr/lib/libgcc_s.dylib (but I think anyone sufficiently enthusiastic to work there, will be willing to do that). I intend to post onto github a suitable replacement lib - it seems that they will allow binaries there. 10.7+ - (albeit 10.7 is somewhat transitionary) here we need to stop building the eh stuff into libgcc, we probably need to split the emultls stuff into a crt. We might want to consider not having a shared lib for the gcc crt at all here (i.e. do much like clang does with the compiler-rt and just append a libgcc.a). The only reason we *need* a dylib at present is the EH (which is unused for these systems) and emults bits (which could be dealt with differently). I don't think that the argument that the exes might grow by a few kb is terribly significant on modern systems. It's not been the case so far in gcc-5 that the old systems have been the painful ones to keep flying ;) I'm not a fan of "supporting only N and N-1" that's one of the suckiest things about the vendor's tools. Maybe we should open an enhancement PR for "rationalising libgcc and crts across the darwin editions".
[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 #26 from Francois-Xavier Coudert --- Created attachment 34077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34077&action=edit Patch removing 10.4 and earlier support from our specs/driver
[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 #25 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #23) > 2. we have so many versions, different layouts and version-specific issues, > that I think it's time to reorganise our GCC extensions library to meet > these different requirements than to limp along with kludge after kludge. As a first step to achieving this, we should decide what targets we support (building on, and compiling for via -mmacosx-version-min). Given the current state of OS X versions, I see two options: a) We keep PowerPC, and thus drop support for 10.4 and earlier (since 10.5 is the last OS X version to support ppc). This helps remove some old stuff (I'll attach a work-in-progress patch). b) We drop PowerPC, then it makes sense to drop support for 10.5 too. This would really simplify things in term of specs and those various support/ext libraries. Given that 10.5 and PowerPC have been vendor-unsupported for more than 3 years at this point, that we don't have regular testing (and bootstrap on those machines is quite slow), I'd say we should focus our energy on providing newer compilers for the newer machines/OSes. So I would suggest we mark powerpc-darwin as obsolete in GCC 5, and remove it for GCC 6. (Or maybe, we even skip the obsolete part and simply drop it?) What do you guys think?
[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 #24 from howarth at bromo dot med.uc.edu --- I always thought the major reorganization would be forced whenever Apple finally fully deprecated the libgcc_s.10.5.dylib stub, the associated libgcc_s.10.4.dylib symlink pointing at libgcc_s.10.5.dylib and the libgcc_s.1.dylib symlink pointing at libSystem.B.dylib. I would imagine that will happen whenever Apple decides to completely remove the legacy libstdc++ support from OS X (which I would imagine is still a few OS releases away).
[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 #23 from Iain Sandoe --- My take is: 1. It's good we have an upstream patch - if it percolates through that's one less thing to worry about - although (of course) that will never realistically be available historically. 2. we have so many versions, different layouts and version-specific issues, that I think it's time to reorganise our GCC extensions library to meet these different requirements than to limp along with kludge after kludge. (temporary fixes might be needed, of course, while we figure out a better layout for the general case).
[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 #22 from howarth at bromo dot med.uc.edu --- (In reply to Francois-Xavier Coudert from comment #21) > True, we could also follow this approach again > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c55), but it's more of a > hack really. There isn't any notations upstream that indicate that original problem with inaccurate results from ___divdc3 was fixed in compiler-rt... http://llvm.org/bugs/show_bug.cgi?id=9150
[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 #21 from Francois-Xavier Coudert --- True, we could also follow this approach again (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c55), but it's more of a hack really.
[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 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #20 from howarth at bromo dot med.uc.edu --- Don't forget, for the historical record, that the original attempt to work around such broken compiler-rt calls was discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333.
[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 #19 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #17) > if it's part of compiler-rt we can just post a patch on llvm-commits and > that will eventually percolate through to the system. I've opened an LLVM PR and attached a patch here: http://llvm.org/bugs/show_bug.cgi?id=21518
[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 #18 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #17) > if it's part of compiler-rt we can just post a patch on llvm-commits and > that will eventually percolate through to the system. It is part of compiler-rt (I mentioned libSystem because libSystem is the one pulling libcompiler-rt.dylib into action). I'll prepare a patch for it, but now the LLVM website is down.
[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 #17 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #16) > (In reply to rguent...@suse.de from comment #15) > > Your example directly calling __addvsi3 should suffice for that. > > I've filed it (radar #18924081), but I don't expect them to fix anything, > because it is an undocumented internal function, supported for backward > compatibility. if it's part of compiler-rt we can just post a patch on llvm-commits and that will eventually percolate through to the system. If it's part of libSystem, then I agree .. they might elect to preserve the status quo. We can still find a way to fix this for GCC tho.
[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 #16 from Francois-Xavier Coudert --- (In reply to rguent...@suse.de from comment #15) > Your example directly calling __addvsi3 should suffice for that. I've filed it (radar #18924081), but I don't expect them to fix anything, because it is an undocumented internal function, supported for backward compatibility.
[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 #15 from rguenther at suse dot de --- On Mon, 10 Nov 2014, fxcoudert at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 > > --- Comment #14 from Francois-Xavier Coudert > --- > (In reply to rguent...@suse.de from comment #12) > > So I bet apple GCC 4.2 is affected as well - not sure if LLVM > > provides libgcc_s on newer systems. > > Apple does not provide GCC 4.2 anymore, but its LLVM compiler provides a > __addvsi3 as part of its libSystem. Probably for backward compatibility, > because… > > > (In reply to rguent...@suse.de from comment #13) > > Simply get libcompiler_rt folks to fix their code? You should be > > able to file a bug somewhere. > > … the current clang-based Apple compilers do not emit any call to __addvsi3, > but directly emit the overflow checking code. So, I cannot get a simple > reproducer to report to them. Your example directly calling __addvsi3 should suffice for that. Richard.
[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 #14 from Francois-Xavier Coudert --- (In reply to rguent...@suse.de from comment #12) > So I bet apple GCC 4.2 is affected as well - not sure if LLVM > provides libgcc_s on newer systems. Apple does not provide GCC 4.2 anymore, but its LLVM compiler provides a __addvsi3 as part of its libSystem. Probably for backward compatibility, because… (In reply to rguent...@suse.de from comment #13) > Simply get libcompiler_rt folks to fix their code? You should be > able to file a bug somewhere. … the current clang-based Apple compilers do not emit any call to __addvsi3, but directly emit the overflow checking code. So, I cannot get a simple reproducer to report to them.
[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 --- 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 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 --- > 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.
[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 #12 from 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
>
> --- Comment #8 from Francois-Xavier Coudert ---
> (In reply to Francois-Xavier Coudert from comment #7)
> > Richard, I am willing to debug this, but don't know where to go after the
> > above analysis.
>
>
> I think it's a libgcc miscompilation somehow. Directly calling __addvsi3 as
> follows:
>
> int __addvsi3 (int, int);
> int main (void)
> { volatile int x = __addvsi3 (__INT_MAX__, 1); }
>
> does not abort, even though (in my understanding) it should.
It definitely does on x86_64-linux. Are you using libgcc_s from
the system (thus darwin)? ISTR old libgcc did the arithmetic
in a bogus way (using undefined behavior). Quoting from GCC 4.3
sources:
Wtype
__addvSI3 (Wtype a, Wtype b)
{
const Wtype w = a + b;
^^^
if (b >= 0 ? w < a : w > a)
abort ();
the addition is done in signed thus invoking undefined behavior.
A fixed variant (trunk) looks like
Wtype
__addvSI3 (Wtype a, Wtype b)
{
const Wtype w = (UWtype) a + (UWtype) b;
if (b >= 0 ? w < a : w > a)
abort ();
doing the addition in unsigned arithmetic.
So I bet apple GCC 4.2 is affected as well - not sure if LLVM
provides libgcc_s on newer systems.
[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 #11 from Francois-Xavier Coudert --- (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!
[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 #10 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #9) > 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. Great! > 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? 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? if that's the case potential solutions: (a) more fiddling with library ordering in the specs (b) we could punt on the hope of ever getting the "extension" shared library to play nicely with the already installed stuff and revert to putting these items in a "crt". This would be a static lib and mentioned on the link-line would take precedence over the system ones. *sigh* also on my TODO is tidying up the maze of twisty passages that constitutes the crt/libgcc_s/libcc_ext support across the darwin patch. This is where we have a huge challenge c.f. other systems since it's not acceptable for end Users to "just install some new libs into some part of /usr/ as root". Thus we have to make whatever we do interact well with what's already there.
[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 Francois-Xavier Coudert 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 --- 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?
