Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.
29306 Discussions

strange behavior with private attribute

galtay
Beginner
725 Views
[sectionBody]Hello all, I'm having some strange behavior using the private / public attributes in my modules.  The code below compiles if I uncomment the line that says "public :: base_par_type", but this line refers to a type defined in a different module.  If I leave the line commented out I get the error message below.  This shouldn't happen as I should not even be able to declare base_par_type as public in the module my_par_class right? Im using ifort (IFORT) 11.1 20091012.  thanks.

private_test.F90(45): error #6633: The type of the actual argument differs from the type of the dummy argument. [MYPAR]
call grid%add(mypar)


!-----------------------------
module base_par_class
private
public :: base_par_type

type base_par_type
real :: p
end type base_par_type

end module base_par_class

!-----------------------------
module my_par_class
use base_par_class
private
public :: my_par_type
!public :: base_par_type
type, extends(base_par_type) :: my_par_type
real :: m
end type my_par_type
end module my_par_class

!-----------------------------
module grid_class
use base_par_class
private
public :: grid_type
type grid_type
real :: data
contains
procedure, pass :: add
end type grid_type

contains

subroutine add(this, par)
class(grid_type) :: this
class(base_par_type) :: par
end subroutine add

end module grid_class

!-----------------------------
program test
use my_par_class
use grid_class
type(my_par_type) :: mypar
type(grid_type) :: grid

call grid%add(mypar)

end program test



[/sectionBody]
0 Kudos
4 Replies
Hirchert__Kurt_W
New Contributor II
725 Views
1. There is nothing illegal about making base_par_type public in my_par_class. Doing so means that a scoping unit that uses my_par_class (e.g., your main program) would be allowed to use the name base_par_type (e.g., to declare another object) without explicitly using base_par_class.

2. On the other hand, I see no reason why you should be required to make base_par_type public in my_par_class. Unless I've missed something, the error message is a bug. Because the dummy argument par in add is declared class(base_par_type), an exact type match should not be required, and you should not need the ability to declare objects of type base_par_type in order for the compiler to recognize that an object of type my_par_type should match class(base_par_type).

-Kurt
0 Kudos
Steven_L_Intel1
Employee
725 Views
I agree that this is a compiler bug. I have escalated it as issue DPD200148744.
0 Kudos
galtay
Beginner
725 Views
I agree that this is a compiler bug. I have escalated it as issue DPD200148744.

thanks Kurt and Steve.
0 Kudos
Steven_L_Intel1
Employee
725 Views
It turns out that this was a bug previously reported and already fixed in our sources. I expect the fix to appear in Update 5 (late January). The issue ID is DPD200140688.
0 Kudos
Reply