--- Comment #11 from bergner at vnet dot ibm dot com 2006-12-05 02:06
---
The testcase pr26943-2.c fails intermittently for me using unpatched mainline.
Is anyone else seeing that? I'm building on powerpc64-linux with -m32. If I
run it a few times, it mainly passes, but every once in
--- Comment #9 from jakub at gcc dot gnu dot org 2006-05-03 12:23 ---
Reassigning to Richard for the optimizations mentioned in #7.
The code in SVN should be correct, but sometimes suboptimal.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from jakub at gcc dot gnu dot org 2006-05-03 12:31 ---
I think using GOMP_1.1 symver instead of GOMP_1.0 would be preferrable.
I think you probably want to keep the state in the user code (probably
inside of .omp_data_* structure) so sender could zero it, then one
--- Comment #8 from jakub at gcc dot gnu dot org 2006-05-02 20:03 ---
Subject: Bug 26943
Author: jakub
Date: Tue May 2 20:03:38 2006
New Revision: 113483
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113483
Log:
PR c++/26943
* omp-low.c
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org
--- Comment #4 from dnovillo at gcc dot gnu dot org 2006-05-01 15:15
---
(In reply to comment #2)
without this we don't remap privatized global vars except directly in the
omp context that privatized them.
But this is as it should be. We are only required to privatize variables in
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-01 16:07 ---
We do need a barrier (well, in some cases with extra code we can avoid
it in some cases), in order to honor 2.8.3.4:
If a list item appears in both firstprivate and lastprivate clauses, the
update
required for
--- Comment #6 from dnovillo at redhat dot com 2006-05-01 16:11 ---
Subject: Re: [gomp] firstprivate not working properly with
non-POD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
jakub at gcc dot gnu dot org wrote:
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-01
--- Comment #7 from rth at gcc dot gnu dot org 2006-05-01 17:58 ---
(In reply to comment #5)
1) if we prove the structured block has at least one barrier in between the
firstprivate and lastprivate code chunks (doesn't matter if explicit #pragma
omp barrier or some other OMP stuff
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 15:07 ---
One incremental fix for the global var case is:
--- omp-low.c.jj5 2006-04-28 13:29:49.0 +0200
+++ omp-low.c 2006-04-28 16:22:36.0 +0200
@@ -674,9 +674,6 @@ omp_copy_decl (tree var,
--- 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
--- Comment #1 from rth at gcc dot gnu dot org 2006-03-30 15:56 ---
Created an attachment (id=11166)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11166action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
12 matches
Mail list logo
