Silverfrost Forums

Welcome to our forums

Does this code work under debugger and without ?

4 Mar 2017 9:39 #18975

As the 64-bit compiler gradually supplants the old reliable FTN95-32, we may run into another curious and unexpected behaviour: with 8-byte integers, the 32-bit compiler can do a more efficient job of catching integer overflow than the 64-bit compiler.

That is because FTN95-32 uses the X87 section of the CPU to do 8-byte integer arithmetic. When an expression is evaluated and saved to memory, an FIST/FISTP instruction is used. If the number is too large an integer for 8 bytes in memory, a floating-point exception is raised, if exceptions are unmasked, and the exception can be processed.

In FTN95-64, in contrast, arithmetic with 8-byte integers is faster with the main (integer) part of the CPU, but a lot more code has to be emitted by the compiler if the user wants to catch integer overflow -- no hardware assist in the form of an exception is available.

4 Mar 2017 11:38 #18976

I consider real*4 overflow to be a user coding error, as typically the wrong precision has been selected. Not a bug in FTN95.

For integer overflow, this has typically been used for random number generators. I have always considered this to not be an error or an exception. This can often occur with integer1, integer2 and integer4, although I'd expect that integer8 would be less frequent. Not sure that it needs to be trapped.

John

4 Mar 2017 12:15 (Edited: 5 Mar 2017 1:50) #18977

Sure, integer overflow is routine and need not be trapped.

However, when the programmer has asked for checking with a compiler option or directive, it is helpful in fixing the code if integer overflow can be trapped and traced. With most compilers, such checking can make the program so slow that one tends to turn on checks less often. With the hardware assist available in the FPU for 8-byte integers, the overhead for checking is greatly reduced, and some checks can be left in place in production code.

5 Mar 2017 3:08 #18978

Since FTN95 is a champ in tricky error cases, it is like Sherlock Holmes among compilers, this option would be great to add. Or at least add kind of more verbose mode to compiler which will generate suggestions/warnings/comments to make sure that integer does not go over 3e7 in mixed Int+FP4 programming and be below ~1e15 in int8 + FP*8.

For example this compiler warns that comparing FP numbers may produce misleading results. I see people use thousands of such IFs in their codes. Why not add one more warning? I am sure people will use mixing Int+FP and be burned. Know cases when they wrote books and published many papers with the bugs in codes found decades later.

Please login to reply.