On Wed, May 28, 2014 at 11:40 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford > <rdsandif...@googlemail.com> wrote: >> Richard Biener <richard.guent...@gmail.com> writes: >>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek <ja...@redhat.com> wrote: >>>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote: >>>>> On May 26, 2014, at 2:22 AM, FX <fxcoud...@gmail.com> 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. Richard. > Thanks, > Richard. > >> Thanks, >> Richard