On Tue, 18 May 2021, Richard Earnshaw wrote: > 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.
It just seemed I had done something similar somewhere in another port, though I can't find it. I could also have only read it... > > > 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. Right. I expressed myself poorly as I share your concerns on this point: after the public commit of a test that had no error, it must never be modified. To wit, such an "adjustment" must be made in the form of an additional, separate test. brgds, H-P
