MASK_UNDERFLOW@

Was it implemented in 64bits? Somewhere in my code happening underflow and there is no easy way to find this place, large code, lot of data, long execution time, hard to find when and how code starts producing semi-reasonable garbage.

Worst of all the underflow may happen in very distant place and this place will not reveal itself. The affected place hence will confuse you being absolutely legit code but it will generate crazy results. Hard to find this bug, it is rarely happening, you always forget about it and as a result you lose a lot of time.

MASK_UNDERFLOW@ has not been implemented for 64 bits (maybe it does not have the same meaning).

You can call PERMIT_UNDERFLOW@(0_2) in order to treat underflows as an error...

SUBROUTINE PERMIT_UNDERFLOW@(opt) INTEGER(2) opt

opt = 0 treat underflows as an error otherwise use hardware to convert unerflows to zero.

Oh my...This revealed amount of roaches i can not believe! I will probably die before cleaning all of them. Thanks, Paul

Somebody probably can get great job using FTN95 by giving ad like this:

'Revealing your programming bugs in Fortran codes. 10 bugs per 1000 lines of code GUARANTEED or your money back' 😃

Dan

I would be interested to know the context in which an underflow is regarded as an error.

I have no tools to reveal such content. Looks like even PERMIT_UNDERFLOW@(0_2) does not catch everything.

By experience, the problems before happened when i ran the code with a lot of EXP(-A) when if A>70-80. These EXPs produce the numbers less then 1.e-38. To fix that i restrict A<70 and the errors disappear.

Currently i search for the bug which is causing similar problem but what causing it is unclear because all EXPonents are restricted as above. The call to PERMIT_UNDERFLOW@(0_2) stops debugger with the underflow error on the line which has legit code like this

          A = F * A + FF * B

with A=1.3e-35 - real4 B=2.d-37 - real8 F =0.999 - real8 FF=0.001 - real8

Fun here is that A is far from being off range to become underflow. The FA - too, and additionally the result of multiplication is real8 so its range is 1.d-308 - way far from becoming the underflow number

The FFB is 2.d-40 but also not underflow number because FF and B are real8, this could be a problem only if they were real*4

The compiler confuses real8 with real4?

Such strange devilry bugs are sucking my time periodically

The following code runs without error and outputs a value of about 1e-35.

The REAL4 value is converted to REAL8 before multiplication and the result of the right hand side is converted from REAL8 to REAL4 for the assignment. You can observe this by using /EXPLIST when compiling.

IMPLICIT NONE
REAL*4 A
REAL*8 B,F,FF
CALL PERMIT_UNDERFLOW@(0_2)
A=1.3e-35 
B=2.d-37
F =0.999d0
FF=0.001d0
A = F * A + FF * B
print*,A
end

No doubts that this extract works ok, I will not even check it myself. The trick is that something else in the code causing change of the state of FPU or some kind of corruption (debugger incorrectly displays results of logical functions for example, though this is still 6 months older version of compiler, will download newer today) and after that the code becomes crazy in the arbitrary place. The suspect #1 is some kind of underflow, isolating all possible such places helped before but I am still not successful.

Is just one call to PERMIT_UNDERFLOW@(0_2) at the beginning of the main program enough to trap underflows everywhere else?

Dan

Yes one call at the beginning is enough.

I was thinking that in a large majority of computations, underflows are common and not a problem. They are just particular instances of round-off error and round-off error can rarely be avoided.

Certainly one can guard against unnecessary loss of precision as in the case of your example where a REAL4 variable has been assigned to the result of a REAL8 calculation and might later be used in another REAL*8 calculation.

If the program that you are working with contains an unwise mix of REAL4 and REAL8 variables then a quick fix is to use /DREAL on the FTN95 command line.

I am also surprised how and why underflow causes havoc in the code. This is very old problem. In /32 the call mask_underflow@() solved this problem. Here with /64 the PERMIT_UNDERFLOW@(.TRUE.) does not change anything

I can not use /dreal because already limited in RAM despite /64. This specific variable i still can afford making real*8. Will search further why this underflow error occurs, looking at 8.40 first

Got 8_40. Found no difference in my code diagnostics.

Trying other options, found that the /CHECK compiler option still does not work in /64. During run compiler finds the out of bound error but points on the line number which is the END statement. This will need me to scale back to 32 bits which is not always easy.

This could be still some my own error (like request of too much memory etc) as 32bit version works OK

Is it possible to send me the code? I would like to see the /64 /CHECK failure.

Quoted from DanRRight ... During run compiler finds the out of bound error but points on the line number which is the END statement. This will need me to scale back to 32 bits which is not always easy.

Given this slight uncertainty w.r.t. the exact line where an error occurs and the line highlighted in the debugger at an error breakpoint, which I have noticed myself occasionally, perhaps Dan can revisit the issue of which statement caused the underflow.

It would help if, when an underflow break occurs, F11 is pressed and the instructions surrounding the breakpoint and the register values are recorded.

Paul, I'd love to prepare the simplest possible variant for you to look as I also have another problems with the code. Hope I will do that quick.

Mecej4 - yes, good idea, forgot about this issue which happened in the past very often