This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/51292] RESULT var with -finit-local-zero -fno-automatic results in error


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-24 13:46:37 UTC ---
(In reply to comment #0)
> fails to compile with -finit-local-zero -fno-automatic.  H variable is in that
> case TREE_STATIC (should it really be?)

Difficult question: -fno-automatic overrides the Fortran defaults to be
backward compatible with some nonstandard code. Thus, one cannot say what is
correct.

Test case:

function f()
  real :: f ! = 0 due to default initialization
  f = f + 1
end

print *, f() ! Should print 1
print *, f() ! should print 1 or 2 with -fno-automatic?
end

That prints "1.0"/"1.0" with gfortran, gfortran -fno-automatic and ifort -save.
If one replaces f() by "g() result(f)", gfortran and ifort -save also print
"1.0"/"1.0" and only gfortran -fno-automatic prints "1.0"/"2.0".

Thus, for consistency and for compatibility with the non RESULT version and
with other compilers, I agree that the TREE_STATIC does not make sense.

(Additionally, Fortran also does not allow SAVE to be specified for the result
value.)

There are two issues:

a) The compile-time check which already complains in resolve.c:
function g() result(f)
                      1
Error: Function result 'f' at (1) cannot have an initializer

b) The tree-generation issue, which can be fixed with the following patch.
However, I wonder whether one needs to exclude more, the check looks very
narrow - and I wouldn't rule out that, e.g., host associated variables or dummy
arguments get through that check as well - ditto for use-associated ones,
though they should be already static. Untested patch:

--- trans-decl.c        (revision 181690)
+++ trans-decl.c        (working copy)
@@ -600,7 +601,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
          || sym->as->type != AS_EXPLICIT
          || sym->attr.pointer
          || sym->attr.allocatable)
-      && !DECL_ARTIFICIAL (decl))
+      && !DECL_ARTIFICIAL (decl)
+      && !sym->attr.result)
     TREE_STATIC (decl) = 1;

   /* Handle threadprivate variables.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]