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

Attachment: 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

Reply via email to