*ping* [patch, fortran] Fix PR 96018, wrong code caused by implicit_pure

[Paul Richard Thomas]

Hi Thomas,

I am fine with this being in frontend-passes.c - it was just a question
:-)  resolve.c has become too large anyway.

The testcase looks familiar! Don't forget to commit and push the additional
source too.

OK for 10-- and all the affected branches.

Cheers

Paul

On Sat, 18 Jul 2020 at 18:57, Thomas Koenig <tkoenig@netcologne.de> wrote:

> Hi Paul,
>
> > The patch looks fine to me but I have two questions:
> >
> > (i) Why is this not done in resolve.c?
>
> Of course it doesn't matter where the function resides :-)  I put it
> into frontend-passes.c because it makes heavy use of gfc_code_walker,
> and out of habit. If you prefer, I can of course move the code to
> resolve.c.
>
> If your question is more like "why is that not done during
> normal resolution" - while fixing this bug, I began to understand
> why the standard has an explicit PURE attribute.  If the compiler
> is chasing after a procedure which may or may not be implicit_pure, then
> everything else needs to have been resolved beforehand. And in normal
> resolution, something needs to be the last.
>
> > (ii) Is Martin's reduced reproducer not the basis for a testcase?
>
> There, git got the better of me.  I thought it was included in the
> patch, but, as I reread it and found that this wasn't the case.
>
> I have attache the test case now.
>
> OK for trunk and backport once gcc 10 is open again?
>
> Regards
>
>         Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein