[Patch, Fortran] PR49791 - Fix legacy namelist support

[Jerry DeLisle]

On 07/23/2011 03:20 AM, Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> I would say OK for trunk and then backport in a few weeks. If you feel like
>> being conservative you could use
>>
>> || (dtp->u.p.ionml->type == BT_DERIVED && !dtp->u.p.ionml->touched)) but I do
>> not think it is necessary.
>
> I have committed the initial patch as Rev. 176661.
>
> * * *
>
> However, the following test case still fails with the now-patched gfortran
> version. It worked with gfortran before the October 2010 patch - and it also
> works with g95, pgi and openf95/pathf95/sunf95/crayftn. The testcase is:
>

Welcome to the world of namelists! I take it this is a new test case you 
developed after my comments on the PR?

Stating the obvious, properly formed namelists need to take priority until this 
is figured out so consider reverting your last commit

> !--------------------------
> ! { dg-do run }
> !
> ! PR fortran/49791
> !
---snip---
>
> Using your patch (cf. below) fixes it - but it regresses for
> gfortran.dg/namelist_66.f90 (PR PR46010):
> Fortran runtime error: Cannot match namelist object name 'bb'
>
> That's while reading:
>
> &naml1
> tracer(1) = 'aa', .true.
> tracer(2) = 'bb', .true.
> tracer(3) = 'cc', .true.
> /
>
> Thus, it somehow regards a quoted string - after the namelist object name - as
> object name! The namelist object is:

While trying to do an extended read, there is no way to know the difference.  I 
suspect it is trying to continue reading beyond tracer(1) and set tracer(2), 
first component, to "tracer(2)".  This is the fundamental problem with extended 
reads, where does it end? Maybe one needs to backup on an error and cycle the 
loop, going to the next object.

Jerry