https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118171
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is we're doing
tree t = build3 (BIT_FIELD_REF, currop->type, genop0, op1, op2);
REF_REVERSE_STORAGE_ORDER (t) = currop->reverse;
return fold (t);
and while we correctly re-build BIT_FIELD_REF <MEM <complex float> [(void
*)&f], 32, 0>, fold generates the invalid GIMPLE (and we assume no
re-gimplification
is necessary). This also shows ifcombine doesn't fold the BIT_FIELD_REFs
it creates.
This is
(simplify
(BIT_FIELD_REF @0 @1 @2)
(switch
(if (TREE_CODE (TREE_TYPE (@0)) == COMPLEX_TYPE
&& tree_int_cst_equal (@1, TYPE_SIZE (TREE_TYPE (TREE_TYPE (@0)))))
(switch
(if (integer_zerop (@2))
(view_convert (realpart @0)))
(if (tree_int_cst_equal (@2, TYPE_SIZE (TREE_TYPE (TREE_TYPE (@0)))))
(view_convert (imagpart @0)))))
and thus a latent issue in PRE. We are not folding MEM_REF or TARGET_MEM_REF,
we do fold most other generated GENERIC trees when building component refs,
but this shows we probably shouldn't (we're eventually re-folding the last
stmt on GIMPLE). Generally folding isn't safe since it might introduce
an rvalue we're creating more component refs ontop.
I'm testing removing the GENERIC folding from create_component_ref_by_pieces_1.
Note we're refusing to GIMPLE fold this given the BIT_FIELD_REF operand
isn't a register.
