This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

# Re: [patch] tree-vrp.c: Compute a correct range when adding twopointers.

*From*: Jeffrey A Law <law at redhat dot com>
*To*: Kazu Hirata <kazu at codesourcery dot com>
*Cc*: gcc-patches at gcc dot gnu dot org, dnovillo at redhat dot com
*Date*: Thu, 23 Jun 2005 09:29:09 -0600
*Subject*: Re: [patch] tree-vrp.c: Compute a correct range when adding twopointers.
*References*: <200506231511.j5NFBSrS029224@sethra.codesourcery.com>
*Reply-to*: law at redhat dot com

On Thu, 2005-06-23 at 08:11 -0700, Kazu Hirata wrote:
> Hi,
>
> Attached is a patch to compute a correct range when adding two pointers.
>
> Consider
>
> void
> foo (int *p, int q)
> {
> if (p == 0)
> {
> if (q == 0)
> {
> int *r = &p[q];
> if (r != 0)
> link_error ();
> }
> }
> }
>
> After passing the first two "if" statements, we know that p and q are
> both 0, so r, which is really &p[q], must also be 0. However, VRP
> thinks that an addition of two pointers *always* results in nonnull,
> which isn't true.
>
> The patch fixes this problem by examing the value ranges of a
> PLUS_EXPR's operands. If either one is nonnull, the result is
> nonnull. If both are null, the result is obviously null. Otherwise,
> the result is VR_VARYING.
>
> Tested on x86_64-pc-linux-gnu. OK to apply?
Does this ever happen in practice? While I can follow the reasoning
which leads to a non-null result for R, I have a hard time seeing
this happening often enough in real code to matter.
If you want to do something interesting with VRP you might look at
extracting ranges from BIT_AND_EXPRs -- that's relatively common and
can often lead to further optimizations, particularly when the
BIT_AND_EXPR turns off the sign bit or constrains a result to a
smaller type.
jeff