[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
crazylht at gmail dot com
gcc-bugzilla@gcc.gnu.org
Fri Sep 3 07:58:01 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #15 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to Jonathan Wakely from comment #13)
> > Is this also the cause of several libstdc++ FAILs on ppc64le?
>
>
> Yes.
>
> I have asked for reversion of g:d2874d905647:
>
> <https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578714.html>
as discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow
specific float-int subreg seems weird.
And when i look the pattern, it also seems to be strange to disallow subreg in
operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in
TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing.
define_insn "movsf_hardfloat"
[(set (match_operand:SF 0 "nonimmediate_operand"
"=!r, f, v, wa, m, wY,
Z, m, wa, !r, f, wa,
!r, *c*l, !r, *h")
(match_operand:SF 1 "input_operand"
"m, m, wY, Z, f, v,
wa, r, j, j, f, wa,
r, r, *h, 0"))]
"(register_operand (operands[0], SFmode)
|| register_operand (operands[1], SFmode))
&& TARGET_HARD_FLOAT
&& (TARGET_ALLOW_SF_SUBREG
|| valid_sf_si_move (operands[0], operands[1], SFmode))"
More information about the Gcc-bugs
mailing list