On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill <ja...@redhat.com> wrote:
>> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
>>>
>>>> I think the adjustment above is intended to match the adjustment of the
>>>> address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
>>>> that bitregion_start%BITS_PER_UNIT == 0.
>>>
>>> That was intentional. bitregion_start always falls on a byte boundary,
>>> does it not?
>>
>> Ah, yes, of course, it's bitnum that might not. The code changes look good,
>> then.
>
> Looks like this was an approval ...
>
> Anyway, I don't think a --param is appropriate to control a flag whether
> to allow store data-races to be created. Why not use a regular option
> instead?
>
> I believe that any after-the-fact attempt to recover bitfield boundaries is
> going to fail unless you preserve more information during bitfield layout.
>
> Consider
>
> struct {
> char : 8;
> char : 0;
> char : 8;
> };
>
> where the : 0 isn't preserved in any way and you can't distinguish
> it from struct { char : 8; char : 8; }.
Oh, and
INNERDECL is the actual object being referenced.
|| (!ptr_deref_may_alias_global_p (innerdecl)
is surely not what you want. That asks if *innerdecl is global memory.
I suppose you want is_global_var (innerdecl)? But with
&& (DECL_THREAD_LOCAL_P (innerdecl)
|| !TREE_STATIC (innerdecl))))
you can simply skip this test. Or what was it supposed to do?
Richard.
