https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99824
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we're value-numbering a char load
Value numbering stmt = _177 = *sc_175;
with sc_175 == _7 and
_7 = &cx_41(D)->i2c_adap[i_24].name;
which get's us a valueized ref (of type 'char') that looks like
cx_41(D)->i2c_adap[i_24].name and ao_ref_init_from_vn_reference turning
that into
$1 = {ref = <tree 0x0>, base = <mem_ref 0x7ffff521cf28>,
offset = {<poly_int_pod<1, long>> = {coeffs = {388000}}, <No data fields>},
size = {<poly_int_pod<1, long>> = {coeffs = {384}}, <No data fields>},
max_size = {<poly_int_pod<1, long>> = {coeffs = {384}}, <No data fields>},
ref_alias_set = 0, base_alias_set = 0, volatile_p = false}
because it looks at COMPONENT_REF/BIT_FIELD_REF sizes but those really only
represent offsets (well, not really really, but ...).
We then arrive at
# .MEM_170 = VDEF <.MEM_169>
cx_41(D)->i2c_adap[i_24].name = "cx18 i2c driver";
So this looks like a latent thing waiting to happen. The GIMPLE FE is
currently not happy to produce a testcase. Trunk is somewhat more
resilent to produce the situation since vn_reference_maybe_forwprop_address
uses the SSA lattice for the address offset calculation (in this case
i_24 has value zero).
With the proposed assert at least the LTRANS unit reproduces an ICE
with a debug build for me.
