public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bonzini at gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/14899] [3.5 Regression] wrong code due to change in compatibility rules for vector types Date: Sun, 11 Apr 2004 12:49:00 -0000 [thread overview] Message-ID: <20040411074133.7283.qmail@sources.redhat.com> (raw) In-Reply-To: <20040409073632.14899.bonzini@gnu.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
next prev parent reply other threads:[~2004-04-11 7:41 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-04-09 7:36 [Bug target/14899] New: " bonzini at gnu dot org 2004-04-09 11:22 ` [Bug target/14899] [3.5 Regression] " pinskia at gcc dot gnu dot org 2004-04-09 17:09 ` fjahanian at apple dot com 2004-04-09 17:17 ` pinskia at gcc dot gnu dot org 2004-04-09 17:20 ` fjahanian at apple dot com 2004-04-09 18:01 ` fjahanian at apple dot com 2004-04-10 14:21 ` bonzini at gnu dot org 2004-04-11 12:49 ` bonzini at gnu dot org [this message] 2004-04-11 14:51 ` jsm at polyomino dot org dot uk 2004-04-26 15:15 ` bonzini at gnu dot org 2004-05-05 7:22 ` cvs-commit at gcc dot gnu dot org 2004-05-05 7:23 ` cvs-commit at gcc dot gnu dot org 2004-05-05 13:32 ` pinskia at gcc dot gnu dot org 2004-05-05 15:33 ` bonzini at gnu dot org 2004-05-05 15:37 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040411074133.7283.qmail@sources.redhat.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).