Patchwork [RFC] Add EXEC_COMPCALL to front end expression walker

login
register
mail settings
Submitter Thomas Koenig
Date Feb. 12, 2011, 12:23 p.m.
Message ID <4D567BDE.8030200@netcologne.de>
Download mbox | patch
Permalink /patch/82902/
State New
Headers show

Comments

Thomas Koenig - Feb. 12, 2011, 12:23 p.m.
Hello world,

the attached patch adds handling for EXEC_COMPCALL to the front end
expression walker.

Based on resolve_ordinary_assign in resolve.c, I think think this is the
right thing to do. However...

I tried finding a use of EXEC_COMPCALL in the testsuite by placing a
gcc_assert((*c)->op != EXEC_COMPCALL) in the front end walker.  I then
ran the testsuite in the hope of ICEing on a dg-do run test, but I only
found EXEC_COMPCALL in dg-do compile tests with syntax errors this way.

When, exactly, is EXEC_COMPCALL used?  Maybe it would be a good idea to
add a test case for this to the testsuite.

No changelog entry (although that one would be obvious), because this is
still an RFC.  I also regression-tested this.

Comments?  Ideas?  Should I just commit this?

	Thomas
Janus Weil - Feb. 12, 2011, 1:04 p.m.
Hi Thomas,

> the attached patch adds handling for EXEC_COMPCALL to the front end
> expression walker.

here is the deal about EXEC_COMPCALL: Basically it's used, analogous
to EXEC_CALL, for calls to type-bound procedures, like

CALL obj%tbp(...)

However, just like EXEC_CALL_PPC, which is its pendant for procedure
pointer component calls, it's only used as a "temporary" statement
descriptor, in the sense that it is being transformed into an
EXEC_CALL at resolution stage. That is also why you will find no
handling of it in trans_*.



> I tried finding a use of EXEC_COMPCALL in the testsuite by placing a
> gcc_assert((*c)->op != EXEC_COMPCALL) in the front end walker.  I then
> ran the testsuite in the hope of ICEing on a dg-do run test, but I only
> found EXEC_COMPCALL in dg-do compile tests with syntax errors this way.

... which is probably because in case of an error the EXEC_COMPCALL
will survive the resolution stage, which it normally does not do.


> Comments?  Ideas?  Should I just commit this?

In view of my above comments, I don't think it is needed. All
EXEC_COMPCALL statements are usually transformed into other stuff
(like EXEC_CALL) at resolution stage, and should not end up in the
front-end passes at all.

So, instead of the patch you proposed, one could maybe just add a
comment in frontend-passes.c, stating this fact.

Cheers,
Janus

Patch

Index: frontend-passes.c
===================================================================
--- frontend-passes.c	(Revision 169491)
+++ frontend-passes.c	(Arbeitskopie)
@@ -654,6 +654,12 @@ 
 		WALK_SUBEXPR (a->expr);
 	      break;
 
+	    case EXEC_COMPCALL:
+	      WALK_SUBEXPR ((*c)->expr1);
+	      for (a = (*c)->expr1->value.compcall.actual; a; a = a->next)
+		WALK_SUBEXPR (a->expr);
+	      break;
+
 	    case EXEC_SELECT:
 	      WALK_SUBEXPR ((*c)->expr1);
 	      for (b = (*c)->block; b; b = b->block)