* [Bug target/49606] mips64: Unrecognizable insn when one noreturn function calling another noreturn function
2011-07-01 12:05 [Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function martin at decky dot cz
@ 2011-07-01 12:13 ` martin at decky dot cz
2011-07-01 15:50 ` [Bug target/49606] mips64: o64 " pinskia at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: martin at decky dot cz @ 2011-07-01 12:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606
--- Comment #1 from Martin Decky <martin at decky dot cz> 2011-07-01 12:12:47 UTC ---
A minimal set of GCC command line arguments that still trigger the bug:
/usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc -mabi=o64 -mlong64 -c
generic/libc.c -o generic/libc.o
Leaving out either of the arguments -mabi=o64 and -mlong64 solves the bug,
however I cannot leave them out because this is precisely what I need: To use
the the O64 ABI and have 64-bit pointers. Or is there any better way how to
achieve this?
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
2011-07-01 12:05 [Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function martin at decky dot cz
2011-07-01 12:13 ` [Bug target/49606] " martin at decky dot cz
@ 2011-07-01 15:50 ` pinskia at gcc dot gnu.org
2011-08-27 9:02 ` rsandifo at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2011-07-01 15:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
2011-07-01 12:05 [Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function martin at decky dot cz
2011-07-01 12:13 ` [Bug target/49606] " martin at decky dot cz
2011-07-01 15:50 ` [Bug target/49606] mips64: o64 " pinskia at gcc dot gnu.org
@ 2011-08-27 9:02 ` rsandifo at gcc dot gnu.org
2011-08-29 15:00 ` martin at decky dot cz
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2011-08-27 9:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
2011-07-01 12:05 [Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function martin at decky dot cz
` (2 preceding siblings ...)
2011-08-27 9:02 ` rsandifo at gcc dot gnu.org
@ 2011-08-29 15:00 ` martin at decky dot cz
2011-09-05 19:40 ` rsandifo at gcc dot gnu.org
2011-09-05 19:48 ` rsandifo at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: martin at decky dot cz @ 2011-08-29 15:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
2011-07-01 12:05 [Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function martin at decky dot cz
` (3 preceding siblings ...)
2011-08-29 15:00 ` martin at decky dot cz
@ 2011-09-05 19:40 ` rsandifo at gcc dot gnu.org
2011-09-05 19:48 ` rsandifo at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2011-09-05 19:40 UTC (permalink / raw)
To: gcc-bugs
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=gcc&view=rev&rev=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_got<mode>): 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_jump<mode>): Rename to...
(indirect_jump_<mode>): ...this.
(tablejump): Use PMODE_INSN.
(tablejump<mode>): 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
trunk/gcc/testsuite/gcc.target/mips/abi-o32-long64-no-shared.c
trunk/gcc/testsuite/gcc.target/mips/abi-o32-long64-pic.c
trunk/gcc/testsuite/gcc.target/mips/abi-o32-long64.c
trunk/gcc/testsuite/gcc.target/mips/abi-o64-long32-no-shared.c
trunk/gcc/testsuite/gcc.target/mips/abi-o64-long32-pic.c
trunk/gcc/testsuite/gcc.target/mips/abi-o64-long32.c
trunk/gcc/testsuite/gcc.target/mips/abi-o64-long64-no-shared.c
trunk/gcc/testsuite/gcc.target/mips/abi-o64-long64-pic.c
trunk/gcc/testsuite/gcc.target/mips/abi-o64-long64.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips-dsp.md
trunk/gcc/config/mips/mips.c
trunk/gcc/config/mips/mips.h
trunk/gcc/config/mips/mips.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/branch-10.c
trunk/gcc/testsuite/gcc.target/mips/branch-11.c
trunk/gcc/testsuite/gcc.target/mips/branch-12.c
trunk/gcc/testsuite/gcc.target/mips/branch-13.c
trunk/gcc/testsuite/gcc.target/mips/branch-2.c
trunk/gcc/testsuite/gcc.target/mips/branch-3.c
trunk/gcc/testsuite/gcc.target/mips/branch-4.c
trunk/gcc/testsuite/gcc.target/mips/branch-5.c
trunk/gcc/testsuite/gcc.target/mips/branch-6.c
trunk/gcc/testsuite/gcc.target/mips/branch-7.c
trunk/gcc/testsuite/gcc.target/mips/branch-8.c
trunk/gcc/testsuite/gcc.target/mips/branch-9.c
trunk/gcc/testsuite/gcc.target/mips/lazy-binding-1.c
trunk/gcc/testsuite/gcc.target/mips/mips.exp
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
2011-07-01 12:05 [Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function martin at decky dot cz
` (4 preceding siblings ...)
2011-09-05 19:40 ` rsandifo at gcc dot gnu.org
@ 2011-09-05 19:48 ` rsandifo at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2011-09-05 19:48 UTC (permalink / raw)
To: gcc-bugs
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|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.
^ permalink raw reply [flat|nested] 7+ messages in thread