Internal compiler error

[mic_esp96]

Hello,

Linked to this thread, the compilation of the file attached, using ifort: Version 2021.7.1 Build 20221019_000000 produces a compiler error.

The problem is specific to procedures `allocI_()` and `allocR_()`.

Not sure if this is valid Modern Fortran or not. However, I post this following @Steve_Lionel suggestion.

Cheers,

Michele

[Barbara_P_Intel]

I duplicated the ICE with the current ifort release, 2021.8.0, and with ifx 2023.0.0.

I'll investigate this a bit. I suspect I can pare this reproducer down a bit. The compiler developers like the minimum amount of code that reproduces the issue.

[FortranFan]

---

@Barbara_P_Intel wrote:

I duplicated the ICE with the current ifort release, 2021.8.0, and with ifx 2023.0.0.

I'll investigate this a bit. I suspect I can pare this reproducer down a bit. The compiler developers like the minimum amount of code that reproduces the issue.

---

@Barbara_P_Intel ,

Given your comment, "The compiler developers like the minimum amount of code that reproduces the issue," you may want to consider the following?

   subroutine a( x )
      integer, allocatable :: x(..)
      call b( sizeof(x) )
   end subroutine

• IFORT

C:\temp>ifort /c /standard-semantics a.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

a.f90(3): 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 a.f90 (code 1)

• IFX

C:\temp>ifx /c /standard-semantics a.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.0.0 Build 20221201
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

 #0 0x00007ff69b4bf1d5 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2ff1d5)
 #1 0x00007ff69b4bf1aa (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2ff1aa)
 #2 0x00007ff69b4c14de (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x3014de)
 #3 0x00007ff69b4c15c7 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x3015c7)
 #4 0x00007ff69b4c9df5 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x309df5)
 #5 0x00007ff69b4c5cde (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x305cde)
 #6 0x00007ff69b486335 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2c6335)
 #7 0x00007ff69b43ea28 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x27ea28)
 #8 0x00007ff69b435416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x275416)
 #9 0x00007ff69b4335ce (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2735ce)
#10 0x00007ff69b4329bd (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2729bd)
#11 0x00007ff69b510416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
#12 0x00007ff69b51096d (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x35096d)
#13 0x00007ff69b512f16 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x352f16)
#14 0x00007ff69b510416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
#15 0x00007ff69b50d2cd (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x34d2cd)
#16 0x00007ff69b510416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
#17 0x00007ff69b38dd7a (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1cdd7a)
#18 0x00007ff69b38d7ca (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1cd7ca)
#19 0x00007ff69b573472 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x3b3472)
#20 0x00007ff69d9fe940 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x283e940)
#21 0x00007ffff5117614 (C:\WINDOWS\System32\KERNEL32.DLL+0x17614)
#22 0x00007ffff65e26a1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x526a1)

a.f90(3): error #5623: **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.
      call b( sizeof(x) )
--------------^
compilation aborted for a.f90 (code 3)

[Barbara_P_Intel]

@FortranFan  Thank you! This helps, too, with creating a complete reproducer that can be run to confirm the fix.

[FortranFan]

@Barbara_P_Intel ,

Re: "creating a complete reproducer that can be run to confirm the fix," here's a simple place to start:

   use, intrinsic :: iso_c_binding, only : c_int, c_sizeof, c_size_t
   integer(c_int), allocatable :: n
   n = 42
   call s1( n )
   call s2( n )
contains
   subroutine s1( x )
      integer(c_int), intent(in) :: x(..)
      call out( c_sizeof(x) )
   end subroutine
   subroutine s2( x )
      integer(c_int), allocatable, intent(in) :: x(..)
      call out( sizeof(x) )
   end subroutine
   subroutine out( sz )
      integer(c_size_t), intent(in) :: sz
      print *, sz
   end subroutine
end  

• gfortran

C:\temp>gfortran p.f90 -o p.exe

C:\temp>q.exe
                    4
                    4

• IFORT

C:\temp>ifort /standard-semantics p.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

p.f90(13): 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 p.f90 (code 1)

[Barbara_P_Intel]

Thank you! We've got the complete reproducer under control now! 

[Barbara_P_Intel]

I filed a bug for you, CMPLRIL0-35116. I'll keep this thread posted on its progress to a fix.

[Barbara_P_Intel]

@mic_esp96, the compiler engineer requests a complete reproducer. She wants to verify that when the ICE is fixed the answers are correct.

Can you do provide that?

I narrowed the problem down to this reproducer. Do you have a way to just test that module? I know it's tough when you can't compile the module.

[mic_esp96]

Dear @Barbara_P_Intel , that's exactly the source of the problem, and the reason of the post.

Using `sizeof(var)`, var being a deferred rank allocatable, causes the ICE. And, I do understand the reasons why of that ICE. As well, I hope my intensions are clear to a similar degree. Of course, one has to know the actual implementation in order to have a full picture of the issue.

I had post the same question in the Fortran Discourse , and experts there correctly pointed out that for it to compile, the line causing the ICE (when using sizeof() intrinsic) has to be moved WITHIN the select rank construct. Of course, in this way the compiler knows at compile time its rank, before thus calling the sizeof().

I am providing the file "allocator_my_narrrow.f90" where this is implemented, in a narrowed but more complete example, and even using sizeof(), it compiles successfully.

I do remain at disposal for any other possible question/clarification.

[Barbara_P_Intel]

Thank you for your help. I'll ask if there are more questions.

[mic_esp96]

@Barbara_P_Intel more than welcome.

In the meantime, thinking about it, I now realise that I had already a solution for doing what I wanted to do back then, which comes to my mind just now.

Attached a patched version of the previous code, which has a slight modification (at the line causing the ICE in the very first version), where I call a "trick" function to do what I wanted to do with `sizeof(var)` (causing the ICE):

pure integer(kind =   function sizeof__(sizeoftype, dims) result(nbytes)
   integer(kind = 8), intent(in) :: sizeoftype
   integer, intent(in) :: dims(..)
   select rank (dims)
      rank (0)
         nbytes = sizeoftype * dims
      rank (1)
         nbytes = sizeoftype * product(dims)
      rank default
         nbytes = -1
   end select
end function

Then, in the `allocI_()` routine, changing the previous (erroneous) line 

call allocOKMsg_(name, loc(var), sizeof(var))

with

call allocOKMsg_(name, loc(var), sizeof__(sizeof(int(1)), dims))

In any case, floor to the engineers on how to handle and fix this ICE.

Kindly,

Michele

[Barbara_P_Intel]

This ICE is gone with the latest compiler that was released this week as part of oneAPI HPC Toolkit 2023.1. Please try it!

And THANK YOU again to all responded on this thread to narrow down the scope of the issue.