| View previous topic :: View next topic |
| Author |
Message |
mecej4
Joined: 31 Oct 2006
Posts: 1897
|
 Posted: Fri Dec 02, 2022 5:59 pm Post subject: Strange effect of unused subroutines on results |
 |
|
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 |
|
 |
Robert
Joined: 29 Nov 2006
Posts: 450
Location: Manchester
|
| Posted: Fri Dec 02, 2022 6:23 pm Post subject: |
|
|
| That is odd. It seems related to the equivalence statement in mdu. |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1897
|
| Posted: Fri Dec 02, 2022 6:44 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Sat Dec 03, 2022 9:39 am Post subject: |
|
|
| The failure appears to be confined to /64 /check and a temporary work-around is to use /inhibit_check 10. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Mon Jan 30, 2023 1:16 pm Post subject: |
|
|
| 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 |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
