[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 --- Comment #21 from Jim Cownie --- Thanks for the workaround, Jakub; it's somewhat perverse, but better than the alternatives!
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #20 from Jakub Jelinek --- It actually is hard, otherwise it would be done sooner. There is easy workaround, one can declare the var before actually defining, extern whatever var; #pragma omp threadprivate(var) whatever var; or once OpenMP 5.1 C++ attributes are implemented through whatever var [[omp::directive(threadprivate(var))]]; because in that case threadprivate is visible right on the var definition. The problem is that right now the construction of vars acts as a variable use and it is impossible to distinguish between such definition and some other uses of the variable in between its definition and the threadprivate directive.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Jim Cownie changed: What|Removed |Added CC||jcownie at gmail dot com --- Comment #19 from Jim Cownie --- The OpenMP aspect of this is still present in GCC 10, so this bug has beena round for almost *15 years*! Other compilers (LLVM, Intel, ...) happily compile such code. Given that the underlying mechanisms now exist, a fix for the OpenMP aspect really shouldn't be too hard, should it? I really don't want to have to write #if (__GNUC__) // Work around GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 // (Scroll near the end...) static thread_local fileStats threadRes; #else static fileStats threadRes; #pragma omp threadprivate (threadRes) #endif in all of my code examples and blog posts, since it just makes GCC look poor.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
Yves Vandriessche changed:
What|Removed |Added
CC||yves.vandriessche at intel dot
com
--- Comment #18 from Yves Vandriessche ---
As mentioned by Sameer, thread_local now works, but the threadprivate OpenMP
directive still fails with a "declared 'threadprivate' after first use" error.
My test fragment, is as follows. It should only print a single "ctor" and twice
the same set of distinct pointers:
#include
#include
struct Foo {
Foo() {puts("ctor");}
int a;
};
int bar() {
int sum=0;
// // alternative to omp threadprivate, works with gcc
// thread_local Foo local;
#pragma omp parallel reduction(+:sum)
{
static Foo local;
#pragma omp threadprivate(local)
local.a = omp_get_thread_num();
printf("%p\n", );
sum += local.a;
}
printf("%d\n", sum);
return sum;
}
int main(int argc, char** argv) {
bar();
bar();
return 0;
}
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
Sameer Sheorey changed:
What|Removed |Added
CC||ssameer at gmail dot com
--- Comment #17 from Sameer Sheorey ---
The second fragment still fails in gcc 5.3.1 (OpenSuse 13.2). I noticed that
the C++11 version succeeds:
struct A {
A() {}
};
thread_local A a;
Is it possible to migrate this to the OpenMP implementation as well?
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.3 |---
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 --- Comment #16 from Matthew Krafczyk krafczyk.matthew at gmail dot com --- I've just checked this bug again with ubuntu 14.10. This is with glibc 2.19, and with the master branch of gcc (commit 3c4e189973c43b7f3c2ebb27abf32e9cb175ba82). The first fragment succeeds, but the second fragment still fails.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 --- Comment #15 from Matthew Krafczyk krafczyk.matthew at gmail dot com --- I can now confirm what siddhesh says. with 4.8 the first fragment succeeds, while the second fails. I also tested the git gcc and git glibc, and the first fragment succeeds, while the second fragment still fails.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 --- Comment #14 from Siddhesh Poyarekar siddhesh at redhat dot com --- I spoke to Jason last week and have now confirmed that the first fragment indeed works correctly with 4.8. Declaring a variable threadprivate *after* it is defined is not yet supported, but it should not be very difficult to work around that limitation. I also have confirmation that the glibc support in place for threadprivate/thread_local is sufficient and complete, so I'm closing out the glibc TODO item.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Matthew Krafczyk krafczyk.matthew at gmail dot com changed: What|Removed |Added CC||krafczyk.matthew at gmail dot com --- Comment #13 from Matthew Krafczyk krafczyk.matthew at gmail dot com --- Hi, this is still broken in the latest git version of gcc. What are the hurdles which need to be accomplished to get this bug fixed?
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Siddhesh Poyarekar siddhesh at redhat dot com changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #11 from Siddhesh Poyarekar siddhesh at redhat dot com --- I had added __cxa_thread_atexit_impl to glibc earlier this year to support c++11 thread_local destructors[1][2]. Wouldn't that be good enough support from glibc for openmp too? [1] http://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables [2] http://sourceware.org/git/?p=glibc.git;a=commit;h=ba384f6ed9275f3966505f2375b56d169e3dc588
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.1 |4.8.2 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 4.8.1 has been released.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |4.8.1 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-22 14:41:46 UTC --- GCC 4.8.0 is being released, adjusting target milestone.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Carlos O'Donell carlos at systemhalted dot org changed: What|Removed |Added CC||carlos at systemhalted dot ||org --- Comment #8 from Carlos O'Donell carlos at systemhalted dot org 2012-11-12 18:29:12 UTC --- The glibc community is aware of this issue. I've added it to our generic todo list from which developers can help coordinate an implementation. http://sourceware.org/glibc/wiki/Development_Todo/Generic
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-10-15 20:36:16 UTC --- The first fragment will be supported in GCC 4.8.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Brooks Moses brooks at gcc dot gnu.org changed: What|Removed |Added CC||brooks at gcc dot gnu.org --- Comment #6 from Brooks Moses brooks at gcc dot gnu.org 2011-04-06 19:54:39 UTC --- It appears that this underlying issue will also affect C++0x support for thread-local storage, assuming that it also allows non-POD thread-local objects. (See links from http://gcc.gnu.org/projects/cxx0x.html.) This is also looking like it's going to be a significant problem for us in the near future in using OpenMP. Are there GLIBC and binutils issues filed for the necessary underlying functionality that Jakub mentions in comment 1? If so, what are they? If not, what additional information is needed to file a coherent and accurate feature request there?
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-18 05:08 --- *** Bug 35246 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-30 21:56 --- *** Bug 34303 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||geir at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-18 16:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-18 16:51:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-16 10:20 --- Guess the message should be sorry rather than error. Without glibc and binutils support for .tinit_array/.tfini_array this really isn't fixable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de 2006-05-16 15:04 --- Yes, I think that would be good. Then you know that you are not doing something wrong but that it is a tool chain limitation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
