Hi Daniel,
thanks for your comments.
here is a patch for PR 41873, which also fixes a part of PR 41556. The
problem was that a check, which prevents abstract interfaces from
being called, falsely triggered an error for deferred type-bound
procedures with abstract interface.
My solution to this may be a bit hackish, but it works very good in
practice: To distinguish both cases I simply check certain fields,
which are always set for the TBP case, but not for plain abstract
interfaces.
Shouldn't the gfc_expr / gfc_code be EXPR_COMPCALL or EXEC_COMPCALL for TBPs
(with or without abstract interface) as possibility to distinguish these?
I may be overlooking something here but if it is, I'd strongly prefer you do
that check instead.
That would be cleaner, but I don't think it's possible.
For type-bound functions, for example, the EXPR_COMPCALL is
transformed into an EXPR_FUNTION in resolve_compcall. For type-bound
subroutines, EXEC_COMPCALL is transformed into EXEC_CALL in
resolve_typebound_call.
Therefore, at the point where the call is resolved, you can't
distinguish the two cases just via EXPR_... or EXEC_...