Internal compiler error with EQUIVALENCE-Statements and Intel Fortran 2018

[Tim_R_]

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)

[FortranFan]

@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.

[Lorri_M_Intel]

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

[Steve_Lionel]

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.

[Lorri_M_Intel]

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

[Steve_Lionel]

Hah!

[Tim_R_]

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?

[Steve_Lionel]

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.