https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
--- Comment #20 from Thomas Koenig ---
Author: tkoenig
Date: Wed Oct 31 18:35:59 2018
New Revision: 265698
URL: https://gcc.gnu.org/viewcvs?rev=265698&root=gcc&view=rev
Log:
2018-10-31 Thomas Koenig
PR fortran/20520
* gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
Dominique d'Humieres changed:
What|Removed |Added
CC||dominiq at lps dot ens.fr
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
Dominique d'Humieres changed:
What|Removed |Added
CC||ondrej.certik at gmail dot com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-09 18:34
---
*** Bug 34159 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
--- Comment #15 from kargl at gcc dot gnu dot org 2009-11-22 17:37 ---
Using -fcheck=all issues a runtime error.
REMOVE:kargl[218] gfc4x -o z -Wall a2.f90
REMOVE:kargl[219] ./z
Segmentation fault (core dumped)
REMOVE:kargl[220] gfc4x -o z -Wall -fcheck=all a2.f90
REMOVE:kargl[221] ./z
A
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-03-30 01:08
---
See Re: DEALLOCATED array's do not have size zero on comp.lang.fortran for
additional discussion.
http://coding.derkeiler.com/Archive/Fortran/comp.lang.fortran/2009-03/msg00073.html
--
http://gcc.gnu.org/
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-03-30 01:01
---
*** Bug 36761 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-03-30 00:51
---
The original code case is invalid. An array that has been declared allocatable
has no size and it is invalid to use it anywhere except in an allocate or
allocated statement.
--
jvdelisle at gcc dot gnu dot o
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2009-03-29 07:51
---
*** Bug 36761 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-10 06:37
---
*** Bug 32709 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-25 20:49 ---
Besides local allocated variables, one can think of local pointers as well:
integer, pointer :: a
a = 4 ! wrong
if(associated(a)) ! wrong
nullify(a)
if(associated(a)) ! ok
a = 4 ! wrong
For allocation, one could als
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-25 20:37 ---
Cross-reference: the other way round, warn if allocatable is already allocated:
PR30676.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-20 17:39 ---
> Even ICC 8.1 accepts the code without warnings
I never found ifort (or sunf95) especially picky - contrary to NAG f95, which
is often too picky.
I'm in favour of giving a warning; actually I would even warn by defa
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-06-20 17:18 ---
*** Bug 32430 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Additional Comments From ebertakis at gmail dot com 2005-03-20 19:22
---
(In reply to comment #4)
This case is slightly different. The compiler just warns you that you are using
variable x before its value have been defined. Many programmers (that have bad
programming habits :-) prob
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-20 18:14
---
real,allocatable:: a(:),b(:)
real::x
a(1)=2*b(1) + x
end
This only gives an "uninitialized" warning for x, but not for a or b:
[EMAIL PROTECTED] tests]$ gfortran -O -Wuninitialized pr20521.f90
pr20521.f90: In
18 matches
Mail list logo