[Patch, Fortran] PR 41873 & 41556

[Janus Weil-3]

Hi all,

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.

When working on this PR, I also noticed that the check for calling
abstract subroutines was missing completely (only functions were
checked), so I also added this (again distinguishing TBPs).

The patch regtests without failures on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2009-11-04  Janus Weil  <janus@...>

        PR fortran/41556
        PR fortran/41873
        * resolve.c (resolve_function,resolve_call): Prevent abstract interfaces
        from being called, but allow deferred type-bound procedures with
        abstract interface.


2009-11-04  Janus Weil  <janus@...>

        PR fortran/41556
        PR fortran/41873
        * gfortran.dg/interface_abstract_4.f90: New test.

[pr41873.diff]

---

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 153911)
+++ gcc/fortran/resolve.c (working copy)
@@ -2526,7 +2526,9 @@ resolve_function (gfc_expr *expr)
       return FAILURE;
     }
 
-  if (sym && sym->attr.abstract)
+  /* If this ia a deferred TBP with an abstract interface (which may
+     of course be referenced), expr->value.function.name will be set.  */
+  if (sym && sym->attr.abstract && !expr->value.function.name)
     {
       gfc_error ("ABSTRACT INTERFACE '%s' must not be referenced at %L",
  sym->name, &expr->where);
@@ -3138,6 +3140,15 @@ resolve_call (gfc_code *c)
  }
     }
 
+  /* If this ia a deferred TBP with an abstract interface
+     (which may of course be referenced), c->expr1 will be set.  */
+  if (csym && csym->attr.abstract && !c->expr1)
+    {
+      gfc_error ("ABSTRACT INTERFACE '%s' must not be referenced at %L",
+ csym->name, &c->loc);
+      return FAILURE;
+    }
+
   /* Subroutines without the RECURSIVE attribution are not allowed to
    * call themselves.  */
   if (csym && is_illegal_recursion (csym, gfc_current_ns))

---

[Daniel Kraft-4]

Janus Weil wrote:

> Hi all,
>
> 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.

> When working on this PR, I also noticed that the check for calling
> abstract subroutines was missing completely (only functions were
> checked), so I also added this (again distinguishing TBPs).
>
> The patch regtests without failures on x86_64-unknown-linux-gnu. Ok for trunk?

Considering my comment above, ok.  Thanks for the fix!

Yours,
Daniel

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

[Janus Weil-3]

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

[Daniel Kraft-4]

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

[Janus Weil-3]

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

Thanks. Committed as 153934.

Cheers,
Janus