http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
--- Comment #6 from Thomas Koenig 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=gcc&view=rev&rev=193793
Log:
2012-11-25 Thomas Koenig
PR
--- 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 #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
--- 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
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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
--- 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 chec
