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
