On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
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.
Sounds like a target-independent bug in the making, lurking and
waiting for a target to do the above adjustment but missing the
bounds-check.
The normal canonicalize_comparison operation tries to simplify
expressions by reducing the value towards zero and making the
appropriate adjustment to the comparison. Arm is a bit different due to
the way constants are encoded and also because of the limitations on how
we expand DImode in the backend. So I don't think this is quite as
general as you suggest.
gcc/testsuite/gcc.dg/pr100563.c | 9 +++++++++
2 files changed, 34 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr100563.c
I'll therefore humbly suggest the test-case adjusted to be a
run-time check (and if not done by others, projecting to do that
myself...some time late next summer9.
That being said, I won't object if you want to /add/ an additional test
to try to catch this; but this test had to be quite carefully crafted to
hit the specific bug in the arm expanders, so I'd prefer that it wasn't
modified directly.
R.
brgds, H-P
