[Bug fortran/60148] New: strings in NAMELIST do not honor DELIM= in open statement

[Bug fortran/60148] New: strings in NAMELIST do not honor DELIM= in open statement

[kargl at gcc dot gnu.org]

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

            Bug ID: 60148
           Summary: strings in NAMELIST do not honor DELIM= in open
                    statement
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.7.4, 4.8.3, 4.9.0

--- Comment #1 from kargl at gcc dot gnu.org ---
program namelistout
   implicit none
   character :: mystring*5 = 'tue'
   namelist /mylist/ mystring
   open(unit=10,file='junk1.dat',delim='apostrophe')
   write(10, mylist)
   close(10)
   open(unit=10,file='junk2.dat',delim='quote')
   write(10, mylist)
   close(10)
   open(unit=10,file='junk3.dat',delim='none')
   write(10, mylist)
   close(10)
   open(unit=10,file='junk4.dat')
   write(10, mylist)
   close(10)
end program

% gfc4x -o z g.f90 && ./z
% cat junk?.dat
&MYLIST
 MYSTRING='tue  ',
 /
&MYLIST
 MYSTRING="tue  ",
 /
&MYLIST
 MYSTRING="tue  ",
 /
&MYLIST
 MYSTRING="tue  ",
 /

junk3.dat and junk4.dat should contain
&MYLIST
 MYSTRING=tue,
 /


10.11.4.2   Namelist output editing

Values in namelist output records are edited as for
list-directed output (10.10.4).

10.10.4
...
Character sequences produced when the delimiter mode has a
value of NONE
  . are not delimited by apostrophes or quotation marks,
  . are not separated from each other by value separators,
  · have each internal apostrophe or quotation mark
    represented externally by one apostrophe or quotation
    mark, and
  · have a blank character inserted by the processor at the
    beginning of any record that begins with the continuation
    of a character sequence from the preceding record.

Character sequences produced when the delimiter mode has a
value of QUOTE are delimited by quotes, are preceded and
followed by a value separator, and have each internal quote
represented on the external medium by two contiguous quotes.

Character sequences produced when the delimiter mode has a
value of APOSTROPHE are delimited by apostrophes, are preceded
and followed by a value separator, and have each internal
apostrophe represented on the external medium by two contiguous
apostrophes.

9.5.6.8   DELIM= specifier in the OPEN statement

The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE,
or NONE.  The DELIM= specifier is permitted only for a connection
for formatted input/output.  It specifies the delimiter mode
(9.6.2.8) for list-directed (10.10.4) and namelist (10.11.4.2)
output for the connection.  This mode has no effect on input.  It
is a changeable mode (9.5.2).  If this specifier is omitted in an
OPEN statement that initiates a connection, the default value is NONE.
>From gcc-bugs-return-443309-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 11 16:31:48 2014
Return-Path: <gcc-bugs-return-443309-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5938 invoked by alias); 11 Feb 2014 16:31:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5879 invoked by uid 48); 11 Feb 2014 16:31:41 -0000
From: "ktietz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58873] [4.7/4.8/4.9 Regression] [c++11] ICE with __underlying_type for broken enum
Date: Tue, 11 Feb 2014 16:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: error-recovery, ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktietz at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58873-4-CHszqsvNlh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58873-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58873-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg01066.txt.bz2
Content-length: 1080

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX873

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #2 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Issue here is that the argument type gets NULL for function-call of
cp_parser_functional_cast.  This invalid type is the result of
cp_parser_simple_type_specifier call.

A fix might be to checking within cp_parser_functional_cast for type == NULL
and set it to error_mark_node if so.

