Hi!
The saving+clearing and restoring of OpenMP state during gfc_resolve is
meant for when during resolving of one subroutine/function etc. we resolve
another one, but apparently ASSOCIATE blocks (and BLOCK, though that isn't
supported yet - OpenMP 4.5 only supports Fortran 2003, not 2008) add another
namespace and we definitely want to e.g. notice vars used as DO loop
iterators even inside of ASSOCIATE.
Fixed thusly, tested on x86_64-linux and i686-linux, committed to trunk,
backports queued.
2016-08-19 Jakub Jelinek <ja...@redhat.com>
PR fortran/71014
* resolve.c (gfc_resolve): For ns->construct_entities don't save, clear
and restore omp state around the resolving.
* testsuite/libgomp.fortran/pr71014.f90: New test.
--- gcc/fortran/resolve.c.jj 2016-08-16 09:01:20.000000000 +0200
+++ gcc/fortran/resolve.c 2016-08-19 15:57:13.173596549 +0200
@@ -15587,7 +15587,8 @@ gfc_resolve (gfc_namespace *ns)
/* As gfc_resolve can be called during resolution of an OpenMP construct
body, we should clear any state associated to it, so that say NS's
DO loops are not interpreted as OpenMP loops. */
- gfc_omp_save_and_clear_state (&old_omp_state);
+ if (!ns->construct_entities)
+ gfc_omp_save_and_clear_state (&old_omp_state);
resolve_types (ns);
component_assignment_level = 0;
@@ -15599,5 +15600,6 @@ gfc_resolve (gfc_namespace *ns)
gfc_run_passes (ns);
- gfc_omp_restore_state (&old_omp_state);
+ if (!ns->construct_entities)
+ gfc_omp_restore_state (&old_omp_state);
}
--- libgomp/testsuite/libgomp.fortran/pr71014.f90.jj 2016-08-19
16:12:40.272914118 +0200
+++ libgomp/testsuite/libgomp.fortran/pr71014.f90 2016-08-19
16:10:33.000000000 +0200
@@ -0,0 +1,20 @@
+! PR fortran/71014
+! { dg-do run }
+! { dg-additional-options "-O0" }
+
+program pr71014
+ implicit none
+ integer :: i, j
+ integer, parameter :: t = 100*101/2
+ integer :: s(16)
+ s(:) = 0
+!$omp parallel do
+ do j = 1, 16
+ associate (k => j)
+ do i = 1, 100
+ s(j) = s(j) + i
+ end do
+ end associate
+ end do
+ if (any(s /= t)) call abort
+end program pr71014
Jakub
