--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-05 13:20
---
Patch:
http://gcc.gnu.org/ml/fortran/2009-04/msg00035.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dfranke at gcc dot gnu dot org 2009-04-05 18:02
---
Subject: Bug 29458
Author: dfranke
Date: Sun Apr 5 18:02:00 2009
New Revision: 145564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145564
Log:
gcc/fortran/:
2009-04-05 Daniel Franke
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-05 18:04
---
Fixed in trunk. Backport unlikely as it's not a regression. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bcbarnes at gmail dot com 2008-01-30 17:18 ---
This bug also shows up when executing the example code for initializing
random_seed in the gfortran documentation. Is it a regression w.r.t. 4.0 or
4.1? Maybe not, but it would be nice if something in the docs didn't
--- Comment #8 from kargl at gcc dot gnu dot org 2008-01-30 19:26 ---
(In reply to comment #7)
This bug also shows up when executing the example code for initializing
random_seed in the gfortran documentation. Is it a regression w.r.t. 4.0 or
4.1? Maybe not, but it would be nice
--- Comment #9 from manu at gcc dot gnu dot org 2008-01-30 19:53 ---
I tried this:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 131893)
+++ gcc/fortran/trans-array.c (working copy)
@@
--- Comment #10 from manu at gcc dot gnu dot org 2008-01-30 20:13 ---
For my classification of -Wuninitialized problems (see
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings), this is caused by a
representation issue.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #6 from terry at chem dot gu dot se 2007-11-16 20:57 ---
I'd just like to remind everyone that this is still an issue in gcc version
4.3.0 20071109
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:15
---
(In reply to comment #2)
Why not create a new i for the inner loop instead of saving it off?
This is indeed what we should do; however, I can't find a way to work it out.
Unassigning myself.
--
fxcoudert at
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-01-31 23:01:50 |2007-08-06 13:47:12
date|
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.1 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26
---
Will not be fixed in 4.2.0; retargeting at 4.2.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-27 22:18 ---
*** Bug 31731 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-31 23:01
---
This is fixed by the following patch:
Index: trans-array.c
===
--- trans-array.c (revision 121280)
+++ trans-array.c (working copy)
@@
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-31 23:07 ---
Why not create a new i for the inner loop instead of saving it off?
Or is:
integer :: n, i
n = 5
n = sum((/(i,i=1,f())/))
contains
function f()
integer :: f
f = i+1
end
valid and well defined?
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
17 matches
Mail list logo
