https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123956
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |rdapp at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So while it's avlprop complaining I think things actually go wrong before then.
In particular we have this insn in .reload:
(insn 14 151 150 3 (set (reg/v:RVVM2SI 98 v2 [orig:143 sumAB ] [143])
(if_then_else:RVVM2SI (unspec:RVVMF16BI [
(const_vector:RVVMF16BI repeat [
(const_int 1 [0x1])
])
(reg:DI 20 s4 [164])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(ashift:RVVM2SI (reg/v:RVVM2SI 98 v2 [orig:143 sumAB ] [143])
(const_int 4 [0x4]))
(unspec:RVVM2SI [
(reg:DI 0 zero)
We substituted the (const_int 4) for the shift count which had been a reg
earlier. That would seem to be fine as thead allows 0..31. But if we look
at the pattern we have:
(any_shift:V_VLSI
(match_operand:V_VLSI 3 "register_operand" "vr,vr, vr,
vr,vr,vr, vr, vr")
(match_operand 4 "pmode_reg_or_uimm5_operand" " r, r, r, r, K, K,
K, K"))
Which looks sensible. If we dive into operand4's predicate:
;; pmode_reg_or_uimm5_operand can be used by vsll.vx/vsrl.vx/vsra.vx
instructions.
;; Since it has the same predicate with vector_length_operand which allows
register
;; or immediate (0 ~ 31), we define this predicate same as
vector_length_operand here.
;; We don't use vector_length_operand directly to predicate
vsll.vx/vsrl.vx/vsra.vx
;; since it may be confusing.
(define_special_predicate "pmode_reg_or_uimm5_operand"
(match_operand 0 "vector_length_operand"))
Uh-oh. Now things are getting interesting. vector_length_operand's behavior
varies based on thead-vector where the only constant allowed is zero. So
naturally the insn won't successfully recognize at this point, but we don't
actually try to recognize it until after making an unrelated change in avlprop.
The fix (of course) is to not abuse vector_length_operand like that. And now
that I think about it, I think that's been fixed as well. Yup. pr122051,
reported by Zdenek's fuzzer. We haven't been terribly aggressive about
backporting fixes for fuzzer detected bugs, especially for those which are not
silent failures. Anyway, now that we've seen this in the wild, backporting is
obviously the right step. I'll take care of that momentarily.
*** This bug has been marked as a duplicate of bug 122051 ***
