Incorrect bitfield aliasing with Tree SSA

Dave Korn dave.korn@artimi.com
Mon Jun 18 14:51:00 GMT 2007


On 18 June 2007 15:38, Richard Kenner wrote:

>>   You know, some of the confusion in this thread may be because your
>> previous example: 
>> 
>> 
>> " So if I have
>> 	struct foo {int x; float y; } bar;
>> 	int *pi;
>> 	float *pf;
>> 
>> and mark X as "nonaddressable", I know that an assigment to *pi can't
>> affect bar.x.  But if Y isn't similarly marked, an assignment to *pf MIGHT
>> affect bar.y unless I could somehow prove by value tracking that it can't.
>> " 
>> 
>> 
>> discussed a field that clearly /was/ addressable.  It's a lot more obvious
>> that something is non-addressable when you use a bitfield width specifier
>> on it.... did you originally intend to do that for foo.x as well?
> 
> No, I was trying to write a C example of a concept in the tree that has no
> equivalent C syntax.  I was saying "you have the tree for the above C, but
> also have the DECL_NONADDRESSABLE_P flag on x".  Eric gave the equivalent
> Ada, but since most people don't know Ada, I used C.
> 
> Yes, bitfield are the same case, but people aren't convinced of that yet,
> so I didn't want to use that in this example.

  It's very tricky.  Didn't we go round more-or-less this same ground a couple
of years back with DECL_READONLY_P vs. constructors of const objects being
allowed to write to them (once)?  Seems to me we perhaps have two analagous
possibile interpretations of DECL_NONADDRESSABLE_P here: not addressable by
user's code, vs. not ever actually addressable even by behind-the-scenes
internal compiler magic.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....



More information about the Gcc-patches mailing list