OpenGL with FTN95/64

We have a library that uses a mix of Fortran 90 and C++ code that interfaces to the OpenGL32.dll providing a standard Fortran interface without any winio calls. This library compiles and runs using FTN95 32 bit compiler but crashes when compiled with FTN95 64 bit compiler after calling the BitBlt function and inside the OpenGL, wglSwapBuffers routine. The crash is an Invalid Floating Point Operation, the stack showing multiple entries to this routine.

Incidentally the same code does work with the Intel 64bit compiler without problem.

Has anyone any ideas what might be the problem?

Do you use any 8-byte integers and do arithmetic on 8 byte integers in your code? If so, note that code compiled with FTN95-32 bit uses X87 instructions for such arithmetic, whereas FTN95-64 uses SSE2 instructions for the same. If there are some uninitialised 8 byte integer variables in the code, the behavior of the 32-bit and 64-bit versions of your code could be quite different.

You may also try running the code with Intel Fortran after compiling with the option /fpe:0 (the default mode is /fpe:3, with which FP exceptions are not raised).

Thanks for the suggestion, and I did try compiling the whole of our library and driver using the Intel /fpe:0 switch and the 64bit Intel implementation still worked with our openGL driver. There were no exceptions raised.

With the FTN95/64 build the problem is a invalid floating point operation, which I think is different from a NaN exception. This is strange because I would think that the wglSwapBuffers function should indeed only be operating on pixel integers, but maybe not!

The last routine I have called is BitBlt with the following arguments:

WM_PAINT BitBlt - hwnd=6554872, hdc=-50259863, bitmap=-1828645786 - region=0 1024 577 0

so wglSwapBuffers is being called internally by this function, but why is there an invalid floating point operation?

Without seeing your source code, I can only speculate. I doubt that the following description has any relevance to your code, but it is illustrative.

The hex representation of -1828645786 is 93011466 (32-bit) or FFFFFFFF93011466 (64-bit). If, because of an error in the source code or a compiler bug, the 64-bit value is stored into memory and later interpreted as a 32-bit real, the upper half, i.e., FFFFFFFF, is a NaN (not a number), and its use may cause an FPU exception.

If you have narrowed down the part of the code where the 64-bit EXE is crashing, looking at the corresponding machine instructions may throw some light on the issue.

If the problem occurs when using a Silverfrost compiler\linker\DLL and if you are able to send me the code so that I can do the build myself then I am willing to check it out to see if I can locate the fault.

I have been concerned about the conversion between 64 bit pointers and addresses being passed to the 32bit OPENGL32.DLL, but it seems to work with the Intel and now Absoft 64 bit compilers, so there is possibly something different about the way Siverfrost deals with these values that is causing the problem.

I will send you a zip file with our dll's and example program that show the problem. Thanks,

The OpenGL32.dll that you are working with must be a 64 bit DLL no matter which compiler is being used, otherwise the linking will fail. The '32' in the name is unrelated.

I've seen this exact issue and can't recall how I worked around it, but I have some sample code if this link does not help https://github.com/RyanONeill1970/FortranOpenGL

Thanks for your optimism Ryan, but have you got your OpenGL examples working with the Silverfrost FTN/64 compiler under Windows? The project you pointed to only uses gfortran, which we don't have a problem with either.

Not those examples, but I do have another project that is purely FTN95 and uses OpenGL that suffered from that same problem. I can't recall what fixed it, Paul may have provided the fix. Do you remember this Paul?

Not off hand but David has indicated that he will send me some code to look at.

Paul, I sent an e-mail with a zip file attachment to 'ftn95@silverfrost.com' with title FAO Paul Laidler last Thursday. Did you not receive it?

So after working with Paul Laidler, it looks like that the floating point exception was occurring within the OPENGL32.DLL (wglSwapBuffers) and that the default action for the 64bit Silverfrost compiler is to trap such exceptions and cause a crash.

This is different from the Intel and Absoft 64bit compilers whose default action is to ignore such exceptions, unless specifically asked to trap them.

Paul has now added a new routine into the Silverfrost compiler - mask_all_fp_errors(on/off) which will allow the user to trap or ignore such errors as required.

Use of this routine has solved our problem and our OpenGL examples now work without crashing. Thank you Paul.