http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
--- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-25
17:24:14 UTC ---
Author: tkoenig
Date: Sun Nov 25 17:24:09 2012
New Revision: 193793
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193793
Log:
2012-11-25
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-04-09 16:03 ---
(In reply to comment #4)
This of cause fails if you change i. As the program is invalid and as I don't
see any possibility to fix this in gfortran, I regard the problem of comment 3
as INVALID/WONTFIX.
In the
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2007-03-21
16:15 ---
The following program causes an infinite loop in gfortran, but not in other
fortrans.
PROGRAM do_index_in_call
DO i = 1, 1
CALL SUB(i)
ENDDO
END PROGRAM do_index_in_call
SUBROUTINE sub(i)
i = 2
END
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 19:07 ---
(In reply to comment #3)
The following program causes an infinite loop in gfortran, but not in other
fortrans.
The program is plainly invalid as one redefines the DO thus your Fortran
compiler is free to do what
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:56 ---
As long as the callee doesn't change the value it's probably valid, so this
would need some kind of interprocedural analysis to give a correct error. A
warning may be in place, though. This shouldn't be to hard, we
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-17 21:20 ---
As long as the callee doesn't change the value it's probably valid, so this
would need some kind of interprocedural analysis to give a correct error.
I think it is formally seen invalid as you have INTENT([IN]OUT)
