On Wed, 22 Jul 2026, Jeff Law wrote: > > But isn't the caller (shifted_store_flag in this case I believe) > checking that the reversed code is not UNKNOWN already? Did I drop > that accidentally? Point being I think this might be a problem in the > caller.
You didn't drop it, the check is still there ... but: The problem is that the guard and the callee answer different questions. noce_reversed_cond_code returns GET_CODE (if_info->rev_cond) whenever a reversed condition exists. noce_emit_store_flag, however, only uses rev_cond when both of its operands pass general_operand; when that test fails, it falls back to "reversed_comparison_code (cond, if_info->jump)" which returns UNKNOWN here, because an ordered FP comparison under HONOR_NANS is not code-reversible. The backtrace goes through the guarded caller. The guard passes, but reversed_comparison_code (cond) returned UNKNOWN => rev_cond must have been non-NULL (canonicalized from the branch) but rejected by the general_operand test. So fixing this caller-side would mean teaching noce_reversed_cond_code about noce_emit_store_flag's internal general_operand and cond_complex handling. Checking in the callee covers all uses, which is why I put the bail-out there. I can also tighten noce_try_store_flag_logical's unguarded arm, but the callee-side check already subsumes it. Philipp. On Wed, Jul 22, 2026 09:53 PM, Jeffrey Law <[email protected]> wrote: > > > On 7/22/2026 12:50 AM, Philipp Tomsich wrote: > > noce_emit_store_flag feeds the possibly-reversed comparison code to a > > store-flag insn, and to emit_store_flag, without checking that the > > reversal succeeded. reversed_comparison_code returns UNKNOWN for > > UNLT/UNLE/UNGT/UNGE, and for a MODE_CC comparison it cannot trace back > > to its COMPARE -- common for a floating-point condition on targets that > > compare into a condition-code register. emit_store_flag then reaches > > its floating-point path and calls swap_condition (UNKNOWN), which aborts. > > > > This was latent until r17-2519-ga33f26607eb4f3 > (noce_try_shifted_store_flag), > > the first caller to reach noce_emit_store_flag with REVERSEP set for such > > a condition. > > > > Bail out early when the reversal failed. > > > > Bootstrapped and regression tested on aarch64-unknown-linux-gnu with no > > regressions. > > > > PR rtl-optimization/126347 > > gcc/ > > * ifcvt.cc (noce_emit_store_flag): Return NULL_RTX when the > > comparison code is UNKNOWN. > But isn't the caller (shifted_store_flag in this case I believe) > checking that the reversed code is not UNKNOWN already? Did I drop > that accidentally? Point being I think this might be a problem in the > caller. > > Jeff >
