This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/51292] RESULT var with -finit-local-zero -fno-automatic results in error
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 24 Nov 2011 13:46:37 +0000
- Subject: [Bug fortran/51292] RESULT var with -finit-local-zero -fno-automatic results in error
- Auto-submitted: auto-generated
- References: <bug-51292-4@http.gcc.gnu.org/bugzilla/>
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. */