This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR66549 [5/6 regression] ICE with OMP PARALLEL
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Thu, 18 Jun 2015 13:35:38 +0200
- Subject: Re: [Patch, fortran] PR66549 [5/6 regression] ICE with OMP PARALLEL
- Authentication-results: sourceware.org; auth=none
- References: <5582A8FA dot 5010002 at sfr dot fr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jun 18, 2015 at 01:18:18PM +0200, Mikael Morin wrote:
> I'm proposing here a fix for an OpenMP ICE regression introduced by me
> at http://gcc.gnu.org/r221586
>
> That revision changed the order in which procedures are resolved, making
> it possible for a procedure to be resolved from within an OpenMP
> construct body. As the OpenMP constructs set some global state, the
> procedure's do loop were registered as OpenMP-managed loops.
>
> The attached patch clears the OpenMP state upon gfc_resolve entry
> and restores it upon return. I don't know the OpenMP code very well,
> but it seems reasonable to me to do that.
>
> Regression-tested on x86_64-linux. OK for trunk/5 ?
I just wonder, the resolve_global_procedure code didn't save just
OpenMP state, but also e.g. gfc_derived_types. Isn't that a problem
too with wherever you are now calling gfc_resolve from within resolving
of some other procedure?
> 2015-06-18 Mikael Morin <mikael@gcc.gnu.org>
>
> PR fortran/66549
> * resolve.c (resolve_global_procedure): Don't save and restore
> OpenMP state around the call to gfc_resolve.
> (gfc_resolve): Save OpenMP state on entry and restore it on return.
>
> 2015-06-18 Mikael Morin <mikael@gcc.gnu.org>
>
> PR fortran/66549
> * gfortran.dg/gomp/omp_parallel_1.f90: New file.
Jakub