Hi Mikael,
> To be honest, both patches look fragile to me. Yours because it leaves
> gfc_current_ns to its value, leaving the door open to other problems.
> Mine, well, because it's playing with a global variable, with the
> possible side-effects this could have.
> However, without a better idea, I'm OK with either patch (or both).
I have found that playing around with gfc_current_ns can be quite
dangerous and can cause regressions in unexpected places. Specifically,
I tried wrapping the callers to create_var and insert_block in
save/restore wrappers for gfc_current_ns, and that caused quite
a few very strange regressions.
So, working on the theory that a fix that may leave unknown problems
open is better than a fix that may introduce unknown problems, and
in order to get the regression out of the way, I have committed the
patch preventing multiple resolution of an array spec.
Maybe we should open a PR for auditing the use of gfc_current_ns
in front-end optmiization.
Regards
Thomas
