On Mon, Jan 30, 2017 at 11:38:19AM +0100, Sebastian Huber wrote:
> >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.
Good, so you have a way forward now. You probably do not want to keep
this forever, of course ;-)
> I am a bit surprised
> that the GCC support for 64-bit PowerPC is so extremely Linux-dependent.
It is not. It also supports FreeBSD (which of course is very much like
Linux), and AIX and Darwin.
But the focus is on Linux, sure.
> 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.
There are hundreds of knobs you can turn. Not all combinations make
sense. Not all the non-sensical combinations are handled gracefully.
> 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.
The IEEE128 code is quite new, and of course still has bugs. You do
not want to use "double-double" in a new ABI though.
> /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))
This is probably created via:
(define_expand "cbranch4"
[(use (match_operator 0 "rs6000_cbranch_operator"
[(match_operand:FP 1 "gpc_reg_operand" "")
(match_operand:FP 2 "gpc_reg_operand" "")]))
(use (match_operand 3 ""))]
""
"
{
rs6000_emit_cbranch (mode, operands);
DONE;
}")
which does
condition_rtx = rs6000_generate_compare (operands[0], mode);
which then does
if (!TARGET_FLOAT128_HW && FLOAT128_VECTOR_P (mode))
comp_mode = CCmode;
else if (FLOAT_MODE_P (mode))
comp_mode = CCFPmode;
else
so it seems you have TARGET_FLOAT128_HW set?
> /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: unable
> to generate reloads for:
> }
> ^
> (insn 138 1211 139 16 (set (reg/v:TF 203 [ a ])
> (unspec:TF [
> (reg:TF 237)
> (reg/v:TF 203 [ a ])
> (reg:TF 238)
> ] UNSPEC_COPYSIGN))
> "/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1998 940
> {copysigntf3_soft}
> (expr_list:REG_DEAD (reg:TF 238)
> (nil)))
But this one has it off. Huh. (The _soft is only generated with it off).
> /home/EB/sebastian_h/archive/gcc-git/newlib/libm/common/sl_finite.c:22:10:
> internal compiler error: in validate_condition_mode, at
> config/rs6000/rs6000.c:20551
>return __builtin_isfinite (x);
> ^~
> 0xd5ed1b validate_condition_mode(rtx_code, machine_mode)
> /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:20547
> 0xd5f12c rs6000_generate_compare
> /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:24323
> 0xd63a92 rs6000_emit_sCOND(machine_mode, rtx_def**)
> /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:24736
> 0xf0998a gen_cstoretf4(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
> /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11703
Machine mode is CCFPmode, but what is the RTL code? rs6000_generate_compare
made a mess here.
> /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/libsupc++/fundamental_type_info.cc:35:1:
> internal compiler error: in write_builtin_type, at cp/mangle.c:2574
> }
> ^
> 0x65a189 write_builtin_type
> /home/EB/sebastian_h/archive/gcc-git/gcc/cp/mangle.c:2574
So it doesn't have a valid FP type here.
All the rest of your errors are duplicates or fallout from earlier
errors.
Segher
