That is exactly related to tsan -- it should skip local variable that
is not address taken (though still addressable, which by addressable,
it means the variable has a memory home).
The problem is that if 'addressable' bit is not equivalent to 'address
taken', it will be too conservative to use it --- as addressable
variables may not be address taken.
Note that even 'address taken' is too conservative to use here. Only
when it is escaped the thread (via non TLS global pointers or other
escaped local, heap memories), should it be considered to be
instrumented.
David
On Thu, Nov 1, 2012 at 11:49 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Nov 01, 2012 at 11:32:01AM -0700, Xinliang David Li wrote:
>> For the following case:
>>
>> int foo()
>> {
>> int a[100];
>>
>> // use 'a' as a[i]
>> ...
>> }
>>
>> Assuming there is no assignment of the form p = &a[i] in the source,
>> variable 'a' still will be allocated in stack and its address is is
>> needed. Is the addressable bit set for 'a'? If yes, then it is not
>> the same as address taken.
>
> But how is that relevant to tsan? If TREE_ADDRESSABLE isn't set on a,
> then yes, you can still use a[i] = 6; or return a[j]; on it, and it will
> be allocated on stack, but different threads can't access the array, so
> there is no data race possible.
> Only if a is static int a[100]; above, or otherwise is_global_var (decl).
>
> Jakub
