- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've just rebuilt a project using the latest version of Intel Parallel Studio Fortran 2017 Update 1 and the program crashes at the call to the OpenGL function:
call fgluQuadricDrawStyle(SObj,GLU_FILL)
Unhandled exception at 0x000007F8CC89A138 (glu32.dll) in FEM2000_x64.exe: 0xC0000005: Access violation writing location 0x00000000B5D62D9C.
I've checked that the SObj is the correct variable type (INTEGER*4) and has been initialised using
SObj = fgluNewQuadric()
so not sure what's causing this. The message seems to suggest that the wrong (32-bit instaed of 64-bit) glu32.dll library is being involved somewhere.
When I revert back to the previous version 2016 in VS2010 the problem goes away.
Any ideas?
Thanks
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It won't be a wrong DLL - it is clear that a 64-bit DLL is being used.
What I see is that gluNewQuadric returns a pointer to the Quadric and that gluQuadricDrawStyle wants the pointer passed in. The declarations in IFOPNGL have this as integer*4, which is incorrect for a 64-bit platform. I think you may have gotten lucky with the older compiler.
As a workaround, copy ifopngl.f90 into your project and edit the declarations of these routines to specify INTEGER(K_GLVOID) for the function return and argument rather than integer*4. It looks as if there are other functions that will need this.
I'll take a quick look to see how extensive the problem is.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve, that's fixed it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
confession! I found all the glu quadrics were wrong for X64 a couple of years ago but didn't mention it. Sorry! I don't use the IFORT gl/glu btw, I use Bind(C) versions, all the quad types are by right type C_PTR in my world but I guess you are stuck with "integer pointers" because that would break users existing code.
Steve, I recall there was some move to update some of the windows sdk interfaces and add some new APIs. Have any new interfaces been added recently and/or what is the status of this project? I ask because I have quite a number of additional interfaces but I won't see any conflicts do to obsessive use of USE ONLY so it might be appropriate to "tidy up" at some point.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
17.0 has a thousand or more new APIs - mostly in KERNEL32 but some in other modules. I've just submitted more updates to KERNEL32 to complete it as far as Windows 8.1, at least. (I also discovered and fixed some errors.) I can't tell you what the future might hold here.
It is a daunting and labor-intensive task to do these updates. I automated bits of it but every API needs manual review and may need tweaks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just had a delve in kernel32 and it seems there are about 3000 new lines of code added to the 7000 already there! Having a quick in my own stuff the first handful that I checked seem to be there now and pleasingly also now "A" postfix versions for unicode. Cheers!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Don't get too excited about the Unicode entry points. That's not currently a priority. Also, it's the W-suffix entry points that are Unicode. A is for 8-bit ASCII.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes brain fade the "A" is for ANSI I believe, I have implimented quite a few "W"s......
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have just checked the files in the latest update and the corrections to ifopngl.90, as made by Steve L (retired), do not seem to have been implemented yet. Is it still Intel's intention to review and update these types of inconsistencies in this and any other declaration modules (e.g. Windows API)?.
![](/skins/images/C4F7392A5C68ACA60290C9576F107044/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page