- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My current ide is Microsoft VS2022 v. 17.9.2. I have some old working code which I can compile and launch, but the code bonks in debug mode when it reaches the line
LARGE_RESULT = GETWSIZEQQ(0_4, QWIN$SIZEMAX, WINFO)
All variables are declared as follows:
Module level:
USE IFQWIN, ONLY : QWINFO
TYPE (QWINFO) :: WINFO
Routine level:
USE IFQWIN, ONLY : GETWSIZEQQ
USE IFQWIN, ONLY : QWIN$SIZEMAX
INTEGER (KIND = 4) LARGE_RESULT
The complaint is forrtl: error(65): floating invalid. What?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We'll need to see a reproducer, as small as you can manage.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel:
Thanks for the prompt response. I am finding it difficult to create the reproducer. I strip down the code to bare bones, but then it does not bonk. I try adding things, but none seem to cause the grief.
The only noteworthy thing I can report is, when I look at the debugger on the line in question and add a watch for the symbol
QWIN$SIZEMAX
it says it is undefined. That is unexpected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By default, debug symbols for PARAMETER constants are omitted. You can change this in the project property page Fortran > Debugging. However, I find that the symbols aren't there no matter what.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel:
Thanks for the quick response. I will continue working on the reproducer.
The other feature here is the code is apparently running "properly" in Release mode. Just ran through an array of unit tests without issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although it is not a great solution, and as long as the code can be in the public view, zip up the whole lot and put it on the forum. Some one can then try it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a reproducer. I believe it has something to do with the compile/build options I have. In Compatibility, I am using the options
Use PowerStation I/O Format
Use PowerStation List Directed I/O Spacing
Use Other PowerStation Run-time Behavior
I have attached a zipped version of the project/solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Considering the number of replies to the reproducer, this apparently is a dead issue. I will endeavor to turn the code into a non-QWIN DLL with an API built from our interface for data transfer. If you see subsequent posts, these will be in this ilk.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The reproducer is not accessible. There was a forum bug on the day you posted it. Post it again.
- 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
I am reproducing this issue with and without the PowerStation compile options and with Intel Fortran 2025.1.0 and Microsoft Visual Studio 17.12.4.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I loaded built and ran your project on 2025.1 and it barfed as you describe in debug. Had a play and don't see an obvious reason. Feels like a compiler bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
andrew_4619,
Thank you for your prompt response. I did not see a way through this either. This "bug" has meant no use of true debugging in my real app for the past few months, which has been a bit of a problem. I can only hope someone might see either a workaround or a means of obtaining a fix in the next few.
Again, thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The exception was caused by a divided by zero inside the GETWSIZEQQ. It will not be caught normally because "fpe" option is set to 3 by default. In your project debug build this option has been explicitly set to "fpe:0" so the run will be aborted. I will open a bug report to remove the divided by zero in the library call.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Xiaoping_D_Intel:
Thank you for the description and quick reply. I now have a workaround and soon a fix. The /fpe:0 option is a normal form of the Debug build for our app, with /fpe:3 being Release. The reason is floating point "fun" ensues with the generation of NaN, and it proves helpful to have the /fpe:0 build to catch the problems with incipient divide by zero.
Thank you.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page