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 

Bug with 64 bit compiler

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



Joined: 18 May 2012
Posts: 874
Location: Lanarkshire, Scotland.

PostPosted: Sun Dec 28, 2025 12:41 pm    Post subject: Bug with 64 bit compiler Reply with quote

The code at the link below runs as expected with the FTN95 64 bit compiler returning results identical to two other compilers.

Now, if the whole module betainv_storage is commented out FTN95 64 continues to return the expected results, even although the variables g_p64, g_alpha64, g_beta64 are never defined anywhere. Other compilers correctly fault the code.

What is interesting, is if you step through the code in the debugger, before the function brent01D is called, you can see that g_p64, g_alpha64, g_beta64 exist as real*8 variables!

I was very confused by this, then found that the 32 bit compiler correctly faults the code when the module betainv_storage is commented out.

An accidental discovery, I changed the name of the storage module, forgot to change the USE statements – and found the code still ran!

https://www.dropbox.com/scl/fi/zx9gptbl3410ax5jhaeqt/problemf95.f95?rlkey=bavxm914syry57dllfq7hhnpm&st=57sbzmqi&dl=0
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1946
Location: USA

PostPosted: Sun Dec 28, 2025 4:26 pm    Post subject: Reply with quote

I suspect that the strange behaviour that Kenneth notes is related to the .MOD files generated by the compiler. If such a file has been produced by a previous compilation, the compiler may find and use it even if it has become stale/invalid by changes to the source file in which the module is declared and defined. It is also possible that the .MOD files are the same regardless of whether or not the /64 option is specified.

Such issues are often troublesome when makefiles are used for building a complex DLL such as for Slatec or NSWC.
I have been in confusing situations where some .OBJ files with 32-bit code that were created earlier are overwritten by newer .OBJ files with 64-bit code, and the linker asks me for help.
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 874
Location: Lanarkshire, Scotland.

PostPosted: Sun Dec 28, 2025 5:10 pm    Post subject: Reply with quote

Mecej4,

Thank you, your suspicions were 100% correct! If I delete the old mod file I get the expected/correct behaviour.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1946
Location: USA

PostPosted: Sun Dec 28, 2025 6:34 pm    Post subject: Reply with quote

Kenneth, thanks for following up and reporting.
I did some more checking with your code, and I am pleased to note that FTN95 uses a different suffix for module files when /64 is used for compilation: the suffix is .MOD64, whereas a 32-bit compilation produces a moule file with the suffix .MOD . This difference could be helpful when writing makefile rules.
Back to top
View user's profile Send private message
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