EOSHIFT generates catastrophic error - Please report...

[martenjan]

Hi all,

The following procedure produces a catastrophic error in a rather large software package:

[fortran]    subroutine testmee
    integer(4) i
      real(8) testvector(20)
      real(8) testvector2(20)
      do i=1,20
        testvector(i) = dsin(dble(i))
      end do
      testvector2 = eoshift(testvector,4)
      print *, testvector(3)
    end subroutine testmee[/fortran]

The error is:

9>0_12459
9>: catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
9>compilation aborted for D:\\SVN\\file.f90 (code 1)

I cannot isolate the precise cause of the error, but have this information:

• After changing eoshift into cshift, the program compiles fine.
• There is no other eoshift routine defined somewhere else in my code
• Moving the subroutine into another module fixes the issue for the current module, but the compiler chokes on the other module that now contains the testmee subroutine. This allows me to move the testmee routine to the very first module to be compiled.
• Putting the code in a stand-alone testing program compiles fine
• The code works fine after replacing the line containing eoshift by

[fortran]      testvector2 = 0d0
      testvector2(1:16) = testvector(5:20)
[/fortran]

I use Visual Studio 2010 Professional, with Intel Visual Fortran, package ID w_fcompxe_2011.8.278

Do you have any advice on how to isolate the cause? Is it possible to coax the compiler into giving more relevant information?

Regards,

Marten Jan

[mecej4]

The compiler should give a pertinent error message instead of crashing. However, note the following:

The intrinsic functions cshift and eoshift take integer arguments.

Unlike what one may have expected from and seen in old Fortran code, performing operations on operands of the wrong type will usually result in run-time errors.

[Steven_L_Intel1]

The first argument to EOSHIFT can be of any type. This is an array element shifting operation, not bit shifting.

I can't reproduce a problem with just that subroutine. Can you provide us a complete source (and the source to any USE or INCLUDE files needed) and show us the compile options used?

[martenjan]

It is the same for me. I cannot reproduce the problem with just that subroutine too. Yet, the compiler returns the catastrophic error for the complete source consistently. I am not allowed to provide you the source, sorry. I already managed to isolate the problem to the eoshift, and have the compilation fail on my provided subroutine.

I assume the compiler options are given in the command line generated by Visual Studio:

/nologo /debug:full /Od /assume:buffered_io /fpp /DIFORT /stand:f90 /warn:all /debug-parameters:used /fp:strict /Qfp-speculation=off /module:"DebugBuffered\" /object:"DebugBuffered\" /Fd"DebugBuffered\vc100.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /libs:static /threads /dbglibs /c

The only non-standard thing on this line is the definition of the IFORT variable, which I use to indicate that I am using the Intel Fortran compiler. Using the g95 compiler under linux, the compilation runs fine.

I attempted the following:

• Clean the project by right-clicking the project and selecting
• Add a new module testeoshift

  [fortran]module testeofshift
  
  contains
  
      subroutine testmee
      integer(4) i
        real(8) testvector(20)
        real(8) testvector2(20)
        do i=1,20
          testvector(i) = dsin(dble(i))
        end do
        testvector2 = eoshift(testvector,4)
        !testvector2 = cshift(testvector,4)
        !testvector2 = 0d0
        !testvector2(1:16) = testvector(5:20)
        print *, testvector(3)
      end subroutine testmee
  
  end module testeofshift[/fortran]

• Compile the unit by right-clicking the new module and selecting 'compile' results in:

  [plain]------ Build started: Project:my_project, Configuration: DebugBuffered|Win32 ------
  
  Compiling with Intel Visual Fortran Compiler XE 12.1.2.278 [IA-32]...
  new.f90
  0_12459
  : catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
  compilation aborted for D:SVNmy_sourcenew.f90 (code 1)
  
  Build log written to  "file://D:SVNmy_sourceDebugBufferedBuildLog.htm"
  my_project - 1 error(s), 0 warning(s)
  
  
  ---------------------- Done ----------------------[/plain]

• Adding the existing file to another project, right-clicking and compiling it goes fine. Modifying compiler options one by one to match the failing project's properties does not break the compilation.

[martenjan]

I have found a culprit:

Compiling the testeoshift module with the option /fp:strict generates the catastrophic error.
Compiling with /fp:precise /fp:except works, hence I suspect the problem is in the disabled contractions or the enabled pragma stdc fenv_access.

regards,

Marten Jan

[Steven_L_Intel1]

Thank you! I can reproduce the problem and will let the developers know. The issue ID is DPD200178252.

[Steven_L_Intel1]

The developers have fixed this problem for a future release.