Invalid floating point operation on 32 bit release build

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.

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?

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:

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.

I have always wanted a change to INTERFACE usage, so that the following could be accepted by the language / compiler. 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: 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.

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.

Quoted from JohnCampbell

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 ):

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:

[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]

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.

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.

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.