--- Comment #18 from burnus at gcc dot gnu dot org 2010-03-11 19:48 ---
Close as FIXED. Thanks for the bugreport!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from burnus at gcc dot gnu dot org 2010-03-11 19:48 ---
Subject: Bug 43228
Author: burnus
Date: Thu Mar 11 19:48:11 2010
New Revision: 157391
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157391
Log:
2010-03-11 Tobias Burnus
PR fortran/43228
--- Comment #16 from burnus at gcc dot gnu dot org 2010-03-11 16:06 ---
Subject: Bug 43228
Author: burnus
Date: Thu Mar 11 16:06:37 2010
New Revision: 157389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157389
Log:
2010-03-11 Tobias Burnus
PR fortran/43228
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-03-11 14:25
---
yes, you have to be careful as you increment through the indexes to not
overwrite a previous good initialization of end. I suspect there is at least
one other bug in there while you are at it. :)
--
http:/
--- Comment #14 from burnus at gcc dot gnu dot org 2010-03-11 12:58 ---
Mine! I now do as written in comment #13 - except for the "if" which is not
needed (it use the wrong index and wouldn't work anyhow) - and except for
moving it down a bit.
--
burnus at gcc dot gnu dot org changed
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-11 07:23 ---
> Any other thoughts? (I am flexible and I am looking at the other idea of #10)
How about something like the following? Note: It does not quite work yet :-(
Index: list_read.c
==
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-03-11 04:52
---
The one liner:
Index: list_read.c
===
--- list_read.c (revision 157277)
+++ list_read.c (working copy)
@@ -2077,7 +2077,7 @@
/*
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-03-11 04:48
---
If we require -std=legacy for non-standard conforming extended reads I find
that we have only one test case that requires modification to "dg-options
-std-legacy" to pass. Besides being a very simple patch (a on
--- Comment #10 from burnus at gcc dot gnu dot org 2010-03-04 11:05 ---
(In reply to comment #9)
> > We turn off this behaviour with -std=f95 or higher.
> Apparently this is not true for -std=f2008:
That's seems to be an (additional) bug ...
> > I am thinking the extended reads should
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-04 10:14 ---
>From http://gcc.gnu.org/ml/fortran/2010-03/msg00020.html
> Currently our default namelist behaviour allows extended reads.
> In other words, reading extra data beyond that specified by the array
> qualifiers in th
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-03-04 05:37
---
Patch in the works. Stay tuned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43228
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-03-04 05:32
---
Try compiling the test program with -std=f95 and then run it. ;)
Oh Bother.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43228
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-02 20:09
---
I will try to get started on this tonight. Is the half-life proportaional to
the degrees of freedom? :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-02 16:23 ---
Paul confirmed that it (comment 1) also fails on the trunk (4.5.0)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-02 15:12 ---
Jerry, you wrote almost exactly one month ago: "Funny how namelist always shows
up as we approach release." -- now that we have a new one: Does this mean that
we indeed approach a release? In any case, the half life t
--- Comment #3 from luflarois at gmail dot com 2010-03-02 14:10 ---
(In reply to comment #1)
> Luiz: Can you please state the version of gfortran? (Use: "gfortran -v" and
> post the "Target:" line and the "gcc version).
> Additionally: For a good bugreport, please also include a minimal
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-02 12:54 ---
On powerpc-apple-darwin9, I have the same kind of outputs (1, 4, 7, 8, and 9
are correct, 6 is correct but at the wrong place, the rest is 0 or garbage) for
the test in comment#1 from 4.2.4 to trunk.
--
http://gc
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-02 12:46 ---
Luiz: Can you please state the version of gfortran? (Use: "gfortran -v" and
post the "Target:" line and the "gcc version).
Additionally: For a good bugreport, please also include a minimal example.
Without an example
18 matches
Mail list logo
