[Bug target/14899] [3.5 Regression] wrong code due to change in compatibility rules for vector types

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-04-11 07:41 -------
The bug is __builtin_types_compatible_p being ill-named because it is actually 
__builtin_same_type_p (it just uses comptypes).  __builtin_types_compatible_p 
(int, unsigned int) is zero, so the problem is the name of the builtin.  And 
this name used in Altivec code caused me to think that comptypes actually meant 
*compatible* types for vectors, instead of *compare* types.  However, the C++ 
front-end's shortcut name for comptypes(..., ..., COMPARE_STRICT), which is 
same_type_p, makes it clear that comptypes is not checking compatibility.

I prepared a patch which has yet another redefinition of comptypes for vector 
types, and posted it to gcc-patches, but it did not pass regtesting (developing 
gcc is expensive for me right now, so I try to limit online time as much as 
possible).  Making two vector types *equivalent* if *one of them* is opaque 
looks wrong, so here is the definition adopted in this patch:

1) if two vector types are of different sizes, they are not equivalent
2) if only one of two vector types is opaque, they are not equivalent
3) else, if both are opaque, they are equivalent
4) or, if they are not opaque but have the same underlying type, they are
equivalent.

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
less what current mainline does in comptypes for vector types.

Paolo



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14899