AltiVec [RFH] Overload resolution of vec_subs intrinsic fails

[Aldy Hernandez]

> > So, really, the bug is the altivec code trying to use "compatibility"
> > to implement something else.
> 
> The bug is the Altivec code using __builtin_types_compatible_p which is
> ill-named because it is actually __builtin_same_type_p (it just uses

The bug is really that the behavior of comptypes() changed from under
us.  Perhaps __builtin_types_compatible_p shoudn't have used
comptypes() in the first place, but I'd rather add a flag than cloning
the function.

Another problem is that the only test that tests
__builtin_types_compatible_p, does not test for signedness:

  gcc.c-torture/execute/builtin-types-compatible-p.c

Would it be ok to add such a check to the existing test?  I'd rather
not add a new test altogether.

> redefinition of comptypes for vector types, I hope this to be the final one.
> Making two vector types *equivalent* if *one of them* is opaque looks wrong,
> so here is the definition adopted in this patch:

Uh, no.  That's exactly what it should mean.  If the target thinks the
vector is opaque, it should be equivalent, and should interconvert
without a cast.  That is the definition we adopted for opaque types.

> 2) if only one of two vector types is opaque, they are not equivalent
> 3) else, if both are opaque, they are equivalent

No, if you have A=opaque and B=V4SI, then they are equivalent.  That's
what is assumed for ppc-e500, which is the only target that uses
opaque types.

> The *compatibility* (as in, you can assign even without an explicit cast) is
> now implemented in a separate vector_types_compatible_p, which matches more or

Can you pass them as arguments without casts?  Can you return them
from functions without casts?  Etc, etc.

Aldy