링크가 복사됨
The forum is where we want you to report issues if you don't want to (or don't have access to) Intel Premier Support. Many times it's beneficial to have the problem description seen by the community - other users can offer advice and experience, and the solution, once found, is available for others to read.
We do have a "bug reporting centre" - Intel Premier Support - but you need to have a current support license to use it. That's one of the benefits of buying ongoing support (the other is having access to product updates.)
/Qtrapuv, theoretically, is what you want. The original specification was that it would store a signaling NaN. But when it was implemented, the value it stores is not one that triggers an exception - it's just an unusual but normal floating point value. This is a bit of a thorn in my side - I have requested that either the implementation be changed to do what it was supposed to do, or be removed, as it continues to trip up users such as yourself. I will point out that even if it did work, it would only solve part of the general problem, since non-REAL values have no corresponding NaN that can be used.
Static Analysis is a very useful feature that goes far beyond what "uninitialized floating point variable" can do, though it is not a complete solution by any means. It does find more kinds of errors than you saw in earlier compilers.
Let me show you a quick example. I tried the following program:
[fortran]
call sub
end
subroutine sub
real xx
call sub2(xx)
print *, xx
end
subroutine sub2 (x)
real, intent(in) :: x
print *, x
end
[/fortran]
There are two opportunities to catch an error here - one is the use of the uninitialized x in "sub" after the call, and one inside sub2. Static Analysis finds them both:
(The line numbers don't match because I took out some irrelevant lines when pasting above). Note that for the reference inside sub2, you get the call chain. I have seen this catch uninitialized integers four levels up a call chain - try that with something like /Qtrapuv!
(The line numbers don't match because I took out some irrelevant lines when pasting above). Note that for the reference inside sub2, you get the call chain. I have seen this catch uninitialized integers four levels up a call chain - try that with something like /Qtrapuv!
