This is the mail archive of the 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 (was: we are starting the wide int merge)

On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
> On May 26, 2014, at 2:22 AM, FX <> 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 (
> > 
> > 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;

foo (void)
  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++, ...


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