| Message ID | CAHqFgjUmzohCh+1h3ekGXQs5x6nUWrK7VjdG=fon7SqtJ7cDbA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Dear Alessandro, Alessandro Fanfarillo wrote: > the compiler returns an ICE when a coarray critical section is used > inside a module procedure. > The symbols related with the lock variables were left uncommitted > inside resolve_critical(). A gfc_commit_symbol after each symbol or a > gfc_commit_symbols at the end of resolve_critical() fixed the issue. > > The latter solution is proposed in the attached patch. > Built and regtested on x86_64-pc-linux-gnu Looks good to me. > PS: This patch should be also included in GCC 5. Yes, that's fine with me. Tobias PS: I saw that you now have a GCC account, which you can use to commit to both the trunk and gcc-5-branch. See https://gcc.gnu.org/svnwrite.html. Additionally, you should update MAINTAINERS (trunk only) by adding yourself under "Write After Approval"; you can simply commit this patch yourself, but you should write an email to gcc-patches with the patch - like Alan did at https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02390.html
Committed as revision 231649 on trunk and as revision 231650 on gcc-5-branch. Thanks. 2015-12-14 20:02 GMT+01:00 Tobias Burnus <burnus@net-b.de>: > Dear Alessandro, > > Alessandro Fanfarillo wrote: >> >> the compiler returns an ICE when a coarray critical section is used >> inside a module procedure. >> The symbols related with the lock variables were left uncommitted >> inside resolve_critical(). A gfc_commit_symbol after each symbol or a >> gfc_commit_symbols at the end of resolve_critical() fixed the issue. >> >> The latter solution is proposed in the attached patch. >> Built and regtested on x86_64-pc-linux-gnu > > > Looks good to me. > >> PS: This patch should be also included in GCC 5. > > > Yes, that's fine with me. > > Tobias > > PS: I saw that you now have a GCC account, which you can use to commit to > both the trunk and gcc-5-branch. See https://gcc.gnu.org/svnwrite.html. > Additionally, you should update MAINTAINERS (trunk only) by adding yourself > under "Write After Approval"; you can simply commit this patch yourself, but > you should write an email to gcc-patches with the patch - like Alan did at > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02390.html
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 65a2b7f..3988b3c 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -8852,6 +8852,7 @@ resolve_critical (gfc_code *code) symtree->n.sym->as->cotype = AS_EXPLICIT; symtree->n.sym->as->lower[0] = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1); + gfc_commit_symbols(); } diff --git a/gcc/testsuite/gfortran.dg/coarray_critical_1.f90 b/gcc/testsuite/gfortran.dg/coarray_critical_1.f90 new file mode 100644 index 0000000..4d93bf6 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/coarray_critical_1.f90 @@ -0,0 +1,12 @@ +! { dg-do compile } +! { dg-options "-fcoarray=lib" } +! + +module m + contains + subroutine f() + critical + end critical + end subroutine f + end module m +end program
Dear all, the compiler returns an ICE when a coarray critical section is used inside a module procedure. The symbols related with the lock variables were left uncommitted inside resolve_critical(). A gfc_commit_symbol after each symbol or a gfc_commit_symbols at the end of resolve_critical() fixed the issue. The latter solution is proposed in the attached patch. Built and regtested on x86_64-pc-linux-gnu Cheers Alessandro PS: This patch should be also included in GCC 5. 2015-12-10 Alessandro Fanfarillo <fanfarillo.gcc@gmail.com> * resolve.c (resolve_critical): Committing symbols of lock variables. 2015-12-10 Alessandro Fanfarillo <fanfarillo.gcc@gmail.com> * gfortran.dg/coarray_critical_1.f90: New. commit ccc06accb4891ab95d33135b62c479d895b2270f Author: Alessandro Fanfarillo <fanfarillo@ing.uniroma2.it> Date: Thu Dec 10 15:28:33 2015 +0000 Committing symbols of lock variables inside resolve_critical()