From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-95100-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2747 invoked by alias); 29 Apr 2004 14:26:42 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 2740 invoked from network); 29 Apr 2004 14:26:42 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sources.redhat.com with SMTP; 29 Apr 2004 14:26:42 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3TEQfKG012946;
	Thu, 29 Apr 2004 10:26:41 -0400
Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3TEQev27088;
	Thu, 29 Apr 2004 10:26:40 -0400
Received: from frogsleap.quesejoda.com (sebastian-int.corp.redhat.com [172.16.52.221])
	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i3TEQdV2022668;
	Thu, 29 Apr 2004 10:26:40 -0400
Received: by frogsleap.quesejoda.com (Postfix, from userid 500)
	id 799D23BC4F; Thu, 29 Apr 2004 10:26:39 -0400 (AST)
Date: Thu, 29 Apr 2004 16:39:00 -0000
From: aldyh <aldyh@redhat.com>
To: "carlo.bonzini@libero.it" <carlo.bonzini@libero.it>
Cc: bonzini <bonzini@gnu.org>, rth <rth@redhat.com>, gcc@gcc.gnu.org
Subject: Re: altivec still broken?!
Message-ID: <20040429142639.GE14457@redhat.com>
References: <HWXRPR$155B48652FCC799C9F3CD6AD93475DFB@libero.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <HWXRPR$155B48652FCC799C9F3CD6AD93475DFB@libero.it>
User-Agent: Mutt/1.4.1i
X-SW-Source: 2004-04/txt/msg01390.txt.bz2

On Thu, Apr 29, 2004 at 04:17:51PM +0200, carlo.bonzini@libero.it wrote:

(copying list)

> > Are you changing the behavior of opaque types?
> 
> No, except with respect to __builtin_types_compatible_p, which does not happen
> anyway because AltiVec does not use them.

Let me see if I get this right...

You are changing the behavior of opaque types with respect to
__builtin_types_compatible_p?  If so, we don't really care about a
change in this functionality because SPE uses opaque types but does
NOT use __builtin_types_compatible_p.  So, nothing changes.

OTOH, if you change the behavior of opaque types wrt
__builtin_types_compatible_p, this doesn't affect AltiVec either
because AltiVec uses __builtin_types_compatible_p but does NOT use
opaque types.

Agreed?

If so, why the change at all.  What code would it affect?

Aldy