https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #4)
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index a6cf0a5546c..ae6abe00f3e 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -8505,7 +8505,8 @@ vect_transform_reduction (loop_vec_info loop_vinfo,
> {
> gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB
> || code == IFN_COND_MUL || code == IFN_COND_AND
> - || code == IFN_COND_IOR || code == IFN_COND_XOR);
> + || code == IFN_COND_IOR || code == IFN_COND_XOR
> + || code == IFN_COND_MIN);
> gcc_assert (op.num_ops == 4
> && (op.ops[reduc_index]
> == op.ops[internal_fn_else_index ((internal_fn)
> code)]));
>
> Could fix the ICE.
Why IFN_COND_MIN and not IFN_COND_MAX?
What about other binary cond_fns? I see
DIV/MOD/RDIV/COPYSIGN/FMIN/FMAX/SHL/SHR.
Though, SHL/SHR/COPYSIGN/DIV/MOD/RDIV aren't commutative nor associative, dunno
about
if FMIN/FMAX could trigger. But certainly IFN_COND_MAX should be handled next
to IFN_COND_MIN.
