https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #4 from Alex Coplan <acoplan at gcc dot gnu.org> ---
I also get an unrecognisable insn ICE when compiling a variant of this testcase
where the FPMR has a compile-time unknown value:
$ cat t.c
#pragma GCC aarch64 "arm_sve.h"
svfloat16_t foo(svfloat16_t a, svmfloat8_t b, svmfloat8_t c, unsigned long fpm)
{
return svdot_lane_fpm (a, b, c, 0, fpm);
}
$ ./xgcc -B . -c t.c -O2 -S -o - -march=armv8.2-a+sve2+fp8dot2
.arch armv8.2-a+crc+sve2+fp8dot2
.file "t.c"
.text
t.c: In function ‘foo’:
t.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 10 9 14 2 (set (reg:VNx8HF 101 [ <retval> ])
(unspec:VNx8HF [
(reg/v:VNx8HF 102 [ a ])
(reg/v:VNx16QI 103 [ b ])
(reg/v:VNx16QI 104 [ c ])
(const_int 0 [0])
(reg:DI 84 fpmr)
] UNSPEC_DOT_LANE_FP8)) "t.c":4:10 -1
(nil))
during RTL pass: vregs
t.c:5:1: internal compiler error: in extract_insn, at recog.cc:2882
0x36f0265 internal_error(char const*, ...)
/fast/trunk/src/gcc/gcc/diagnostic-global-context.cc:517
0x36ade5c fancy_abort(char const*, int, char const*)
/fast/trunk/src/gcc/gcc/diagnostic.cc:1810
0x1984d6c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/fast/trunk/src/gcc/gcc/rtl-error.cc:108
0x1984db1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/fast/trunk/src/gcc/gcc/rtl-error.cc:116
0x1931a33 extract_insn(rtx_insn*)
/fast/trunk/src/gcc/gcc/recog.cc:2882
0x146bbc0 instantiate_virtual_regs_in_insn
/fast/trunk/src/gcc/gcc/function.cc:1609
0x146d23c instantiate_virtual_regs
/fast/trunk/src/gcc/gcc/function.cc:1985
0x146d320 execute
/fast/trunk/src/gcc/gcc/function.cc:2032
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The insn is recognised if +fp8dot4 is added, so I suspect the gating of this
insn is also wrong in the backend.
