Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29029 Discussions

Problem with QWIN graphics and debug

NotThatItMatters1
633 Views

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?

0 Kudos
14 Replies
Steve_Lionel
Honored Contributor III
615 Views

We'll need to see a reproducer, as small as you can manage.

0 Kudos
NotThatItMatters
Beginner
521 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
508 Views

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.

0 Kudos
NotThatItMatters
Beginner
501 Views

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.

0 Kudos
JohnNichols
Valued Contributor III
494 Views

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. 

0 Kudos
NotThatItMatters
Beginner
459 Views

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.

(Virus scan in progress ...)
0 Kudos
NotThatItMatters
Beginner
188 Views

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.

0 Kudos
andrew_4619
Honored Contributor III
179 Views

The reproducer is not accessible. There was a forum bug on the day you posted it. Post it again.

0 Kudos
NotThatItMatters
Beginner
165 Views

Okay, I am sorry for that. Good grief.

0 Kudos
NotThatItMatters
Beginner
162 Views

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.

0 Kudos
andrew_4619
Honored Contributor III
151 Views

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. 

NotThatItMatters
Beginner
147 Views

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.

0 Kudos
Xiaoping_D_Intel
Employee
83 Views

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.


NotThatItMatters
Beginner
71 Views

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.

0 Kudos
Reply