Richard Biener <[email protected]> writes: > On Wed, May 28, 2014 at 11:40 AM, Richard Biener > <[email protected]> wrote: >> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford >> <[email protected]> wrote: >>> Richard Biener <[email protected]> writes: >>>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek <[email protected]> wrote: >>>>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote: >>>>>> On May 26, 2014, at 2:22 AM, FX <[email protected]> wrote: >>>>>> >> This causes GCC bootstrap to fail on Darwin systems (whose system >>>>>> > compiler is clang-based). Since PR 61146 was resolved as INVALID >>>>>> > (but I’m not sure it’s the right call, see below), I’ve filed a >>>>>> > separate report for the bootstrap issue >>>>>> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). >>>>>> > >>>>>> > Since my PR has been closed twice by Andrew Pinski (“it’s clang’s >>>>>> > fault, bouh ouh”), I’d ask the maintainers to step in. Can we >>>>>> > please provide a GCC that works for the default darwin setup? Or at >>>>>> > least drop darwin as secondary target and document the failure? >>>>>> >>>>>> The best coarse of action, post a patch, have it reviewed and put in. >>>>>> Current action, a patch has been posted, the review is outstanding, I’d >>>>>> like to see it put in; though, I am curious why the casts were there in >>>>>> the first place. >>>>> >>>>> Note, haven't added them there, but from what I can test, the casts there >>>>> can serve as a compile time check that the right type is used, e.g. >>>>> unsigned long i; >>>>> >>>>> void >>>>> foo (void) >>>>> { >>>>> asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0" >>>>> ((unsigned long long) 0)); >>>>> } >>>> >>>> Ah, interesting. A not-so-hineous extension then. >>> >>> In that case, how about just protecting the include with: >>> >>> #if GCC_VERSION >= 4300 && (W_TYPE_SIZE == 32 || defined >>> (__SIZEOF_INT128__)) >>> >>> rather than: >>> >>> #if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined >>> (__SIZEOF_INT128__)) >>> >>> so that clang will fail the version check? At the end of the day we >>> only really care what happens during stage 2 and 3. Cross-compilers >>> built with recentish gccs will still benefit. >> >> Works for me (thus, pre-approved with a comment explaining the version >> choice). > > Btw, testing coverage would ask for && defined (__OPTIMIZE__), too, disabling > that path in stage1 unconditionally even for new GCC.
Ah, but surely the day is near when we use -O or -Og for stage1? I've been using -O for a good few years now and it definitely makes things faster (and without affecting debugging too much -- in the rare cases where it does affect debugging, a recompile with -g is very quick). ATM we get the testing coverage for i686 and ppc32 hosts. So TBH I'd prefer to keep it simple and just bump the version number. Thanks, Richard
