This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] Simplify lbound
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Thomas Koenig <tkoenig at netcologne dot de>, fortran at gcc dot gnu dot org
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 May 2015 12:03:38 +0200
- Subject: Re: [Patch, Fortran] Simplify lbound
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header dot from=mikael dot morin at sfr dot fr
- 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> <5551A10A dot 6080707 at netcologne dot de>
Le 12/05/2015 08:43, Thomas Koenig a Ãcrit :
> 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.
>
thanks.