Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

[Eric Christopher]

On Mon, May 26, 2014 at 3:10 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, May 26, 2014 at 12:05 PM, Eric Christopher <echristo@gmail.com> wrote:
>> On Mon, May 26, 2014 at 1:14 AM, FX <fxcoudert@gmail.com> wrote:
>>>> > .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
>>>> > cast in a inline asm context requiring an l-value: remove the cast or
>>>> > build with -fheinous-gnu-extensions
>>>> >           umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ());
>>>> >           ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> This is PR 61146.  You can get around it by adding -fheinous-gnu-extensions
>>>> to BOOT_CFLAGS.
>>>
>>> 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).
>>>
>>> Regarding PR 61146, I agree with Marc Glisse (comment #3) that the casts in question look weird and should probably be removed, as was done in GMP. This code should be cleaned up, and it will fix bootstrap on clang-based target coincidentally, without adding another kludge.
>>>
>>
>> I think that posting a patch is probably the best bet. Then the
>> various merits of the patch to clean up the code can be argued. As far
>> as some sort of workaround, I'd suggest seeing if there's something
>> else that can be done first.
>
> You can always use a different host compiler as a workaround,
> for example by building and installing gcc 4.9 first.
>
> But indeed I agree with Andrew that compilers defining __GNUC__
> but not behaving exactly like gcc should be punished.  What
> does LLVM define as the actual version, and/or as __GNUC_MINOR__
> and __GNUC_PATCHLEVEL__?
>

#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC__ 4

It's pretty old and a better way of keeping up with features is
probably a good idea, but I don't think anyone has proposed the
__has_feature thing that clang implements which is pretty useful for
this sort of thing.

For what it's worth the number of extensions that are hidden under the
flag are pretty small and only the ones that were deemed dangerous to
use at the time. I wasn't involved nor do I remember the decision
making though.

-eric