http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52760
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-29 13:19:33 UTC --- On Thu, 29 Mar 2012, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52760 > > --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-29 > 12:54:31 UTC --- > (In reply to comment #7) > > (In reply to comment #6) > > > Created attachment 27030 [details] > > > gcc48-pr52760.patch > > > > > > So do you prefer this instead? > > > > Yes. In a non-constant case we'd miss a conversion, so I suppose we only > > expect constant shift counts here - which means you should assert > > constant_p instead of verifying it. > > vectorizable_shift has > > /* Unlike the other binary operators, shifts/rotates have > the rhs being int, instead of the same type as the lhs, > so make sure the scalar is the right type if we are > dealing with vectors of long long/long/short/char. */ > if (dt[1] == vect_constant_def) > op1 = fold_convert (TREE_TYPE (vectype), op1); > else if (!useless_type_conversion_p (TREE_TYPE (vectype), > TREE_TYPE (op1))) > { > if (slp_node > && TYPE_MODE (TREE_TYPE (vectype)) > != TYPE_MODE (TREE_TYPE (op1))) > { > if (vect_print_dump_info (REPORT_DETAILS)) > fprintf (vect_dump, "unusable type for last operand in" > " vector/vector shift/rotate."); > return false; > } > so, it can be non-constant just fine, but in that case would just have the > same > mode. So asserting constant_p there would be wrong. Hmm, but certainly the same mode is not a compatible type. I suppose we just do not verify that the constructor elements have compatible type to the vector component type anywhere. Note the previous fix in this place has been triggered by the assert in build_vector_from_val.
