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 

OpenGL with FTN95/64

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



Joined: 20 Nov 2006
Posts: 31

PostPosted: Tue Apr 16, 2019 5:38 pm    Post subject: OpenGL with FTN95/64 Reply with quote

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?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Apr 17, 2019 3:59 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
dbradly



Joined: 20 Nov 2006
Posts: 31

PostPosted: Wed Apr 17, 2019 10:37 am    Post subject: OpenGL with FTN95/64 Reply with quote

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?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Apr 17, 2019 11:57 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Apr 18, 2019 6:59 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
dbradly



Joined: 20 Nov 2006
Posts: 31

PostPosted: Thu Apr 18, 2019 11:33 am    Post subject: OpenGL with FTN95/64 Reply with quote

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,
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Apr 18, 2019 12:08 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Sat Apr 20, 2019 7:54 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
dbradly



Joined: 20 Nov 2006
Posts: 31

PostPosted: Mon Apr 22, 2019 10:43 am    Post subject: OpenGL with FTN95/64 Reply with quote

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.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Apr 22, 2019 11:56 am    Post subject: Reply with quote

I may be looking at this rather simply, but isn't there a specific OpenGL 64 bit DLL ?
I thought it was in general heresy to try to mix 64 bit and 32 bit codes
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Mon Apr 22, 2019 12:19 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 22, 2019 12:28 pm    Post subject: Reply with quote

Not off hand but David has indicated that he will send me some code to look at.
Back to top
View user's profile Send private message AIM Address
dbradly



Joined: 20 Nov 2006
Posts: 31

PostPosted: Mon Apr 22, 2019 12:45 pm    Post subject: OpenGL with FTN95/64 Reply with quote

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?
Back to top
View user's profile Send private message
dbradly



Joined: 20 Nov 2006
Posts: 31

PostPosted: Thu May 02, 2019 3:46 pm    Post subject: OpenGL with FTN95/64 Reply with quote

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.
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 -> General 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