From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9596 invoked by alias); 23 Nov 2014 16:08:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 9554 invoked by uid 48); 23 Nov 2014 16:08:22 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13 Date: Sun, 23 Nov 2014 16:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-11/txt/msg02615.txt.bz2 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".