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/41242] [4.5 Regression] PPC call rejected (related to user-defined assignment?)



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


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