This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] Simplify lbound
- From: Thomas Koenig <tkoenig at netcologne dot de>
- To: Mikael Morin <mikael dot morin at sfr dot fr>, fortran at gcc dot gnu dot org
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 May 2015 08:43:22 +0200
- Subject: Re: [Patch, Fortran] Simplify lbound
- Authentication-results: sourceware.org; auth=none
- References: <553B7BA4 dot 6040103 at netcologne dot de> <553BD925 dot 3050401 at sfr dot fr> <553E83B4 dot 8020005 at netcologne dot de> <5542722E dot 3030307 at sfr dot fr> <5543EA34 dot 6060304 at sfr dot fr> <5546872F dot 7040507 at netcologne dot de> <554F640D dot 5020506 at sfr dot fr> <CAMe9rOra_hoDhhkrrTzY3VSAo-A+Bww-FgZ1avKVPFWxnie8-Q at mail dot gmail dot com> <554FD6E1 dot 8090202 at netcologne dot de> <5550ABEC dot 8050909 at sfr dot fr>
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