From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7307 invoked by alias); 11 Apr 2004 07:41:40 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 7284 invoked by uid 48); 11 Apr 2004 07:41:33 -0000 Date: Sun, 11 Apr 2004 12:49:00 -0000 Message-ID: <20040411074133.7283.qmail@sources.redhat.com> From: "bonzini at gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040409073632.14899.bonzini@gnu.org> References: <20040409073632.14899.bonzini@gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/14899] [3.5 Regression] wrong code due to change in compatibility rules for vector types X-Bugzilla-Reason: CC X-SW-Source: 2004-04/txt/msg00927.txt.bz2 List-Id: ------- 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