This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/71014] New: associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
- From: "klindsay at ucar dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 08 May 2016 22:36:13 +0000
- Subject: [Bug fortran/71014] New: associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014
Bug ID: 71014
Summary: associate statement inside omp parallel do appears to
disable default private attribute for inner loop
indices
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: klindsay at ucar dot edu
Target Milestone: ---
Created attachment 38446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38446&action=edit
program demonstrating problem
Hi,
I have some code using the associate construct inside an openmp parallel do
loop. The associate construct appears to disable giving loop indices inside the
construct the private attribute. The attached program demonstrates the problem.
The inner loop adds the numbers 1..100, and should yield 5050. This is done 8
times. When I run the program with OMP_NUM_THREADS=8, I usually get mismatches
between s_true and s. Sometimes the program hangs, seemingly in an infinite
loop. I am running this on a Linux system.
If I add a PRIVATE(i) clause to the OMP directive, the problem goes away.
If I comment out the associate construct, the problem goes away, even without
adding a PRIVATE(i) clause. Note that the associate construct in this example
is not really doing anything. The associated name is not actually used inside
the associate construct.
Could this be looked into please?
Thank you,
Keith Lindsay