Request undefined variables be named when detected

In error messages following the detection of an undefined variable being used, when /checkmate was used to compile the program being run, only the line numbers and routine names are printed out. It would be very helpful if the particular variable responsible were named in the error message.

Here is an example. The buggy line of code:

IF (KA.LE.N-M+1) GA(KA+M-1)=GA(KA+M-1)+0.25D 0*PAR*(+A1*GA3(5)-A2*GA4(4))

Here is the error message that is printed at present when the bug is detected and the program is terminated:

Reference to undefined variable, array element or function result (/UNDEF) at address 5c767f

Within file teql.exe
in TAGU18 in line 5815, at address 22ad5

...more traceback lines...

Contrast this with the message from NAG Fortran for the same bug:

Runtime Error: tssubs.f, line 5815: Reference to undefined variable GA(KA+M-1)

Thanks.

Thanks for the feedback. I have made a note of this.

This suggestion has been adopted and work is in progress. The aim is to implement this for 64 bits and notification for simple variables is already in place (for the next release).

I do not keep 32bit version on sidelines for almost a year. Before if tricky error appeared i had no choice but scale down 64bits to 32buts. But bit by bit 64bit started to beat 32bit a bit and do not dig into 32th basement floor anymore. I understand that for a while the 32 and 64 bit version will be supported because there is no reason to switch to 64 if 32 works. I do not know how painful this synchronization job for Silverfrost is. On my experience on my own programs supporting two versions always was a nighmire hell. If for Silverftost this also is painful then my suggestion is to perform long overdue optimization of just the 64bit version to reach Intel IVF on Polyhedron tests and all users will switch to 64bits overnight. A lot of new users will also join or switch to Silverfrost i expect as this is the major issue which drags FTN95 from much broader adoption. Adding parallelization will be almost all what people need. Good also probably to do some cosmetic lift and change the name to FTNX or something

Dan

Thanks for the feedback.

Having been named, yes, I do still adhere to the 32-bit version. Partly it is due to its stability, but also because I like the idea of x87 code. Another thing is that I have, and use, a very small format laptop with only 2Gb RAM soldered in, so it cannot run Windows 10 64 bit reliably for several things. 32 bit Fortran programs that don't need every last bit and byte are as important to some of us as the multi-gigabyte using Dan and John. Not everyone has the latest and best

But, do I care a fig about enhancements to facilities that I don't use? Probably not. Is the future the 64-bit version? Of course it is.

Things could change dramatically with a simple decision at Micro$oft to remove 32-bit support from Windows

As an update to my previous post, that 2Gb laptop becomes unusable if OneDrive is enabled, and the MS Teams app runs in the background, so its days are numbered.

As to your laptop, Eddie, you probably can keep your computer forever if you do not need multitasking, as single cores only became barely 50% faster in the whole decade, and if you overclock then 0% like in my case. I upgraded PCs after 8-10 years and the compilation time, data load time, OpenGL speed even almost did not change at all. Good that they are hurricane fast with FTN95. RAMdrive speeds surprisingly also did not increase twice despite DDR3 RAM was substituted by DDR4. The only what changed 4x was parallel algebra speed, because of 4x more cores. Read-write speed of hardware in principle potentially improved 10-20x but we need some additional efforts to get that gain, like special HDF5 drivers compatible with FTN95 we still do not have. Windows loading speed did not increase 10-20x, by the way, maximum 1.5x. There was saying i agree with 'Computers with speed difference less than 1.5 are the same'