This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
- From: "dnovillo at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Apr 2006 04:55:52 -0000
- Subject: [Bug c++/26943] [gomp] firstprivate not working properly with non-POD
- References: <bug-26943-119@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-29 04:55 -------
(In reply to comment #2)
> In addition to this, I'm not sure what exactly the standard requires say when
> firstprivate is used on a global var. The global var can be visible to the
> threads and they can modify it, do we need to make any guarantees about what
> exact value gets assigned to the privatized n variable in various threads?
>
No, we do not need to handle this case. In A.26.2, pg 169:
---------------------------------------------------------------------------------
The private clause of a parallel construct is only in effect inside the
construct,
and not for the rest of the region. Therefore, in the example that follows, any
uses of the
variable a within the loop in the routine f refers to a private copy of a,
while a usage in
routine g refers to the global a.
C/C++
Example A.26.2c
int a;
void g(int k) {
a = k; /* The global "a", not the private "a" in f */
}
void f(int n) {
int a = 0;
#pragma omp parallel for private(a)
for (int i=1; i<n; i++) {
a = i;
g(a*2); /* Private copy of "a" */
}
}
---------------------------------------------------------------------------------
So, we only need to privatize the references inside the construct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943