On 10/22/26 9:33 PM, Igor Shevlyakov wrote:
On 10/22/26 5:48 PM, Jeff Law wrote:
> Is this still relevant or is it subsumed by the if-combine fix?
It is still needed. The ifcombine fix (r17-4921, "Preserve comparison
operand order when if-combining") makes ifcombine pass the comparisons
in evaluation order, which covers the short-circuited case. This patch
is about the callers that combine two comparisons that are both
evaluated: reassoc, for the operands of a BIT_AND_EXPR or BIT_IOR_EXPR,
and if-conversion's fold_or_predicates. They still pass
TRUTH_ANDIF_EXPR/TRUTH_ORIF_EXPR, so combine_comparisons may drop the
exception of the second comparison. On current trunk at -O2 on
x86_64, all three examples in the patch still return without raising
FE_INVALID for a quiet NaN operand; with the patch they raise it.
It does not depend on patch 1/2, so I will repost it on its own as v2,
rebased onto current trunk, with its execution test in a file of its own
(in this version it adds to the test that patch 1/2 creates).
Sounds good, I'm burning through the backlog, but making progress.
Hopefully I'll get to it shortly after posting.
jeff
