This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 6 Dec 2018 21:32:52 +0100
- Subject: Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367)
- References: <20181206064535.GN12380@tucnak> <4111f316-2383-d9ff-c5db-0b5f9475e9c7@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Dec 06, 2018 at 01:08:34PM -0700, Jeff Law wrote:
> > I hope we can still say that pointer wrapping even with
> > -fno-delete-null-pointer-checks is UB, so this patch differentiates between
> > positive offsets (in ssizetype), negative offsets (in ssizetype) and zero
> > offsets and handles both the same for both ptr p+ offset and &MEM_REF[ptr, offset]
> > If offset is 0 and ptr is ~[0, 0], then the result is ~[0, 0] as before.
> > If offset is positive in ssizetype, then even for VARYING ptr the result is
> > ~[0, 0] pointer. If the offset is (or maybe could be) negative in
> > ssizetype, then for -fno-delete-null-pointer-checks the result is VARYING,
> > as we could go from a non-NULL pointer back to NULL on those targets; for
> > -fdelete-null-pointer-checks we do what we've done before, i.e. ~[0, 0].
> I'm not sure why we'd treat subtraction and addition any differently,
> but maybe I'm missing something subtle (or not so subtle).
>
> ISTM that ~[0,0] +- <whatever> still results in ~[0,0] for
> -fdelete-null-pointer-checks.
Yes, the patch preserves that (unless -fwrapv-pointers).
Additionally, it does VARYING += ~[0,0] in that mode to ~[0,0].
> For -fno-delete-null-pointer-checks ISTM
> we should indicate "we don't know anything about the result" of such an
> operation.
There are cases where we still know something. The largest valid object
that can be supported is half of the address space, so without pointer
wrapping, positive additions to the pointer shouldn't wrap around and yield
NULL, negative ones can. With -fwrapv-pointers anything can happen, sure,
the only case handled in that case is &[ptr + 0] if ptr is ~[0, 0] then
&[ptr + 0] is also ~[0, 0].
Jakub