Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Internal compiler error

mic_esp96
New Contributor I
1,356 Views

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

 

Labels (1)
11 Replies
Barbara_P_Intel
Moderator
1,255 Views

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.

 

 

0 Kudos
FortranFan
Honored Contributor II
1,077 Views

@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
Moderator
1,043 Views

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

 

0 Kudos
FortranFan
Honored Contributor II
1,031 Views

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

 

0 Kudos
Barbara_P_Intel
Moderator
1,027 Views

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

0 Kudos
Barbara_P_Intel
Moderator
1,250 Views

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



Barbara_P_Intel
Moderator
1,161 Views

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

 

 

 

0 Kudos
mic_esp96
New Contributor I
1,133 Views

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.

0 Kudos
Barbara_P_Intel
Moderator
1,115 Views

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



0 Kudos
mic_esp96
New Contributor I
1,094 Views

@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

 

 

0 Kudos
Barbara_P_Intel
Moderator
745 Views

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.


0 Kudos
Reply