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