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
