soccer jersey forums.silverfrost.com :: View topic - Strange effect of unused subroutines on results
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 

Strange effect of unused subroutines on results

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



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Dec 02, 2022 5:59 pm    Post subject: Strange effect of unused subroutines on results Reply with quote

I have a problem reproducer code that is about 220 lines long, of which about 70 lines are surrounded by #ifdef BIG ... #endif. These 70 lines contain two subroutines, neither of which is called from anywhere in the program. Nevertheless, including these lines in the compilation by defining BIG=1 causes the output of the program to change.

The source code may be downloaded from the cloud, using the link https://drive.google.com/file/d/1FwlLhhaqpb4X7ZmAU87GLhO6xeEgnisT/view?usp=sharing .

Compile and link and run using the command
Code:
ftn95 /Cfp /64 /check /define BIG 1 tmdcs.f90 /link

Running the program gives the output
Code:
mark(5), mark(8) =       5    8

which is wrong. The correct output is
Code:
mark(5), mark(8) =       2    2

as can be seen using other compilers (or by using FTN95 8.92 without /define BIG).

What is perplexing to me is that the inclusion of a subroutine that is never called and in which the only executable statement is RETURN can cause the calculated results to be affected.
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Fri Dec 02, 2022 6:23 pm    Post subject: Reply with quote

That is odd. It seems related to the equivalence statement in mdu.
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Dec 02, 2022 6:44 pm    Post subject: Reply with quote

Indeed, Robert, the equivalence statement makes itself felt, even though the two variables being equivalenced are both local variables in a subroutine that is not called.

Similarly, I observed that if I removed some comment lines with PRINT statements in them the output of the program changed! Death to determinism?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Dec 03, 2022 9:39 am    Post subject: Reply with quote

The failure appears to be confined to /64 /check and a temporary work-around is to use /inhibit_check 10.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Mon Jan 30, 2023 1:16 pm    Post subject: Reply with quote

This failure has been fixed for the next release of FTN95. It relates to 64 bits, CHECK mode and the use of EQUIVALANCE within subroutines in a CONTAINS section.
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 -> 64-bit 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