On 7/22/2026 8:15 AM, Philipp Tomsich wrote:
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.
Ah. I see. I haven't really analyzed it, but I suspect that
cond_complex condition could lead to similar problems given it inverts
reversep. Both your issue and that would suggest fixing
noce_emit_store_flag.
Anyway OK for the trunk. I suspect there's cleanups we could do in the
callers given the improved checking down in noce_emit_store_flag.
jeff
