Dear all,

I'm new to this forum and to the FTN95 Personal edition compiler. I tried to compile some of my code and I got an, in my opinion, strange error message or warning (depending on the compiler options).

Source code:

module problem_ftn95 contains subroutine fie1 implicit none type type1 integer :: elem(2) integer :: scal end type type1

type (type1) :: var1

var1%elem(1) =  7
var1%scal    =  7

end subroutine fie1

subroutine fie2 implicit none type type2 integer :: elem(2) integer :: scal end type type2

type(type2) :: var2

var2%elem(1) = 5
var2%scal    =  7

end subroutine fie2 end module problem_ftn95

Compilation:

D:\problem_ftn95>ftn95 /error_num /iso problem_ftn95.f90 [FTN95/Win32 Ver. 5.50.0 Copyright (c) Silverfrost Ltd 1993-2010] PROCESSING MODULE [<PROBLEM_FTN95> FTN95/Win32 v5.50.0] NO ERRORS [<FIE1> FTN95/Win32 v5.50.0] 0019) integer :: elem(2) *** Error 149: Duplicate definition of elem 1 ERROR [<FIE2> FTN95/Win32 v5.50.0] NO ERRORS [<PROBLEM_FTN95> FTN95/Win32 v5.50.0] *** Compilation failed

Compilation:

D:\problem_ftn95>ftn95 /error_num problem_ftn95.f90 [FTN95/Win32 Ver. 5.50.0 Copyright (c) Silverfrost Ltd 1993-2010] PROCESSING MODULE [<PROBLEM_FTN95> FTN95/Win32 v5.50.0] NO ERRORS [<FIE1> FTN95/Win32 v5.50.0] 0019) integer :: elem(2) WARNING - 520: elem has been declared more than once with the same type (see line 1) NO ERRORS, 1 WARNING [<FIE2> FTN95/Win32 v5.50.0] NO ERRORS [<PROBLEM_FTN95> FTN95/Win32 v5.50.0]

I don't understand why the elem member, inside a type definition results in this error / warning. The problem only occurs for arrays.

Anybody an idea or is this a compiler bug ?

Best Regards,

Albert

I've never understood the contains bit, so here is a module to define the types.

winapp
module problem_ftn95 
 
type type1 
integer :: elem(2) 
integer :: scal 
end type type1 

type type2 
integer :: elem(2) 
integer :: scal 
end type type2 

end module problem_ftn95



subroutine fie1 
use problem_ftn95
implicit none 

type (type1) :: var1 

var1%elem(1) = 7 
var1%elem(2) = 77 
var1%scal = 7 
print *,var1
end subroutine fie1 

subroutine fie2 
use problem_ftn95
implicit none 

type(type2) :: var2 

var2%elem(1) = 5 
var2%elem(2) = 55 
var2%scal = 7 
print *,var2
end subroutine fie2 

program test
call fie1
call fie2
end

Regards Ian

Ian,

Thanks for the answer your solution is just going around the real problem. The modules are, in my opinion, there to do hide details from the larger program. In the solution you give the routines fie1 and fie2 are again visible to the total program and not only through the module construct. In my, simplified, program I tried to point out the fundamental problem in the compiler that in a module it was not possible to have in 2 subroutine a type definition with elements of the same name. The later should, according to my understanding from the standard and from programming languages in general be possible. So I think this is a bug in the compiler.

Regards,

Albert

Sorry, I'm just a simple guy. But if you want to use MODULEs and CONTAINS, then this works and doesn't mix up modules for type definition and modules for subprogram definition. You can probably use a module for transfer of data as well.

winapp
module problem_ftn95 
 
type type1 
integer :: elem(2) 
integer :: scal 
end type type1 

type type2 
integer :: elem(2) 
integer :: scal 
end type type2 

end module problem_ftn95


module noproblem_ftn95
contains
subroutine fie1 
use problem_ftn95
implicit none 

type (type1) :: var1 

var1%elem(1) = 7 
var1%elem(2) = 77 
var1%scal = 7 
print *,var1
end subroutine fie1 

subroutine fie2 
use problem_ftn95
implicit none 

type(type2) :: var2 

var2%elem(1) = 5 
var2%elem(2) = 55 
var2%scal = 7 
print *,var2
end subroutine fie2 
end module noproblem_ftn95

program test
use noproblem_ftn95

call fie1
call fie2
end

If you don't put 'use noproblem_ftn95' in the main program, then the subroutines are undefined at link time, so I suppose it achieves what you wanted, to hide things. Regards Ian

Ina,

Thanks for this workaround, I can think of some more (eg. giving the elements of type an other name). The point of the example is not to find work arounds. The example is there to signal the problem, I think there is, in the compiler.

Regards,

Albert

The example you have given may be a compiler diagnostic bug but what would be wrong with using module problem_ftn95

type type1 
integer :: elem(2) 
integer :: scal 
end type type1 

type type2 
integer :: elem(2) 
integer :: scal 
end type type2 

public  type1
private type2

contains 

subroutine fie1 
implicit none 

type (type1) :: var1 

var1%elem(1) = 7 
var1%scal = 7 
end subroutine fie1 

subroutine fie2 
implicit none 

type(type2) :: var2 

var2%elem(1) = 5 
var2%scal = 7 
end subroutine fie2 

end module problem_ftn95 

It makes more sense to me to declare the structures in the main part of the module, then contain the routines that use them. I did not see any indication of how you wanted to hide the detail in your first example, but that can be done using PUBLIC/PRIVATE if required. Certainly fie1 and fie2 can't be private ??

John

John,

Your solution would in this example make more sense, but I extracted this example from a larger code base. I also think that it is a compiler diagnostics bug

Regards,

Albert

I am investigating this bug but it is not as easy to fix as I expected.

I have now managed to fix this bug and the fix will be in the next release.