forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Floating Point Exception Mode

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279
PostPosted: Thu Apr 24, 2014 1:43 pm    Post subject: Floating Point Exception Mode Reply with quote
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7924
Location: Salford, UK
PostPosted: Sat Apr 26, 2014 6:24 am    Post subject: Reply with quote
I am sorry for the delay in responding to this post.
I hope to have some information on this shortly.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7924
Location: Salford, UK
PostPosted: Tue Apr 29, 2014 3:06 pm    Post subject: Reply with quote
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.
Back to top
View user's profile Send private message AIM Address
dgurok



Joined: 26 May 2011
Posts: 66
PostPosted: Thu Jul 21, 2016 1:13 pm    Post subject: Reply with quote
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
Back to top
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 317
PostPosted: Sat Oct 15, 2016 7:03 pm    Post subject: A follow up question on invalid floats Reply with quote
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
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1886
PostPosted: Mon Oct 17, 2016 12:23 pm    Post subject: Re: A follow up question on invalid floats Reply with quote
KennyT wrote:
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.

Quote:
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.

Last edited by mecej4 on Sun Oct 23, 2016 1:34 am; edited 1 time in total
Back to top
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 317
PostPosted: Fri Oct 21, 2016 4:25 pm    Post subject: Reply with quote
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
Back to top
View user's profile Send private message Visit poster's website
KennyT



Joined: 02 Aug 2005
Posts: 317
PostPosted: Mon Oct 24, 2016 2:22 pm    Post subject: Reply with quote
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
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1886
PostPosted: Mon Oct 24, 2016 2:31 pm    Post subject: Re: Reply with quote
KennyT wrote:
it's unformatted so there's no IOSTAT option.

That is not true as far as I know. Here is a simple test program.
Code:
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.
Back to top
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 317
PostPosted: Mon Oct 24, 2016 2:41 pm    Post subject: Re: Reply with quote
mecej4 wrote:
KennyT wrote:
it's unformatted so there's no IOSTAT option.

That is not true as far as I know. Here is a simple test program.
Code:
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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7924
Location: Salford, UK
PostPosted: Mon Oct 24, 2016 2:43 pm    Post subject: Reply with quote
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.
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317
PostPosted: Mon Oct 24, 2016 2:49 pm    Post subject: Re: Reply with quote
PaulLaidler wrote:
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
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1886
PostPosted: Mon Oct 24, 2016 3:57 pm    Post subject: Re: Reply with quote
KennyT wrote:
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 memory read, 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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7924
Location: Salford, UK
PostPosted: Tue Oct 25, 2016 7:03 am    Post subject: Reply with quote
Kenny

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

Code:
extern "C" int invalid_float(float f);
extern "C" int invalid_double(double d);


So in FTN95 you could write

Code:
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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group