Confirmed.

Created attachment 29734 [details]
Draft patch (only for read_integer)

Draft patch - fixes the issue of the test case, but one probably should do an audit of the whole file (list_read). For instance, using REAL instead of INTEGER in the test case also fails. One probably does not need to handle all CASE_SEPARATORS, but presumably a large number of those.

Agree, we should just audit list_read.c for this case.

Created attachment 29752 [details]
Test case  - please read comment in the file or comment 4

The test case is successful with ifort 13.1, it fails (iostat/=0, run time failure) with Crayftn and PGI already for "i=1!".


According to the Fortran standard, the example - as the example in comment 0 - is invalid. From Fortran 2008, "10.11.3.6 Namelist comments":

"Except within a character literal constant, a "!" character after a value separator or in the first nonblank position of a namelist input record initiates a comment."

Note the "after a value separator". In "i=1!" there is no value separator after the value "1".


For my character example "c1 = a": Also that example is invalid according to the Fortran standard, which states in "10.11.3.3 Namelist input values":

"When the next effective item is of type character, the input form consists of a delimited sequence of zero or more rep-chars [...]"

Thus, either " or ' is required as delimiter - but the example doesn't use neither.



EXPECTED RESULTS:

(a) "i=1!" is either accepted as vendor extension as "i=1 !...", matching Intel's result.  Or it is rejected with a compile-time error as Crayftn and PGI do it.

Currently, integers and reals (except for INF/NAN) give not error but the result is not modified (BUG!).  For logical, complex and delimited character strings, the value is read (as vendor extension), and for INF and NAN a "cannot match namelist object" error is shown - which is acceptable according to the standard an matches PGI/Crayftn.


(b) For nondelimited character strings: Currently, it gives the error "Cannot match namelist object", which is fine according to the standard. One could still consider to support reading it as vendor extension - as Intel does. (Simply read from the first nonspace character to the first value separator.)

I have a patch testing that fixes the items identified in the attachment of Comment #4 by accepting them as extension.

I forgot about this one.

Potential simple patch.

Index: io/list_read.c
===================================================================
--- io/list_read.c	(revision 222110)
+++ io/list_read.c	(working copy)
@@ -53,7 +53,7 @@ typedef unsigned char uchar;
                       case '5': case '6': case '7': case '8': case '9'
 
 #define CASE_SEPARATORS  case ' ': case ',': case '/': case '\n': case '\t': \
-                         case '\r': case ';'
+                         case '\r': case ';': case '!'
 
 /* This macro assumes that we're operating on a variable.  */

Author: jvdelisle
Date: Tue Apr 21 16:13:54 2015
New Revision: 222271

URL: https://gcc.gnu.org/viewcvs?rev=222271&root=gcc&view=rev
Log:
2015-04-21 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/56743
	* io/list_read.c (CASE_SEPARATORS): Add case for '!'.
	(is_separator): Add condition for '!'.
	(eat_separator): Use notify_std to warn or errord if '!' is
	encountered before a proper separator.

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

Author: jvdelisle
Date: Tue Apr 21 16:33:27 2015
New Revision: 222272

URL: https://gcc.gnu.org/viewcvs?rev=222272&root=gcc&view=rev
Log:
2015-04-21 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/56743
	* gfortran.dg/namelist_87.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/namelist_87.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

Fixed on trunk. Closing.