Another bug found while chasing paths to fix the remaining issues in
pr116256.
This case is sometimes benign when the optimizers are enabled. But
could show up in a -O0 compile with some patterns I was playing around with.
Basically we have a predicate that is meant to return true if bits set
in the operand are all consecutive.
That predicate would return the wrong value when presented with
(const_int 0) indicating it had a run of on bits when obviously no bits
are on ;-)
It's pretty obvious once you look at the implementation.
if (exact_log2 ((val >> ctz_hwi (val)) + 1) < 0)
return false
return true;
The right shift is always going to produce 0. 0 + 1 = 1 which is a
power of 2. So exact_log2 returns 0 and we get a true result rather
than a false result.
The fix is trivial. "<=". While inside we might as well fix the
formatting.
Tested on rv32 and rv64 in my tester. Waiting on upstream pre-commit
testing to render a verdict.
jeff
PR target/116256
gcc/
* config/riscv/predicates.md (consecutive_bits_operand): Properly
handle (const_int 0).
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 1f67d30be9d..f26bafcc688 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -423,11 +423,11 @@ (define_predicate "imm123_operand"
(define_predicate "consecutive_bits_operand"
(match_code "const_int")
{
- unsigned HOST_WIDE_INT val = UINTVAL (op);
- if (exact_log2 ((val >> ctz_hwi (val)) + 1) < 0)
- return false;
+ unsigned HOST_WIDE_INT val = UINTVAL (op);
+ if (exact_log2 ((val >> ctz_hwi (val)) + 1) <= 0)
+ return false;
- return true;
+ return true;
})
(define_predicate "const_two_s12"
