Host association twists
Harald Anlauf
I made funny experiences with the following code which I threw
at different compilers. It is possibly not F95 conforming but I
believe
it to be fully F2003 conforming.
Here it goes:
% cat hostassoc.f90
module hostassoc
implicit none
interface pack
module procedure pack_sub
end interface
contains
subroutine pack_sub ()
end subroutine pack_sub
subroutine foo (a)
integer, intent(in) :: a(:)
! intrinsic :: pack ! Try uncommenting this line...
print *, pack (a, a /= 0)
end subroutine foo
end module hostassoc
It compiles flawlessly with gfortran, g95 and PGI Fortran 11.1.
Sunstudio 12.1 gives a warning only with -ansi:
% sunf95 -V
sunf95: Sun Fortran 95 8.4 Linux_i386 Patch 141856-01 2009/07/22
Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details
% sunf95 -c hostassoc.f90 -ansi
interface pack
^
"hostassoc.f90", Line = 4, Column = 13: ANSI: This generic interface
has both functions and subroutines added to it.
print *, pack (a, a /= 0)
^
"hostassoc.f90", Line = 16, Column = 14: ANSI: This generic interface
has both functions and subroutines added to it.
f90comp: 19 SOURCE LINES
f90comp: 0 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 2 ANSI
IBM's xlf 13.1 does not like it:
% xlf -qversion
IBM XL Fortran for AIX, V13.1 (5724-X15)
Version: 13.01.0000.0004
% xlf hostassoc.f90
"hostassoc.f90", line 16.14: 1516-001 (S) Identifier pack was
elsewhere defined or used as a subroutine.
** hostassoc === End of Compilation 1 ===
1501-511 Compilation failed for file hostassoc.f90.
NAG Fortran:
% nagfor -f2003 hostassoc.f90
NAG Fortran Compiler Release 5.2(747)
Error: hostassoc.f90, line 16: Generic SUBROUTINE PACK called as a
function
[NAG Fortran Compiler error termination, 1 error]
Uncommenting the line "intrinsic :: pack" leads to
% nagfor -f2003 -c hostassoc.f90
NAG Fortran Compiler Release 5.2(747)
[NAG Fortran Compiler normal termination]
Intel compiler 12.1:
% ifort -V
Intel(R) Fortran Compiler XE for applications running on IA-32,
Version 12.0.1.107 Build 20101116
Original version:
% ifort -c hostassoc.f90
hostassoc.f90(16): error #6284: There is no matching specific function
for this generic function reference. [PACK]
print *, pack (a, a /= 0)
-------------^
compilation aborted for hostassoc.f90 (code 1)
Enabling the line "intrinsic :: pack" leads to
% ifort -c hostassoc.f90
hostassoc.f90(10): error #7055: This specific procedure is a function
and the generic_name is an intrinsic subroutine. [PACK]
subroutine pack_sub ()
-------------^
compilation aborted for hostassoc.f90 (code 1)
Reading in the F2008 draft standard, section:
12.5.5 Resolving named procedure references
I could not find anything that prohibits the above code versions.
Steve Lionel
> Hi,
>
> I made funny experiences with the following code which I threw
> at different compilers. It is possibly not F95 conforming but I
> believe
> it to be fully F2003 conforming.
>
> Here it goes:
>
> % cat hostassoc.f90
> module hostassoc
> implicit none
>
> interface pack
> module procedure pack_sub
> end interface
>
> contains
>
> subroutine pack_sub ()
> end subroutine pack_sub
>
> subroutine foo (a)
> integer, intent(in) :: a(:)
> ! intrinsic :: pack ! Try uncommenting this line...
> print *, pack (a, a /= 0)
> end subroutine foo
>
> end module hostassoc
The key to this is paragraph number 5 on p286 of F2008 (12.4.3.4.5
Restrictions on generic declarations). It says:
Within the scope of a generic name that is the same as the generic name
of an intrinsic procedure, the intrinsic procedure is not accessible by
its generic name if the procedures in the interface and the intrinsic
procedure are not all functions or not all subroutines.
In your case with the INTRINSIC commented out, the PACK intrinsic is
made inaccessible because your generic PACK has a subroutine as one of
the interfaces. Since the intrinsic is inaccessible, the reference to
PACK as a function fails.
If you uncomment the INTRINSIC, then you are violating constraint C1215
(F2008) "Within the scope of a generic name, each pair of procedures
identified by that name shall both be subroutines or both be functions"
--
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/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.
Steve Lionel
> If you uncomment the INTRINSIC, then you are violating constraint C1215
> (F2008) "Within the scope of a generic name, each pair of procedures
> identified by that name shall both be subroutines or both be functions"
A better reference for this point is C543 in F2008:
If the generic name of an intrinsic procedure is explicitly declared to
have the INTRINSIC attribute, and it is also the generic name of one or
more generic interfaces (12.4.3.2) accessible in the same scoping unit,
the procedures in the interfaces and the specific intrinsic procedures
shall all be functions or all be subroutines, and the characteristics of
the specific intrinsic procedures and the procedures in the interfaces
shall differ as specified in 12.4.3.4.5.
Harald Anlauf
thanks for the very clear explanation.
On Feb 23, 11:49 pm, Steve Lionel <steve.lio...@intel.invalid> wrote:
> The key to this is paragraph number 5 on p286 of F2008 (12.4.3.4.5
> Restrictions on generic declarations). It says:
>
> Within the scope of a generic name that is the same as the generic name
> of an intrinsic procedure, the intrinsic procedure is not accessible by
> its generic name if the procedures in the interface and the intrinsic
> procedure are not all functions or not all subroutines.
I had missed that point, assuming that different type, kind and rank
of
the arguments were sufficient to make resolution unambiguous.
> In your case with the INTRINSIC commented out, the PACK intrinsic is
> made inaccessible because your generic PACK has a subroutine as one of
> the interfaces. Since the intrinsic is inaccessible, the reference to
> PACK as a function fails.
>
> If you uncomment the INTRINSIC, then you are violating constraint C1215
> (F2008) "Within the scope of a generic name, each pair of procedures
> identified by that name shall both be subroutines or both be functions"
The variant with INTRINSIC was suggested to me by somebody else.
(By the way: changing the module procedure in the example to a
function
makes the module compilable on all platforms I have access to.)
In case anybody still reads: the project I am participating in heavily
uses overloading of several intrinsic procedures for user-defined
derived types, while trying to stay mostly Fortran 95 compatible and
portable. In the case of PACK a subroutine would have been more
natural than a function.