https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I can finally reproduce, one needs -m32 -Os -mcpu=power7 (or power8 or
power9) to reproduce.
And the bug is created in store_bit_field_1 doing:
rtx sub;
HOST_WIDE_INT regnum;
poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
if (known_eq (bitnum, 0U)
&& known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0))))
{
sub = simplify_gen_subreg (GET_MODE (op0), value, fieldmode, 0);
if (sub)
{
if (reverse)
sub = flip_storage_order (GET_MODE (op0), sub);
emit_move_insn (op0, sub);
return true;
}
}
(there is similar code later on).
value is
(const_vector:V16QI [
(const_int 65 [0x41]) repeated x15
(const_int 0 [0])
])
simplify_gen_subreg from V16QImode to TFmode makes
(const_double:TF 4.5232690196078126318752765655517578125e+6
[0x0.8a0a0a0a0a0904p+23])
out of that and the problem is that this constant doesn't convert back to value
when simplify_gen_subreg converted back to V16QImode, instead it yields
(const_vector:V16QI [
(const_int 65 [0x41])
(const_int 81 [0x51])
(const_int 65 [0x41]) repeated x5
(const_int 32 [0x20])
(const_int 62 [0x3e])
(const_int 0 [0]) repeated x7
])
So, to me this looks like a dup of PR95450, except in simplify-rtx.c rather
than in fold-const.c.
Do we want to do the same thing in simplify_subreg and try to convert back for
MODE_COMPOSITE_P?
