> > Recently I proposed that implicit conversions between vectors with > differing numbers of elements yet the same total bitlength be disallowed. > It was agreed that this was reasonable, and I shall be submitting a > patch to vector_types_convertible_p and the testsuite in the near future. > > I would now like to propose that the check in that function be made > even stronger such that it disallows conversions between vectors > whose element types differ -- even if an implicit conversion exists > between those element types. > > There are three examples I know about where it seems that this decision > has been made: > > - the C++ valarray class, whose assignment operators are declared to > be of the form (note the parameterization upon only one type): > > valarray<T>& operator=(const valarray<T>&); > > - the AltiVec programming interface manual, which reads in section > 2.4.2 "If either the left hand side or right hand side of an expression > has a vector type, then both sides of the expression must be of the same > vector type."; > > - the ARM NEON architecture, where there is a similar expectation.
And the "C/C++ Language extension for CBEA 2.2" (and the older "SPU C/C++ Langauge Extensions 2.1") says: If either the left or right side of an expression has a vector type, both sides of the expression must be of the same vector type. Thus, the expression a = b is valid and represents assignment if a and b are of the same type or if neither variable is a vector type. Otherwise, the expression is invalid, and the compiler reports the inconsistency as an error. Which follows exactly the Altivec PIM. I think we should reject those cases. The Altivec PIM is very clear about "vec_add(vector unsigned int, vector signed int)", it is not valid code. Likewise the "C/C++ Language extension for CBEA 2.2" is also clear with respect of "spu_add (vector unsigned int, vector signed int)". If we accept those what is the return type? Thanks, Andrew Pinski
