forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Compiler fails to catch clashing module variables

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Oct 30, 2019 12:03 pm    Post subject: Compiler fails to catch clashing module variables Reply with quote

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:

Code:
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:

Quote:
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'


Last edited by mecej4 on Mon Nov 25, 2019 11:44 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Oct 30, 2019 1:15 pm    Post subject: Reply with quote

Many thanks for this bug report. I have logged it as needing fixing.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Nov 02, 2019 12:54 am    Post subject: Reply with quote

mecej4,
once again I'm amazed at your tenacity in identifying and tracking down potential resons for bugs.
I doff my titfa in your direction.

In pasing I note that the paragraph you quote from the FORTRAN manuals goes to show the 'legal speak' which 90% of users I'm sure find fatifėguing in the extreme to read.
Prėbably written by the same kind of people who write the oft cryptic, oft confusing, error messages which get discussed so oft on here,
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Nov 02, 2019 2:58 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sat Nov 02, 2019 10:56 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Nov 02, 2019 12:21 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
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.

Quote:
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?

Quote:
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+.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sun Nov 03, 2019 2:39 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Mar 03, 2020 3:21 pm    Post subject: Reply with quote

This has now been fixed for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group