[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu May 13 14:19:09 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Earnshaw
<rearnsha@gcc.gnu.org>:
https://gcc.gnu.org/g:1d1a690b4dfa224228151fed4bed47c7fe412e0b
commit r10-9821-g1d1a690b4dfa224228151fed4bed47c7fe412e0b
Author: Richard Earnshaw <rearnsha@arm.com>
Date: Thu May 13 11:42:58 2021 +0100
arm: correctly handle inequality comparisons against max constants
[PR100563]
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be able to generate correct
code in these cases.
In this example, we have a comparison of the form
(unsigned long long) op <= ~0ULL
which, of course is always true.
Normally, in the arm back-end we handle these expansions where the
immediate cannot be handled directly by adding 1 to the constant and
then adjusting the comparison operator:
(unsigned long long) op < CONST + 1
but we cannot do that when the constant is already the largest value.
Fortunately, we observe that the comparisons we need to handle this
way are either always true or always false, so instead of forming a
comparison against the maximum value, we can replace it with a
comparison against the minimum value (which just happens to also be a
constant we can handle. So
op1 <= ~0ULL -> op1 >= 0U
op1 > ~0ULL -> op1 < 0U
op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1)
op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1)
gcc:
PR target/100563
* config/arm/arm.c (arm_canonicalize_comparison): Correctly
canonicalize DImode inequality comparisons against the
maximum integral value.
gcc/testsuite:
* gcc.dg/pr100563.c: New test.
More information about the Gcc-bugs
mailing list