- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I just updated from the 2017 Update 4 Intel Fortran Compiler to the 2018 one (18.0.0.124) and am now getting a bunch of these messages:
fortcom: Fatal: There has been an internal compiler error (C0000005).
I narrowed down the problem to the EQUIVALENCE-Statement, which our legacy code still uses. I made a minimal working example, which produces the error:
SUBROUTINE Test() INTEGER IWERT REAL RWERT EQUIVALENCE (IWERT,RWERT) ENDSUBROUTINE
The original is in fixed-form, but the problem also occurs with free-form. The buildlog says:
Compiling with Intel(R) Visual Fortran Compiler 18.0.0.124 [IA-32]... ifort /nologo /debug:full /Od /I"C:\sw\tre\Rukon Git\Output\Modules_Debug" /I"C:\sw\tre\Rukon Git\Module\Debug" /DDEBUG /warn:all /align:commons /assume:byterecl /Qtrapuv /Qfp-stack-check /iface:cvf /module:"C:\sw\tre\Rukon Git\Output\Modules_Debug" /object:"Debug\\" /Fd"Debug\vc140.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:stack /libs:dll /threads /dbglibs /c /fltconsistency /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin" /Qm32 "C:\sw\tre\Rukon Git\1da\Source1.f90" C:\sw\tre\Rukon Git\1da\Source1.f90(2): remark #7712: This variable has not been used. [IWERT] INTEGER IWERT -------------^ C:\sw\tre\Rukon Git\1da\Source1.f90(3): remark #7712: This variable has not been used. [RWERT] REAL RWERT -------------^ fortcom: Fatal: There has been an internal compiler error (C0000005). compilation aborted for C:\sw\tre\Rukon Git\1da\Source1.f90 (code 1) 1da - 1 error(s), 0 warning(s)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Tim R.,
It's alright to view all "internal compiler errors" as definitive compiler bugs and report them to Intel. Note Intel now expects you to submit an incident on all their product-related issues at their Online Service Center (OSC):
https://supporttickets.intel.com/?lang=en-US
I suggest you do so to bring this to the attention of the Intel Fortran team.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can reproduce this failure with the 18.0.0 release, and it's related to the Qtrapuv switch.
If you remove that switch, you should be able to build.
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had tried for years to get /Qtrapuv "deprecated", since it serves no useful function. Well, maybe it does - it had been responsible for quite a few ICEs during my time at Intel. I don't know why it persists. In any case, it doesn't do what you think it does and I recommend avoiding it. Use /Qinit:snan instead.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Alas, in this case, Qinit:snan won't help either
Qtrapuv enables Qinit:snan (among other things) and it is, unfortunately, the support for Qinit that is having problems with EQUIVALENCE.
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hah!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I committed the bug as ticket 03084037.
Thank you for the quick analysis of the problem! Since I tested the new Compiler on my development machine, I already uninstalled the new and reinstalled the old compiler. Guess we will wait until the problem is fixed, even though we only use that option in debug mode.
Steve Lionel (Ret.) wrote:
I had tried for years to get /Qtrapuv "deprecated", since it serves no useful function. Well, maybe it does - it had been responsible for quite a few ICEs during my time at Intel. I don't know why it persists. In any case, it doesn't do what you think it does and I recommend avoiding it. Use /Qinit:snan instead.
I would expect that switch to e.g. set integers to random values - I'm curious about how it does not do what I think it does?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the past, /Qtrapuv set some stack local variables to a fixed "unusual" value, not random and one that is unlikely to trigger exceptions. It also disables some optimizations. I see that it now, as Lorri says, implies /Qinit:snan, which is an improvement as far as FP values are concerned. Originally, the description of this option said that it set floating point values to a sNaN, which it never did.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page