IFX: LLVM ERROR: SmallVector unable to grow.

[IVV]

I'm trying to build a library for the release configuration on windows using ifx.

One file always causes the compiler to crash reporting this:

Compiling with Intel® Fortran Compiler 2025.3.2 [Intel(R) 64]...
V3MatIO.F90
LLVM ERROR: SmallVector unable to grow. Requested capacity (18446744073709551615) is larger than maximum value for size type (4294967295)
#0 0x00007ff67f32662a (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x1a4662a)
#1 0x00007ff67f326695 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x1a46695)
#2 0x00007ff67ece06cf (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x14006cf)
#3 0x00007ff67ec6d32c (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x138d32c)
#4 0x00007ff67ee26414 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x1546414)
#5 0x00007ff67ed31594 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x1451594)
#6 0x00007ff67e7a0d0d (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0xec0d0d)
#7 0x00007ff67e8f2f5d (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x1012f5d)
#8 0x00007ff67e8e97ba (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x10097ba)
#9 0x00007ff67da9868b (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x1b868b)
#10 0x00007ff67ea80b83 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x11a0b83)
#11 0x00007ff67dc49c6b (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x369c6b)
#12 0x00007ff67de4b6fb (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x56b6fb)
#13 0x00007ff67de4b011 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x56b011)
#14 0x00007ff67df1166d (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x63166d)
#15 0x00007ff67df11084 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x631084)
#16 0x00007ff67df10de1 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x630de1)
#17 0x00007ff67df1166d (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x63166d)
#18 0x00007ff67f28425c (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x19a425c)
#19 0x00007ff67f282b42 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x19a2b42)
#20 0x00007ff67efe026b (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x170026b)
#21 0x00007ff67e05a593 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x77a593)
#22 0x00007ff67ecdb600 (C:\PROGRA~2\Intel\oneAPI\compiler\2025.3\bin\compiler\xfortcom.exe+0x13fb600)
#23 0x00007ff964d1e8d7 (C:\WINDOWS\System32\KERNEL32.DLL+0x2e8d7)
#24 0x00007ff965fcc53c (C:\WINDOWS\SYSTEM32\ntdll.dll+0x8c53c)
C:\Users\obe\AppData\Local\Temp\301646.i90: error #5629: **Internal compiler error: abort signal raised** 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 C:\Development\ivv\T3.Venus\IVV.VENUS\IVV.VENUS.Matrix.Native\V3Mat\V3MatIO.F90 (code 3)

The comiler is invoked using this statement:

ifx /nologo /O2 /assume:buffered_io /fpp /DUSEZLIB /Dx64 /warn:all /align:rec2byte /align:commons /align:sequence /Qinit:zero /module:"x64\Release\\" /object:"x64\Release\\" /libs:static /threads /c /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64" /Qm64 "C:\Development\ivv\T3.Venus\IVV.VENUS\IVV.VENUS.Matrix.Native\V3Mat\V3MatIO.F90"

The debug configuration compiles fine. If I disable optimization (/Od instead of /O2), the release configuration compiles as well.

System: Windows 11 Pro (25H2)

Compiler: Intel Fortran Essentials 2025.3.2

[Stef67]

I am facing the same problem. I am honestly quite surprised no one from Intel answered your question? Is there anybody out there?

[JohnNichols]

There is just not enough information to help.  Supply a simple Fortran file that can be tested.  

Is my simple suggestion, plus this board has been quiet for months.  

[JohnNichols]

My apologies I missed the file I will try it.  

[JohnNichols]

I tried it, it threw 31 errors, but you could set it up with all the bells and whistles and zip file it, it is asking for things I cannot find in your file. 

[witwald]

The error message includes:

Requested capacity (18446744073709551615) is larger than maximum value for size type (4294967295)

 @IVV In case it helps, the number 18446744073709551615 = 2^64 - 1, while the number 4294967295 = 2^32 - 1. You could try commenting out large sections of the Fortran code to try and isolate which area is causing the issue. The code appears to use recursive functions, so maybe one of those is the cause of the issue.

[witwald]

@IVV If we are to try and test this on our own systems to try and help, then the full suite of source code should be supplied, if that is at all possible.

[andrew_4619]

An internal compiler error (ICE) is a compiler bug, even with bad source it should not crash. You note to post source that reproduces the problem, the source posted seems to have a load of other dependencies.  Your evaluation suggests it is optimisation that triggers the error but I would strip out those align and qinit options one a t a time to see if those are part of the trigger. 

[Stef67]

We found the root cause on our side.

In a call like:

CALL SubA(obj, SubB, unit, ierr)

the second argument was intended to be the name of the calling routine, so it should have been passed as a character literal:

CALL SubA(obj, "SubB", unit, ierr)

Without the quotation marks, SubB is interpreted as an identifier (a procedure name) instead of a string. After adding the quotes, the Release build with IFX succeeds.

That said, IFX 2025.3.2 (Release configuration) was not issuing a diagnostic for this invalid argument and instead failed with:

LLVM ERROR: SmallVector unable to grow

For reference, IFORT compiled the same source without complaint.

So while the source was incorrect, this still appears to be a robustness issue in IFX, since an invalid argument should normally produce a clear compiler error rather than an internal compiler failure.

[JohnNichols]

I am glad you found and reported the error. At least this site will attempt to answer your questions, you should try some of the other sites I am on.

If you want to know pain, try Microsoft Fortran PowerStation that is a grandfather to IFX, then you knew true pain. 

