[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer

2019-01-19 Thread dominiq at lps dot ens.fr 
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

2019-01-19 Thread dominiq at gcc dot gnu.org 
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
* 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

2019-01-15 Thread dominiq at lps dot ens.fr 
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

2019-01-15 Thread dominiq at lps dot ens.fr 
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

2009-02-09 Thread pault at gcc dot gnu dot org 


--- 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

2008-10-16 Thread burnus 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 -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

2008-10-16 Thread burnus at gcc dot gnu dot org 


--- 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

2008-10-15 Thread burnus at gcc dot gnu dot org 


--- 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