forums.silverfrost.com

[Albert]

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

[IanLambley]

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

[Albert]

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

[IanLambley]

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.

[Albert]

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

[JohnCampbell]

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

[Albert]

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

[PaulLaidler]

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

[PaulLaidler]

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