Silverfrost Forums

Welcome to our forums

Compiler fails to catch clashing module variables

30 Oct 2019 11:03 (Edited: 25 Nov 2019 10:44) #24599

If more than one module contains identically named variables, and a program unit USEs more than one such module, and there are no rename clauses or ONLY clauses in the USE statements to suppress duplicates, references to those variables become ambiguous, and the language does not allow it. Section 11.3.2 of the Fortran 95 standard says

Two or more accessible entities, other than generic interfaces, may have the same name only if the name is not used to refer to an entity in the scoping unit. Generic interfaces are handled as described in section 14.1.2.3. Except for these cases, the local name of any entity given accessibility by a USE statement shall differ from the local names of all other entities accessible to the scoping unit through USE statements and otherwise.

FTN95 8.51 fails to detect the duplicate declarations and definitions in the following example, even with /checkmate:

module mod1
implicit none
integer :: w1=0, w2=-1, w3=-2
end module mod1

module mod2
implicit none
integer :: w1=2, w2=3, w3=-1
end module mod2

subroutine sub(x,y,z,n)
use mod1
use mod2
implicit none
integer, intent(in) :: n
real, dimension(n) :: x,y,z
integer i
if(w1 > 1)z(1:n) = x(1:n) + y(1:n)
return
end subroutine

program pgm
implicit none
real x(4),y(4),z(4)
call random_number(x)
call random_number(y)
call sub(x,y,z,4)
print *,z
end program

Gfortran says: modbug.f90:18:5:

18 | if(w1 > 1)z(1:n) = x(1:n) + y(1:n) | 1 Error: Name 'w1' at (1) is an ambiguous reference to 'w1' from module 'mod1'

30 Oct 2019 12:15 #24600

Many thanks for this bug report. I have logged it as needing fixing.

2 Nov 2019 1:58 #24613

John, it was more necessity than tenacity that motivated me.

In a medium sized collaborative project with 70 source files and 19 modules, my collaborator decided (with good reasons) to move some variables from one module to another. He forgot, however, to remove those variables from the old place, yet FTN95 compiled and built the EXE with no error messages!

Only after several hours of perplexing debugging did I happen to use another compiler, and then found out what had happened.

2 Nov 2019 9:56 #24614

So isn't it the case that 'compiler fails to find programmer's error', thus apportioning blame equally and fairly?

Aren't collaborators usually punished for their crimes by public humiliation (or worse)?

Good job the project didn't have a load of Clearwin+ stuff, or you'd still be working on it!

Eddie

2 Nov 2019 11:21 #24615

Quoted from LitusSaxonicum So isn't it the case that 'compiler fails to find programmer's error', thus apportioning blame equally and fairly?

This is one of those errors that are more likely to be committed when there are 'too many cooks in the kitchen' working without a coordinator/supervisor. One can be a great solo programmer and yet not do well when added to a team. Secondly, one of the main reasons to use FTN95 is its excellent error-catching capability. This is one of those cases where FTN95 did not live up to its reputation, but once such issues are reported, Paul & Co. are very responsive and quick in fixing them.

Aren't collaborators usually punished for their crimes by public humiliation (or worse)?

I have made such mistakes myself. Do you want a display of self-flagellation? Anyway, DanRRight is doing a great job in that department all by himself. Why compete?

Good job the project didn't have a load of Clearwin+ stuff, or you'd still be working on it!

It *does *involve Clearwin+. The GUI and graphics parts of the program are fine as they are, although they had to change the colour palette to RGB, and the graphical output could benefit from being resized for today's screen resolutions. We are trying to improve the computational parts of the program while mostly leaving the GUI alone, since 'it ain't broke'. We now have a codebase that can be compiled with Gfortran or FTN95, and linked with Clearwin+.

3 Nov 2019 1:39 #24619

Mecej4,

I don't think that the sort of collaborators I was hinting at do self-flagellation, they normally have it done for them. A play on words was intended.

Good luck with the rest of the team and the rest of the job.

Eddie

3 Mar 2020 2:21 #25035

This has now been fixed for the next release of FTN95.

Please login to reply.