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 <mik...@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 <mik...@gcc.gnu.org>
>
> PR fortran/66549
> * gfortran.dg/gomp/omp_parallel_1.f90: New file.
Jakub
