Routine maintenance broke everything

[Norman_K_]

While doing some routine maintenance I got

1>MIRI.f90
1>04010002_1543
1>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.

I have tried to unwind the updates and to my intense frustration this error persists

Is there any hint in "04010002_1543" which tells me what to look for?

Windows 10, Compiling with Intel(R) Visual Fortran Compiler 19.1.2.254 [Intel(R) 64]... in Microsoft Visual Studio Community 2019 Version 16.7.2

I was refactoring to reduce the possibility of name clashes!

Thanks in advance

N

[Steve_Lionel]

That code comes from the optimization phase - more than that I can't tell you. You can experiment with different compiler options, reducing the ones you use until you find one that triggers the error. My guess is that it isn't related to the compiler updates.

[Norman_K_]

Dear Steve,

Thanks, it is useful to know that I may not be looking for a simple typo - the absence of a line number, but the presence of a warning that it may not be accurate anyway, was worrying me.

Can a change in use association cause this sort of problem?

I will look at the compiler options to seek clues.

Thanks

Norman

[Steve_Lionel · Accepted solution]

Anything that changes the program can potentially trigger a difference in optimization. What I do in such situations is copy the entire command line used and verify that I can reproduce the error from a command prompt. I then remove one option at a time, skipping initially those that change the meaning of the program (/names, /iface, /assume, etc.). Once I get it down to a minimal set, then I'll start removing other options until I find one that, if present, triggers the error and if absent, doesn't - assuming there is such an option. (There isn't always.)

If I get that far, I start commenting out bits of the source to see if I can identify a particular construct that triggers the problem. The goal is to end up with the shortest source file and the fewest options that reproduce the problem. This will sometimes give me a clue as to a modification I can make to work around the issue while the bug (and such an error from the compiler is ALWAYS a bug) gets fixed. I'll then send the minimal reproducer AND the full test case to support.

[Ron_Green]

I can get a bug report for this if you can zip up enough code for me to reproduce the error.  Maybe clean the project, zip up the whole directory, and share it.  Assuming you can share the code.  If you have a Premier account you can open an issue that is private to Intel.   If you post it here it's public.

[Norman_K_]

Thanks for your message

I have now isolated the problem to a few lines of code in one module, but I cannot (have not) reproduce the problem in a simple example.

I am reluctant to inflict the full (300 k lines in 350 modules) code on Intel just yet

More anon

Thanks again,

Norman

[Norman_K_]

Dear All,

Grant application written & submitted, back to this... - I now have example code as follows

module MOD_A
implicit none; private
public MOD_A_sub
integer, public :: my_dim = 1

interface
    module subroutine MOD_A_sub()
    end subroutine MOD_A_sub
end interface

end module MOD_A

submodule(MOD_A) MOD_A_subm
implicit none
real :: array(my_dim)

contains

module subroutine MOD_A_sub()
implicit none

array = 0.
print *, 'Hello'
end subroutine MOD_A_sub

end submodule MOD_A_subm

!------ Build started: Project: test_crash, Configuration: Debug Win32 ------
!1>Compiling with Intel(R) Visual Fortran Compiler 19.1.1.216 [IA-32]...
!1>MOD_A.f90
!1>04010002_1543
!1>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.
!1>compilation aborted for C:\Users\ces1nk\Dropbox\Shuttlebackup\Dept\Research\Programs\Test\test_crash\test_crash\MOD_A.f90 (code 1)
!1>test_crash.f90
!1>
!1>Build log written to  "file://C:\Users\ces1nk\Dropbox\Shuttlebackup\Dept\Research\Programs\Test\test_crash\test_crash\Debug\BuildLog.htm"
!1>test_crash - 1 error(s), 0 warning(s)
!========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I know this code is wrong

The compiler knows this code is wrong

The only difference is I can tell you where and why it is wrong.

BW, & stay safe

Norman

[Ron_Green]

I'll open a bug report for this. 

[FortranFan]

@Ron_Green ,

For whatever it's worth, version 19.1.2.254 on Windows Intel (R) 64 target compiled the smaller reproducer upthread without issuing an ICE.  I tried /Ox with x= {0,1,2,3}

[Johannes_Rieke]

Maybe you can enlighten us and point to the wrong part. gfortran 10.0.2 at least says:

    15 | real :: array(my_dim)
       |                     1
ERROR: Explicit shaped array with nonconstant bounds at (1)

Adding the PARAMETER attribute to

integer, public :: my_dim=1
-->
integer, parameter, public :: my_dim=1

compiles with gfortran.

Is the code nonconforming to the standard or is gfortran wrong here? Why is 19.1 compiling?

[Steve_Lionel]

An internal compiler error is not the compiler complaining about your code. 

[Ron_Green]

This one is interesting - and the report that it IS compiling on Windows makes sense from the debug info I'm seeing.  Seems to be in the ELF code generation, which would not apply to Windows. 

Bug ID CMPLRIL0-33245

[FortranFan]

This one is interesting - and the report that it IS compiling on Windows makes sense from the debug info I'm seeing.  Seems to be in the ELF code generation, which would not apply to Windows. 

Bug ID CMPLRIL0-33245

@Ron_Green ,

Sorry I wasn't completely clear, I meant to indicate that it is rather surprising to find v19.1.2.254 of Intel compiler on Windows process the code without issuing any diagnostic, for the smaller reproducer by OP is in violation of constraint C831 in section 8.5.8.2 of the Fortran standard which states:

1 C831 (R816) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subpro-
2             gram, derived type definition, BLOCK construct, or interface body.

Will this Bug ID cover this root issue as well?

Thanks,

[Ron_Green]

I did my testing on Linux and mac with -O0.  I asked a colleague to test on Windows.  It was found that debug config gets the ICE and Release does not ICE and no error message.  Retesting on mac and linux I also found -O2 passes this code silently.  So yes, I'll add the note about generating a warning for the Standard violation.

[Steve_Lionel]

This one should be an error - there's no valid interpretation of that line, as Ian says.

[FortranFan]

..  So yes, I'll add the note about generating a warning for the Standard violation.

@Ron_Green ,

Thanks but please note for this violation, given it's with respect to a constraint in the standard, generating an error from the compiler may serve Intel Fortran customers better than a warning.  It will be useful if you (perhaps in consultation with your Fortran team) can consider an error response over a warning.

Thanks,

[IanH]

---

@Johannes_Rieke wrote:

Maybe you can enlighten us and point to the wrong part. gfortran 10.0.2 at least says:

    15 | real :: array(my_dim)
       |                     1
ERROR: Explicit shaped array with nonconstant bounds at (1)

Adding the PARAMETER attribute to

integer, public :: my_dim=1
-->
integer, parameter, public :: my_dim=1

compiles with gfortran.

Is the code nonconforming to the standard or is gfortran wrong here? Why is 19.1 compiling?

---

It is nonconforming, and doesn't make conceptual sense - so this isn't an extension.  You can't have an automatic object (`array`) directly in the specification part of a submodule - the value of `my_dim` can change - so when in the lifetime of the program does its value actually specify the shape of `array`?  Compilation without a diagnostic when the compiler is trying to be standard compliant is [also] a compiler bug [beyond any compiler internal errors] - the requirement for the bounds to be specified by constant expression is a constraint (F2018 C831).

There may be a link between the conceptual problem that apparently successful compilation blunders into, and the trouble that the optimiser/code generator subsequently experiences.

[Johannes_Rieke]

Thanks Ian for clarification, which I can follow and makes sense for me.

So ifort (19.1.x) is wrong here and should throw a compile time error instead of compiling? Further, gfortran is correctly giving the error then.

[Barbara_P_Intel]

This internal compiler error (ICE) is now fixed. AND there's an error message diagnosing the problem in the developer's code.

+ ifort -c -what repro.f90
 Intel(R) Fortran 2021.4.0-2742
repro.f90(15): error #8971: An automatic object must not appear in the specification part of a submodule.   [ARRAY]
real :: array(my_dim)
--------^
compilation aborted for repro.f90 (code 1)

Please try the current compiler release, 2021.4.0, and confirm. It's part of the oneAPI HPC Toolkit.