https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 16 Nov 2022, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655 > > Andrew Macleod <amacleod at redhat dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > Assignee|unassigned at gcc dot gnu.org |amacleod at redhat > dot com > > --- Comment #14 from Andrew Macleod <amacleod at redhat dot com> --- > Created attachment 53910 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53910&action=edit > patch to fix the problem > > This patch fixes the PR, but exposes issues in other passes. They introduce > undefined behaviour by hoisting POINTER_PLUS expressions into blocks in which > the operand is not known to be non-null. (See PR 107709) > Until this can be audited fully, we put this patch on hold. In fact the patch doesnt 'exploit the fact that the result of pointer addition can not be nullptr' but it exploits that if ptr + CST is performed then 'ptr' cannot be nullptr(?) That is, it assumes that there is a zero sized object at nullptr and thus the pointer increment to outside (but not one after it) invokes UB. That's much more aggressive than optimizing ptr + 4 != nullptr to true and I'm not sure the reasoning follows. I think at 'nullptr' there is _no_ object and thus the restriction to pointer addition doesn't apply at all - if a pointer does not refer to an object then the rule that increment to outside of the object invokes UB doesn't apply.
