Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367)

[Jeff Law <law at redhat dot com>]

On 12/5/18 11:45 PM, Jakub Jelinek wrote:
> Hi!
> 
> If we consider -fno-delete-null-pointer-checks as a way to support e.g. AVR
> and other targets which can validly place objects at NULL rather than a way
> to workaround UBs in code, I believe the following testcase must pass if
> there is e.g.
Well, the intent was to be able to turn off the assumption that *0 would
cause a fault and halt the program.  That assumption allows us to use an
earlier pointer dereference to infer it currently has a non-NULL value
and eliminate subsequent tests against NULL.

It was never really meant to be a general escape hatch to allow other
forms of undefined behavior.

Though the name is particularly bad since it implies we never delete any
null pointer checks.


> 
> 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.  For -fno-delete-null-pointer-checks ISTM
we should indicate "we don't know anything about the result" of such an
operation.


Jeff