https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734
Bug ID: 88734
Summary: [8/9 Regression] AArch64's ACLE intrinsics give an ICE
instead of compile error when option mismatch.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Using a neon intrinsics with the wrong commandline option used to lead to a
nice options mismatch error. Instead now in GCC 8 and 9 we get an ICE from
recog because the RTX is generated but can't be matched.
This code
```
#include <arm_neon.h>
int main ()
{
float32x4_t r = {0};
float16x8_t a = {0};
float16x8_t b = {0};
float32x4_t res = vfmlslq_laneq_high_u32 (r, a, b, 0);
return 0;
}
```
shouldn't ice when compiled with
```
aarch64-none-elf-gcc test2.c -specs=aem-validation.specs -O3
```
but it does with
```
test2.c: In function 'main':
test2.c:10:1: error: unrecognizable insn:
}
^
(insn 8 7 9 2 (set (reg:V4SF 91)
(fma:V4SF (float_extend:V4SF (neg:V4HF (vec_select:V4HF (reg:V8HF 93)
(parallel:V8HF [
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
]))))
(float_extend:V4SF (vec_duplicate:V4HF (vec_select:HF (reg:V8HF 94)
(parallel [
(const_int 0 [0])
]))))
(reg:V4SF 92))) "arm_neon.h":32284 -1
(nil))
during RTL pass: vregs
test2.c:10:1: internal compiler error: in extract_insn, at recog.c:2304
```
The RTX is generated when it shouldn't have been.
Seems to be an issue in arm_neon.h, one option after vadd_f16 must have popped
something it shouldn't have as that works.
The expected behavior is to get
```
../include/arm_neon.h:18282:1: error: inlining failed in call to always_inline
'vfmlslq_laneq_high_u32': target specific option mismatch
18282 | vfmlslq_laneq_high_u32 (float32x4_t __r, float16x8_t __a, float16x8_t
__b,
| ^~~~~~~~~~~~~~~~~~~~~~
test2.c:8:21: note: called from here
8 | float32x4_t res = vfmlslq_laneq_high_u32 (r, a, b, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
as one does on arm-*
