[Bug libfortran/49791] New: [4.6 Regression] Formatted namelist reads of arrays don't work

[Bug libfortran/49791] New: [4.6 Regression] Formatted namelist reads of arrays don't work

[quantum.analyst at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

           Summary: [4.6 Regression] Formatted namelist reads of arrays
                    don't work
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: quantum.analyst@gmail.com


Created attachment 24797
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24797
Code to reproduce problem

I have some old code that performs a namelist read on a file of formatted form.
There's an array in the namelist. With 4.5.1, reading works just fine, and I
get the following output:

 xpos   0.0000000000000000       0.10000000000000001       0.20000000000000001 
     0.29999999999999999       0.40000000000000002        0.0000000000000000   
    0.0000000000000000        0.0000000000000000        0.0000000000000000     
  0.0000000000000000      ypos  0.50000000000000000       0.59999999999999998  
    0.69999999999999996       0.80000000000000004       0.90000000000000002    
   0.0000000000000000        0.0000000000000000        0.0000000000000000      
 0.0000000000000000        0.0000000000000000     


But with 4.6.0, I get the following error:

At line 15 of file gf-namelist.f (unit = 4, file = 'geometry.in')
Fortran runtime error: Cannot match namelist object name 0.60



gfortran -v for working version:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) 

gfortran -v for non-working version:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2011.07.20 09:30:41
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jvdelisle at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1
            Summary|[4.6 Regression] Formatted  |[4.4/4.5/4.6/4.7
                   |namelist reads of arrays    |Regression] Formatted
                   |don't work                  |namelist reads fails with:
                   |                            |Cannot match namelist
                   |                            |object
   Target Milestone|---                         |4.4.7

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-20 09:30:41 UTC ---
CONFIRMED.

 * * *

Note: The format is not standard conform. Issues: "$" vs "&", "$end" vs "/".
However, the real problem is:
 xpos(1)= 0.00, 0.10, 0.20, 0.30, 0.40,
instead of (working)
 xpos(1:5)= 0.00, 0.10, 0.20, 0.30, 0.40,
or
 xpos= 0.00, 0.10, 0.20, 0.30, 0.40,
or
 xpos(:)= 0.00, 0.10, 0.20, 0.30, 0.40,
or
 xpos(1:)= 0.00, 0.10, 0.20, 0.30, 0.40,
or ...

Thus, the workaround is to fix the array bounds in the namelist file.

Note: The program works with ifort, g95, pathf95, openf95, pgf90; it fails with
the pedantic NAG - and (this PR) with the current gfortran versions.

 * * *

Working: (4.6 trunk) 2010-09-28-r164677
             gcc-4.5-2010-07-23-r162436
Failing:
         4.7 trunk: current, 2011-05-10, 2011-05-28-r174379
              gcc-4.5-x86_64-2010-11-13-r166693

Combining the 4.6/4.7 and the 4.5 data, I think the following patch is the
culprit. As it has been back-ported to 4.4/4.5, I have now adapted the summary.
When we know how obvious the patch is, we can still adjust the target milestone
- currently it is 4.4.7.


