[Bug fortran/71014] New: associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
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
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #2 from Keith Lindsay --- Created attachment 38454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38454&action=edit output from gfortran -v
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #3 from Keith Lindsay --- Created attachment 38455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38455&action=edit output from gfortran -v
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #4 from Keith Lindsay --- Thanks for taking a look. I've attached the output from the command gfortran -v -fopenmp openmp_nested_loops.f90 -o openmp_nested_loops on two different systems where I'm seeing the problem.
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #6 from Keith Lindsay --- Harald, The problem does go away if I add a PRIVATE(i) clause to the OMP directive. However, my understanding of OpenMP in fortran is that all loop iteration variables, even inner nested loops, in an OpenMP PARALLEL DO construct (and some others) are private by default. I.e., they do not need to be declared private in the OMP directive. (I think this specification is different than the specification for inner loops in C.) Indeed, if I comment out the associate construct, the problem goes away. So I'm inferring that the associate construct is interfering with the inner loop index being assigned the private attribute. Keith
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #7 from Keith Lindsay --- The Linux system that I'm working on has multiple versions of gcc/gfortran installed. I've compiled and run my example program with different versions and have found the following: Versions 4.9.0, 4.9.1, 4.9.2, 4.9.3, 5.0.1, 5.1.0 Program, as is, works (i.e. no reported mismatches over 10 runs) Versions 5.2.0, 5.3.0, 6.0.1, 6.1.0 Program, as is, reports mismatches (and sometimes hangs) So it seems like the behavior I'm seeing originated in 5.2.0.
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014
--- Comment #9 from Keith Lindsay ---
Harald,
Thanks for your tips on validation/sanitizing tools.
I am not sufficiently fluent in standard-ese to know what 'associated
do-loops(s)" means. It doesn't help that BLOCK and ASSOCIATE appear in other
contexts in the OpenMP standard, making it challenging to locate information
about them in the standard.
If I replace ASSOCIATE with BLOCK/END BLOCK, I do see the same problems.
I added -fdump-tree-original to the gfortran invocation and compiled code with
and without the BLOCK construct. The generated intermediate files have the
difference
@@ -6,7 +6,7 @@
static integer(kind=4) s_true = 5050;
s = {};
- #pragma omp parallel private(i)
+ #pragma omp parallel
{
{
#pragma omp for private(j) nowait
(There are other differences that appear to simply be renaming of labels, I'm
ignoring those.) So it does seem that the presence of the BLOCK construct is
changing how the compiler assigns attributes to the inner loop index. I didn't
think this was correct, but perhaps I'm misunderstanding how the OpenMP and
Fortran standards interact.
At this point, I would like to know if the compiler is in the right in doing
this. If it is, then I would change my coding practice. If it isn't, then I
assume that gfortran developers would want to know about this.
Keith
[Bug fortran/68546] New: passing non-contiguous associated array section garbles results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68546 Bug ID: 68546 Summary: passing non-contiguous associated array section garbles results Product: gcc Version: 5.2.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 36840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36840&action=edit program demonstrating problem Hi, I've associated a non-contiguous array section to a name. I.e. A2=>A(2,:) When I pass A2 to a subroutine, the contents are garbled (see below). When I compile and run the attached program, I expect the output to be write statement with fixed i section 201.0 202.0 203.0 -- calling foo with fixed i section 201.0 202.0 203.0 -- write statement with associated fixed i section 201.0 202.0 203.0 -- calling foo with associated fixed i section 201.0 202.0 203.0 -- Instead, with gfortran v5.2.0, the last 4 lines are -- calling foo with associated fixed i section 201.0 301.0 102.0 -- If the contents of the associate construct are (A2=>A(:,2)), then the output from the program is as I would expect it to be. So the problem seems to be related to the non-contiguous nature of the array section. Could this be looked into please? Thank you, Keith Lindsay
