From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28129 invoked by alias); 25 Nov 2004 17:39:46 -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 28109 invoked from network); 25 Nov 2004 17:39:42 -0000 Received: from unknown (HELO mail2.codesourcery.com) (66.160.135.55) by sourceware.org with SMTP; 25 Nov 2004 17:39:42 -0000 Received: (qmail 9107 invoked from network); 25 Nov 2004 15:58:50 -0000 Received: from admin.voldemort.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.9) by mail2.codesourcery.com with SMTP; 25 Nov 2004 15:58:50 -0000 Received: (qmail 31809 invoked from network); 25 Nov 2004 15:58:49 -0000 Received: from localhost (HELO ?192.168.189.167?) (nathan@127.0.0.1) by mail.codesourcery.com with SMTP; 25 Nov 2004 15:58:49 -0000 Message-ID: <41A60132.2050203@codesourcery.com> Date: Thu, 25 Nov 2004 17:48:00 -0000 From: Nathan Sidwell Organization: Codesourcery LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 MIME-Version: 1.0 To: Diego Novillo CC: "gcc@gcc.gnu.org" , Jeff Law , "Joseph S. Myers" Subject: Re: [RFC] ignoring type alias conflicts between structures and scalars References: <1101396789.31231.84.camel@localhost.localdomain> In-Reply-To: <1101396789.31231.84.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00978.txt.bz2 Diego Novillo wrote: > Jeff noticed that TBAA was creating some alias relations that don't seem > to make much sense. For instance, given > Jeff's argument is that it's not really possible for a pointer to a > structure to point to a scalar variable. If the structure is not type > compatible with the scalar, then they can't alias. That makes some > sense to me. > If the program isn't well defined, why is alias_sets_conflict_p() saying > that 'struct int_float_s' and 'int' have conflicting alias sets? these conflict because the following program is well formed (typos excepting :) struct int_s {int i;}; struct int_s thing = {5}; void foo (int *i_ptr, struct int_s *s_ptr) { if (*i_ptr) ... *s_ptr = thing; // could clobber *i_ptr if (*i_ptr) ... } void baz () { struct int_s s = {0}; foo (&s.i, &s); } your example is different, in that the int lvalue is not some arbitrary pointer dereference, but a known variable. Your example looks to me like the rule about structs with identical initial field sequences conflict up to the point where the fields diverge, coupled with the rule that the address of a struct is the address of its first element (and vice versa). Thus I think int_float_s conflicts with an int variable, but not a float variable. I don't think Joseph's example of struct float_int_s {float f; int i;}; int i; ((float_int_s *)&((&i)[1]))[-1].i being possibly valid is actually valid. Notice this is forming the address just past the int variable (valid), casting that to 'float_int_s *' (valid), indexing -1 struct elements into that (INVALID due to address of start of struct being outside of i), and then obtaining the i field (valid), which is where the int is. If the final two operations are folded together, no ill-formed address is created, so the construct could be valid. I think that reasoning is wrong, because it is presuming an optimization that might not be implemented. But Joseph has thought about this more than me. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk