- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all;
I am getting an invalid floating point operation error in release mode, which is not the case in the debug mode.I do not think thatthis is because of project setting differences between these two modes, since I already tried almost every combination.
The most interesting point is, I get the same error also in debug mode with "debug information format = line numbers only".
I get the error in the following line:
if (x .gt.0 .and. y .gt. 0) then
check=.not. ((REAL(t)/x .le. p/y).and.(REAL(t)/x .lt. 2))
else
check = .true.
However, unfortunately,I cannot see the current values of these variables since debug information format is
"line numbers only".
When I put a write statement in front of the lines above, the problem interestingly disappears.
What may be the problem ? Someting about compiler optimization or floating point stack ?
I am getting an invalid floating point operation error in release mode, which is not the case in the debug mode.I do not think thatthis is because of project setting differences between these two modes, since I already tried almost every combination.
The most interesting point is, I get the same error also in debug mode with "debug information format = line numbers only".
I get the error in the following line:
if (x .gt.0 .and. y .gt. 0) then
check=.not. ((REAL(t)/x .le. p/y).and.(REAL(t)/x .lt. 2))
else
check = .true.
However, unfortunately,I cannot see the current values of these variables since debug information format is
"line numbers only".
When I put a write statement in front of the lines above, the problem interestingly disappears.
What may be the problem ? Someting about compiler optimization or floating point stack ?
Link Copied
- « Previous
- Next »
45 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi;
Actually the C++ was containing one invalid floating point operation, and it is solved.
However, we still get it at the Fortran part on the line that I wrote in one of my previous posts.
Anyway, I converted the calculation into pieces, and I get the error at the following line:
xInverse = 1.0 / x
( x being integer(2) and xInverse being real(4) )
Since I need to use xInverse, I tried to change the expression above as follows:
xInverse = x**-1.0
And I get no error with this change.
In another case (with different input), I get the same invalid operation error at the following line:
temp1 = js * temp2
( js being integer(2) and [temp1, temp2] being real(4) )
However, when I change the expression as follows, the error disappears:
temp1 = temp2 * js (only the order of temp2 and js are changed)
How can it be ? Actually in the first case maybe we are changing the alignment of the executable and associated memory (for variables, arrays etc.) by using the exponentiation operator. But can the memory alignment also
be changed in the second case ? (just the same line but only the order of multiplied values is changed)
If it is not a corrupted memory issue, then what can be the reason ?
Thanks again...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The way your errors change when you make code changes is typical with a Heisenbug (one which moves when you look at it). It is virtually certain that you have some sort of memory violation error, or stack corruption, in my opinion. Another tricky bug occurs when you pass a constant as a parameter (e.g. 1.0) to a procedure that modifies that parameter value. Do you have all run-time error checking turned on?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Change
xInverse = 1.0 / x
to
if(x .eq. 0) Call BugCheck()
xInverse = 1.0_4 / FLOATI(x)
See what happens
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - gib
The way your errors change when you make code changes is typical with a Heisenbug (one which moves when you look at it). It is virtually certain that you have some sort of memory violation error, or stack corruption, in my opinion. Another tricky bug occurs when you pass a constant as a parameter (e.g. 1.0) to a procedure that modifies that parameter value. Do you have all run-time error checking turned on?
Yes, all run-time error checking options are enabled.
So if this is the case, why we do not receive a stack error, or an array index or memory violation error ?
And all outputs seem quite meaningful, and just the same results when we get the error and when we do not get it.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
- Next »