https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103255
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:c39cb6bf835ca12e590eaa6f90222e51be207c50 commit r12-5336-gc39cb6bf835ca12e590eaa6f90222e51be207c50 Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Nov 17 13:45:53 2021 +0100 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 <ja...@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.
