On 30/01/17 11:38, Sebastian Huber wrote:
On 25/01/17 18:55, Segher Boessenkool wrote:
On Wed, Jan 25, 2017 at 01:11:49PM +0100, Sebastian Huber wrote:
>I still get a lot of ICEs with the attached two patches (examples):
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function
>'__multc3':
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error:
>unrecognizable insn:
> }
> ^
>(insn 59 58 60 2 (set (reg:CCFP 219)
> (compare:CCFP (reg/v:TF 193 [ x ])
> (reg/v:TF 193 [ x ])))
>"/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1
> (nil))
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal
>compiler error: in extract_insn, at recog.c:2311
The IEEE128 code almost certainly has some bugs on non-Linux
configurations.
You could try debugging it, or you could avoid it (for now) by e.g.
making
long double the same as double.
If I set rs6000_long_double_type_size to 64, then I can build all
libgcc multilibs including the one for -m64 -mcpu=e6500. I am a bit
surprised that the GCC support for 64-bit PowerPC is so extremely
Linux-dependent. I guess that I have to figure out all the magic
configuration bits to get everything set up like it is on Linux. It
would be nice if the working Linux configuration bits are the default.
With rs6000_long_double_type_size == 128, then I get the attached ICEs.
I would be glad to get some advice how I can debug them, since I have
no idea how the compiler works actually if it comes to code generation.
I gave it a new try after the SPE split up. I still have problems to
build a bi-arch PowerPC compiler for RTEMS. I get an ICE with this test
case:
typedef float TFtype __attribute__ ((mode (TF)));
void
f (TFtype b)
{
if (b - b) {
__asm__ volatile ("");
}
}
xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -mcpu=e6500
-m64 -O2 -fpreprocessed -S test-v0.i -o /dev/null 2>&1
test-v0.i: In function 'f':
test-v0.i:8:1: error: unrecognizable insn:
}
^
(insn 12 11 13 2 (set (reg:CCFP 126)
(compare:CCFP (reg:TF 123)
(reg:TF 124))) "test-v0.i":5 -1
(nil))
during RTL pass: vregs
test-v0.i:8:1: internal compiler error: in extract_insn, at recog.c:2311
0x40a233 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:108
0x40a252 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:116
0x965abf extract_insn(rtx_insn*)
/home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2311
0x71dd73 instantiate_virtual_regs_in_insn
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1589
0x71dd73 instantiate_virtual_regs
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1957
0x71dd73 execute
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
I built a native GCC on gcc112. It produces:
./install-gcc-git/bin/gcc -S -O2 -mcpu=e6500 -m64 -o - test.c
.file "test.c"
.abiversion 2
.globl __gcc_qsub
.section ".text"
.align 2
.p2align 4,,15
.globl f
.type f, @function
f:
.LCF0:
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry f,.-f
fmr 4,2
mflr 0
fmr 3,1
std 0,16(1)
stdu 1,-32(1)
bl __gcc_qsub
nop
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lfd 12,0(9)
lfd 13,8(9)
fcmpu 7,1,12
bne 7,$+8
fcmpu 7,2,13
beq- 7,.L1
.L1:
addi 1,1,32
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,0,0,0
.size f,.-f
.section .rodata.cst16,"aM",@progbits,16
.align 4
.LC0:
.long 0
.long 0
.long 0
.long 0
.ident "GCC: (GNU) 8.0.0 20170720 (experimental) [master
revision f37822f:0bf6d30:61658d61fdbd0e76bb1b7ea20c3bb8dc334568cd]"
.gnu_attribute 4, 5
.section .note.GNU-stack,"",@progbits
So, I looked for " __gcc_qsub" in the GCC sources. It seems this is
generated by rs6000_init_libfuncs() for some "sub_optab" stuff. If I run
my bi-arch GCC in GDB, then I get:
Breakpoint 1, rs6000_init_libfuncs () at
/home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:18670
18670 if (TARGET_FLOAT128_TYPE)
(gdb) n
18677 if (TARGET_LONG_DOUBLE_128)
(gdb)
18684 init_float128_ieee (TFmode);
(gdb) s
init_float128_ieee (mode=TFmode) at
/home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:18581
18581 if (FLOAT128_VECTOR_P (mode))
(gdb) n
18580 {
(gdb)
18581 if (FLOAT128_VECTOR_P (mode))
(gdb)
18640 set_optab_libfunc (add_optab, mode, "_q_add");
(gdb)
18641 set_optab_libfunc (sub_optab, mode, "_q_sub");
Ok, so why do I get a "error: unrecognizable insn:"? How can I debug a
message like this:
(insn 12 11 13 2 (set (reg:CCFP 126)
(compare:CCFP (reg:TF 123)
(reg:TF 124))) "test-v0.i":5 -1
(nil))
I don't know how I can figure out the corresponding GCC sources that are
involved here.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
