[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- Closing.
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
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&root=gcc&view=rev Log: 2019-01-19 Dominique d'Humieres PR fortran/37835 * resolve.c (resolve_types): Add !flag_automatic. * symbol.c (gfc_add_save): Silence warnings. 2019-01-18 Dominique d'Humieres PR fortran/37835 * gfortran.dg/no-automatic.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/no-automatic.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835 Dominique d'Humieres changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Dominique d'Humieres --- > (6) ... The additional patch --- ../_clean/gcc/fortran/symbol.c 2019-01-09 22:54:02.0 +0100 +++ gcc/fortran/symbol.c2019-01-15 16:28:17.0 +0100 @@ -1306,9 +1306,7 @@ gfc_add_save (symbol_attribute *attr, sa if (s == SAVE_EXPLICIT) gfc_unset_implicit_pure (NULL); - if (s == SAVE_EXPLICIT && attr->save == SAVE_EXPLICIT) + if (s == SAVE_EXPLICIT && attr->save == SAVE_EXPLICIT && flag_automatic) { if (!gfc_notify_std (GFC_STD_LEGACY, "Duplicate SAVE attribute specified at %L", silences the warnings (errors). Do we need to add to the -fno-automatic doc a note saying that TUs with variables having an explicit SAVE attribute are silently accepted (even with -std=f*)? Along this line do we need to forbid it with -pedantic (by adding && !pedantic)?
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
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 (gfc_namespace *ns) gfc_traverse_ns (ns, resolve_values); - if (ns->save_all) + if (ns->save_all || !flag_automatic) gfc_save_all (ns); iter_stack = NULL; With this patch the tests gfortran.dg/dec_static_2.f90 gfortran.dg/save_1.f90 gfortran.dg/save_5.f90 gfortran.dg/save_6.f90 regress with Warning: Legacy Extension: Duplicate SAVE attribute specified at (1) At this point I don't know what to do. I can (1) adjust the tests by removing the explicit SAVEs, (2) add -w to the options to silence the warning, (3) adjust the doc to say that -fno-automatic should not be used in TUs with variables having an explicit SAVE attribute, (4) add a suitable condition to the test, (5) leave thing as they are now and close the PR as WONTFIX or INVALID, (6) ...
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
--- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-09 08:42:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
--- 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 -fno-automatic. (It doesn't and I have no idea how it could, but seemingly one can read the option such that it would.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
--- 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 ifort /Qsave and gfortran -fno-automatic. The former says only that it saves all variables in static allocation except local variables within a recursive routine and variables declare as AUTOMATIC. This is not the same as treating every program unit except those marked as RECURSIVE as if the SAVE statement were specified for every local variable and array referenced in it. For example ifort leaves open the possibility of reinitializing instances of user-defined types with default initialization and gfortran does not. This on the one hand permits standard-conforming code to behave the same way with /Qsave specified whereas the change should be detectable for -fno-automatic but on the other hand creates an ambiguity as to whether ifort actually does leave the semantics of standard-conforming code intact as it doesn't say whether it does or not in the documentation. It might be useful for the gfortran team to compare with ifort and determine whether they want to maintain semantics of standard-conforming code before considering failure to change semantics to be a bug. Of course the documentation would have to be rewritten if the decision were made to change the behavior. Sometimes it's just so difficult to rewrite the documentation that a documented bad behavior gets left intact. For example in the original f90 standard, non-advancing I/O was specified to advance on format reversion due to a carry-over from f77 that had no non-advancing I/O. I imagine everyone tries to write non-advancing I/O taking for granted that format reversion also does not advance to the next record and indeed early f90 compilers behaved in just this way. However the simply-worded standard says otherwise and rather than fix this bug in the standard the compilers got 'fixed' so that now format reversion is just useless in conjunction with non- advancing I/O." Wording of gfortran: http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html Wording of ifort: "This option saves all variables in static allocation except local variables within a recursive routine and variables declared as AUTOMATIC." http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/copts_for/fortran_options/option_save.htm I think gfortran's wording implies that derived-types are SAVEd, ifort's is a bit more ambiguous, but ifort does the do so. Thus I think it might be enough to fix the 'bug' as stated in comment 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
--- 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