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: Jakub Jelinek <jakub at redhat dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: FX <fxcoudert at gmail dot com>, echristo at gmail dot com, Stan Shebs <stanshebs at earthlink dot net>, GCC Development <gcc at gcc dot gnu dot org>, glisse at gcc dot gnu dot org, Richard Sandiford <rdsandiford at googlemail dot com>, 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: Wed, 28 May 2014 08:50:33 +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> <769D0D77-6DB3-421F-9006-326B0E2B42FE at gmail dot com> <71C2DDBB-87AE-491D-9074-F5744B8AFF61 at comcast dot net>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
> On May 26, 2014, at 2:22 AM, FX <firstname.lastname@example.org> 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;
asm volatile ("# %0 %1" : "=r" ((unsigned long long) i) : "0" ((unsigned long long) 0));
errors out on x86_64 -m32, but compiles fine with -m64, because in the
latter case the type has the correct size, while in the former case it
doesn't. So, perhaps instead of removing the casts we should replace them
with some kind of static assertions (whether
extern char foobar[sizeof (arg) == sizeof (UDItype) && __builtin_classify_type (arg) == 1 ? 1 : -1];
or __builtin_types_compatible_p, or C++ templates for C++, ...