[Bug fortran/34427] New: [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[Bug fortran/34427] New: [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

Revision 130629:

http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00079.html

failed 481.wrf:

module_io.fppized.f90:18531: internal compiler error: in change_file, at
fortran/scanner.c:322
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
specmake[1]: *** [module_io.fppized.o] Error 1

Revision 130712:

http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00163.html

fixed the compiler crash. But it miscompiled wrf:

****************************************
Contents of wrf.err
****************************************
STOP wrf_abort
 -------------- FATAL CALLED ---------------
 module_configure: initial_config: error reading namelist
 -------------------------------------------


-- 
           Summary: [4.3 Regression]   481.wrf in SPEC CPU 2006 miscompiled
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2007-12-10 22:57 -------
I can't see how that would be related to the # line and include handling fixes.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #2 from hjl at lucon dot org  2007-12-10 23:49 -------
This regression was introduced between revision 130629 and 130712.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2007-12-11 07:32 -------
(In reply to comment #2)
> This regression was introduced between revision 130629 and 130712.

There was a stupid I/O bug of mine between Rev. 130708 and 130723. Have you
tried with Rev. 130723 or later?


-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2007-12-11 10:48 -------
I also see this.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2007-12-11 10:57 -------
(In reply to comment #4)
> I also see this.

Is this with Rev. 130723 or higher? If not, can you update and try again?

If yes, can you revert libgfortran to prior 130629 and try again? That way we
know whether it is in libgfortran or in the front end.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #6 from hjl at lucon dot org  2007-12-11 13:46 -------
I saw it with revision 130726.


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-11 13:46:58
               date|                            |


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #7 from hjl at lucon dot org  2007-12-11 14:03 -------
Revision 130707 is OK if I back out revision 130629.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #8 from hjl at lucon dot org  2007-12-11 14:18 -------
Revision 130726 failed after I backed out revisions 130629 and 130712.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #9 from hjl at lucon dot org  2007-12-11 14:56 -------
Revision 130726 is OK  after I reverted libgfortran to revision 130629.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2007-12-11 16:37 -------
> Revision 130726 failed after I backed out revisions 130629 and 130712.
> Revision 130726 is OK  after I reverted libgfortran to revision 130629.

Jerry, do you have an idea?

Between 130629 and 130726 there is my "Nan"/"Inf" patch. Looking at the diff
("svn diff -r130629:130726 libgfortran/"), I fail to see how it can possibly
break, except 481.wrf expects that parsing the string "NaN" or "Inf" or
"Infinity" gives an error. As other compilers support reading NaN/Inf/Infinity,
I regard this as unlikely.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #11 from hjl at lucon dot org  2007-12-11 20:16 -------
[hjl@gnu-26 34427]$ cat foo.f90 
  IMPLICIT NONE
  real , DIMENSION(11) ::foo 
  integer :: isfflx
  NAMELIST /nl/ foo
  NAMELIST /nl/ isfflx
  open (10, status="scratch")
  write (10,*) " &nl"
  write (10,*) " foo = 5, 5, 5,"
  write (10,*) " isfflx = 1,"
  write (10,*) " /"
  rewind (10)
  READ (10, NML = nl, ERR = 9200)
  CLOSE (10)
  STOP
9200 CALL abort ()
 END
[hjl@gnu-26 34427]$ /export/gnu/import/svn/rrs/34427/usr/bin/gfortran -static
-o new foo.f90
[hjl@gnu-26 34427]$ ./new 
Aborted
[hjl@gnu-26 34427]$


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #12 from hjl at lucon dot org  2007-12-11 20:58 -------
Revision 130708 is wrong. We can't do

  if ((c == 'i' || c == 'I')
      && ((c = next_char (dtp)) == 'n' || c == 'N')
      && ((c = next_char (dtp)) == 'f' || c == 'F'))
    {
...
  if (nml_bad_return (dtp, c))
    return 0;

since it will change 'c' passed to nml_bad_return (). We need to restore
the old char when it doesn't match INF/NAN.


-- 


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

[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled

[hjl at lucon dot org]

------- Comment #13 from hjl at lucon dot org  2007-12-11 21:06 -------
Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables?


-- 


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #14 from hjl at lucon dot org  2007-12-11 22:31 -------
The current Inf/NAN I/O support is broken. Given a namelist input 

 &nl
 foo = 5,
 infinity1 = 1,
 /

where foo is an array of 2 reals, we need to unget up to 8 chars (infinity).
If it can't be done with the current runtime support, we should revert revision
130708.


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.3 Regression]   481.wrf  |[4.3 Regression]  Revision
                   |in SPEC CPU 2006 miscompiled|130708 breaks namelist input


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #15 from hjl at lucon dot org  2007-12-11 22:37 -------
We can change the last_char field to

#define MAX_LAST_STRING_LEN 8
char last_string[MAX_LAST_STRING_LEN];
int last_char_pos;

we can unget up to MAX_LAST_STRING_LEN chars.


-- 


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[burnus at gcc dot gnu dot org]

------- Comment #16 from burnus at gcc dot gnu dot org  2007-12-11 22:47 -------
> Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables?

I think they are. But none which start with an integer or a '+'/'-'/'.', which
is why the old technique "Read a single character, if it is not valid, -
restore it and return" worked before.

The question is how to tackle this properly to allow for:

  NAMELIST /nl/ foo
  NAMELIST /nl/ infinity
  open (10, status="scratch")
  write (10,*) " &nl foo = 5, 5, 5, infinity, infinity"
  write (10,*) "      = 1, /"

(For this one, g95 also fails.)


I was thinking of something like:
   if ((c == 'i' || c == 'I')
       && ((save[i++] = next_char (dtp)) == 'n' || save[i] == 'N')
       && ((save[i++] = next_char (dtp)) == 'f' || save[i] == 'F'))
[...]
 unwind:
  for (j = i; i >= 0; j--)
    unget_char(dtp, save[j]);

but this does not work as one can only unget a single character:
  unget_char (st_parameter_dt *dtp, char c) 
   { dtp->u.p.last_char = c; }

For valid input, one needs to unget at least "INFINITY" + separator + (eat
whitespace) + separator, i.e. 9 to 10 characters.


-- 


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[kargl at gcc dot gnu dot org]

------- Comment #17 from kargl at gcc dot gnu dot org  2007-12-11 23:31 -------
(In reply to comment #16)
> > Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables?
> 
> I think they are. But none which start with an integer or a '+'/'-'/'.', which
> is why the old technique "Read a single character, if it is not valid, -
> restore it and return" worked before.
> 
> The question is how to tackle this properly to allow for:
> 
>   NAMELIST /nl/ foo
>   NAMELIST /nl/ infinity
>   open (10, status="scratch")
>   write (10,*) " &nl foo = 5, 5, 5, infinity, infinity"
>   write (10,*) "      = 1, /"
> 
> (For this one, g95 also fails.)
> 
> 
> I was thinking of something like:
>    if ((c == 'i' || c == 'I')
>        && ((save[i++] = next_char (dtp)) == 'n' || save[i] == 'N')
>        && ((save[i++] = next_char (dtp)) == 'f' || save[i] == 'F'))
> [...]
>  unwind:
>   for (j = i; i >= 0; j--)
>     unget_char(dtp, save[j]);
> 
> but this does not work as one can only unget a single character:
>   unget_char (st_parameter_dt *dtp, char c) 
>    { dtp->u.p.last_char = c; }
> 
> For valid input, one needs to unget at least "INFINITY" + separator + (eat
> whitespace) + separator, i.e. 9 to 10 characters.
> 

Tobias,

Can you use the method used in many of the gfc_match_* fucntions.

   locus old_locus;

   old_locus = current_locus;
   if (check for Inf/Nan)
     {
     }

bad_infnan:
   current_locus = old_locus;


-- 


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[burnus at gcc dot gnu dot org]

------- Comment #18 from burnus at gcc dot gnu dot org  2007-12-12 00:03 -------
Created an attachment (id=14736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14736&action=view)
Draft Patch

Test patch. It seems to fix the REAL reading part. I run out of time for the
COMPLEX part (parse_real), but it should follow accordingly; maybe I have time
tomorrow afternoon, otherwise feel free to pick it up - or come up with
something better.

Additionally, the test case contains a comment-out example which does not work.

Steve wrote:
> Can you use the method used in many of the gfc_match_* fucntions.
>    locus old_locus;
>    old_locus = current_locus;

This assumes that one can seek, doesn't it? (Remember, this is libgfortran and
not the frontend.)


-- 


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2007-12-12 01:05 -------
We have a mechanism already in list_read.c to allow transparently reading ahead
and buffering as far as we need to.  I wish I had been able to respond to this
report sooner and could have saved some time.

Its called lpush_char and uses line_buffer.  Tobias, if you would like, I can
work up a patch using this.  You can see how it is used in read_logical.


-- 


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

[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2007-12-12 01:14 -------
When you mention that, is it right that you are pushing different chars than
what has been actually read?  E.g.:
  c = tolower (next_char (dtp));
  l_push_char (dtp, c);
Shouldn't that be instead:
  c = next_char (dtp);
  l_push_char (dtp, c);
  c = tolower (c);
?


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #21 from hjl at lucon dot org  2007-12-12 01:56 -------
(In reply to comment #18)
> Created an attachment (id=14736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14736&action=view) [edit]
> Draft Patch
> 
> Test patch. It seems to fix the REAL reading part. I run out of time for the
> COMPLEX part (parse_real), but it should follow accordingly; maybe I have time
> tomorrow afternoon, otherwise feel free to pick it up - or come up with
> something better.
>

Do we need to fix parse_real?


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2007-12-12 04:34 -------
Reply to comment #20:

It does not matter since we translate all variable names to lower case.  It
would matter if we used this mechanism to read literal string constants, but we
don't.  I will look that over a bit more before we are all done with this.

I am looking at using l_push_char here instead of save. Tobias. do as you
please.  We can either revert the original patch and get back to this without
time pressure or proceed quickly.  I would prefer to use the l_push mechanism
to reduce duplicative code, but if we do use l_push we have to approach the
matching differently.

With the current patch I am now concerned about hitting EOL or EOF conditions,
since we do not test the character after each read.  For example:

 IMPLICIT NONE
  real , DIMENSION(11) ::foo 
  real :: isfflx
  NAMELIST /nl/ foo
  NAMELIST /nl/ isfflx
  open (10, status="scratch")
  write (10,*) " &nl"
  write (10,*) " foo = 5, 5, 5,"
  write (10,*) " isfflx = infin/"
  rewind (10)
  READ (10, NML = nl, ERR = 9200)
  CLOSE (10)
  STOP
9200 CALL abort ()
 END
I think this will give an error, but have not had time to check.

Reply to comment #21, we do need to fix parse_real since it is used to
read_complex.


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[burnus at gcc dot gnu dot org]

------- Comment #23 from burnus at gcc dot gnu dot org  2007-12-12 07:20 -------
> Tobias. do as you
> please.  We can either revert the original patch and get back to this without
> time pressure or proceed quickly.
Maybe reverting and proceeding then quickly w/o time pressure is best.

> With the current patch I am now concerned about hitting EOL or EOF conditions,
> since we do not test the character after each read.  For example:
>
>   write (10,*) " isfflx = infin/"
> I think this will give an error, but have not had time to check.

It does (end of file instead of invalid real), but as the input is invalid, it
should not matter too much.


> Reply to comment #21, we do need to fix parse_real since it is used to
> read_complex.
Maybe not. The problem of reading an infinity= cannot occur as complex numbers
start with a '(', which is checked in read_complex, unless I missed something.


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #24 from hjl at lucon dot org  2007-12-12 15:26 -------
(In reply to comment #23)
> > Tobias. do as you
> > please.  We can either revert the original patch and get back to this without
> > time pressure or proceed quickly.
> Maybe reverting and proceeding then quickly w/o time pressure is best.
> 

Right now we can't run SPEC CPU since gfortran runtime is broken. which means
other Fortran bugs may get in without notice. I think it should be reverted
for now so that we can work on it without pressure.


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[burnus at gcc dot gnu dot org]

------- Comment #25 from burnus at gcc dot gnu dot org  2007-12-12 19:11 -------
Created an attachment (id=14739)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14739&action=view)
Improved patch

> > Maybe reverting and proceeding then quickly w/o time pressure is best.
> Right now we can't run SPEC CPU since gfortran runtime is broken [...]
> I think it should be reverted for now so that we can work on it without 
> pressure.

Which is what I suggested this morning, but had no time to actually do so.

I meanwhile updated the patch based on Jerry's comments. The following seems
work for most but the weirdest input files.

Please test/have a look; I intent to submit that patch in a moment.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14736|0                           |1
        is obsolete|                            |


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

------- Comment #26 from jvdelisle at gcc dot gnu dot org  2007-12-13 06:06 -------
Tobias, I know why the weird case in the namelist_42.f90 fails.  We just are
not addressing the need to eat spaces or separators at the right places.  I
started working up an updated patch tonight, but have not got it yet.

If your patch as-is passes all regression tests and spec its OK to commit.  Its
very close and we can follow with an update.  Its just a time issue.


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[burnus at gcc dot gnu dot org]

------- Comment #27 from burnus at gcc dot gnu dot org  2007-12-13 11:01 -------
Subject: Bug 34427

Author: burnus
Date: Thu Dec 13 11:01:00 2007
New Revision: 130889

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130889
Log:
2007-12-13  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34427
        * io/list_read.c (read_real): Fix unwinding for namelists.

2007-12-13  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34427
        * gfortran.dg/namelist_42.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/namelist_42.f90
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/list_read.c


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[burnus at gcc dot gnu dot org]

------- Comment #28 from burnus at gcc dot gnu dot org  2007-12-13 17:10 -------
Could someone confirm that gfortran (with no reverted patches) now works again
with 481.wrf or with SPEC in general?


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #29 from hjl at lucon dot org  2007-12-13 17:16 -------
(In reply to comment #28)
> Could someone confirm that gfortran (with no reverted patches) now works again
> with 481.wrf or with SPEC in general?
> 

I am running SPEC CPU 2000/2006 now. I will report results when they are
finished.


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #30 from hjl at lucon dot org  2007-12-14 04:15 -------
(In reply to comment #29)

> 
> I am running SPEC CPU 2000/2006 now. I will report results when they are
> finished.
> 

They are finished. No regressions. Thanks.


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[hjl at lucon dot org]

------- Comment #31 from hjl at lucon dot org  2007-12-14 04:23 -------
(In reply to comment #30)
> (In reply to comment #29)
> 
> > 
> > I am running SPEC CPU 2000/2006 now. I will report results when they are
> > finished.
> > 
> 
> They are finished. No regressions. Thanks.
> 

SPEC CPU 2000/2006 on Intel64 ran correctly with gcc 4.3 revision 130894.


-- 

hjl at lucon dot org changed:

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


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

------- Comment #32 from jvdelisle at gcc dot gnu dot org  2007-12-17 00:47 -------
Subject: Bug 34427

Author: jvdelisle
Date: Mon Dec 17 00:47:14 2007
New Revision: 131003

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131003
Log:
2007-12-16  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/34427
        * io/list_read.c (read_real): Handle intervening line ends and spaces.
        (get_name): Don't push separators to saved_string.
        (eat_separator): If in namelist mode eat spaces and line ends as well.

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


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

------- Comment #33 from jvdelisle at gcc dot gnu dot org  2007-12-17 00:51 -------
Subject: Bug 34427

Author: jvdelisle
Date: Mon Dec 17 00:51:25 2007
New Revision: 131004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131004
Log:
2007-12-16  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/34427
        * gfortran.dg/namelist_42.f90: Update.
        * gfortran.dg/namelist_43.f90: New.

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


-- 


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