This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/41242] [4.5 Regression] PPC call rejected (related to user-defined assignment?)
- From: "janus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Sep 2009 16:05:43 -0000
- Subject: [Bug fortran/41242] [4.5 Regression] PPC call rejected (related to user-defined assignment?)
- References: <bug-41242-15192@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from janus at gcc dot gnu dot org 2009-09-10 16:05 -------
Ok, I think I know what's going on here.
Some background: A PPC call is usually parsed as EXPR_PPC, which happens in
gfc_match_varspec. At resolution stage this is transformed to an EXPR_FUNCTION
(if the PPC is a function), cf. resolve_expr_ppc. Both of this happens
correctly for the test case.
The problem here is that the PPC call is resolved twice: The first time the
EXPR_PPC is correctly transformed to an EXPR_FUNCTION. The second time this
EXPR_FUNCTION is resolved again via resolve_function, which can not handle PPCs
and claims the encountered expression is not a function.
This double resolution seems to be caused by the call to 'resolve_code' which
is inserted by Daniel's r151140 in resolve_ordinary_assign.
I haven't regtested the following patch, but it makes the test case work:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 151596)
+++ gcc/fortran/resolve.c (working copy)
@@ -6958,7 +6958,6 @@ resolve_ordinary_assign (gfc_code *code,
&& (lhs->symtree->n.sym == (*rhsptr)->symtree->n.sym))
*rhsptr = gfc_get_parentheses (*rhsptr);
- resolve_code (code, ns);
return true;
}
Daniel, do you think this patch is ok, or is there a better way to fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41242