https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-9 branch has been updated by Tamar Christina <tnfch...@gcc.gnu.org>: https://gcc.gnu.org/g:f6e9ae4da8f040ab2ef2eb37d0fb4da6f823bf81 commit r9-8210-gf6e9ae4da8f040ab2ef2eb37d0fb4da6f823bf81 Author: Tamar Christina <tamar.christ...@arm.com> Date: Tue Feb 11 10:50:12 2020 +0000 middle-end: Fix logical shift truncation (PR rtl-optimization/91838) (gcc-9 backport) This fixes a fall-out from a patch I had submitted two years ago which started allowing simplify-rtx to fold logical right shifts by offsets a followed by b into >> (a + b). However this can generate inefficient code when the resulting shift count ends up being the same as the size of the shift mode. This will create some undefined behavior on most platforms. This patch changes to code to truncate to 0 if the shift amount goes out of range. Before my older patch this used to happen in combine when it saw the two shifts. However since we combine them here combine never gets a chance to truncate them. The issue mostly affects GCC 8 and 9 since on 10 the back-end knows how to deal with this shift constant but it's better to do the right thing in simplify-rtx. Note that this doesn't take care of the Arithmetic shift where you could replace the constant with MODE_BITS (mode) - 1, but that's not a regression so punting it. gcc/ChangeLog: Backport from mainline 2020-01-31 Tamar Christina <tamar.christ...@arm.com> PR rtl-optimization/91838 * simplify-rtx.c (simplify_binary_operation_1): Update LSHIFTRT case to truncate if allowed or reject combination. gcc/testsuite/ChangeLog: Backport from mainline 2020-01-31 Tamar Christina <tamar.christ...@arm.com> Jakub Jelinek <ja...@redhat.com> PR rtl-optimization/91838 * g++.dg/opt/pr91838.C: New test.
