This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/79734] [6/7 Regression] ICE: verify_gimple failed


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79734

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> I think the problem is that generic vector lowering isn't prepared to handle
> _4 = VEC_COND_EXPR <_3 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }, { 0, 0, 0, 0 },
> { -1, -1, -1, -1 }>;
> where _3 is V4SFmode vector and _4, { 0, 0, 0, 0 } and { -1, -1, -1, -1 } are
> QImode (i.e. the AVX512-ish boolean vectors).  The vectorizer would try to
> do something like _5 = _3 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> _4 = ~_5;
> in this case I believe.
> So, either we shouldn't create these at all (but they come from the FEs
> already), or expand_vec_cond_expr_p/expand_vec_cond_expr should also handle
> the cases where value_type is VECTOR_BOOLEAN_TYPE_P but cmp_op_type is not
> (use a new optab for it, or expand directly) and value_mode is MODE_INT?
> If one or both of rhs2 and rhs3 are constant, then it can be expanded into
> performing the comparison first and on the VECTOR_BOOLEAN_TYPE with MODE_INT
> result do bitwise ops, (cmp_result & rhs2) | ((~cmp_result) & rhs3) with
> simplifications if rhs2 and/or rhs3 is a constant true or false vector.
> 
> So, shall we handle this in the FEs, or transform it in vector lowering to
> the bitwise stuff, something different?

I'd be fine with handling this in vector lowering.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]