https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #16 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Andrew Macleod from comment #12)
> > Maybe I'm a little dense.
> >
> > if we are presuming that
> > &x + (a + b)
> > implies a + b == 0, then we also should assume that
>
> &x + (a + b) for scalar x doesn't imply a + b == 0, it implies a + b <= 1.
> Only when it is dereferenced, i.e. (&x)[a + b] is accessed a + b has to be 0.
OK. certain things about this still confuse me, but thats OK for now. we'll
come back to them.
There seems to be 2 things at play here:
1) lhs = ptr + X
has certain implications on X, it ptr is &scalar then X = [0, 1] * sizeof
(&scalar)?
2) if lhs is later de-referenced, then X is known to have been [0,0]?
We're ignoring the nonscalar cases of ptr for now, but Im guessing they are
similar just the values for X are determined differently.
1) a) could be handled with something like a previously mentioned
range_after_stmt() API for operands which are affected by statements.
b) It can also be impacted by op2_range() during a wind back, but would
likely require some tweaking of gimple_range_calc_op2() to determine that 'ptr'
satisfied the criteria of this scalar condition. the a) solution would
eliminate the necessity of this.
2) This one is a bit trickier. We cant use the non-null property since &x +
blah will already make it non-null... so you are looking for an actual
dereference of itself or an equivalence? I can probably tweak the non-null
property manager to indicate whether the non-null property also contains a
dereference.. but I guess you would need to know that ALL paths contain a
dereference.
We'd probably get most of what we're looking for if we simply check for a
dereference of LHS in the same block? and then assert that X is 0.
Is that he basic gist?
Regardless, I'll come back to this eventually and get someone to clarify all
the intricacies for me, IM just trying to understand the general requirements.
