http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The problem seems to be
2012 finish_list_read (st_parameter_dt *dtp)
...
2019 if (dtp->u.p.at_eol)
2020 {
2021 dtp->u.p.at_eol = 0;
2022 return;
2023 }
2024
2025 err = eat_line (dtp);
as at_eol == 1.
Draft patch:
The first hunk solves the actual problem of this PR.
The second one handles the case "abc\rdef" where \r is not followed by \n and
does not start a new record. (Note: gfortran does not handle pre-MacOS X line
breaks of the form "\r", only Windows \r\n and Unix (Linux, MacOS X,...) "\n".)
- that's unrelated to this PR.
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -244,3 +244,3 @@ next_char (st_parameter_dt *dtp)
done:
- dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF);
+ dtp->u.p.at_eol = (c == '\n' || c == EOF);
return c;
@@ -336,3 +336,2 @@ eat_separator (st_parameter_dt *dtp)
case '\r':
- dtp->u.p.at_eol = 1;
if ((n = next_char(dtp)) == EOF)
