https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81222
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can you create a smaller self-contained testcase?
Also, thread_local isn't strictly interoperable with OpenMP (which is in 4.5
only defined for C++98, so thread_local is in the unspecified behavior
category), and it is unclear what you want to achieve with it.
#pragma omp parallel for reduction(+: results[:n])
for(int s = 0; s < n; ++s) {
thread_local vector<vector<int>> p(n);
use (p);
}
will construct the p variable only the first time a particular thread
encounters it (with whatever n is at that point), but if you call the function
containing this again later on and n happens to be different, it is not
destructed and constructed again and so you can overflow buffers etc.
If you want the vars to be persistent across different iterations scheduled to
the same thread, you can either define them before #pragma omp parallel for and
firstprivatize them, or e.g.
#pragma omp parallel reduction(+: results[:n])
{
vector<vector<int>> p(n);
#pragma omp for nowait
for(int s = 0; s < n; ++s) {
use(p);
}
}
or similar.
> It appears that the segfault appears at the very beginning of the thread
> start.
No, it crashes in the outlined body of the parallel region.