Index: parser.c
==================================================================--- parser.c    (Revision 207686)
+++ parser.c    (Arbeitskopie)
@@ -23167,6 +23167,9 @@ cp_parser_functional_cast (cp_parser* parser, tree
   tree cast;
   bool nonconst_p;

+  if (!type)
+    type = error_mark_node;
+
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
     {
       maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-02-11
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed on 4.7.4, 4.8.3, and trunk (4.9).

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Like this:

&MYLIST
 MYSTRING        = 'tue  '
 /
 &MYLIST
 MYSTRING        = "tue  "
 /
 &MYLIST
 MYSTRING        = tue  
 /
 &MYLIST
 MYSTRING        = tue  
 /

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> Like this:
> 
> &MYLIST
>  MYSTRING        = 'tue  '
>  /
>  &MYLIST
>  MYSTRING        = "tue  "
>  /
>  &MYLIST
>  MYSTRING        = tue  
>  /
>  &MYLIST
>  MYSTRING        = tue  
>  /

Dang!  You beat me to the patch.  Here's what I have.
I'm not sure if the first chunk is needed.  Currently,
running the testsuite.

Index: io/write.c
===================================================================
--- io/write.c  (revision 207664)
+++ io/write.c  (working copy)
@@ -1832,8 +1832,10 @@ nml_write_obj (st_parameter_dt *dtp, nam
                dtp->u.p.current_unit->delim_status = DELIM_QUOTE;
              if (dtp->u.p.nml_delim == '\'')
                dtp->u.p.current_unit->delim_status = DELIM_APOSTROPHE;
+             if (dtp->u.p.nml_delim == ' ')
+               dtp->u.p.current_unit->delim_status = DELIM_NONE;
              write_character (dtp, p, 1, obj->string_length);
-               dtp->u.p.current_unit->delim_status = tmp_delim;
+             dtp->u.p.current_unit->delim_status = tmp_delim;
               break;

            case BT_REAL:
@@ -1972,7 +1974,12 @@ namelist_write (st_parameter_dt *dtp)
   /* Set the delimiter for namelist output.  */
   tmp_delim = dtp->u.p.current_unit->delim_status;

-  dtp->u.p.nml_delim = tmp_delim == DELIM_APOSTROPHE ? '\'' : '"';
+  if (tmp_delim == DELIM_APOSTROPHE)
+    dtp->u.p.nml_delim = '\'';
+  else if (tmp_delim == DELIM_QUOTE)
+    dtp->u.p.nml_delim = '"';
+  else
+    dtp->u.p.nml_delim = ' ';

   /* Temporarily disable namelist delimters.  */
   dtp->u.p.current_unit->delim_status = DELIM_NONE;

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Feb 12, 2014 at 03:12:52AM +0000, kargl at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148
> 
> --- Comment #5 from kargl at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #4)
> > Like this:
> > 
> > &MYLIST
> >  MYSTRING        = 'tue  '
> >  /
> >  &MYLIST
> >  MYSTRING        = "tue  "
> >  /
> >  &MYLIST
> >  MYSTRING        = tue  
> >  /
> >  &MYLIST
> >  MYSTRING        = tue  
> >  /
> 
> Dang!  You beat me to the patch.  Here's what I have.
> I'm not sure if the first chunk is needed.  Currently,
> running the testsuite.
> 

There are few regressions, which I haven't looked through, yet.
I suspect these are related to looking for ' or " in a result
that was written to a file and then re-read.

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The regressions are two fold:

1) Tests are specifically looking for a " or a ' when no longer generated,

and

2) We need to also revise namelist reading of character types which are no
longer delimited

namelist_18.f90, modify test
namelist_38.f90, error in read
namelist_56.f90, ...
namelist_70.f90, ...

My patch is as follows so far, a little different from Steve's. With this patch
I don't explicitly write a space delim because we write one in the first chunk
below.  This was needed for namelist_16.f90

Index: write.c
===================================================================
--- write.c    (revision 206864)
+++ write.c    (working copy)
@@ -1921,7 +1921,8 @@
          to column 2. Reset the repeat counter.  */

       dtp->u.p.no_leading_blank = 0;
-      write_character (dtp, &semi_comma, 1, 1);
+      if (dtp->u.p.nml_delim || (obj->type != BT_CHARACTER))
+        write_character (dtp, &semi_comma, 1, 1);
       if (num > 5)
         {
           num = 0;
@@ -1971,9 +1972,18 @@

   /* Set the delimiter for namelist output.  */
   tmp_delim = dtp->u.p.current_unit->delim_status;
+  switch (tmp_delim)
+    {
+      case DELIM_APOSTROPHE:
+        dtp->u.p.nml_delim = '\'';
+    break;
+      case DELIM_QUOTE:
+    dtp->u.p.nml_delim = '"';
+    break;
+      default:
+    dtp->u.p.nml_delim = '\0';
+    }

-  dtp->u.p.nml_delim = tmp_delim == DELIM_APOSTROPHE ? '\'' : '"';
-
   /* Temporarily disable namelist delimters.  */
   dtp->u.p.current_unit->delim_status = DELIM_NONE;

I have not looked at read yet.

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Running into some snags here:

gfc -fdump-tree-original pr60148.f90 
pr60148.f90: In function ‘namelistout’:
pr60148.f90:38:0: internal compiler error: Segmentation fault
 end program

I will be fixing this while I am at it. Maybe there is a PR for it already.
>From gcc-bugs-return-444656-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 23 20:49:37 2014
Return-Path: <gcc-bugs-return-444656-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4060 invoked by alias); 23 Feb 2014 20:49:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4012 invoked by uid 48); 23 Feb 2014 20:49:32 -0000
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
Date: Sun, 23 Feb 2014 20:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pault at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59198-4-KFVN0VQESo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59198-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59198-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg02413.txt.bz2
Content-length: 1137

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY198

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Tobias,

I need to walk away from this one for 24 hours.

I have established this chain:
(i) We start building decay_t;
(ii) During which we have to build decay_gen_t (from trans-types.c:2456);
(iii) Followed by decay_term_t;
(iv) Which has a decay_t as its only component;
(v) Since this is in the process of being built, what is retruned is the
backend_decl without any of the fields.  Thus the size cannot be determined;
(vi) For reasons that I cannot see, since this component is a pointer,
indeterminate size this propagates back to the size of the decay_gen_t
component in decay_t; and
(vii) This I suppose but have not confirmed, clobbers the initialisation of the
vtable.

