Tbp and generic

If I'm understanding the standard correctly (big if ), a type bound
procedure cannot bind to a generic name, only to module and external
procedures (C465 in f2008). So the following would not be allowed.

type t1
contains
procedure, nopass :: sub
end type

interface sub
procedure sub1
procedure sub2
end interface

The compiler I use (gfortran 4.7.0) indeed gives an error when attemting
to compile this.

However, if I change the name of sub1 to sub (both in the procedure
statement and in the definition of the subroutine), gfortran not only
accepts it, but surprisingly treats the tbp as if it binds to the
generic name.

See the following code and output. I would have expected an error during
compilation or at least during runtime at execution of the second call
statement.

module foo
implicit none

type t1
contains
procedure, nopass :: sub
end type

interface sub
procedure sub
procedure sub2
end interface
contains
subroutine sub
print *, 'sub1'
end subroutine

subroutine sub2(arg1)
integer arg1

print *, 'sub2'
end subroutine
end module

program bar
use foo
implicit none

type(t1) obj

call obj%sub
call obj%sub(0)
end program

$ gfortran foobar.f90 -o foobar && ./foobar
sub1
sub2

Is my understanding wrong and is this to be expected?

Erik.

On Thu, 19 Jul 2012 06:00:46 -0500, Erik Toussaint
<user@example.net.invalid> wrote:

> If I'm understanding the standard correctly (big if ), a type bound
> procedure cannot bind to a generic name, only to module and external
> procedures (C465 in f2008). So the following would not be allowed.
>
> type t1
> contains
> procedure, nopass :: sub
> end type
>
> interface sub
> procedure sub1
> procedure sub2
> end interface

Since it seems I'm the only one who noticed this post, I'll ask: isn't
that what the GENERIC statement is for?:

type t1
contains
procedure, nopass :: sub1
procedure, nopass :: sub2
generic :: sub => sub1, sub2
end type


> The compiler I use (gfortran 4.7.0) indeed gives an error when attemting
> to compile this.
>
> However, if I change the name of sub1 to sub (both in the procedure
> statement and in the definition of the subroutine), gfortran not only
> accepts it, but surprisingly treats the tbp as if it binds to the
> generic name.
>
> See the following code and output. I would have expected an error during
> compilation or at least during runtime at execution of the second call
> statement.
>
> module foo
> implicit none
>
> type t1
> contains
> procedure, nopass :: sub
> end type
>
> interface sub
> procedure sub
> procedure sub2
> end interface
> contains
> subroutine sub
> print *, 'sub1'
> end subroutine
>
> subroutine sub2(arg1)
> integer arg1
>
> print *, 'sub2'
> end subroutine
> end module
>
> program bar
> use foo
> implicit none
>
> type(t1) obj
>
> call obj%sub
> call obj%sub(0)
> end program
>
> $ gfortran foobar.f90 -o foobar && ./foobar
> sub1
> sub2
>
> Is my understanding wrong and is this to be expected?

It looks like a compiler bug. Intel's compiler (still) requires "module
procedure" for the INTERFACE block, so after making that change I get:

error #6784: The number of actual arguments cannot be greater than the
number of dummy arguments. [SUB]
call obj%sub(0)
-------------^

--
John

On 7/22/2012 4:24 PM, JWM wrote:
> It looks like a compiler bug. Intel's compiler (still) requires "module
> procedure" for the INTERFACE block, so after making that change I get:
>
> error #6784: The number of actual arguments cannot be greater than the
> number of dummy arguments. [SUB]
> call obj%sub(0)
> -------------^

Just replacing "procedure" with "module procedure" in the quoted program
is not the appropriate fix. You had it right in the earlier text about
the use of generic. Erik's program declared a generic, but outside the
context of the type. There's the additional problem that a generic name
in a type-bound-generic-stmt is not allowed to be the same as that of a
specific-type-bound-procedure-name in that type. See note 4.44 in F2008.

Here is how you should do it; the Intel compiler accepts this and does
the right thing:

module foo
implicit none

type t1
contains
procedure, nopass :: sub1
procedure, nopass :: sub2
generic :: sub => sub1,sub2
end type

contains
subroutine sub1
print *, 'sub1'
end subroutine

subroutine sub2(arg1)
integer arg1

print *, 'sub2'
end subroutine
end module

program bar
use foo
implicit none

type(t1) obj

call obj%sub
call obj%sub(0)
end program

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/arti...ization-notice
for more information regarding performance and optimization choices in
Intel software products.

On Mon, 23 Jul 2012 10:53:24 -0500, Steve Lionel
<steve.lionel@intel.invalid> wrote:

> On 7/22/2012 4:24 PM, JWM wrote:
>> It looks like a compiler bug. Intel's compiler (still) requires "module
>> procedure" for the INTERFACE block, so after making that change I get:
>>
>> error #6784: The number of actual arguments cannot be greater than the
>> number of dummy arguments. [SUB]
>> call obj%sub(0)
>> -------------^
>
> Just replacing "procedure" with "module procedure" in the quoted program
> is not the appropriate fix.

I wasn't implying that "module procedure" was the appropriate fix, rather
that it was required in order to compile that piece of code using ifort.
I apologize about the confusion.

I made it clear from the start that it was a bug in gfortran ---and a good
one, since some people might consider it a feature.... just like those
"cvf features" that still show up from time to time.

--
John