Re: Even stricter implicit conversions between vectors

[Andrew Pinski <pinskia at physics dot uc dot edu>]

> 
> 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