Author: jvdelisle
Date: Tue Oct 26 19:05:08 2010
New Revision: 165979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165979
Log:
2010-10-26  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/46010
    * io/list_read.c (nml_parse_qualifier): Add additional conditions for
    setting the end index for loop specification. Fix some whitespace.
    * io/write.c (write_default_char4): Const-ify the source argument.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/write.c

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-07-20 15:42:23 UTC ---
(In reply to comment #1)
> CONFIRMED.
> 
>  * * *
> 
> Note: The format is not standard conform. Issues: "$" vs "&", "$end" vs "/".
>
> However, the real problem is:
>  xpos(1)= 0.00, 0.10, 0.20, 0.30, 0.40,

> 
> Thus, the workaround is to fix the array bounds in the namelist file.
>

Why are you calling this a workaround.  It looks like it is fixing
a bug in the user's program.

> 
> Note: The program works with ifort, g95, pathf95, openf95, pgf90; it fails with
> the pedantic NAG - and (this PR) with the current gfortran versions.
> 
>  * * *
> 
> Working: (4.6 trunk) 2010-09-28-r164677
>              gcc-4.5-2010-07-23-r162436
> Failing:
>          4.7 trunk: current, 2011-05-10, 2011-05-28-r174379
>               gcc-4.5-x86_64-2010-11-13-r166693
> 

I'm also not sure why you call this a regression.  The user
appears to use on a nonconforming namelist, which depends on
undefined behavior.  The behavior has change.

-- 
steve

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-20 16:16:43 UTC ---
(In reply to comment #2)
> Why are you calling this a workaround.  It looks like it is fixing
> a bug in the user's program.

In an ideal world, all code would use only standard Fortran and fixing the code
would be trivial. However, in a real world, we live with more or less common
vendor extensions which are used by real programs, even if there is now a
better standard-conform replacement. I am sure that version of namelist
predates Fortran 90.

If the bug reporter can, I think he should convert all the input files to the
Fortran 90 syntax of namelists. However, one needs to be careful to not
inadvertently to change the meaning (e.g. remove the wrong "(1)") and it might
affect many files.


> I'm also not sure why you call this a regression.

That's simple: It worked before, now it stopped. As the vendor extension is
very common - it works at least with PGI, Intel, g95, gfortran (before the
2010-10), Sun, Open64, Pathf95 and crayftn, it makes sense to regard this as
supported vendor extension. (I am sure more compiler support it, but I don't
have access to them.)

A different example would be:
  &nml tag = string /
which is only supported by ifort. All other compilers fail as "string" is not
quoted. If gfortran had supported such a feature as only compiler or as one of
very few compilers, I would agree that breaking it, would probably fall into
the WONTFIX category.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-07-20 17:15:19 UTC ---
On Wed, Jul 20, 2011 at 04:18:01PM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791
> 
> --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-20 16:16:43 UTC ---
> 
> > I'm also not sure why you call this a regression.
> 
> That's simple: It worked before, now it stopped. As the vendor extension is
> very common - it works at least with PGI, Intel, g95, gfortran (before the
> 2010-10), Sun, Open64, Pathf95 and crayftn, it makes sense to regard this as
> supported vendor extension. (I am sure more compiler support it, but I don't
> have access to them.)
> 

It's an undocumented bug^H^H^H extension.

The undocumented extension cannot be flagged by any combination of
-Wall, -Wextra, -fcheck=all, -Wsurprising and/or -std=f95,f2003,f2008.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-20 17:24:47 UTC ---
(In reply to comment #4)
> The undocumented extension cannot be flagged by any combination of
> -Wall, -Wextra, -fcheck=all, -Wsurprising and/or -std=f95,f2003,f2008.

Different run-time behaviors can never be diagnosed at compile time. One could
argue whether libgfortran should behave differently, depending on flags (such
as -std=* or -f*), but that's something different. (And some flags *do* change
what libgfortran accepts)

> It's an undocumented bug^H^H^H extension.

I would love to have a complete documentation of the language including the
vendor extensions - as some major vendors have. However, unless someone
actually does, one has to live with an incomplete documentation. I think most
users prefer fixed bugs and new features to a better documentation.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[quantum.analyst at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #6 from Elliott Sales de Andrade <quantum.analyst at gmail dot com> 2011-07-20 21:09:20 UTC ---
(In reply to comment #3)
> If the bug reporter can, I think he should convert all the input files to the
> Fortran 90 syntax of namelists. However, one needs to be careful to not
> inadvertently to change the meaning (e.g. remove the wrong "(1)") and it might
> affect many files.
> 

I can change the test suite, but since we also use the Intel and PGI compilers,
I wouldn't be able to guarantee other people won't get confused with this.

(In reply to comment #4)
> 
> It's an undocumented bug^H^H^H extension.
> 
> The undocumented extension cannot be flagged by any combination of
> -Wall, -Wextra, -fcheck=all, -Wsurprising and/or -std=f95,f2003,f2008.

Perhaps I am misreading it, but I thought it was actually documented at
http://gcc.gnu.org/onlinedocs/gfortran/Extensions-to-namelist.html

> Expanded namelist reads are permitted. This causes an error if -std=f95 is
> used. In the following example, the first element of the array will be given
> the value 0.00 and the two succeeding elements will be given the values 1.00
> and 2.00.
>
>     &MYNML
>       X(1,1) = 0.00 , 1.00 , 2.00
>     /
>

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-07-20 21:22:36 UTC ---
> (In reply to comment #3)
>> If the bug reporter can, I think he should convert all the input
>> files to the Fortran 90 syntax of namelists. However, one needs
>> to be careful to not inadvertently to change the meaning (e.g.
>> remove the wrong "(1)") and it might
>> affect many files.
>> 
> 
> I can change the test suite, but since we also use the Intel and
> PGI compilers, I wouldn't be able to guarantee other people won't
> get confused with this.

Confused by using standard conforming syntax?

Perhaps, people should not use features of a language 
if they do not understand those features.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-20 21:53:42 UTC ---
(In reply to comment #1)
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165979
>     PR libgfortran/46010

The problem is that "dtp->u.p.ionml->touched" becomes 0 (initially it is 1)
such that one stops the expanded_read.

It seems as if the issue of this PR is solved - without causing test-suite
regressions -, if one removes that check while keeping the line for BT_DERIVED.
(I am currently testing the whole test suite; however, all namelist*.* tests
already succeeded.)

Jerry what do you think? I have to admit that I have not the slightest idea
what ionml->touched does - thus, I cannot come up of a possibly failing
namelist.

--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2213,7 +2213,6 @@ nml_parse_qualifier (st_parameter_dt *dtp,
descriptor_dimension *ad,
                      do not allow excess data to be processed.  */
                  if (is_array_section == 1
                      || !(compile_options.allow_std & GFC_STD_GNU)
-                     || !dtp->u.p.ionml->touched
                      || dtp->u.p.ionml->type == BT_DERIVED)
                    ls[dim].end = ls[dim].start;
                  else

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-07-21 18:32:31 UTC ---
(In reply to comment #8)
> Jerry what do you think? I have to admit that I have not the slightest idea
> what ionml->touched does - thus, I cannot come up of a possibly failing

As you know, the namelist code is difficult to follow and touched was not my
invention, but basically it is a flag that tells us that we already encountered
this variable or a parent in a previous iteration.  I don't have the code in
front of me, but I seem to recall there is a comment elsewhere in the file that
mentions something about it.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-07-22 01:28:19 UTC ---
(In reply to comment #6)
> (In reply to comment #3)
> > If the bug reporter can, I think he should convert all the input files to the
> > Fortran 90 syntax of namelists. However, one needs to be careful to not
> > inadvertently to change the meaning (e.g. remove the wrong "(1)") and it might
> > affect many files.
> > 
> 
> I can change the test suite, but since we also use the Intel and PGI compilers,
> I wouldn't be able to guarantee other people won't get confused with this.

Regardless of how we end up resolving this bug, if you can change your namelist
files to be "more correct" you should do so.  The idea of legacy behavior
support is to be practical for those who have no control over older codes.  I
will comment further on the patch itself after I have a review our code.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-07-22 13:49:59 UTC ---
After reviewing the listread.c and the test case I see that the touched should
have nothing to do with this test case since the case has nothing to do with
derived types.

I think the flaw is that touched should be combined with BT_DERIVED if used
here at all. This leads me to believe we are missing a parenthesis around
BT_DERIVED and touched and they should be ANDed in some manner..

Tobias patch is probably safe, but it may be possible to dream up a test case
with derived types that will fail. (There is probably one buried in my archives
but finding it would be a chore)

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-22 22:44:24 UTC ---
Author: burnus
Date: Fri Jul 22 22:44:20 2011
New Revision: 176661

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176661
Log:
2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * io/list_read.c (nml_parse_qualifier): Remove check to
        enabled extended read for another case.

2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * gfortran.dg/namelist_72.f: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/namelist_72.f
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/list_read.c

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-23 10:27:00 UTC ---
(In reply to comment #12)
> New Revision: 176661

This commit fixes the original issue. A more special case still fails,
cf. http://gcc.gnu.org/ml/fortran/2011-07/msg00252.html Thus, the support for
the vendor extension has still regressed. But since Rev. 176661, at least the
test case of comment 0 is fixed.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-07-23 15:26:09 UTC ---
Several years ago, I sketched out a "flow" chart for all of namelist so I could
walk the logic and see what to do. I think we need to do this again and maybe
post it to the wiki.  (unfortunately I do not have that sketch)

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-27 17:45:10 UTC ---
Author: burnus
Date: Wed Jul 27 17:45:01 2011
New Revision: 176839

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176839
Log:
2011-07-27  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * io/list_read.c (nml_parse_qualifier): Remove check to
        enabled extended read for another case.

2011-07-27  Tobias Burnus  <burnus@net-b.de>

        Backported from mainline
        2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * gfortran.dg/namelist_72.f: New.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/namelist_72.f
Modified:
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/libgfortran/ChangeLog
    branches/gcc-4_6-branch/libgfortran/io/list_read.c

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-27 21:35:15 UTC ---
Author: burnus
Date: Wed Jul 27 21:35:08 2011
New Revision: 176850

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176850
Log:
2011-07-27  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * io/list_read.c (nml_parse_qualifier): Remove check to
        enabled extended read for another case.

2011-07-27  Tobias Burnus  <burnus@net-b.de>

        Backported from mainline
        2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * gfortran.dg/namelist_72.f: New.


Added:
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_72.f
Modified:
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/libgfortran/ChangeLog
    branches/gcc-4_5-branch/libgfortran/io/list_read.c

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-28 05:39:00 UTC ---
Author: burnus
Date: Thu Jul 28 05:38:54 2011
New Revision: 176857

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176857
Log:
2011-07-28  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * io/list_read.c (nml_parse_qualifier): Remove check to
        enabled extended read for another case.

2011-07-28  Tobias Burnus  <burnus@net-b.de>

        Backported from mainline
        2011-07-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49791
        * gfortran.dg/namelist_72.f: New.


Added:
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_72.f
Modified:
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_4-branch/libgfortran/ChangeLog
    branches/gcc-4_4-branch/libgfortran/io/list_read.c

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-28 05:47:39 UTC ---
The issue of the original report (comment 0) is now fixed for GCC 4.4 to the
trunk (4.7): The vendor extension extended array read of normal arrays in
namelists works again.

However, the following program still fails. It uses the same vendor extension
but for array components of derived types. The program works with gfortran
(before the 2010-10-xx commits), g95, sunf95, openf90, pathf95, pgf90 and
crayftn. It does not work with ifort.

TODO: Either one allows this test case (cf. comment 13) - or one decides that
that part (extended array read for derived-type components) of the vendor
extension won't be support anymore and updates the manual.


! { 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

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #19 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-05 23:00:16 UTC ---
I think the patch suggested in
http://gcc.gnu.org/ml/fortran/2011-07/msg00252.html is actually correct - which
then fixes the issue of comment 18. 

--- ../../libgfortran/io/list_read.c    (Revision 183913)
+++ ../../libgfortran/io/list_read.c    (Arbeitskopie)
@@ -2206,3 +2211,4 @@ nml_parse_qualifier (st_parameter_dt *dt
                      || !(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))
                    ls[dim].end = ls[dim].start;


However, one then runs into a failure for fortran.dg/namelist_66.f90, but it
fails in the same way for the program below. Contrary to comment 18 (which is
about a vendor extension), I believe the following program *is* valid. At least
one combines an incomplete read of the whole array "(:)" with some explicit
reads.


One should recall that in namelist, all character constants have to start with
a quotation mark. Thus, if one reads [a-z], one is always matching a namelist
object name! Thus, before reading the next array element, one should check
whether one has as next item something starting with "a-zA-z"; if so, one does
an early return from nml_read_obj



Expected (as with NAG):
 &NAML1 TRACER = aa T bb T XX F/

Result with gfortran:
 Fortran runtime error: Cannot match namelist object name 'bb'


Example:

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

tracer(:) = ptracer('XXX', .false.)
open (99, file='nml.dat', status="replace")
write(99,*) "&naml1"
write(99,*) "   tracer(:)   = 'aa' , .true."
write(99,*) "   tracer(2)   = 'bb' , .true. /"
rewind(99)
read (99, nml=naml1)
write (*, nml=naml1)
close (99, status="delete")
end



Using the following early draft patch, the example above works. However, if one
changes one tracer(2) line to:
  write(99,*) "   tracer(2)   = 'bb' , .true. "
(i.e. removes the "/") one gets:
  Fortran runtime error: End of file
which looks reasonable.

However, if one adds after that line:
  write(99,*) "   tracer(3)   = 'cc' , .true. "
one now gets:
  Fortran runtime error: Internal namelist read error

It works correctly if a "/" is added in the last write above.


Hence, I think the patch is in the correct direction, but not yet ready.

--- ../../libgfortran/io/list_read.c    (Revision 183913)
+++ ../../libgfortran/io/list_read.c    (Arbeitskopie)
@@ -2517,2 +2518,19 @@ nml_read_obj (st_parameter_dt *dtp, name

+/*       if (dtp->u.p.expanded_read)*/
+           {
+             char c;
+
+             /* Skip whitespace.  */
+             do
+               c = next_char (dtp);
+             while (c != EOF && (c == ' ' || c == '\t' || c == '\r' || c ==
'\n'));
+             unget_char (dtp, c);
+
+             /* Stop early - next namelist object found. */
+             if ((c >= 'A' && c <= 'Z') || (c >= 'a' && c <= 'z'))
+             {
+               return SUCCESS;
+             }
+           }
+
           switch (nl->type)

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-06 22:18:39 UTC ---
(In reply to comment #19)
> --- ../../libgfortran/io/list_read.c    (Revision 183913)
> @@ -2206,3 +2211,4 @@ nml_parse_qualifier (st_parameter_dt *dt
> @@ -2517,2 +2518,19 @@ nml_read_obj (st_parameter_dt *dtp, name

Using the two patches, the related PR 51825 is not fixed - and one additionally
gets the following failures:
 gfortran.dg/namelist_17.f90
 gfortran.dg/namelist_23.f90
 gfortran.dg/namelist_42.f90
 gfortran.dg/namelist_43.f90
 gfortran.dg/namelist_44.f90
 gfortran.dg/pr19657.f

[Bug libfortran/49791] [4.5/4.6/4.7/4.8 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |4.5.4

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 12:46:49 UTC ---
4.4 branch is being closed, moving to 4.5.4 target.

[Bug libfortran/49791] [4.6/4.7/4.8 Regression] Formatted namelist reads fails with: Cannot match namelist object

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

[Bug libfortran/49791] [4.6/4.7/4.8 Regression] Formatted namelist reads fails with: Cannot match namelist object

[orion at cora dot nwra.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #22 from Orion Poplawski <orion at cora dot nwra.com> 2012-07-02 14:04:57 UTC ---
I am on vacation and will be out of the office until Monday, July 2nd.

Your message has been saved and I will respond if needed when I return.

If this is an urgent CoRA computing issue, please contact Andy Frahm or
send email to coracomputer@cora.nwra.com.

Cheers,

   Orion

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion@cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

[Bug libfortran/49791] [4.6/4.7/4.8 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |jvdelisle at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #23 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2013-01-02 17:17:53 UTC ---
I will work this one along with pr51825

[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #25 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2013-03-30 03:18:49 UTC ---
Lets close this one and carry forward on PR56660.