On 9/30/26 12:50 AM, Dominic P wrote:
dom3 now folds the limit of the second SVE control in a widening loop,
MAX (33, [2, 2]) - [2, 2], to the unsigned int POLY_INT_CST [31, 4294967294],
i.e. 31 - 2x. fold_const_call read that as the poly_uint64
31 + 4294967294x, so .WHILE_ULT (0, 31 - 2x) became all-true and the first
vector iteration stored past the end of the array for VL >= 1152 bits.
Read the limit as poly_int64, which sign-extends POLY_INT_CST coefficients,
and fold only if it is known to be nonnegative. The MAX fold appeared with
a3fb4bf350d (POLY_INT_CST bounds for SVE), which also lowered the whilelo
counts in slp_12.c; those folds were right only because x <= 15 there, so
restore the old counts. GCC 16 is not affected.
Bootstrapped and regression tested on x86_64-pc-linux-gnu; regression
tested on aarch64-linux-gnu (qemu, VL 128 and SVE VL 2048).
Assisted-by: Claude Opus 5 (Anthropic)
gcc/ChangeLog:
* fold-const-call.cc (fold_const_call) <CFN_WHILE_ULT>: Read the
limit as poly_int64 and require it to be known nonnegative.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/slp_12.c: Restore the whilelo counts.
* gcc.target/aarch64/sve/while_ult_poly_1.c: New test.
* gcc.target/aarch64/sve/while_ult_poly_1_run.c: New test.
Signed-off-by: Dominic P <[email protected]>
---
OK for trunk?
I think Tamar should probably chime in here.
Jeff
