[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606

rsandifo@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.