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

ftn95 /Cfp /64 /check /define BIG 1 tmdcs.f90 /link

Running the program gives the output

mark(5), mark(8) =       5    8

which is wrong. The correct output is

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.

That is odd. It seems related to the equivalence statement in mdu.

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?

The failure appears to be confined to /64 /check and a temporary work-around is to use /inhibit_check 10.

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.