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 ?
連結已複製
45 回應
Quoting - ylmz
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.
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.
Try making a logical function out of the if/then/else/endif block passing in x, y, p (use conditional compilation so you can easily switch back and forth).
If the problem goes away then the compiler optimization might be at fault. See if you can construct a simple test case and submit it to premier support.
Also try
if (x .gt.0 .and. y .gt. 0) then
tOVERx = REAL(t)/x
check=.not.(tOVERx .le. p/y).and.(tOVERx .lt. 2.0))
else
check = .true.
Note the 2.0
Also,what type are x, y, t and p?
Jim Dempsey
Quoting - tim18
It does look like the compiler may be setting up to execute the division unconditionally. Did you set /fp:precise ?
Hi Tim;
Now I tried what you said, but it says:
"ifort: command line error: use of '/fp:
what should i do ?
Quoting - ylmz
"ifort: command line error: use of '/fp:
what should i do ?
Quoting - Steve Lionel (Intel)
Please show us the command line you are using to compile.
The following command line is for Visual Fortran compiler:
/nologo /Oy- /Qparallel /assume:buffered_io /include:".Release2/" /DRELEASE_EXTERNAL /DNDEBUG /DDEBUG_CPU /DCOMPILER_IS_IVF /assume:nocc_omp /extend_source:132 /fpscomp:ioformat /fpscomp:logicals /warn:errors /stand:f90 /warn:declarations /warn:unused /warn:truncated_source /warn:interfaces /Qsave /align:commons /align:sequence /Qzero /fpe:0 /names:as_is /iface:cvf /module:".Release2ForLib/" /object:".Release2ForLib/" /traceback /check:format /check:output_conversion /libs:dll /threads /c
and the following is for C++:
/Ob2 /Oi /Ot /Oy /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "FATES2000" /D "_VC80_UPGRADE=0x0710" /D "_AFXDLL" /D "_MBCS" /GF /FD /EHsc /MD /Zp4 /Gy /Yu"stdafx.h" /Fp"Release2Fates.pch" /Fo"Release2" /Fd"Release2vc90.pdb" /W4 /nologo /c /Wp64 /TP /wd4290 /errorReport:prompt
By the way, I do not believe that there are any unexpected numbers such as (0 / 0) in the lines of code that I gave before.
We very recently hit a similar problem, though I wouldn't expect it to happen without at least some optimization turned on. Is the code shown inside a loop?
There is a mismatch between the C++ and FORTRAN expectations as to whether or not FP exceptions are enabled. It gets worse when you are writing FORTRAN libraries than can be called with either setting. We used the "safe" setting for fp speculation to get around it.
The code in our case was a tight loop doing conditional assignment with an explicit division in the RHS, conditional on the divisor being not-too-close-to-zero. This was being compiled as an SSE2 vector sequence using and/or masking logic to overwrite the result of the division with the "else" case value (a simple array lookup) in the register before writing the result back to the array. Nice pretty branch-free vector code but not semantically equivalent to the source when FP exceptions are enabled.
That's probably what you're seeing but why it's dependent on the type of DB info generated is puzzling. Perhaps the setting to choose that DB format is equivalen to no debugging in terms of the resultant optimizer settings?
There is a mismatch between the C++ and FORTRAN expectations as to whether or not FP exceptions are enabled. It gets worse when you are writing FORTRAN libraries than can be called with either setting. We used the "safe" setting for fp speculation to get around it.
The code in our case was a tight loop doing conditional assignment with an explicit division in the RHS, conditional on the divisor being not-too-close-to-zero. This was being compiled as an SSE2 vector sequence using and/or masking logic to overwrite the result of the division with the "else" case value (a simple array lookup) in the register before writing the result back to the array. Nice pretty branch-free vector code but not semantically equivalent to the source when FP exceptions are enabled.
That's probably what you're seeing but why it's dependent on the type of DB info generated is puzzling. Perhaps the setting to choose that DB format is equivalen to no debugging in terms of the resultant optimizer settings?
Quoting - ylmz
The following command line is for Visual Fortran compiler:
/nologo /Oy- /Qparallel /assume:buffered_io /include:".Release2/" /DRELEASE_EXTERNAL /DNDEBUG /DDEBUG_CPU /DCOMPILER_IS_IVF /assume:nocc_omp /extend_source:132 /fpscomp:ioformat /fpscomp:logicals /warn:errors /stand:f90 /warn:declarations /warn:unused /warn:truncated_source /warn:interfaces /Qsave /align:commons /align:sequence /Qzero /fpe:0 /names:as_is /iface:cvf /module:".Release2ForLib/" /object:".Release2ForLib/" /traceback /check:format /check:output_conversion /libs:dll /threads /c
Unless you know you have a need for these, reset to the defaults these: /fpe:0, /Qsave, /Qzero, /fpscomp:ioformat, /fpscomp:logicals, /iface:cvf
I VERY strongly recommend against using /names:as_is. That has no bearing on the problem at hand, but why is it there?
What does your declaration of the Fortran routine on the C++ side look like? I'm going to guess that you're corrupting the stack because of a C-STDCALL mismatch. Removing /iface:cvf could be a test of that.
The IEEE_HANDLER can catch an Invalid Operation if the IEEE_FLAG has been set. Shouldn't Traceback kick in and identify the module and other gory details in which the exception is flagged?, it not always being where you think is.
Gerry
Gerry
Quoting - ylmz
Hi Jim;
x is INTEGER(2)
y is REAL(4)
t is INTEGER(2)
p is REAL(4)
x is INTEGER(2)
y is REAL(4)
t is INTEGER(2)
p is REAL(4)
You might find this faster:
[cpp]check = .true.
if (x .gt. 0 .and. y .gt. 0.0_4) then
if(t/x .lt. 2) then
check =((REAL(t)/REAL(x) .gt. p/y)
endif
endif
------------------------------------[/cpp]
Jim
Oops I ment
[cpp]check = .true.
if (x .gt. 0) then
if(y .gt. 0.0_4) then
if(t/x .lt. 2) then
check =((REAL(t)/REAL(x) .gt. p/y)
endif
endif
endif
[/cpp]
Fortran evaluates all terms of the (expr .and. expr) as opposed to C/C++ breaking out in the middle of the evaluation.
The above code reduces the number of tests and conversions from integer to real
Jim
Gerry;
Actually wedisabled the associated exception bit in the control register and
traced the problem ourselves by checking the status register after almost
every block. We detected the problemat the same place. But the most interesting pointis,
when we put an additional line of code just above to the line where we are getting the error,
the problem disappears.
( this additional line may be even completely irrelevant,
for example: write (1, *) 'zzz' )
Actually wedisabled the associated exception bit in the control register and
traced the problem ourselves by checking the status register after almost
every block. We detected the problemat the same place. But the most interesting pointis,
when we put an additional line of code just above to the line where we are getting the error,
the problem disappears.
( this additional line may be even completely irrelevant,
for example: write (1, *) 'zzz' )
Quoting - ylmz
Gerry;
Actually wedisabled the associated exception bit in the control register and
traced the problem ourselves by checking the status register after almost
every block. We detected the problemat the same place. But the most interesting pointis,
when we put an additional line of code just above to the line where we are getting the error,
the problem disappears.
( this additional line may be even completely irrelevant,
for example: write (1, *) 'zzz' )
Actually wedisabled the associated exception bit in the control register and
traced the problem ourselves by checking the status register after almost
every block. We detected the problemat the same place. But the most interesting pointis,
when we put an additional line of code just above to the line where we are getting the error,
the problem disappears.
( this additional line may be even completely irrelevant,
for example: write (1, *) 'zzz' )
Hi Jim;
I tried what you proposed. But still I'm getting the error. I guess the error is not specific to this line, because the numbers at that point are even not close to zero. Can it be something related to floating point stack, etc. ?
I changed some compiler options, and now I geta completely differenterror:
"access violationREADING location 0x..." (and sometimes, "access violation WRITING location 0x...")
Here is the line where it occurs:
stddev_x = MAX(stddev_y, SQRT(stddev_x / MAX(icount, 1_2)))
Now in the code on this line, there is neither an explicit read nor write ata specific memory location.
Doesthe problem occurmaybe because parameters to functions SQRT and MAX cannot be passed correctly ?
Corrupted stack etc. ?
"access violationREADING location 0x..." (and sometimes, "access violation WRITING location 0x...")
Here is the line where it occurs:
stddev_x = MAX(stddev_y, SQRT(stddev_x / MAX(icount, 1_2)))
Now in the code on this line, there is neither an explicit read nor write ata specific memory location.
Doesthe problem occurmaybe because parameters to functions SQRT and MAX cannot be passed correctly ?
Corrupted stack etc. ?
In this context "read" and "write" mean get data from memory and put data into memory.
This kind of error is often associated with exceeding an array bounds, and/or uninitialised variables.
For a start I would suggest you look at Project->Properties->Fortran-> Run time-> Run time Error Checkingand turn on the checks for array and string bounds, and uninitialised variables.
If this does not throw up any problems then you may be reduced to printing out values at various stages of the program. Howeveradding write statements to code often has the effect of moving these "access violation"problems to somewhere else :-( This is known as a Heisenbug.
Les
