From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30524 invoked by alias); 25 Nov 2004 17:41:28 -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 30436 invoked from network); 25 Nov 2004 17:41:21 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 25 Nov 2004 17:41:21 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA06923; Thu, 25 Nov 04 12:45:46 EST Date: Thu, 25 Nov 2004 17:48:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10411251745.AA06923@vlsi1.ultra.nyu.edu> To: dnovillo@redhat.com Subject: Re: [RFC] ignoring type alias conflicts between structures and scalars Cc: gcc@gcc.gnu.org X-SW-Source: 2004-11/txt/msg00979.txt.bz2 So, what I want to teach the alias analyzer is that given a pointer to an aggregate type A and a regular variable of a scalar type S, such that A and S are not type-compatible, then a pointer to 'A' cannot possibly point to a variable of type 'S'. So, it boils down to alias_sets_conflict_p being symmetric. We want to consider 'int * -> struct int_float_s' to alias, but we want to reject 'struct int_float_s * -> int'. Right. I think it's just a matter of writing a version of alias_sets_conflict_p with the second block of code that checks children removed, leaving just the checks for set 0, the same alias set, and the first being a subset of the second. Then call that routine. It might be worth checking if other places should be using that new routine. It looks like the usage in gimplify.c and perhaps tree-data-ref.c should as well.