------- 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
the direct context that privatized them. We currently aren't, but if 'n' was
accessed inside a separate function, the global 'n' should be accessed.
> With the above patch, we still create wrong code, with 2 different bugs:
> 1) there is no barrier to separate firstprivate assignments from lastprivate
>
Barrier? We don't need a barrier. We just need to make sure that only the
thread handling the very last iteration of the loop or the thread executing the
last omp section is the only one executing the copy-out operation.
> 2) on the sender side, we store the global var n into
> .omp_data_o.4D.1945.nD.1938, but on the receiver side we access either the
> remapped private n (assuming the above patch is in) or, when accessing the
> outside n we use the global variable n rather than .omp_data_iD.1937.nD.1938
>
We should not need to access via .omp_data_o/.omp_data_i. So, if n.1591 is the
privatized version of n.1567, we should emit something like:
#pragma omp parallel firstprivate(n.1567) lastprivate(n.1567)
n.1591 = n.1567
#pragma omp for
for (i.1587 = 0; i.1587 <= 15; i.1587 = i.1587 + 1)
< ... use and set n.1591 ...>
OMP_CONTIUNE
if (i.1587 == 16)
n.1567 = n.1591
OMP_RETURN [nowait]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