If you want lousy error messages, try AutoCAD DXF reader, sorry, there are no message, one has to search in the DXF file. And only VEDIT will open such a file, many years of personal experience.  VEDIT is the best as it shows crud in files no other editor does not.  

MSVS this morning has been filling in my output statements, it is like it thinks faster than I can, right it can.  

This should be zero if all bytes are accounted for! ::

This is the correct message, MSVS got it in a millisecond, I had to read it. 

So good work and splice the main brace.

[andrew_4619]

did you have an explicit interface or the check interfaces option? The compiler might not otherwise be able to see the interface error.

[Igor_V_Intel]

I have tried to create a simple reproducer, but it did NOT trigger the LLVM crash, e.g.

module V3MatType
  implicit none
  type :: T_MATRIX
    integer :: iODCount
    integer :: iFlags
    integer :: hWnd
  end type T_MATRIX
  integer, parameter :: gc_FlagOrigin = 1
end module V3MatType

module V3Mat
  use V3MatType
  implicit none

contains
  logical function Init(pMat, size, flags)
    type(T_MATRIX), pointer :: pMat
    integer, intent(in) :: size, flags
    Init = .true.
  end function
  subroutine V3RaiseStatus(hWnd, msg)
    integer, intent(in) :: hWnd
    character(len=*), intent(in) :: msg
    print *, msg
  end subroutine
end module V3Mat

module V3MatIO
  use V3MatType
  use V3Mat
  implicit none
contains
  ! External function that expects a string for the caller name
  logical(4) function V3FileTest(flags, filename, caller_info)
    integer(4), intent(in) :: flags
    character(len=*), intent(in) :: filename
    character(len=*), intent(in) :: caller_info  ! Should be a string!

    print *, 'V3FileTest called from: ', trim(caller_info)
    V3FileTest = .true.
  end function V3FileTest

  ! This function demonstrates the CORRECT pattern
  logical(2) recursive function V3MatRead_Correct(cFile, pMat)
    character(len=*) :: cFile
    type(T_MATRIX), pointer :: pMat
    logical(4) :: V3FileTest
    logical(4) :: lRet
    external :: V3FileTest

    V3MatRead_Correct = .false.

    ! CORRECT - using string literal with quotes
    if (.not. V3FileTest(ior(2, 4), cFile, 'V3MatRead_Correct( cFile, pMat )')) return

    nullify(pMat)
    lRet = Init(pMat, 0, gc_FlagOrigin)
    V3MatRead_Correct = .true.
  end function V3MatRead_Correct

  ! This function demonstrates the BUGGY pattern
  logical(2) recursive function V3MatRead_Buggy(cFile, pMat)
    character(len=*) :: cFile
    type(T_MATRIX), pointer :: pMat
    logical(4) :: V3FileTest
    logical(4) :: lRet
    external :: V3FileTest

    V3MatRead_Buggy = .false.

    ! BUG: V3MatRead_Buggy should be a quoted string!
    ! This passes the function name instead of a string
    if (.not. V3FileTest(ior(2, 4), cFile, V3MatRead_Buggy)) return

    nullify(pMat)
    lRet = Init(pMat, 0, gc_FlagOrigin)
    V3MatRead_Buggy = .true.
  end function V3MatRead_Buggy

  ! Another buggy variant
  logical(2) recursive function V3MatWrite_Buggy(pMat, cFile)
    type(T_MATRIX), pointer :: pMat
    character(len=*) :: cFile
    logical(4) :: v3FileTest
    external :: V3FileTest

    V3MatWrite_Buggy = .false.

    ! BUG: V3MatWrite_Buggy without quotes
    if (.not. V3FileTest(ior(1, 4), cFile, V3MatWrite_Buggy)) return

    V3MatWrite_Buggy = .true.
  end function V3MatWrite_Buggy

  ! Complex scenario with multiple buggy calls
  logical(2) recursive function CMaToV3Mat_Buggy(cFile, pMat)
    character(len=*) :: cFile
    type(T_MATRIX), pointer :: pMat
    logical(4), external :: V3FileTest
    logical(2) :: lRet
    character(len=300) :: cStatus

    lRet = .false.

    ! BUG: CMaToV3Mat_Buggy without quotes
    if (.not. V3FileTest(ior(2, 4), cFile, CMaToV3Mat_Buggy)) return

    nullify(pMat)
    lRet = Init(pMat, 100, gc_FlagOrigin)

    write(cStatus, '(a,a,a)') 'Reading CMA matrix ', cFile, ' ...'
    call V3RaiseStatus(pMat%hWnd, trim(cStatus))

    ! Another buggy call pattern
    if (.not. V3FileTest(ior(1, 4), cFile, CMaToV3Mat_Buggy)) return

    lRet = .true.
  end function CMaToV3Mat_Buggy
end module V3MatIO

program test_reproducer
  use V3MatIO
  implicit none

  type(T_MATRIX), pointer :: pMat
  logical(2) :: result

  ! Test correct version - should work
  result = V3MatRead_Correct('test.mv3', pMat)

  ! Test buggy versions - may crash IFX during compilation
  result = V3MatRead_Buggy('test.mv3', pMat)
  result = V3MatWrite_Buggy(pMat, 'output.mv3')
  result = CMaToV3Mat_Buggy('test.cma', pMat)

end program test_reproducer

It looks like the bug requires additional context from module dependencies and it is not possible to proceed further with no dependent modules. Since the optimizer is involved it is really sensitive to any modifications in the code.