--- 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 #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 routine
--- 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 #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=gcc&view=rev&rev=113483
Log:
PR c++/26943
* omp-low.c (maybe_lookup_decl_in_ou
--- 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 #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 #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 lastpri
--- 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
--
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 #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 #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, copy_body_dat
--- 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=11166&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
12 matches
Mail list logo
