I attached patch that fixes issues exposed by bug 743. The problem is that for each program unit, the compiler is currently generating a new symbol for each thread private pointer array (this symbol points to the array of pointers that point to the memory associated each threads version of the symbol).
This obviously wrong, but it didn't matter since the compiler usually allocates the thread private array symbol as common, and the assembler allows multiple common definitions. However if the original symbol that is being directed to be thread private is file scoped, then the assembler complains about having multiple definitions. The fix is that the data structure that maps the user's symbol to the compiler generated symbol needs to be allocated once. Also for safety sake, the patch removes mappings associated with PU static symbols that are thread private when a new PU is being processed. I uncovered other problems that I fixed that are included in this patch. The test example bug743pu.c is a test that exercises the issues that were fixed (test bug743.c is a test for the main issue). Could a gatekeeper review/approve this patch when they have the chance? Thanks, Doug
bug743.patch
Description: bug743.patch
/* { dg-do run } */ static int foo = 123; #pragma omp threadprivate(foo) void abort(void); void bar(void) { #pragma omp parallel { if (foo != 123) abort(); } } int main() { #pragma omp parallel { if (foo != 123) abort(); } bar(); return 0; }
/* { dg-do run } */ void abort(void); int main() { static int foo = 123; #pragma omp threadprivate(foo) #pragma omp parallel { if (foo != 123) abort(); } return 0; }
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel