https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #3 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe. In principle
> foo() could launch a thread and make the 'atemp' available to it. As long
> as foo() outlives thread termination that should be all well-defined and so
> we'd have to take this possibility into account.
>
> There's currently no code ruling this out and doing that is likely difficult.
> So maybe the answer is to add -fallow-store-data-races={local,all}, map
> -fallow-store-data-races to -fallow-store-data-races=all and make
> -fallow-store-data-races=local the default?
For the local automatic variables(not global, not static), they should be
stored on one's own thread stack. I think they can't be accessed by other
threads. Other threads should create their own instance for the local automatic
variables. So 'atemp' is thread safe in the example code? Could you please
explain why it's unsafe when foo outlives thread termination? Thanks a lot.
diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 6d9316eed1f..e2b6b927351 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -2219,7 +2219,10 @@ execute_sm (class loop *loop, im_mem_ref *ref,
bool always_stored = ref_always_accessed_p (loop, ref, true);
if (maybe_mt
&& (bb_in_transaction (loop_preheader_edge (loop)->src)
- || (! flag_store_data_races && ! always_stored)))
+ || (! flag_store_data_races && ! always_stored
+ && (!auto_var_in_fn_p (ref->mem.ref, current_function_decl)
+ || TREE_THIS_VOLATILE (ref->mem.ref)
+ || TREE_STATIC (ref->mem.ref)))))
multi_threaded_model_p = true;
Could we use above conditions to exclude local auto variables from
multi-threaded safe considerations?
