https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 9 Apr 2025, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399 > > Richard Sandiford <rsandifo at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot > gnu.org > > --- Comment #3 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- > Taking for the pointer difference. > > (In reply to Richard Biener from comment #2) > > Still the actual alias check looks prone to overflow issues since we do > > not distinguish before/after placement. > Could you go into more detail? The check is only performed when n>0, so we > know that q+4 is well-defined and that q<q+4. Yes, when q[i] is accessed a pointer to one-after-the-object should be constructable and after q. > We require the pointers to be > aligned to 4 bytes (otherwise there is UB in the input) I think in general we cannot assume alignment, I think we vectorize the same loop with packed ints (thus byte aligned) as well. >, so for a 4-element > vector, the only problem cases are p==q+4, p==q+8 and p==q+12. That's > equivalent to testing whether the unsigned value p-(q+4) <= 8. So the reasoning is that for p == q + 12 iff q + 12 wraps then it has to be outside of the object, thus n is low enough that we don't reach that point? w/o alignment knowledge problematic cases would include p == q + 1 to p == q + 15, but that would still be no problem I think, the same wrapping argument can be used to simplify the p == q + 15 compare to p - (q + 4) <= 11? What was the reason to not do p - q <= 15 (or 12)? But yes, it seems the actual problem is only the use of POINTER_DIFF_EXPR.
