Hello Harald, Could you point me to those cases, please?
The problem here is that the bounds check comes before the evaluation of the loop variables. I tried all manner of things to get around that but all resulted in segfaults. Thanks, I will push as is and hope, as you say, that somebody will come up with a way to eliminate the warning. Perhaps a temporary generated in resolve.cc might be best. Regards Paul On Tue, 24 Mar 2026 at 21:33, Harald Anlauf <[email protected]> wrote: > > Hi Paul, > > this looks good to me, so OK from my side. > > Thanks for the patch! > > Harald > > P.S.: We have a couple of other cases where we evaluate expressions > with side-effects more than once, contrary to what the standard says. > Once we solve this, we might be able to get rid of your new warning ;-) > > On 3/24/26 17:53, Paul Richard Thomas wrote: > > Please find attached a version of the patch that excludes implicitly > > pure procedures from the bounds warning. > > > > Cheers > > > > Paul > > > > On Tue, 24 Mar 2026 at 10:42, Paul Richard Thomas > > <[email protected]> wrote: > >> > >> Hello all, > >> > >> The attached fixes the above regression. I would have pushed it as > >> obvious were it not for my decision to warn for index expressions > >> containing functions not declared to be pure. If the warning is > >> thought to be OTT, I can remove it. > >> > >> Also, note the pointer assignment at the end, which demonstrates that > >> this regression is not specific to the associate statement but to > >> pointer expressions in general. > >> > >> Regtests with FC43/x86_64 - OK for all the affected branches? > >> > >> Cheers > >> > >> Paul >
