Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
367 Views

Routine maintenance broke everything

Jump to solution

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

0 Kudos

Accepted Solutions
Highlighted
Black Belt Retired Employee
318 Views

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.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran

View solution in original post

0 Kudos
17 Replies
Highlighted
Black Belt Retired Employee
359 Views

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.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor I
325 Views

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

0 Kudos
Highlighted
Black Belt Retired Employee
319 Views

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.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran

View solution in original post

0 Kudos
Highlighted
Moderator
309 Views

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.

0 Kudos
Highlighted
New Contributor I
277 Views

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

0 Kudos
Highlighted
New Contributor I
233 Views

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

0 Kudos
Highlighted
Moderator
211 Views

I'll open a bug report for this. 

0 Kudos
Highlighted
Valued Contributor III
200 Views

@Ronald_G_Intel ,

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}

0 Kudos
Highlighted
New Contributor III
197 Views

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?

0 Kudos
Highlighted
Black Belt Retired Employee
190 Views

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

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Moderator
184 Views

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

0 Kudos
Highlighted
Black Belt
168 Views

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

Highlighted
New Contributor III
151 Views

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.

0 Kudos
Highlighted
Valued Contributor III
141 Views
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

 

@Ronald_G_Intel ,

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,

0 Kudos
Highlighted
Moderator
128 Views

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.

0 Kudos
Highlighted
Black Belt Retired Employee
121 Views

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

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Valued Contributor III
119 Views
..  So yes, I'll add the note about generating a warning for the Standard violation.

 

@Ronald_G_Intel ,

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,

0 Kudos