Hi, All, I am running a mod
 

Hi, All,

I am running a modified version of OpenFOAM 1.4.1 cross-compiled with MingW compiler on Windows, and we have a runtime error like:

forrtl: error (73): floating divide by zero

On Windows (MingW port) his error will get triggered with or without FOAM_SIGFPE being set.

The same source code compiled with Linux/gcc can run when FOAM_SIGFPE is NOT set, but will crash in the same location when FOAM_SIGFPE is set in the env.

So obviously, this is an issue with the Foam::sigFpe::set() implementation.

Is there any special gcc switch used in the Linux compilation that allows more tolerance to division by zero?

Any suggestions?

OF on Linux does not set anyth
 

OF on Linux does not set anything unless FOAM_SIGPFE is set so guess default behaviour is different. No special gcc flags are used except -O3.

All applications should run with FOAM_SIGFPE switched on anyway.

It appears a MinGW compiled ex
 

It appears a MinGW compiled executable will raise a FPE by default, so I suggest modifying the Windows FPE code to respond to the FOAM_SIGFPE. For details visit:
http://www.symscape.com/openfoam-on-windows#comment-182

Hi, Richard, Just tried the
 

Hi, Richard,

Just tried the modification, but my colleague just told me that the fail-out error message is exactly the same.

What we did was just to update the file, and removed all the lib/<platform> directory, and force the linking of all the libraries.

Maybe that is not enough?

Hi Allen, I think your comp
 

Hi Allen,

I think your compiling strategy is fine - the dependency tracking works well enough that you could just recompile without forcing relinks.

I just tried forcing a floating point exception with details at:
http://www.symscape.com/openfoam-on-windows#comment-184

I found that the original version of sigFpe.C worked as expected according to the env FOAM_SIGFPE setting under Wine on Linux and Windows XP.

As I recall you are running OpenFOAM from within a fortran process - right? I wonder if that is causing a problem.

Have you tried running using a vanilla dos cmd console?

We got the same error when run
 

We got the same error when running from dos command.

I am reviewing the way how we build the mingw compiler: we download the vanila copy of the source code, but I have "enable_sjlj_exceptions=1" enabled for the build.

Could it be part of the issue? I guess I know too little about this sjlj exception thing - it may not be relevant at all.

In building the cross compiler
 

In building the cross compiler I did the same as you and also used the "--enable-sjlj-exceptions" option.

If it's any help I've posted a link to the MinGW cross compiler script I used at:
http://www.symscape.com/openfoam-on-windows

The link is within the sentence "I used the build-mingw script" which is part of stage 1 of the Patch Build Process.

It turns out that in order to
 

It turns out that in order to use your implementation of sigFpe.C, I have to use the MingW compiler with "--enable-sjlj-exceptions".

We actually tried to disable the setjmp/longjmp option when compiling the mingw gcc, then we got these:

signals/sigFpe.C: In function 'void clearFpe()':
signals/sigFpe.C:52: error: '_clearfp' was not declared in this scope
signals/sigFpe.C:53: error: '_controlfp' was not declared in this scope
signals/sigFpe.C: In member function 'void Foam::sigFpe::set()':
signals/sigFpe.C:137: error: '_controlfp' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_ZERODIVIDE' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_INVALID' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_OVERFLOW' was not declared in this scope
signals/sigFpe.C:140: error: '_MCW_EM' was not declared in this scope

So, it seems that these native Win32 fpe exception call is only available when setjmp/longjmp is enforced.

Don't know what it means though.

This is to be expected, as the
 

This is to be expected, as the FPE exception trap in OpenFOAM uses the setjmp/longjmp mechanism.

If you want to pursue this route (disabling setjmp/longjmp) then comment out the body of the methods in signals/sigFpe.C to avoid the compile errors. However, I think you'll also have to address other exceptions within signals/*.C

Sorry, just get chance to come
 

Sorry, just get chance to come back to the topic.

I guess I have to describe some details about our application.

1) Our main executable is compiled on Windows using Intel ifort compiler, with /fpe0 or fpe1 options.

2) The executable will dynamically load the OpenFoam.dll when needed.

We found that that the Foam::sigFpe::set() is always called when the OpenFOAM.dll is loaded (using LoadLibrary()), but the Foam::sigFpe::sigFpeHandler does not get invoked at all. We reach this conclusion by writing a line at the beginning of each of the 2 functions. It is indeed true, though surprising that sigFpeHandler() was never invoked, with or without FOAM_SIGFPE set.

According to Intel's ifort documentation, with /fpe0, Intel compiler does install its own fp exception handler, though with /fpe1, the fp exception is "disabled". Is it possible that the usage of _controlfp here is conflicting with Intel's FP exception handling?

Some further observation:

1) with ifort /fpe0 (Intel FP exception is used), the application will crash with or without FOAM_SIGFPE set, in either case, sigFpeHandler does not seem to be invoked.

2) with ifort /fpe1 (Intel FP exception is supposed to get disabled), the application will continue to run with some warning when FOAM_SIGFPE is not set; but crash when FOAM_SIGFPE is set (still the cout inside sigFpeHandler does not seem to have any effect).

Is it possible that in above case, some intel provided FPE handlers are in action?

I know that these observations can be interpreted in many ways, but hopefully someone already has a solution for it.