From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-93848-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22895 invoked by alias); 2 Apr 2004 19:41:56 -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 22884 invoked from network); 2 Apr 2004 19:41:55 -0000
Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22)
  by sources.redhat.com with SMTP; 2 Apr 2004 19:41:55 -0000
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i32JfstO025565
	for <gcc@gcc.gnu.org>; Fri, 2 Apr 2004 11:41:54 -0800 (PST)
Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T68b76f2986118064cc3cc@mailgate2.apple.com>;
 Fri, 2 Apr 2004 11:41:54 -0800
Received: from [17.201.20.186] (gambrinus.apple.com [17.201.20.186])
	by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i32JfpOj008198;
	Fri, 2 Apr 2004 19:41:52 GMT
In-Reply-To: <200404021818.i32IIPve000486@desire.geoffk.org>
References: <F0209661-68A9-11D8-8C0E-000A95D7CD40@apple.com> <20040226230842.GA28463@redhat.com> <jmwu698lfu.fsf@desire.geoffk.org> <20040227211712.GB16448@daikokuya.co.uk> <jmoerk8ae8.fsf@desire.geoffk.org> <20040227220212.GC16448@daikokuya.co.uk> <404CF3C5.4070803@codesourcery.com> <m3n06rlzgj.fsf@uniton.integrable-solutions.net> <20040308153208.A23517@synopsys.com> <61884C8A-715D-11D8-87F8-000A95D7CD40@apple.com> <jmad1v2p4h.fsf@desire.geoffk.org> <37619788-8440-11D8-8F7D-000A95D7CD40@apple.com> <200404021818.i32IIPve000486@desire.geoffk.org>
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <EA2439E8-84DD-11D8-B624-000A95D7CD40@apple.com>
Content-Transfer-Encoding: 7bit
Cc: neil@daikokuya.co.uk, rth@redhat.com, gcc@gcc.gnu.org,
        Dale Johannesen <dalej@apple.com>, gdr@integrable-solutions.net,
        mark@codesourcery.com
From: Dale Johannesen <dalej@apple.com>
Subject: Re: IMA vs tree-ssa
Date: Fri, 02 Apr 2004 19:41:00 -0000
To: Geoff Keating <geoffk@desire.geoffk.org>
X-SW-Source: 2004-04/txt/msg00138.txt.bz2

On Apr 2, 2004, at 10:18 AM, Geoff Keating wrote:
>> Restricting p and q to be non-char, it does; *p and *q have
>> non-compatible types.
>
> They have non-compatible types with each other, but that's not the
> test for whether two things can't alias; the standard talks about the
> 'effective type of the object'.  So two accesses can alias if there
> could be a type which is compatible with both of the types involved,
> even if the two types are not themselves compatible.  If you can work
> out what the object's effective type is (which is not always possible
> at compile time, since it's a run-time property) then you could test
> for compatibility with that, which would be a more precise test.

OK, I believe that.  Then what we have is a bug.  Do you agree the
following is standard-conforming?  It gets different results with 
different
options on ppc; the pointer  derefs in foo have different alias classes,
and the scheduler does not find a dependency between them.

unsigned int a, b;
enum e1 { x, y, z };
enum e2 {t,u,v};
void foo (enum e1* e1p, enum e2* e2p, int x)
{ *e1p = x;
   b = *e2p; }

main() {
   enum e1* e1p = (enum e1*) &a;
   enum e2* e2p = (enum e2*) &a;
   foo (e1p, e2p, 3);
   printf("%d\n", b);
}