[RFC] Add EXEC_COMPCALL to front end expression walker

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

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