This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: [Patch, Fortran] PR 41873 & 41556


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


>> The patch regtests without failures on x86_64-unknown-linux-gnu. Ok for
>> trunk?
>
> Considering my comment above, ok. ?Thanks for the fix!

So, unless you have a better idea, I would go with my solution.

Cheers,
Janus


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