https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118692
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
CC| |jakub at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
Last reconfirmed| |2025-01-29
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We expand
vect__6.6_4 = MEM <vector(2) double> [(double *)&c + 8143523003042804629B];
again via the
11809 exp = build3 (BIT_FIELD_REF, type, base, TYPE_SIZE (type),
11810 bitsize_int (offset * BITS_PER_UNIT));
11811 REF_REVERSE_STORAGE_ORDER (exp) = reverse;
11812 return expand_expr (exp, target, tmode, modifier);
fallback. The issue is offset * 8 is "negative", more to the point,
it overflows poly_uint64. It should in reality use poly_offset_int
and the assert in bit_field_offset is problematic. Similar issues
would exist for TYPE_SIZE.
Changing bit_field_{offset,size} to return poly_offset_int is probably
the correct thing to do?
Note I do not like the above BIT_FIELD_REF fallback much, the other
fallback is stack. I'm not sure if we invoke this fallback for
EXPAND_WRITE for example ... (but why not).
The trivial fix for the regression part is to avoid the use of
bit_field_{offset,size} in tree_could_trap_p/bit_field_ref_in_bounds_p.
I'm going to do that now.
