https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #41 from Kewen Lin <linkw at gcc dot gnu.org> --- (In reply to Kewen Lin from comment #40) > > >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc > > >index d666ccccf67..7d8b4ac2200 100644 > > >--- a/gcc/internal-fn.cc > > >+++ b/gcc/internal-fn.cc > > >@@ -3750,7 +3750,12 @@ static bool > > > direct_optab_supported_p (direct_optab optab, tree_pair types, > > > optimization_type opt_type) > > > { > > >- machine_mode mode = TYPE_MODE (types.first); > > >+ tree type = types.first; > > >+ machine_mode mode = TYPE_MODE (type); > > >+ /* Scalar mode optab can't work for vector type, return false if > > >+ the given type is vector type but the mode isn't vector mode. */ > > >+ if (VECTOR_TYPE_P (type) != VECTOR_MODE_P (mode)) > > >+ return false; > > > > There are a few which scalar mode and vector types can differ and still > > work: IOR, XOR, and AND. I wonder if those should be special cased here or > > somewhere else. > > Good point! This is overkill then. Not sure if there is this kind of routine > to special case them. When I was cooking one function to special case Andrew's concerns, I realized that the touched functions direct_optab_supported_p, convert_optab_supported_p and multi_vector_optab_supported_p are only for optabs used in internal-fn.def, for now there are not {and,ior,xor}_optab or their similars (I quickly went through binary/unary ones). So it seems we don't need to consider this for now?