https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033
--- Comment #2 from qinzhao at gcc dot gnu.org ---
I can repeat this ICE on the gcc farm machine gcc112, which is a Powerpcle
linux machine with the latest upstream gcc (11/2/2021).
and locate the issue at:
Breakpoint 2, expand_DEFERRED_INIT (stmt=0x3fffaf162c88) at
../../latest_gcc_git/gcc/internal-fn.c:3085
3085 if (can_native_interpret_type_p (var_type))
(gdb) n
3086 init = native_interpret_expr (var_type, buf, total_bytes);
(gdb) n
3105 expand_assignment (lhs, init, false);
(gdb) print init
$8 = (tree) 0x0
(gdb) call debug_tree(var_type)
<real_type 0x3fffaf0c1500 long double sizes-gimplified TF
size <integer_cst 0x3fffaf091038 type <integer_type 0x3fffaf0c01f8
bitsizetype> constant 128>
unit-size <integer_cst 0x3fffaf091050 type <integer_type 0x3fffaf0c0150
sizetype> constant 16>
align:128 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x3fffaf0c1500 precision:127
pointer_to_this <pointer_type 0x3fffaf0c1a40>>
i.e, in the above, there is an inconsistency between
"can_native_interpret_type_p" and "native_interpret_expr" for "long double" on
Powerpcle: although "can_native_interpre_type_p(long double)" return true,
"native_interpret_expr (long double, buf,...) return NULL on Powerpcle, This is
due to the following code in "native_interpret_expr":
if (MODE_COMPOSITE_P (mode))
{
/* For floating point values in composite modes, punt if this folding
doesn't preserve bit representation. As the mode doesn't have fixed
precision while GCC pretends it does, there could be valid values that
GCC can't really represent accurately. See PR95450. */
unsigned char buf[24];
if (native_encode_expr (ret, buf, total_bytes, 0) != total_bytes
|| memcmp (ptr, buf, total_bytes) != 0)
ret = NULL_TREE;
}
this part of the code is to fix PR95450, which is bug on Powerpcle too, so,
looks like this is the reason why this bug only for powerpc.
