https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117912
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> From what I can see, this VN is purely from vn_reference_eq and it just
> skips over
> the COMPONENT_REFs after taking into account their vro?->off (but I do not
> yet understand why the similar case with unions isn't handled the same).
> So if we want to disallow value numbering them the same before PROP_objsz in
> problematic cases which lead to same offset through different access path,
> we'd need to do it somewhere before for (; vr1->operands.iterate (i, &vro1);
> i++).
> And the problematic cases for objsz are either zero sized FIELD_DECLs (one
> of them but not both), or I guess as well starting offset of one field vs.
> ending offset of another field, say if we have
> struct S { char a[24]; char b[24]; char c; };
> and struct S *p, then &p->a[24] might value number the same as &p->b[0] or
> vice versa, but __builtin_object_size (, 1) in one case should be 0 and in
> the other case should be 24 (minimum with actual object size).
The protection against !PROP_objsz works by _not_ setting .off in
copy_reference_ops_from_ref. The issue in this case is this doesn't
trigger because the check only prohibits a zero offset?!
poly_offset_int off
= (wi::to_poly_offset (this_offset)
+ (wi::to_offset (bit_offset) >> LOG2_BITS_PER_UNIT));
/* Probibit value-numbering zero offset components
of addresses the same before the pass folding
__builtin_object_size had a chance to run. */
if (TREE_CODE (orig) != ADDR_EXPR
|| maybe_ne (off, 0)
|| (cfun->curr_properties & PROP_objsz))
off.to_shwi (&temp.off);
it seems to be this way since forever - r0-126594-g1eadb567eff34d introduced it
this way. Likely the intent was to cover addresses of union components only
here and not out-of-bound array offsets. So possibly the "fix" that's
least intrusive on FRE performance is to put a similar guard for
known-out-of-bound array indicies.
