On 12/19/25 03:31, Richard Biener wrote:
On Thu, Dec 18, 2025 at 11:42 PM Andrew MacLeod <[email protected]> wrote:This was exposed by the new prange PTA code, but it does show up in trunk, and back as far as GCC 13. GORI aggressively recomputes values when the inputs have changed on conditi0nal branches. It avoids PHIS and statements with side effects, but pretty much tries everything else. THis is too agressive as the following test case shows: int foo (int x) { int y = __builtin_constant_p (x); if (y) isconst (y, x); else nonconst (y, x); if (x == 24) { /* Y should have the same value as earlier. */ if (y) isconst (y, x); else nonconst (y, x); } } y evaluates to [0, 0] as x is not a constant. However, in the conditional branch x is known to be 24, and GORi recomputes y using this values, and since [24, 24] is a constant, decides y is [1, 1] in this block and promptly folds the condition and leaves a call to isconst (1,24) instead of the correct nonconst (0, 24) This hasn't really been much of a problem because for most non range-op statetmets, changing the inputs is not likely to change the resulting range. Given that, its probably a waste of time to even try. This patch adds a fields to the gimple_range_op_handler class wihch indicates whether the range_operator is recomputable or not, and defaults them to yes. GORI then checks this method instead to determine if recomputation should be attempted. Finally, the flag is set to false for the __builtin_constant_p handler to avoid recomputing this. All the rest are OK I think. Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?OK. I suspect this also affects branches? Yeah, as far back as GCC 13 I think.
Andrew
