[Patch, Fortran] PR 41873 & 41556

Daniel Kraft d@domob.eu
Thu Nov 5 10:31:00 GMT 2009


Janus Weil wrote:
> 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_...

Ok...  I was not sure about the order of the calls; and I think before 
the introduction of polymorphism (with my old static dispatch 
implementation) the call would then also have been to the "real" 
procedure without abstract interface, so also ok.

But yes, in this case I think it is ok.  I would maybe add a TODO or 
like to mark this "hack", but your comments are quite clear.

So indeed ok as is.

Daniel

-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri



More information about the Gcc-patches mailing list