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 

Invalid floating point operation on 32 bit release build

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



Joined: 25 Feb 2016
Posts: 76

PostPosted: Thu May 23, 2019 6:11 pm    Post subject: Invalid floating point operation on 32 bit release build Reply with quote

We have four batch files to build our app into debug/release and 32/64 bit combinations.

When testing the 32 bit release build it fails with one of the following;
* 100% CPU and then quitting.
* Invalid floating point operation in one of two places.

Test suites against the 32 bit debug, 64 bit debug and 64 bit release all work perfectly. If it failed in one of the debug builds I might be able to get more information but it works correctly in those.

Snipped floating point error log below;

Runtime error from program:c:\users\whatever\myexe.exe
Invalid floating point operation
Floating point co-processor fault at address 0047f13e

0047e440 POTENTIALL [+0cfe]
0047dc70 POTENTIAL [+041e]
00478c10 POTFLD [+1230]
004fcd30 OUTPUT_POTSFLDS [+4bf5]
00401070 MAINPR [+10aa3]
0050b670 RUN [+0402]
00520fc0 ALL3VIEW_CALLBACK [+003f]

2b6cde76 call_function(<ptr>(func()ÄreturningÄint),<ptr>char,<ptr>void,enumÄlogical,enum [+0181]


eax=00000007 ebx=00000004 ecx=0000000a
edx=21ea2c08 esi=21ea2860 edi=00000007
ebp=21ea3558 esp=21ea2658 IOPL=0
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00010202 [NC OP NZ SN DN NV]

0047f13e dfstp [ebp-0x870]
0047f144 dfld [ebp-0x870]
0047f14a dfcomp [1ec27378]

Now this could be a bug in the source but I suspect that the 32 bit release build is not compiling correctly or that there is a race condition in the 32 bit release combination.

I have more logs to share if needed.
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 76

PostPosted: Thu May 23, 2019 8:39 pm    Post subject: Reply with quote

I've got further with this, it might be due to inconsistent interface declarations between functions and their callers.

This was revealed by adding the /u /z flags to the compilation.

I'll have to go through them all and check manually. I'm used to this kind of error being caught at compile time (C,C++, .Net etc).

Is there a way for the compiler to take the definition of a function as the interface and so remove the need to have duplicate and possibly differing definitions?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1179

PostPosted: Fri May 24, 2019 1:25 am    Post subject: Reply with quote

The compiler does check for mismatched interfaces when possible. In particular, if no explicit interface is required (by the rules of the language), and the mismatched interfaces are in the same source file, the compiler issues a warning.

However, if the caller and callee are in separate files, the mismatch can be caught only at run time, if that particular CALL does get executed, and the /check compiler option was used when building.

Try the following:
Code:
program badinterface
integer a
real x
call sub(a,x)
end program

subroutine sub(x,a)
integer a
real x
x = x+a
return
end


There are third party tools for generating interface blocks, and tools for checking interfaces. If you change the subroutine argument list, and forget to regenerate the interface blocks or to use those interfaces in the callee in a separate source file, again the error cannot be caught at compile time.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2103
Location: Sydney

PostPosted: Fri May 24, 2019 8:23 am    Post subject: Reply with quote

I have always wanted a change to INTERFACE usage, so that the following could be accepted by the language / compiler.
Code:
program badinterface
integer a
real x
include 'interfaces.ins'
call sub(a,x)
end program

subroutine sub(x,a)
integer a
real x
include 'interfaces.ins'
x = x+a
return
end

where the include file interfaces.ins consists of:
Code:
  INTERFACE
  subroutine sub(x,a)
    real a
    integer x
  end subroutine sub(x,a)

  subroutine sub2(x,a)
    integer a
    real x
  end subroutine sub2(x,a)
 END INTERFACE


If the program is compiled, this should check compatibility between the routine and interface definition and when the subroutine is compiled a kind incompatibility should be identified. Unfortunately F95+ does not allow this use of INTERFACE definition. Alternatively we could use a module with interface definitions.
Years ago I thought this approach could be good for library routines and tried this with a large number of routines, only to find I could not check the interfaces.ins with the described routines, which defeated the purpose.
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 76

PostPosted: Fri May 24, 2019 10:36 am    Post subject: Reply with quote

Sounds like I would have to have this as part of the integration testing in the build process.

I appreciate that this can't be done but I mention it in passing; C# is now built with C# which means that the full compiler is in C#. What this enables is the loading of source from your C# code and analysing the parse tree, looking for code issues.

Effectively you can analyse your code from more code that you write, checking if everything has a comment, is properly named etc. It's really quite neat but it took Microsoft years to do.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1179

PostPosted: Fri May 24, 2019 12:26 pm    Post subject: Re: Reply with quote

JohnCampbell wrote:

If the program is compiled, this should check compatibility between the routine and interface definition and when the subroutine is compiled a kind incompatibility should be identified. Unfortunately F95+ does not allow this use of INTERFACE definition. Alternatively we could use a module with interface definitions.
Years ago I thought this approach could be good for library routines and tried this with a large number of routines, only to find I could not check the interfaces.ins with the described routines, which defeated the purpose.

What you are asking for (but does not exist in and probably will not be added to Fortran) is sometimes named "Interface To Self". Function prototypes in C behave that way.

Pragmatically, you can do almost all of what you wish for in the following way.

1. Write the codes for the subroutines and functions first.

2. Use a tool to generate the inferfaces from the codes that you wrote in Step 1.

3. Include those interfaces (or put the interfaces into one or more modules and USE the modules) in codes that call those routines.

4. Run the compiler on the modified source files and fix any mismatched interfaces.

For the example code, I placed the subroutine in file jcsub.f90, without the INCLUDE statement, and generated the interface by using M. Olagnon's F90AIB (available at ftp://ftp.ifremer.fr/ifremer/fortran90/f90aib.f90.gz ):

Code:
f90aib < jcsub.f90 > interfaces.ins


and compiled the subroutine source file.

I then placed just the main program code (with the INCLUDE) into file badi.f90. Attempting to compile this file induced the compiler to say:
Code:
[FTN95/Win32 Ver. 8.40.0 Copyright (c) Silverfrost Ltd 1993-2019]
0005) call sub(a,x)
*** In the INTERFACE to SUB, the first dummy argument (X) was of type REAL(KIND=1), whereas the actual argument is of
    type INTEGER(KIND=3)
    1 ERROR  [<BADINTERFACE> FTN95 v8.40.0]
*** Compilation failed/code]


Last edited by mecej4 on Sat May 25, 2019 12:14 am; edited 1 time in total
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 76

PostPosted: Fri May 24, 2019 10:02 pm    Post subject: Reply with quote

After much hunting I have tracked this down to a faulty optimisation of the release build using the /optimise flag.

By that flag being present the app will crash with an access violation or occasionally a floating point error. Removing the flag fixes it which is a terrible shame as we were getting good results with timings.

I can provide a repro but it would have to be the whole code base as I don't think I can isolate what is triggering it.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1179

PostPosted: Fri May 24, 2019 11:29 pm    Post subject: Reply with quote

Do you have an estimate for the size of the reproducer?

I do not think that at this point you can rule out bugs in the source code and conclude that it is only the 32-bit optimiser that is at fault.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6002
Location: Salford, UK

PostPosted: Sat May 25, 2019 7:40 am    Post subject: Reply with quote

Ryan

If the optimiser is at fault then you can do one of two things and hopefully retain your good timings.

1) You can add /inhibit_opt n (where n is a positive integer in the range 1 to 74). Try different values of n to find out which optimisation is failing.

2) You can switch off all optimisations only for the routine where it fails.
Back to top
View user's profile Send private message
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