https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 19 21:45:43 2019
New Revision: 268098
URL: https://gcc.gnu.org/viewcvs?rev=268098=gcc=rev
Log:
2019-01-19 Dominique d'Humieres
PR fortran/37835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
Dominique d'Humieres changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
--- Comment #5 from Dominique d'Humieres ---
Updated patch
--- ../_clean/gcc/fortran/resolve.c 2019-01-13 08:36:53.0 +0100
+++ gcc/fortran/resolve.c 2019-01-15 11:06:51.0 +0100
@@ -16649,7 +16649,7 @@ resolve_types
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-09 08:42 ---
Does not
if (ns-save_all || !gfc_option.flag_automatic)
gfc_save_all (ns);
in resolve_types not fix the problem? (I have not had a chance to try this
yet.)
Confirmed
Paul
--
pault at gcc dot gnu dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-16 09:41 ---
Hmm, maybe the wording could (should?) be changed to make clear that for
subroutine sub(n)
integer n
real automatic_data_object(n)
end subroutine sub
the automatic_data_object gets no SAVE with
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-16 09:37 ---
Regarding -fno-automatic, James Van Buskirk suggested to compare the details
with ifort's -save (see URL above):
The description in my admittedly old version of ifort documentation
allows for different semantics for
--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-15 08:30 ---
Forgot to add:
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/57938d5454a90397/589afd86ab2aab9b
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835