https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Aldy Hernandez <al...@gcc.gnu.org>: https://gcc.gnu.org/g:054d7b9f6f6816a83dcadfdfe2532795cae04ff3 commit r11-4532-g054d7b9f6f6816a83dcadfdfe2532795cae04ff3 Author: Aldy Hernandez <al...@redhat.com> Date: Thu Oct 22 08:39:04 2020 +0200 Selectively trap if ranger and vr-values disagree on range builtins. The UBSAN builtins degrade into PLUS/MINUS/MULT and call extract_range_from_binary_expr, which as the PR shows, can special case some symbolics which the ranger doesn't currently handle. Looking at vr_values::extract_range_builtin(), I see that every single place where we ask for a range, we bail on non-integers (symbolics, etc). That is, with the exception of the UBSAN builtins. Since this seems to be particular to UBSAN, we could still go with the original plan of removing the duplicity in ranger vs vr-values, but leave in the UBSAN builtin handling. This isn't ideal, as we'd like to remove all the common code, but I'd be willing to put up with UBSAN duplication for the time being. This patch disables the assert on the UBSAN builtins, while still trapping if any other differences are found between the vr_values and the ranger versions of builtin range handling. As a follow-up, once Fedora can test this approach, I'll remove all the builtin code from extract_range_builtin, with the exception of the UBSAN stuff (renaming it to extract_range_ubsan_builtin). Since the builtin code has proven fickle across architectures, I've tested this with {-m32,-m64,-fsanitize=signed-integer-overflow} on x86, ppc64le, and aarch64. I think this should be enough. If it isn't, we can revert the patch, and leave the duplicate code until the next release cycle when hopefully vr_values, evrp, and friends will all be overhauled. gcc/ChangeLog: PR tree-optimization/97505 * vr-values.c (vr_values::extract_range_basic): Enable trap again for everything except UBSAN builtins.
