This is the mail archive of the mailing list for the GCC 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] PR39850: Too strict checking for procedures as actual argument

Janus Weil wrote:
>> No for the reason outline above. If the actual argument is BT_UNKNOWN
>> and attr.subroutine is not set, one should call gfc_set_default_type -
>> then one can continue with checking whether ts.type/kind match.
> Actually I don't think it would be correct to use
> 'gfc_set_default_type', since such a case could also be a subroutine
> (which has no return type). Instead I use 'gfc_get_default_type' to
> check if the symbol *could* get an implicit type, without actually
> setting the type.
While I had not thought much about the problem, I think using
gfc_set_default_type at some point is correct. If I go to your example:

> program test
>   external func  ! subroutine or implicitly typed real function
>   call sub(func)
>   call sub2(func)
> contains
>   subroutine sub(a)
>     real, external :: a
>     print *, a(0.4)
>   end subroutine sub
>   subroutine sub2(a2)
>     interface
>       subroutine a2
>       end subroutine
>     end interface
>     call a2()
>   end subroutine
> end

The program is invalid: Before the first call, "func" can be either a
subroutine or a function. But then for "sub" it is used as function
while for "sub2" it is used as subroutine, which is not simultaneously
possible. Thus if you had either call, the program is valid, but if you
have both calls it isn't.

Thus you should use at some point set attr.function and ts.type/kind for
encountering the first call. And when reversing the order: For "call
sub2(func)" one should set the attr.subroutine. That way one gets a
proper error message for either order.

(For C binding, it would be sometimes useful to allow the same name as
function and as subroutine as one can ignore in C the return value. But
the standard does not allow this. [In any case, also under C it is often
not advisable to ignore error status.])

Sorry for raising again another issue.

Best regards on this very rainy day,


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