Re: [tsan] ThreadSanitizer instrumentation part

[Xinliang David Li <davidxl at google dot com>]

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.

David


On Thu, Nov 1, 2012 at 11:24 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
>> But it skips those globals without static storage and marked as not addressable.
>>
>> It seems to me you want to skip all stack local variables that are not
>> address escaped.  Without address escape analysis, the address taken
>> bit (not the same as addressable attribute) should be used. As far as
>> I can tell, such bit is not available in var_decl. The varpool_node
>> has one, but it is only for var_decls with static storage.  It is also
>> unfortunate that there is no single bit to test if a variable is
>> function auto, though there is an interface to call which is
>> 'auto_var_in_fn_p (...)'.  The condition to skip such variable
>> references are:
>>
>>   if (tcode == VAR_DECL && auto_var_in_fn_p (expr, ..) &&
>> !address_taken (expr))
>>
>> The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
>> of ssa name) appears in the assignment, why would it not be
>> 'addressable'? And being addressable does not mean it is address taken
>> either.
>
> TREE_ADDRESSABLE really is a flag whether the
> address of the decl is ever taken (or addresses of its fields etc.),
> and it is updated from time to time (execute_update_addresses_taken)
> after certain passes.  Don't understand why you think it is redundant.
>
>         Jakub