[Bug c++/26943] [gomp] firstprivate not working properly with non-POD

[rth at gcc dot gnu dot org]

------- 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 that acts similarly)
> 2) if the variable is not passed by reference (i.e. scalar put directly into
> .omp_data_*) and we use 2 fields for it rather than one - sender initializes
> first field and firstprivate uses that, then lastprivate sets the second field
> and sender copies from the second field.

Both of these are fairly valuable.

But for when optimization fails, I think adding a specialized construct
for this in libgomp would also be helpful.  Something akin to a semaphore
initialized to -thread_count, such that a wait on the semaphore before the
lastprivate is assured that all the firstprivates are done.  One would expect
that the common case is that they will be done, and the semaphore will take
the unlocked fast-path.

I'll look into adding this.  Since we've already shipped this library in fc5,
do you think it's worthwhile adding it to a new version tag?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943