Hi!
As discussed in the PR, nerrs(i,io) isn't allocatable var even
when nerrs is allocatable, thus a reasonable reading of the new OpenMP 4.0
requirement is that the testcase is still valid.
I went ahead and committed the change suggested by Tobias. For the rest
mentioned in the PR, more thought and much larger patch will be needed.
2014-08-15 Jakub Jelinek <ja...@redhat.com>
Tobias Burnus <bur...@net-b.de>
PR fortran/62131
* openmp.c (resolve_omp_atomic): Only complain if code->expr1's attr
is allocatable, rather than whenever var->attr.allocatable.
* gfortran.dg/gomp/pr62131.f90: New test.
--- gcc/fortran/openmp.c.jj 2014-08-14 18:38:46.000000000 +0200
+++ gcc/fortran/openmp.c 2014-08-15 12:02:13.025699623 +0200
@@ -2744,7 +2744,7 @@ resolve_omp_atomic (gfc_code *code)
break;
}
- if (var->attr.allocatable)
+ if (gfc_expr_attr (code->expr1).allocatable)
{
gfc_error ("!$OMP ATOMIC with ALLOCATABLE variable at %L",
&code->loc);
--- gcc/testsuite/gfortran.dg/gomp/pr62131.f90.jj 2014-08-15
12:02:37.510575517 +0200
+++ gcc/testsuite/gfortran.dg/gomp/pr62131.f90 2014-08-15 12:03:28.421317788
+0200
@@ -0,0 +1,19 @@
+! PR fortran/62131
+! { dg-do compile }
+! { dg-options "-fopenmp" }
+
+program pr62131
+ integer,allocatable :: nerrs(:,:)
+ allocate(nerrs(10,10))
+ nerrs(:,:) = 0
+!$omp parallel do
+ do k=1,10
+ call uperrs(k,1)
+ end do
+contains
+ subroutine uperrs(i,io)
+ integer,intent(in) :: i,io
+!$omp atomic
+ nerrs(i,io)=nerrs(i,io)+1
+ end subroutine
+end
Jakub
