[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

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))"