[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606 --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-09-05 19:39:30 UTC --- Author: rsandifo Date: Mon Sep 5 19:39:27 2011 New Revision: 178557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178557 Log: gcc/ PR target/49606 * config/mips/mips.h (ABI_HAS_64BIT_SYMBOLS): Check Pmode. (PMODE_INSN): New macro. * config/mips/mips.c (gen_load_const_gp): Use PMODE_INSN. (mips_got_load, mips_expand_synci_loop): Likewise. (mips_save_gp_to_cprestore_slot): Handle SImode and DImode cprestore patterns. (mips_emit_loadgp): Use PMODE_INSN. Handle SImode and DImode copygp_mips16 patterns. (mips_expand_prologue): Handle SImode and DImode potential_cprestore and use_cprestore patterns. (mips_override_options): Check for incompatible -mabi and -mlong combinations. * config/mips/mips.md (unspec_gotmode): Rename to... (unspec_got_mode): ...this. (copygp_mips16): Use the Pmode iterator. (potential_cprestore, cprestore, use_cprestore): Likewise. (clear_cache, indirect_jump): Use PMODE_INSN. (indirect_jumpmode): Rename to... (indirect_jump_mode): ...this. (tablejump): Use PMODE_INSN. (tablejumpmode): Rename to... (tablejump_mode): ...this. (exception_receiver): Handle restore_gp_si and restore_gp_di. (restore_gp): Use the Pmode iterator. * config/mips/mips-dsp.md (mips_lbux, mips_lhx, mips_lwx): Use PMODE_INSN. gcc/testsuite/ PR target/49606 * gcc.target/mips/abi-main.h: New file. * gcc.target/mips/abi-o32-long32.c: New test. * gcc.target/mips/abi-o32-long64.c: Likewise. * gcc.target/mips/abi-o64-long32.c: Likewise. * gcc.target/mips/abi-o64-long64.c: Likewise. * gcc.target/mips/abi-n32-long32.c: Likewise. * gcc.target/mips/abi-n32-long64.c: Likewise. * gcc.target/mips/abi-n64-long32.c: Likewise. * gcc.target/mips/abi-n64-long64.c: Likewise. * gcc.target/mips/abi-o32-long32-no-shared.c: Likewise. * gcc.target/mips/abi-o32-long64-no-shared.c: Likewise. * gcc.target/mips/abi-o64-long32-no-shared.c: Likewise. * gcc.target/mips/abi-o64-long64-no-shared.c: Likewise. * gcc.target/mips/abi-n32-long32-no-shared.c: Likewise. * gcc.target/mips/abi-n32-long64-no-shared.c: Likewise. * gcc.target/mips/abi-n64-long32-no-shared.c: Likewise. * gcc.target/mips/abi-n64-long64-no-shared.c: Likewise. * gcc.target/mips/abi-o32-long32-pic.c: Likewise. * gcc.target/mips/abi-o32-long64-pic.c: Likewise. * gcc.target/mips/abi-o64-long32-pic.c: Likewise. * gcc.target/mips/abi-o64-long64-pic.c: Likewise. * gcc.target/mips/abi-n32-long32-pic.c: Likewise. * gcc.target/mips/abi-n32-long64-pic.c: Likewise. * gcc.target/mips/abi-n64-long32-pic.c: Likewise. * gcc.target/mips/abi-n64-long64-pic.c: Likewise. * gcc.target/mips/abi-eabi32-long32.c: Likewise. * gcc.target/mips/abi-eabi32-long64.c: Likewise. * gcc.target/mips/abi-eabi64-long32.c: Likewise. * gcc.target/mips/abi-eabi64-long64.c: Likewise. * gcc.target/mips/mips.exp: Make -mshared implied -mabicalls. * gcc.target/mips/branch-2.c: Remove -mabicalls. * gcc.target/mips/branch-3.c: Likewise. * gcc.target/mips/branch-4.c: Likewise. * gcc.target/mips/branch-5.c: Likewise. * gcc.target/mips/branch-6.c: Likewise. * gcc.target/mips/branch-7.c: Likewise. * gcc.target/mips/branch-8.c: Likewise. * gcc.target/mips/branch-9.c: Likewise. * gcc.target/mips/branch-10.c: Likewise. * gcc.target/mips/branch-11.c: Likewise. * gcc.target/mips/branch-12.c: Likewise. * gcc.target/mips/branch-13.c: Likewise. * gcc.target/mips/lazy-binding-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/mips/abi-eabi32-long32.c trunk/gcc/testsuite/gcc.target/mips/abi-eabi32-long64.c trunk/gcc/testsuite/gcc.target/mips/abi-eabi64-long32.c trunk/gcc/testsuite/gcc.target/mips/abi-eabi64-long64.c trunk/gcc/testsuite/gcc.target/mips/abi-main.h trunk/gcc/testsuite/gcc.target/mips/abi-n32-long32-no-shared.c trunk/gcc/testsuite/gcc.target/mips/abi-n32-long32-pic.c trunk/gcc/testsuite/gcc.target/mips/abi-n32-long32.c trunk/gcc/testsuite/gcc.target/mips/abi-n32-long64-no-shared.c trunk/gcc/testsuite/gcc.target/mips/abi-n32-long64-pic.c trunk/gcc/testsuite/gcc.target/mips/abi-n32-long64.c trunk/gcc/testsuite/gcc.target/mips/abi-n64-long32-no-shared.c trunk/gcc/testsuite/gcc.target/mips/abi-n64-long32-pic.c trunk/gcc/testsuite/gcc.target/mips/abi-n64-long32.c trunk/gcc/testsuite/gcc.target/mips/abi-n64-long64-no-shared.c trunk/gcc/testsuite/gcc.target/mips/abi-n64-long64-pic.c trunk/gcc/testsuite/gcc.target/mips/abi-n64-long64.c trunk/gcc/testsuite/gcc.target/mips/abi-o32-long32-no-shared.c trunk/gcc/testsuite/gcc.target/mips/abi-o32-long32-pic.c trunk/gcc/testsuite/gcc.target/mips/abi-o32-long32.c
[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
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.
[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606 --- Comment #4 from Martin Decky martin at decky dot cz 2011-08-29 14:33:07 UTC --- (In reply to comment #3) 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. Yes, this is indeed the most reasonable solution for me. 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. 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.
[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
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.
[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|mips64: Unrecognizable insn |mips64: o64 Unrecognizable |when one noreturn function |insn when one noreturn |calling another noreturn|function calling another |function|noreturn function Severity|major |normal --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-01 15:49:41 UTC --- O64 is the least supported ABI in GCC for MIPS.
