Re: Darwin bootstrap failure following wide int merge

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, May 28, 2014 at 11:49 AM, Richard Sandiford
<rsandifo@linux.vnet.ibm.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>>> <rdsandiford@googlemail.com> wrote:
>>>> Richard Biener <richard.guenther@gmail.com> writes:
>>>>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek <jakub@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 <fxcoudert@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.
>
> 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.

Works for me (though see Jakubs idea on the other thread, so please
wait until we settled on a solution).

Richard.

> Thanks,
> Richard
>