- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am having a problem when I overload a type with its associated constructor procedure.
The error appears during compilation and is located at the line where the derived-type variable is declared.
The stange thing is that type overloading works fine if the derived-type variable is declared as a module entity but it fails if it is declared as a local variable inside a procedure.
The error message is:
[bash]ifort -c type_definition_module.f90; ifort -c another_module.f90; ifort main.f90 type_definition_module.o another_module.o; ./a.out another_module.f90(17): error #6463: This is not a derived type name. [MYTYPE] type(MyType) :: VarType[/bash]
It is as if the compiler see the generic interface MyType only as a procedure and not also as a derived-type when the variable is decalred as a local variable.
Is this a compiler bug or I am doing something wrong ?
Thanks.
Here is an example.
The Type_Definition_Module module defines the MyType derived-type which is being overloaded by its constructor procedure.
The Another_Module module access the MyType derived-type by host association and constructs the variable using the MyType generic interface to the constructor procedure.
Here is the main program:
[fortran]Program main use Type_Definition_Module ,only: MyType use Another_Module ,only: Do_Something implicit none logical ,parameter :: ldum = .true. integer ,parameter :: idum = 1 real ,parameter :: rdum = 1.0 call Do_Something( ldum, idum, rdum ) End Program[/fortran]Here is the type definition module:
[fortran]Module Type_Definition_Module implicit none private public MyType Type :: MyType logical :: ldum integer :: idum real :: rdum End Type interface MyType module procedure Constructor end interface contains Subroutine Constructor ( This, ldum, idum, rdum ) implicit none class(MyType) ,intent(out) :: This logical ,intent(in) :: ldum integer ,intent(in) :: idum real ,intent(in) :: rdum This%ldum = ldum This%idum = idum This%rdum = rdum End Subroutine End Module[/fortran] Here is the module calling the generic interface. By commenting the derived-type variable declaration in the Do_Something procedure (line 17) and decommenting its declaration in the specification statement part of the module (line 8), the error goes away.
[fortran]Module Another_Module use Type_Definition_Module ,only: MyType implicit none private public Do_Something ! type(MyType) :: VarType contains Subroutine Do_Something ( ldum, idum, rdum ) implicit none logical ,intent(in) :: ldum integer ,intent(in) :: idum real ,intent(in) :: rdum type(MyType) :: VarType VarType = MyType( ldum, idum, rdum ) End Subroutine End Module[/fortran]
I am having a problem when I overload a type with its associated constructor procedure.
The error appears during compilation and is located at the line where the derived-type variable is declared.
The stange thing is that type overloading works fine if the derived-type variable is declared as a module entity but it fails if it is declared as a local variable inside a procedure.
The error message is:
[bash]ifort -c type_definition_module.f90; ifort -c another_module.f90; ifort main.f90 type_definition_module.o another_module.o; ./a.out another_module.f90(17): error #6463: This is not a derived type name. [MYTYPE] type(MyType) :: VarType[/bash]
It is as if the compiler see the generic interface MyType only as a procedure and not also as a derived-type when the variable is decalred as a local variable.
Is this a compiler bug or I am doing something wrong ?
Thanks.
Here is an example.
The Type_Definition_Module module defines the MyType derived-type which is being overloaded by its constructor procedure.
The Another_Module module access the MyType derived-type by host association and constructs the variable using the MyType generic interface to the constructor procedure.
Here is the main program:
[fortran]Program main use Type_Definition_Module ,only: MyType use Another_Module ,only: Do_Something implicit none logical ,parameter :: ldum = .true. integer ,parameter :: idum = 1 real ,parameter :: rdum = 1.0 call Do_Something( ldum, idum, rdum ) End Program[/fortran]Here is the type definition module:
[fortran]Module Type_Definition_Module implicit none private public MyType Type :: MyType logical :: ldum integer :: idum real :: rdum End Type interface MyType module procedure Constructor end interface contains Subroutine Constructor ( This, ldum, idum, rdum ) implicit none class(MyType) ,intent(out) :: This logical ,intent(in) :: ldum integer ,intent(in) :: idum real ,intent(in) :: rdum This%ldum = ldum This%idum = idum This%rdum = rdum End Subroutine End Module[/fortran] Here is the module calling the generic interface. By commenting the derived-type variable declaration in the Do_Something procedure (line 17) and decommenting its declaration in the specification statement part of the module (line 8), the error goes away.
[fortran]Module Another_Module use Type_Definition_Module ,only: MyType implicit none private public Do_Something ! type(MyType) :: VarType contains Subroutine Do_Something ( ldum, idum, rdum ) implicit none logical ,intent(in) :: ldum integer ,intent(in) :: idum real ,intent(in) :: rdum type(MyType) :: VarType VarType = MyType( ldum, idum, rdum ) End Subroutine End Module[/fortran]
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suspect that this is the same as a problem we are already working on - where in some instances having a derived type and a generic interface of the same name confuses the compiler. I'll check to see if your example matches the known problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which specific compiler version are you using? I can't reproduce this with Update 9 (12.1.3).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My version is the 12.1.0.
Let me update ifort and see if the bug is still there.
Let me update ifort and see if the bug is still there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As you mentionned, this comiler bug is corrected by updating ifort from 12.1.0 to 12.1.3
Thus, the problem is solved.... no more bug
Thanks.
Thus, the problem is solved.... no more bug
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's my favorite kind of bug - one already squashed.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page