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
