http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606
rsand...@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
2011-09-05 19:47:38 UTC ---
Thanks for the feedback.
(In reply to comment #4)
> > So do you actually have a system that uses this ABI
> > (o64+mlong64)?
>
> Actually, no. I was trying to cross-compile our own OS for mips64 and the
> o64+mlong64 combination was the first one I have tried. The 32-bit file format
> might or might not be eventually a problem if the compilation works (I can
> imagine that it might actually work fine at least for user space binaries).
> But
> the n64 ABI seems definitively to be a better choice.
I suppose the problem for userspace stuff is that pointers
will be 64 bits but GOT entries only 32 bits.
However, it seems that the non-abicalls (kernel/bare-metal)
form really is supported, so the error needs to be restricted
to abicalls.
> > If so, could you give a few more details?
> > TBH, my instinctive reaction is that this is a missing
> > diagnostic bug, and that we should refuse to compile
> > -mabi=o64 -mlong64.
>
> Well, I do not insist that this bug should be fixed only by making the
> compilation work. Your suggestion that this combination of options is not very
> reasonable and should be refused is sound.
>
> Either way, the compiler should not end with an internal error.
Agreed. It's definitely a bug whichever way you cut it.
I've now applied a fix to report an error for this case.
I don't think it's appropriate for the release branches though.
