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|UNCONFIRMED |WAITING
Last reconfirmed| |2011-08-27
CC| |rsandifo at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
2011-08-27 08:39:09 UTC ---
The problem here isn't really o64 itself (which is well
supported on *-elf targets, but less so on *-linux-gnu).
The problem is the combination of "-mabi=o64 -mlong64".
That isn't really a defined ABI.
As well as making longs 64 bits wide, -mlong64 makes
pointers 64 bits wide. But you're still using a
32-bit file format. If you want an LP64 ABI,
then n64 seems like a better choice.
So do you actually have a system that uses this ABI
(o64+mlong64)? 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.
The immediate cause of the ICE is that the -mabicalls
support for o32 and o64 assumes that pointers are
32 bits wide. It would be theoretically possible
to extend it to cope with 64-bit pointers, but that
shouldn't be necessary as far as the defined ABIs go.
