Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28925 Discussions

ifort gets confused with procedure names in conjunction with submodules

martinmath
New Contributor II
1,214 Views

The small example below shows what look like a compiler bug, occurring with current versions ifx 2023.0.0 20221201 as well as ifort 2021.8.0 20221119.

Compilation with "ifort submod_aux.f90 submod_class.f90 submod_class_smod.f90 -c" (or ifx) gives the error message:

 

submod_class_smod.f90: error #8262: For a type-bound procedure that has the PASS binding attribute, the first dummy argument must have the same declared type as the type being defined.   [SELF]

submod_class_smod.f90(6): error #8278: An overriding binding and its corresponding overridden binding must have the same number of dummy arguments.   [SUB]
   procedure :: sub

 

and some more.

In the example there is an auxiliary module submod_aux providing a derived-type "aux" with type-bound procedure sub. The subroutine "sub" itself is private.

Furthermore, there is a module submod_class.f90, defining an abstract type "t", providing only the interface of t. An implementation for "t" is provided in the submodule with extended type "s", which is not exported by module t. Type "t" has a type-bound procedure of name "sub" (deferred) which is implemented by "s". It has an argument of type "aux". Somehow, the compiler confuses the subroutine "sub" from the submodule and the subroutine of same name from auxiliary module, which is demonstrated by the following work-around.

Work-around: rename subroutine "sub" in the submodule to "sub_s" and declare type-bound procedure with "procedure :: sub => sub_s".

 

 

module submod_aux

implicit none
private

type, public :: aux
   integer :: i = 42
contains
   procedure :: sub
end type aux

contains

subroutine sub(self)
   class(aux), intent(out) :: self
   self%i = 43
end subroutine sub

end module submod_aux
module submod_class

use submod_aux
implicit none
private

public create

type, abstract, public :: t
contains
   procedure(sub_ifc), deferred :: sub
end type t

abstract interface
   subroutine sub_ifc(self, a)
      import t, aux
      class(t), intent(out) :: self
      class(aux), intent(in) :: a
   end subroutine sub_ifc
end interface

interface
   module function create() result(x)
      class(t), pointer :: x
   end function create
end interface

end module submod_class
submodule (submod_class) submod_class_smod

type, extends(t) :: s
   integer :: i
contains
   procedure :: sub
end type s

contains

module function create() result(x)
   class(t), pointer :: x
   allocate(s :: x)
end function create

subroutine sub(self, a)
   class(s), intent(out) :: self
   class(aux), intent(in) :: a
   self%i = a%i
end subroutine sub

end submodule submod_class_smod

 

 

EDIT: corrected description of usage of aux (it is used argument not as component).

1 Solution
martinmath
New Contributor II
1,060 Views

Thanks for checking.

It is actually an old bug, which I also get with an older ifort version. Meanwhile I also saw (with another real code case) that an abstract derived-type in the main module (as in the example) is not necessary.

 

View solution in original post

0 Kudos
6 Replies
FortranFan
Honored Contributor III
1,181 Views

The code looks conforming to me, I reckon it's a compiler bug.

0 Kudos
Barbara_P_Intel
Employee
1,109 Views
$ ifort --version
ifort (IFORT) 2021.8.0 20221119
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.
$ ifort -c submod_aux.f90 submod_class.f90 submod_class_smod.f90
$

I'm confused. I copy/pasted those three files. I don't get the error messages. What am I missing?

 

 

0 Kudos
FortranFan
Honored Contributor III
1,092 Views

@Barbara_P_Intel wrote:
..

.. What am I missing?


Could it be Windows OS?

C:\temp>ifort /c submod_aux.f90 submod_class.f90 submod_class_smod.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

submod_class_smod.f90: error #8262: For a type-bound procedure that has the PASS binding attribute, the first dummy argument must have the same declared type as the type being defined.   [SELF]
submod_class_smod.f90(6): error #8278: An overriding binding and its corresponding overridden binding must have the same number of dummy arguments.   [SUB]
   procedure :: sub
----------------^
submod_class_smod.f90(6): error #8383: The dummy arguments of an overriding and overridden binding that correspond by position must have the same characteristics, except for the type of the passed object dummy arguments.   [SUB]
   procedure :: sub
----------------^
submod_class_smod.f90: error #8322: A deferred binding is inherited by non-abstract type; It must be overridden.   [SUB]
submod_class_smod.f90(3): error #6136: Derived-type declared must be ABSTRACT   [S]
type, extends(t) :: s
--------------------^
compilation aborted for submod_class_smod.f90 (code 1)
0 Kudos
Barbara_P_Intel
Employee
1,089 Views

Thanks for the sanity check, @FortranFan. What I copy/pasted compiles OK on Windows, too.

So I redid the copy/paste and I now get the error messages on Linux.

(rolling my eyes)


0 Kudos
Barbara_P_Intel
Employee
1,084 Views

Bug filed, CMPLRLLVM-46225. I get the same error messages with ifx and ifort.



0 Kudos
martinmath
New Contributor II
1,061 Views

Thanks for checking.

It is actually an old bug, which I also get with an older ifort version. Meanwhile I also saw (with another real code case) that an abstract derived-type in the main module (as in the example) is not necessary.

 

0 Kudos
Reply