Patchwork [Fortran] PR49791 - Fix legacy namelist support

login
register
mail settings
Submitter Tobias Burnus
Date July 23, 2011, 10:20 a.m.
Message ID <4E2AA070.1030709@net-b.de>
Download mbox | patch
Permalink /patch/106426/
State New
Headers show

Comments

Tobias Burnus - July 23, 2011, 10:20 a.m.
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:

!--------------------------
! { dg-do run }
!
!  PR fortran/49791
!

type t
   integer :: array(4)
end type t

type(t) :: a
namelist /nml/a

a%array = [ 1,2,3,4]
open(999, status='scratch')
write(999,'(a)') '&nml a%array(1) = 99, 192 /'
rewind(999)
read(999, nml=nml)
if (any (a%array /= [ 99, 192, 3, 4])) call abort ()
!write(*,nml=nml)
end
!--------------------------


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:

type ptracer
    character(len = 2)  :: sname
    logical              :: lini
end type ptracer
type(ptracer) , dimension(3) :: tracer

Tobias

PS: The patch which causes the regression is:

                     ls[dim].end = ls[dim].start;
jerry DeLisle - July 23, 2011, 3:18 p.m.
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

Patch

--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2215,3 +2215,4 @@  nml_parse_qualifier (st_parameter_dt *dtp, 
descriptor_dimension *ad,
                       || !(compile_options.allow_std & GFC_STD_GNU)
-                     || dtp->u.p.ionml->type == BT_DERIVED)
+                     || (dtp->u.p.ionml->type == BT_DERIVED
+ && !dtp->u.p.ionml->touched))