This latter is surmise, on the basis that changing the 'term' field to a
pointer still causes the size problem but the ICE goes away. The programme even
executes!

I cannot see why there is a problem in estimating the size, since the relevant
components are either allocatable or pointers - thus the size can be
determined.

Cheers

Paul

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #8)
> gfc -fdump-tree-original pr60148.f90 
> pr60148.f90: In function ‘namelistout’:

Cf. PR60147 / http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01360.html
>From gcc-bugs-return-444658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 23 21:35:30 2014
Return-Path: <gcc-bugs-return-444658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20341 invoked by alias); 23 Feb 2014 21:35:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20318 invoked by uid 48); 23 Feb 2014 21:35:25 -0000
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/60324] New: Handle arbitrarily long path names
Date: Sun, 23 Feb 2014 21:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jb at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-60324-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg02415.txt.bz2
Content-length: 1126

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`324

            Bug ID: 60324
           Summary: Handle arbitrarily long path names
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jb at gcc dot gnu.org

libgfortran uses (stack allocated) arrays of size PATH_MAX or smaller in many
places, when creating a temporary path name with a trailing NULL from a Fortran
string. However, it's possible for the user to create longer paths, and most
libc functions and/or syscalls do support longer path names just fine. So
PATH_MAX isn't that useful; properly designed software should be able to deal
with arbitrarily long path names.

Instead of using such temp arrays, we should instead allocate them on the heap,
limited in length only by the available memory. Thus, the current
unpack_filename() should be replaced with some kind of fc_strdup() (that is,
given a Fortran string, return a pointer to a heap allocated NULL terminated
duplicate).

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 32217
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32217&action=edit
Substantial patch

This patch is larger then it looks due to my editor judiciously removing
trailing space in write.c.  The patch passes regression testing.  I modified
the way we handle disabling delimiters for writing the namelist narrative.  I
also made use of the DELIM_UNSPECIFIED to indicate defaulting to "quote".

I will post to list for approval on my next opportunity.

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Tue Mar  4 04:33:40 2014
New Revision: 208302

URL: http://gcc.gnu.org/viewcvs?rev=208302&root=gcc&view=rev
Log:
2014-03-03  Jerry DeLisle  <jvdelisle@gcc.gnu>

    PR libfortran/60148
    * io/inquire.c (inquire_via_unit): In the case of
    DELIM_UNSPECIFIED set inquire return string to "NONE".
    * io/list_read.c (read_character): In the case of DELIM_NONE and
    namelists, complete the character read using the namelist
    variable length.
    * io/open.c (new_unit): Don't set delim status to none if not
    specified so that DELIM_UNSPECIFIED can be used later.
    * io/transfer.c (data_transfer_init): For namelist I/O, if the
    unit delim status is unspecified set the current status to quote.
    Otherwise, set current status to the unit status.
    * io/unit.c (get_internel_unit, init_unit): Remember to set
    flags_delim initially to DELIM_UNSPECIFIED so defaults come out
    correctly.
    * io/write.c (write_character): Add a new function argument
    "mode" to signify that raw output is to be used vs output with
    delimiters. If the mode is set to DELIM (1) proceed with
    delimiters. (list_formatted_write_scalar): Write the separator
    only if a delimiter was previously specified. Update the call to
    write_character with the mode argument given.
    (namelist_write_newline): Use the mode argument. (nml_write_obj):
    Use the mode argument. Remove use of tmp_delim. Write the
    semi-colon or comma correctly only when needed with using
    delimiters. Cleanup whitespace.
    (namelist_write): If delim is not specified in namelist I/O,
    default    to using quotes. Get rid of the tmp_delim variable and
    use the new mode argument in write_character.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/inquire.c
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/open.c
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/unit.c
    trunk/libgfortran/io/write.c

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Tue Mar  4 05:46:06 2014
New Revision: 208303

URL: http://gcc.gnu.org/viewcvs?rev=208303&root=gcc&view=rev
Log:
2014-03-03  Jerry DeLisle  <jvdelisle@gcc.gnu>

    PR libfortran/60148
    * gfortran.dg/namelist_84.f90: New test.

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

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Only documentation remains for this patch.  Need to document gfortran extended
behavior for default behavior when writing to name lists whne no DELIM= has
been specified.  gfortran defaults to DELIM="quotes" to assure the namelist can
be read back in.

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Fri Mar 21 22:14:36 2014
New Revision: 208757

URL: http://gcc.gnu.org/viewcvs?rev=208757&root=gcc&view=rev
Log:
2014-03-21  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/60148
    * gfortran.texi: Add description of namelist DELIM= behavior.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Fri Mar 21 22:19:44 2014
New Revision: 208759

URL: http://gcc.gnu.org/viewcvs?rev=208759&root=gcc&view=rev
Log:
2014-03-21  Jerry DeLisle  <jvdelisle@gcc.gnu>

    PR libfortran/60148
    * io/transfer.c (data_transfer_init): If std= was specified, set
    delim status to DELIM_NONE of no other was specified.

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

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

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

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

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on trunk.