This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR39594 - 4.3/4.4 regression with COMMON variable as actual argument
- From: Tobias Burnus <burnus at net-b dot de>
- To: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 02 Apr 2009 21:23:12 +0200
- Subject: Re: [Patch, Fortran] PR39594 - 4.3/4.4 regression with COMMON variable as actual argument
- References: <49D5100A.8090800@net-b.de>
For someone being employed at a virtual institute, having a virtual
patch should be OK. But maybe you prefer an actual patch ;-)
Tobias
Tobias Burnus wrote:
> Hello all,
>
> as Jakub has found out the problem was introduced when procedure
> pointers in COMMON were supported. Before every COMMON member was had
> also the flavour FL_VARIABLE, but with procpointer it stayed FL_UNKNOWN.
>
> The patch does do two things:
>
> a) It added the FL_VARIABLE flavour in resolve.c - here one already
> knows that it can never become a proc pointer. (That patch is nice, but
> it does not help with the regression; I still think it belongs there for
> completeness.)
>
> b) It does something similar in primary.c. It took me a while to realize
> that although sym->referenced is set, this does not become fully active
> as for FL_UNKNOWN some settings are reset. Again, setting the flavour is
> not needed, but I think it is cleaner to do so before doing a "break".
>
> Build and being regtested on x86-64-linux. OK for the 4.5 trunk and for
> the 4.4? (I assume there is nothing from the RM side which speaks
> against it?)
>
> Tobias
>
>
2009-04-02 Tobias Burnus <burnus@net-b.de>
PR fortran/39594
* resolve.c (resolve_common_vars): Add FL_VARIABLE to symbol
if it is not a procedure pointer.
* primary.c (match_actual_arg): Ditto.
2009-04-02 Tobias Burnus <burnus@net-b.de>
PR fortran/39594
* gfortran.dg/common_12.f90: New.
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (Revision 145468)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -719,6 +719,9 @@ resolve_common_vars (gfc_symbol *sym, bo
gfc_error_now ("Derived type variable '%s' in COMMON at %L "
"may not have default initializer", csym->name,
&csym->declared_at);
+
+ if (csym->attr.flavor == FL_UNKNOWN && !csym->attr.proc_pointer)
+ gfc_add_flavor (&csym->attr, FL_VARIABLE, csym->name, &csym->declared_at);
}
}
Index: gcc/fortran/primary.c
===================================================================
--- gcc/fortran/primary.c (Revision 145468)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -1401,6 +1401,13 @@ match_actual_arg (gfc_expr **result)
&& sym->attr.flavor != FL_UNKNOWN)
break;
+ if (sym->attr.in_common && !sym->attr.proc_pointer)
+ {
+ gfc_add_flavor (&sym->attr, FL_VARIABLE, sym->name,
+ &sym->declared_at);
+ break;
h+ }
+
/* If the symbol is a function with itself as the result and
is being defined, then we have a variable. */
if (sym->attr.function && sym->result == sym)
Index: gcc/testsuite/gfortran.dg/common_12.f90
===================================================================
--- gcc/testsuite/gfortran.dg/common_12.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/common_12.f90 (Revision 0)
@@ -0,0 +1,18 @@
+! { dg-do compile }
+!
+! PR fortran/39594
+!
+! Contributed by Peter Knowles and reduced by Jakub Jelinek.
+!
+module pr39594
+ implicit double precision(z)
+ common /z/ z0,z1,z2,z3,z4,z5,z6,z7
+contains
+ subroutine foo
+ implicit double precision(z)
+ common /z/ z0,z1,z2,z3,z4,z5,z6,z7
+ call bar(z0)
+ end subroutine foo
+end module
+
+! { dg-final { cleanup-modules "pr39594" } }