Floating Point Exception Mode

Is there an option to change the Floating Point Exception Mode (FPE mode) for ftn95 or scc?

I do not know the FPE mode used by ftn95 and scc.

I would like to change it to IEEE-754 mode, if possible (and if this is not the FPE mode used by ftn95 and scc).

Thanks for any information, Dietmar

I am sorry for the delay in responding to this post. I hope to have some information on this shortly.

My understanding is that IEEE-754 is a hardware standard over which FTN95 and SCC has no control apart from the following routines...

PERMIT_UNDERFLOW@

and

MASK_UNDERFLOW@ (reversed by UNMASK_UNDERFLOW@).

By default, under flows are permitted and unmasked.

I have an array with values and some of them are listed as 'Invalid floating point number'. Is there a change to recognize them during runtime and fix them to 0.0 as example?

edit: Ok, I have a solution using EQUIVALENCE

A customer has managed somehow to write an invalid floating point value into one of his data files. i can trap the exception when use of the value is attempted but, for now, i am putting up a brief warning message in the trapping routine but that 'worries' the user!!!.

Now, i can obviously remove the warning or use MASK_UNDERFLOW@ but wondered if there was actually a way to reset the variable to some default value (e.g. 0.0 or a generic value of our choice)?

K

Quoted from KennyT A customer has managed somehow to write an invalid floating point value into one of his data files.

Is this data file formatted or unformatted? If the former, the program will need to read the data with a format, and an I/O error will result. You can take IOSTAT and take appropriate action. If the file is unformatted, you will need to track down how the invalid value appeared; you could write a utility program to check the file for invalid values.

Now, i can obviously remove the warning or use MASK_UNDERFLOW@ but wondered if there was actually a way to reset the variable to some default value (e.g. 0.0 or a generic value of our choice)?

See the /Zeroise and /LOcal_zero compiler options. Zero is not always a suitable default value, e.g., for the number of days in a month.

it's unformatted so there's no IOSTAT option.

i just wondered whether, at runtime in the trapping routine, there was a way to recover the address of the offending variable so we could replace the contents with our own 'flag as null' value and continue execution, that way, when the user updated his data file, it would 'auto-repair' itself?

K

edit, it looks as though ACCESS_DETAILS@ may be useful here!

K

but ACCESS_DETAILS@ doesn't seem to work? it causes an access violation, perhaps it's not available under Win64, and i can't seem to find it in any .INS file in the Salford folder?

K

Quoted from KennyT it's unformatted so there's no IOSTAT option.

That is not true as far as I know. Here is a simple test program.

program tst
integer :: i,j,k,stat
open(10,file='xyz.ufd',status='replace',form='unformatted')
i=17; j=i*i; k=2*j+3*i
write(10)i,j,k
close(10)

open(11,file='xyz.ufd',status='old',iostat=stat,form='unformatted')
write(*,100)'After open',stat
read(11,iostat=stat)i,j,k
write(*,100)'After read',stat
close(11,iostat=stat)
write(*,100)'After close',stat

100 format(1x,A12,I8)
end program

The program prints IOSTAT=0 after the three I/O statements pertaining to file unit-11.

Quoted from mecej4

Quoted from KennyT it's unformatted so there's no IOSTAT option.

That is not true as far as I know. Here is a simple test program.

program tst
integer :: i,j,k,stat
open(10,file='xyz.ufd',status='replace',form='unformatted')
i=17; j=i*i; k=2*j+3*i
write(10)i,j,k
close(10)

open(11,file='xyz.ufd',status='old',iostat=stat,form='unformatted')
write(*,100)'After open',stat
read(11,iostat=stat)i,j,k
write(*,100)'After read',stat
close(11,iostat=stat)
write(*,100)'After close',stat

100 format(1x,A12,I8)
end program

The program prints IOSTAT=0 after the three I/O statements pertaining to file unit-11.

unfortunately, the crash doesn't happen on the READ statement, it only happens when i try subsequently to use the value that's been read (which, programmatically, may be far away from the read itself), that's what i meant when i said that there's no IOSTAT available...

K

ACCESS_DETAILS@ has not been ported to 64 bits. You should get a warning from the linker and 'Call to missing routine' message at run time.

Quoted from PaulLaidler ACCESS_DETAILS@ has not been ported to 64 bits. You should get a warning from the linker and 'Call to missing routine' message at run time.

i'm still using the 32-bit compiler/linker but under win10-64, there's no warning from SLINK and no 'Call to missing routine' at run time...

K

edit: on a related note, is there a way to get the crash stack dump, under program control, so we can capture it and store it ready to be automatically emailed to us (along with any related datafiles), rather than the user having to manually store the relevant information themselves?

K

Quoted from KennyT Unfortunately, the crash doesn't happen on the READ statement, it only happens when i try subsequently to use the value that's been read (which, programmatically, may be far away from the read itself), that's what i meant when i said that there's no IOSTAT available...K

Oh, in that case you are really not dealing with an I/O statement, but with a [u:95bafcc1af]memory read[/u:95bafcc1af], so IOSTAT is not relevant at all.

I wish that FTN95 provided a console traceback (by line or address, whichever is available) in the way that the RUN77 utility of Salford FTN77 used to provide. It is a nuisance to go to the error pop-up click on some buttons, copy and paste information that is less complete than that which can be obtained in SDBG.

With a traceback, you would know the code location where the invalid real was used, and the data address.

Kenny

Here are a couple of functions that might be helpful...

extern 'C' int invalid_float(float f);
extern 'C' int invalid_double(double d);

So in FTN95 you could write

C_EXTERNAL invalid_float@ 'invalid_float'(VAL):INTEGER*4
C_EXTERNAL invalid_double@ 'invalid_double'(VAL):INTEGER*4

and call one of these functions to test each incoming value.

I have not had time to test these so let me know if it doesn't work.