]> git.ipfire.org Git - thirdparty/gcc.git/commit
ranger: Fix up fold_using_range::range_of_address [PR103255]
authorJakub Jelinek <jakub@redhat.com>
Wed, 17 Nov 2021 12:45:53 +0000 (13:45 +0100)
committerJakub Jelinek <jakub@redhat.com>
Wed, 17 Nov 2021 12:45:53 +0000 (13:45 +0100)
commitc39cb6bf835ca12e590eaa6f90222e51be207c50
tree9551bdb0e2e842f89422b87783b382c092be20f4
parent7061300025188d57e715c1593b8dae598c87b3c5
ranger: Fix up fold_using_range::range_of_address [PR103255]

If on &base->member the offset isn't constant or isn't zero and
-fdelete-null-pointer-checks and not -fwrapv-pointer and base has a range
that doesn't include NULL, we return the range of the base.
Usually it isn't a big deal, because for most pointers we just use
varying, range_zero and range_nonzero ranges and nothing beyond that,
but if a pointer is initialized from a constant, we actually track the
exact range and in that case this causes miscompilation.
As discussed on IRC, I think doing something like:
              offset_int off2;
              if (off_cst && off.is_constant (&off2))
                {
                  tree cst = wide_int_to_tree (sizetype, off2 / BITS_PER_UNIT);
                  // adjust range r with POINTER_PLUS_EXPR cst
                  if (!range_includes_zero_p (&r))
                    return true;
                }
              // Fallback
              r = range_nonzero (TREE_TYPE (gimple_assign_rhs1 (stmt)));
              return true;
could work, given that most of the pointer ranges are just the simple ones
perhaps it is too much for little benefit.

2021-11-17  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/103255
* gimple-range-fold.cc (fold_using_range::range_of_address): Return
range_nonzero rather than unadjusted base's range.  Formatting fixes.

* gcc.c-torture/execute/pr103255.c: New test.
gcc/gimple-range-fold.cc
gcc/testsuite/gcc.c-torture/execute/pr103255.c [new file with mode: 0644]