My host app is written in fortran. I am loading the DLL at runtime using LoadLibrary. Before the LoadLibrary call, my 8087 control word is $33F. After the LoadLibrary call, the control word is $332.

I feel very lucky that I managed to narrow it down to this - if I was not using the LoadLibrary method of loading the DLL, I may never have found it. This might cost some other programmer many hours of frustration.

I have added fortran code to query the control word before LoadLibrary, and then restore it afterwards. It seems to work OK for the debug build of my fortran application. But for the release build of my fortran app I end up with heap corruption message from windows; it tells me that I have a bug in either my host application or one of the DLLs it has loaded.

Steps To Reproduce

1) write an application in fortran, using compiler setting to generate NaNs instead of throwing floating point exceptions
2) write a DLL with lazarus
3) in the fortran, add a call LoadLibrary, and code to query the 8087 control word before and after the call.

Additional Information

The lazarus DLL and the fortran exe are both 64-bit. So I'm not really sure how legitimate it is for me to be messing with the 8087 control word at all, because I have read that doing so is IA32-specific??? So, even though un-blatting the control word seemed to fix the problem for my debug build of the Fortran exe, maybe that was just lucky?

As explained in the other bug report, there are multiple reasons why it is done as it is done.

By default FPC is not perfectly delphi compatible: only the behaviour in case of exceptions is the same. To get the same behaviour with delphi and fpc: just mask the exceptions in your dll init code as needed. Due to the global exception masking of x86 CPUs there is no way to satisfy everybody needs.

If you need further assistence, please discuss the matter on the mailing lists.