This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Darwin bootstrap failure following wide int merge


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.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]