https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 25 Mar 2022, guihaoc at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030 > > --- Comment #5 from HaoChen Gui <guihaoc at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #4) > > something like > > > > void *bar (void *x) > > { > > *(double *)x = 1.; > > } > > > > void foo(int n) > > { > > double atemp; > > pthread_create (..., bar, &atemp); > > for (int i = 0; i < n; i++) > > if (a[i] < atemp) > > atemp = a[i]; > > pthread_join (...); > > if (atemp != 1.) > > abort (); > > } > > > > if it is ensured the store to atemp in the loop never takes place then > > we have created a store data race when applying store motion. Of course > > thread creation/join can be hidden in other functions called from foo() > > as long as 'atemp' escapes to callers. > > I got it. Thanks a lot. > In the original case, the bar is called after the loop. So we still think the > atemp is safe for multi-threaded, as atemp can't be changed by others threads? > > If the bar is executed before the loop, it's unsafe. Could we check all blocks > dominated by the loop head to find out the reference used in a call? Yes, we could look at whether there's an escape point of 'atemp' between function entry and the loop. Similarly there would have to be a possible pthread_join _after_ the loop (even if there's an escape point before the loop). Not sure if it's worth the trouble though - do you have a compelling real-world example where it would help?
