https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |11.3.0, 13.0, 9.1.0
Target Milestone|--- |11.4
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-12-15
Summary|ICE: in extract_insn, at |[11/12/13 Regression] ICE:
|recog.cc:2791 (on ARM with |in extract_insn, at
|-mfpu=neon |recog.cc:2791 (on ARM with
|-freciprocal-math -O3) |-mfpu=neon
| |-freciprocal-math -O3)
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. there is a mismatch between div<mode>3 and ARM_HAVE_NEON_V2SF_ARITH
(ARM_HAVE_NEON_V4SF_ARITH )
/* SF operations always flush to zero, regardless of FPSCR.FZ, so we can
only use them for general arithmetic when -funsafe-math-optimizations
is in effect. */
#define ARM_HAVE_NEON_V2SF_ARITH \
(TARGET_NEON && flag_unsafe_math_optimizations)
#define ARM_HAVE_NEON_V4SF_ARITH ARM_HAVE_NEON_V2SF_ARITH
(define_expand "div<mode>3"
[(set (match_operand:VCVTF 0 "s_register_operand")
(div:VCVTF (match_operand:VCVTF 1 "s_register_operand")
(match_operand:VCVTF 2 "s_register_operand")))]
"TARGET_NEON && !optimize_size
&& flag_reciprocal_math"
This mismatch was introduced with r9-3954-g536ecfc44b1fd2 which introduced the
div<mode>3 (note ARM_HAVE_NEON_V4SF_ARITH was done differently but still have
the check on flag_unsafe_math_optimizations).
I suspect div<mode>3 here should become:
(define_expand "div<mode>3"
[(set (match_operand:VCVTF 0 "s_register_operand")
(div:VCVTF (match_operand:VCVTF 1 "s_register_operand")
(match_operand:VCVTF 2 "s_register_operand")))]
"ARM_HAVE_NEON_<MODE>_ARITH && !optimize_size
&& flag_reciprocal_math"
Note the iterator here maybe should be VF too but I am not 100% sure the HF
modes support all the instructions that this generates.
