- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The code looks conforming to me, I reckon it's a compiler bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
$ 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bug filed, CMPLRLLVM-46225. I get the same error messages with ifx and ifort.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page