https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-03-15
Known to fail| |11.0
Ever confirmed|0 |1
CC| |ktkachov at gcc dot gnu.org,
| |sripar01 at gcc dot gnu.org
Keywords| |ice-on-valid-code
Target|arm |arm-eabi
Status|UNCONFIRMED |NEW
--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
The problematic insn is:
(insn 8 7 9 2 (set (reg:V4SI 119)
(const_vector:V4SI [
(const_int 4095 [0xfff])
(const_int 0 [0]) repeated x3
])) "ice.c":3:21 2998 {*mve_movv4si}
(nil))
We ICE in the output code for *mve_mov<mode> with which_alternative == 4. It
looks like the constraint is wrong for this alternative:
(define_insn "*mve_mov<mode>"
[(set (match_operand:MVE_types 0 "nonimmediate_operand"
"=w,w,r,w,w,r,w,Ux,w")
(match_operand:MVE_types 1 "general_operand"
"w,r,w,Dn,Uxi,r,Dm,w,Ul"))]
Unless I'm missing something, I don't think "Uxi" is a valid constraint.
Perhaps the "Ux" constraint was intended instead?
If the constraint really is invalid, it would be nice to catch this earlier
(ideally when the MD files are processed at build time).
Changing the constraint to Ux leads to cycling in LRA. Perhaps something went
wrong at expand time? Need to do some more debugging.
