Le 18/06/2015 13:35, Jakub Jelinek a écrit : > 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? > Hmm, for gfc_derived_types at least, I would say no. gfc_derived_types seems to be a per root namespace global, in other words shared between contained procedures, so it should not be saved/restored upon resolution of sibling or internal procedures. And I don't think it's possible to escape one root namespace; use-associated symbols are not shared with the corresponding module symbols for example. So we are (quite) safe here, I think.
To be honest, I'm not at ease with these globals, both openmp and derived_types, and I'm not fond of starting resolution of a different procedure in the middle of nowhere. I can try to produce a patch that walks the procedure code to pick the needed information instead of doing full procedure resolutions at arbitrary places, if that seems worth it. Or try to remove gfc_derived_types. But IMHO the patch proposed here makes sense in any case. Mikael
