https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
--- Comment #7 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #3)
> More importantly, the OpenMP version does not wait for the loop to finish
> (or at least, I see "#pragma omp for nowait" in the GIMPLE dump), so there
> is no h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
--- Comment #6 from morandidodo at gmail dot com ---
(In reply to Jakub Jelinek from comment #5)
> Pedantically this isn't valid, because you are mixing C++11 features
> (lambdas) with OpenMP, which doesn't support C++11 even in 4.5, so it is all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
--- Comment #5 from Jakub Jelinek ---
Pedantically this isn't valid, because you are mixing C++11 features (lambdas)
with OpenMP, which doesn't support C++11 even in 4.5, so it is all unspecified
behavior.
Also, have you built libgomp with -fsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
--- Comment #4 from Jonathan Wakely ---
This shows the same race, without any library components:
struct regex {
struct regex_impl { int i; int size() const { return i; } };
regex_impl* p;
regex() : p(new regex_impl{42}) { }
~regex() { d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
--- Comment #3 from Jonathan Wakely ---
The std::thread example is similar, but not the same. The OpenMP version shares
f, so is equivalent to creating the std::thread objects with std::ref(f).
More importantly, the OpenMP version does not wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
--- Comment #2 from morandidodo at gmail dot com ---
(In reply to Jakub Jelinek from comment #1)
> If the C++ standards allows these to be used without locking, then it is
> likely a bug in libstdc++, not libgomp.
Sorry, my fault ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744
Jakub Jelinek changed:
What|Removed |Added
Component|libgomp |libstdc++
--- Comment #1 from Jakub Jeli
