Inconsistent INTERFACEs with regards ALLOCATABLE are not detected

[Cross__Mat]

Hi. I'm on

> uname -a
Linux stonehenge 3.1.4-1.fc16.x86_64 #1 SMP Tue Nov 29 11:37:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

with

> ifort --version
ifort (IFORT) 12.1.0 20111011

For input source

> cat alloc.f90
module m
interface
subroutine sub(a)
integer :: a(:)
end subroutine sub
end interface
end module
subroutine sub(a)
integer, allocatable :: a(:)
end subroutine sub
use m
integer, allocatable :: a(:)
call sub(a)
end

I would expect to see a compilation failure for the lack of ALLOCATABLE in the INTERFACE for SUB.

Additionaly, the Fortran generated by -gen-interfaces omits the ALLOCATABLE from the INTERFACE for SUB.

[Ron_Green]

This is an interesting issue. But I don't see a bug here.

Rules and Restrictions on interface blocks say the following: "5. The attributes of the dummy arguments and function result must be completely specified in the specification part, and these specifications must be consistent with those specified in the procedure definition. Note that the dummy argument names may be different, but the attribute names must be the same." - Fortran 95 Handbook, 12.8.2.1, Rules and Restrictions, 5.

Based on this, the code you have above is non-conformant. What a compiler does with non-conformant code is up to the implementaton.

Another aspect of this is suba() itself. As an external procedure, very little checking is done for argument passing to suba. This external routine could be in a diffferent compilation unit. Granted, it is in the same source file as the interface and USE/reference BUT since it's an external procedure it is treated in isolation during the compilation - no symantic information is carried from the module or the reference. External procedures require the user to manage the correctness of argument matching.

The main program uses the INTERFACE to construct the call to suba, but again, since it's external there is no checking of the arguments. Similarly, the -gen-interfaces is created from the existing INTERFACE block. Thus, as you noted, no 'allocatable' attribute is present in the generated interface. This MAY be a bug or something we could improve upon. I'll check with the developers on this point.

Irrelevant, but a point of reference, gfortran also compiles this code without complaint.

I hope this helps. It also illustrates why an INTERFACE for an external procedure is not quite as good as defining the procedure within a MODULE. Externals just do not get as thorough argument checking as do references/definitions of module procedures.

ron

[Cross__Mat]

Thanks for the comments Ron.
I realise that ifort doesn't have to do any checking here, but in my experience of gfortran, g95, nagfor, ifort, pgf90 and Oracle f95, ifort does the most thorough compile-time checking of INTERFACE matches anyway, so I'd be surprised if you don't consider it worthwhile to check this too.

Does the -gen-interfaces output from my source really come from the existing INTERFACE? With just

subroutine sub(a)
integer, allocatable :: a(:)
end subroutine sub

the ALLOCATABLE is dropped too. Surely outputting an INTERFACE with different characteristics to the input source is a bug?

[Cross__Mat]

Playing around with

subroutine supersub(sub,a)
interface
subroutine sub(a)
integer, allocatable :: a(:)
end subroutine sub
end interface
integer :: a(:)
call sub(a)
end subroutine supersub
end

I see can the different issues now. Here, the mismatched ALLOCATABLE is trapped at compile time. I'm happy with that.