[Fwd: Re: C++0x Memory model and gcc]

[Andrew MacLeod]

Oops, didn't reply all...


-------- Original Message --------
Subject: 	Re: C++0x Memory model and gcc
Date: 	Fri, 07 May 2010 10:37:40 -0400
From: 	Andrew MacLeod <amacleod@redhat.com>
To: 	Ian Lance Taylor <iant@google.com>
References: 	<4BE2E39A.5060706@redhat.com> 
<n2j84fc9c001005060850z942976d9n2b8431ff66cf995e@mail.gmail.com> 
<k2o84fc9c001005060910w30a6a9a6r4a89d26ab716dc0e@mail.gmail.com> 
<4BE2ECDB.2040003@redhat.com> 
<m2n84fc9c001005070214u4ef0af75me6815cae6ef70e8a@mail.gmail.com> 
<4BE41552.4000100@redhat.com> 
<mcr632zvld8.fsf@dhcp-172-17-9-151.mtv.corp.google.com>



Ian Lance Taylor wrote:
> Andrew MacLeod <amacleod@redhat.com> writes:
>
>   
>> They are independent as far as dependencies within this compilation unit.
>> The problem is if thread number 2 is performing
>>  a.j = val
>>  b.i = val2
>>
>> now there are data races on both A and B if we load/store full words
>> and the struct was something like: struct {
>>  char i;
>>  char j;
>> } a, b;
>>
>> The store to B is particularly unpleasant since you may lose one of
>> the 2 stores.  The load data race on A is only in the territory of
>> hardware or software race detectors.
>>     
>
> In this exmaple, if we do a word access to a, then we are running past
>   

yes, well that's not what I was getting at.  Add a short to the struct 
to pad it out to a word or access the variables via a short load and 
store...  and do the appropriate masking.   I was just trying not to 
make the example any bigger than need be :-P

> So the only potential problem here is if we have two small variables
> where one is aligned and the other is not.  This is an unusual
> situation because small variables are not normally aligned.  We can
> avoid trouble by forcing an alignment to a word boundary after every
> aligned variable.
>
> Or so it seems to me.
>   

The problem is when you load or store a larger unit than the actual 
object you are loading or storing.  Its not specifically an alignment 
thing.

I don't know how many architectures still do this, but we need to 
disable those that do.

Andrew