This is the mail archive of the
mailing list for the GCC project.
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Christopher <echristo at gmail dot com>
- Cc: FX <fxcoudert at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, glisse at gcc dot gnu dot org, Richard Sandiford <rdsandiford at googlemail dot com>, Mike Stump <mikestump at comcast dot net>, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>
- Date: Mon, 26 May 2014 12:10:56 +0200
- Subject: Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
- Authentication-results: sourceware.org; auth=none
- References: <97BE9F46-EB35-4B06-9065-915D7259E701 at gmail dot com> <CALehDX51OGHxehk5NZDCa7eb6k_2oWTqTD-4gE9NRoiLVsMgVg at mail dot gmail dot com>
On Mon, May 26, 2014 at 12:05 PM, Eric Christopher <email@example.com> wrote:
> On Mon, May 26, 2014 at 1:14 AM, FX <firstname.lastname@example.org> 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, val, 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__