Re: How to configure a bi-arch PowerPC GCC?

[Sebastian Huber <sebastian.huber@embedded-brains.de>]

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.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.