From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22468 invoked by alias); 25 Jan 2002 22:55:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 22431 invoked from network); 25 Jan 2002 22:55:15 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 25 Jan 2002 22:55:15 -0000 Received: from localhost (pool-151-204-230-39.bos.east.verizon.net [151.204.230.39]) (authenticated (0 bits)) by dberlin.org (8.11.6/8.11.6) with ESMTP id g0PMtEn02137; Fri, 25 Jan 2002 17:55:14 -0500 Date: Fri, 25 Jan 2002 15:43:00 -0000 Subject: Re: g++ and aliasing bools Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: gcc@gcc.gnu.org To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) From: Daniel Berlin In-Reply-To: <10201251431.AA12029@vlsi1.ultra.nyu.edu> Message-ID: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) X-SW-Source: 2002-01/txt/msg01704.txt.bz2 Message-ID: <20020125154300.yWFgm6BpoI0rKmRufEBngoWJ0od40CorJ7ye5pNxUho@z> On Friday, January 25, 2002, at 09:31 AM, Richard Kenner wrote: > Errr, not really. > They just happen to be our representation of aliases for types. > > In some sense, but they avoid undecidability problems because you just > need to look at language semantics, not run-time behavior of a > particular program. > They don't avoid undecidability, or else we wouldn't have alias set 0. If we could determine what everything aliases, we wouldn't need a set that aliases everything. We can't. Undecidability is not just based on run-time behavior of the program. It's also undecidable in the static case. may-alias is undecidable statically, as is must-alias (Unless i'm misremembering). IIRC, these were proven on either C or modula-3, so the language semantics don't help us at all. > The issue with alias sets is whether you can prove from the language > specification that two objects *cannot* alias each other. If and only > if you can, they are in different alias sets. Of course. I know how alias sets in gcc/g++ work, i know how non-type-based alias analysis works. I know how non-type-based alias analysis with type based disambiguation work. That doesn't make it any easier. --Dan