[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385 Martin Decky martin at decky dot cz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Known to fail|4.7.2, 4.8.0| --- Comment #9 from Martin Decky martin at decky dot cz 2012-11-08 10:24:06 UTC --- I can confirm that the bug is no longer present in 4.7.2, as noted in comment #8. Therefore I am closing this bug as resolved/fixed. I am not marking it as duplicate of 49866 since this bug was reported earlier and to a different version (but feel free to change this). Thanks for fixing this!
[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] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606
Summary: mips64: Unrecognizable insn when one noreturn function
calling another noreturn function
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@decky.cz
Target: mips64
Created attachment 24654
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24654
Preprocessed file
Simple test case:
extern void first(void) __attribute__((noreturn));
extern void second(void) __attribute__((noreturn));
void first(void)
{
second();
}
Output of /usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/cross/mips64/libexec/gcc/mips64el-linux-gnu/4.6.1/lto-wrapper
Target: mips64el-linux-gnu
Configured with: /root/install/cross/mips64/gcc-4.6.1/configure
--target=mips64el-linux-gnu --prefix=/usr/local/cross/mips64
--program-prefix=mips64el-linux-gnu- --with-gnu-as --with-gnu-ld --disable-nls
--disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib
--disable-libgcj --without-headers --disable-shared --enable-lto
Thread model: single
gcc version 4.6.1 (GCC)
Command line that triggered the bug:
/usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc -I../../lib/c/include -O3
-imacros ../../../config.h -fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE
-finput-charset=UTF-8 -ffreestanding -fno-builtin -nostdlib -nostdinc -Wall
-Wextra -Wno-clobbered -Wno-unused-parameter -Wmissing-prototypes -std=gnu99
-Werror-implicit-function-declaration -Wwrite-strings -pipe -g -D__LE__ -Werror
-mips3 -mabi=o64 -mlong64 -Xassembler -64 -I../../srv/loader/include -c
generic/libc.c -o generic/libc.o
Compiler output:
generic/libc.c: In function 'first':
generic/libc.c:7:1: error: unrecognizable insn:
(insn 16 15 18 2 (parallel [
(set (mem/c:DI (plus:DI (reg/f:DI 29 $sp)
(const_int 32 [0x20])) [2 S8 A64])
(unspec:SI [
(const_int 32 [0x20])
(reg:DI 28 $28)
] UNSPEC_POTENTIAL_CPRESTORE))
(clobber (scratch:DI))
]) generic/libc.c:5 -1
(nil))
generic/libc.c:7:1: internal compiler error: in extract_insn, at recog.c:2109
[Bug target/49606] mips64: Unrecognizable insn when one noreturn function calling another noreturn function
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?
[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385 --- Comment #2 from Martin Decky martin at decky dot cz 2011-06-30 16:03:08 UTC --- Created attachment 24646 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24646 Initial proposed patch The attached patch works as a temporary workaround and might also hint where exactly the problem is. Now, guys, please don't crucify me for this patch. I am well aware that this patch is no more than a dirty hack and probably breaks other thinks. I present it here only to provoke some reaction from somebody who knows GCC sources well enough to propose a real solution. I have just spent some 4 hours browsing the sources, analysing relevant functions such as output_asm_insn(), ix86_print_operand(), print_reg() and similar to figure out how to change the way the tail call instruction is generated for this particular case. But I would really appreciate a little help from a senior GCC developer who not only knows what and how, but also why. Thanks in advance!
[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385 --- Comment #6 from Martin Decky martin at decky dot cz 2011-07-01 02:53:18 UTC --- Created attachment 24650 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24650 Short test case Thanks, H.J. Lu, for providing the short test case. I have just added three extern declarations to make it compile in my freestanding setup and I confirm that it demonstrates the bug in my environment. I'll post the save-temps output shortly.
[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385
Martin Decky martin at decky dot cz changed:
What|Removed |Added
Attachment #23836|0 |1
is obsolete||
--- Comment #7 from Martin Decky martin at decky dot cz 2011-07-01 02:57:21
UTC ---
Created attachment 24651
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24651
Preprocessed file for the short test case
Output of /usr/local/cross/amd64/bin/amd64-linux-gnu-gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/local/cross/amd64/bin/amd64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/cross/amd64/libexec/gcc/amd64-linux-gnu/4.6.1/lto-wrapper
Target: amd64-linux-gnu
Configured with: /root/install/cross/amd64/gcc-4.6.1/configure
--target=amd64-linux-gnu --prefix=/usr/local/cross/amd64
--program-prefix=amd64-linux-gnu- --with-gnu-as --with-gnu-ld --disable-nls
--disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib
--disable-libgcj --without-headers --disable-shared --enable-lto
Thread model: single
gcc version 4.6.1 (GCC)
Command line that triggered the bug:
/usr/local/cross/amd64/bin/amd64-linux-gnu-gcc -DKERNEL -DRELEASE=0.4.3
-DNAME=Sashimi -D__64_BITS__ -D__LE__ -Igeneric/include -O3 -imacros
../config.h -fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE
-finput-charset=UTF-8 -ffreestanding -fno-builtin -nostdlib -nostdinc
-std=gnu99 -Wall -Wextra -Wno-unused-parameter -Wmissing-prototypes
-Werror-implicit-function-declaration -Wwrite-strings -pipe -Werror -m64
-mcmodel=large -mno-red-zone -fno-unwind-tables -fno-omit-frame-pointer
-march=opteron -Itest/ -mno-sse -mno-sse2 -c -o genarch/src/mm/page_pt.o
genarch/src/mm/page_pt.c
Compiler output:
{standard input}: Assembler messages:
{standard input}:284: Error: immediate operand illegal with absolute jump
[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385 Martin Decky martin at decky dot cz changed: What|Removed |Added Version|4.6.0 |4.6.1 --- Comment #1 from Martin Decky martin at decky dot cz 2011-06-29 15:01:46 UTC --- The bug is still present in GCC 4.6.1.
[Bug c/48385] New: x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385
Summary: x86-64: Tail call recursion optimization with
-mcmodel=large can generate invalid assembly
(immediate operand illegal with absolute jump)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@decky.cz
Created attachment 23836
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23836
Compiler result using -save-temps
When using -mcmodel=large and -O3, a tail call to an extern function can
generate an invalid assembly like in the following example:
jmp *$memsetb
The correct assembly output should be perhaps:
jmp *memsetb
The problem can be worked around by adding the -fno-optimize-sibling-calls
option to the compiler command line.
Output of /usr/local/cross/amd64/bin/amd64-linux-gnu-gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/local/cross/amd64/bin/amd64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/cross/amd64/libexec/gcc/amd64-linux-gnu/4.6.0/lto-wrapper
Target: amd64-linux-gnu
Configured with: /root/install/cross/amd64/gcc-4.6.0/configure
--target=amd64-linux-gnu --prefix=/usr/local/cross/amd64
--program-prefix=amd64-linux-gnu- --with-gnu-as --with-gnu-ld --disable-nls
--disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib
--disable-libgcj --without-headers --disable-shared --enable-lto
Thread model: single
gcc version 4.6.0 (GCC)
Command line that triggered the bug:
/usr/local/cross/amd64/bin/amd64-linux-gnu-gcc -DKERNEL -DRELEASE=0.4.3
-DNAME=Sashimi -D__64_BITS__ -D__LE__ -Igeneric/include -O3 -imacros
../config.h -fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE
-finput-charset=UTF-8 -ffreestanding -fno-builtin -nostdlib -nostdinc -Wall
-Wextra -Wno-unused-parameter -Wmissing-prototypes
-Werror-implicit-function-declaration -Wwrite-strings -pipe -Werror -m64
-mcmodel=large -mno-red-zone -fno-unwind-tables -fno-omit-frame-pointer
-march=opteron -Itest/ -mno-sse -mno-sse2 -c -o genarch/src/mm/page_pt.o
genarch/src/mm/page_pt.c
Compiler output:
{standard input}: Assembler messages:
{standard input}:722: Error: immediate operand illegal with absolute jump
