https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126289
--- Comment #3 from Jeevitha <jeevitha at gcc dot gnu.org> ---
__builtin_bcdsub_ge expands to
(define_expand "bcd<bcd_add_sub>_<code>_<mode>"
[(parallel [(set (reg:CCFP CR6_REGNO)
(compare:CCFP
(unspec:V2DF [(match_operand:VBCD 1 "register_operand")
(match_operand:VBCD 2 "register_operand")
(match_operand:QI 3 "const_0_to_1_operand")]
UNSPEC_BCD_ADD_SUB)
(match_dup 4)))
(clobber (match_scratch:VBCD 5))])
(set (match_operand:SI 0 "register_operand")
(BCD_TEST:SI (reg:CCFP CR6_REGNO)
(const_int 0)))]
"TARGET_P8_VECTOR"
{
operands[4] = CONST0_RTX (V2DFmode);
})
whereas the pattern that would normally recognize the resulting ge comparison
is disabled when -ffinite-math-only is in effect:
(define_code_iterator fp_two [ltgt le ge unlt ungt uneq])
(define_insn_and_split "*<code><mode>_cc"
[(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
(fp_two:GPR (match_operand:CCFP 1 "cc_reg_operand" "y")
(const_int 0)))]
"!flag_finite_math_only"
"#"
"&& 1"
[(pc)]
{
rtx cc = rs6000_emit_fp_cror (<CODE>, <MODE>mode, operands[1]);
emit_move_insn (operands[0], gen_rtx_EQ (<MODE>mode, cc, const0_rtx));
DONE;
}
This is exactly the mismatch driving the ICE: the
bcd<bcd_add_sub>_<code>_<mode> expander unconditionally produces (ge:SI
(reg:CCFP CR6_REGNO) (const_int 0)) via the BCD_TEST iterator, with no
reference to flag_finite_math_only anywhere in the BCD path. The only pattern
that can recognize that RTL shape, however, is gated by
"!flag_finite_math_only", so as soon as that flag is enabled, the pattern is
unavailable and the BCD-generated insn is left with nothing to match against.
