ifx ices pasing substring of component of allocatable array element to assumed length dummy

[IanH]

Subject ... says it all!

MODULE ifx_ice_20230313
  IMPLICIT NONE
  PRIVATE
  TYPE, PUBLIC :: String
    CHARACTER(:), ALLOCATABLE :: item
  END TYPE String
CONTAINS
  SUBROUTINE kapow
    TYPE(String), ALLOCATABLE :: expanded_args(:)
    
    allocate(expanded_args(1))
    expanded_args(1)%item = 'abcdef'
    CALL get_option_name(expanded_args(1)%item(3:))
  END SUBROUTINE kapow
  
  SUBROUTINE get_option_name(text)
    CHARACTER(*), INTENT(IN) :: text
  END SUBROUTINE get_option_name
END MODULE ifx_ice_20230313

>ifx /c ifx_ice_20230313.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 0x00007ff64f6cf1d5 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2ff1d5)
 #1 0x00007ff64f6cf1aa (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2ff1aa)
 #2 0x00007ff64f5c3622 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1f3622)
 #3 0x00007ff64f5c8b6a (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1f8b6a)
 #4 0x00007ff64f5ccde3 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1fcde3)
 #5 0x00007ff64f643b34 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x273b34)
 #6 0x00007ff64f6429bd (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x2729bd)
 #7 0x00007ff64f720416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
 #8 0x00007ff64f72096d (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x35096d)
 #9 0x00007ff64f722f16 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x352f16)
#10 0x00007ff64f720416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
#11 0x00007ff64f72096d (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x35096d)
#12 0x00007ff64f71dc30 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x34dc30)
#13 0x00007ff64f720416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
#14 0x00007ff64f71d2cd (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x34d2cd)
#15 0x00007ff64f720416 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x350416)
#16 0x00007ff64f59dd7a (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1cdd7a)
#17 0x00007ff64f59d7ca (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x1cd7ca)
#18 0x00007ff64f783472 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x3b3472)
#19 0x00007ff651c0e940 (C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\xfortcom.exe+0x283e940)
#20 0x00007ff8f30d7614 (C:\WINDOWS\System32\KERNEL32.DLL+0x17614)
#21 0x00007ff8f41826a1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x526a1)

ifx_ice_20230313.f90(14): 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 get_option_name(expanded_args(1)%item(3:))
---------^
compilation aborted for ifx_ice_20230313.f90 (code 3)

[FortranFan]

Intel team,

Has Intel management considered open-sourcing the IFX and IFORT front-end and to manage its development and rearchitecting and refactoring via public repositories, say GitHub?  Because it will be really interesting to peruse for oneself what is going on under the hood but which can't be all that proprietary.  This due to the fact it's really odd to keep coming across ICEs like the one in the original post, for IFX doesn't fall over with a more complex but somewhat related data reference like the following:

MODULE ifx_ice_20230313
  IMPLICIT NONE
  PRIVATE
  TYPE, PUBLIC :: String
    CHARACTER(:), ALLOCATABLE :: item
  END TYPE String
CONTAINS
  SUBROUTINE kapow
    TYPE(String), ALLOCATABLE :: expanded_args(:)
    
    allocate(expanded_args(1))
    expanded_args(1)%item = 'abcdef'
    associate ( item => expanded_args(1)%item(3:) ) 
       CALL get_option_name( item )
    end associate
  END SUBROUTINE kapow
  
  SUBROUTINE get_option_name(text)
    CHARACTER(*), INTENT(IN) :: text
  END SUBROUTINE get_option_name
END MODULE ifx_ice_20230313

What is with `CALL get_option_name(expanded_args(1)%item(3:))` in the original post that stumbles IFX?  One can't help fathom but that's not a good look for IFX.

[Ron_Green]

We have received requests to open source our front end.  Thank you for adding your request to the other requests.  Yes, Intel management continues to considered this request, along with all other similar requests for new features, packages, extensions and offerings.  
This case is another example of where even with extensive test suites, commercial and open source, and test cases used in development activities, a user combines features in a way we have not anticipated.  One tries to anticipate usages but obviously it is impossible to cover all possible combination of language features.  This particular case is where the front end is doing the right thing, but the translation and lowering to LLVM missed something.  We will see this in IFX as we get more user testing this year and the coming years.

That said, WHEN we get bug reports and fix them, our developers MUST add a regression test of the reproducer(s) to our extensive regression suite containing 10s of thousands of such reproducers BEFORE they can submit their fix to our internal development branch.  Our regression suite goes all the way back in our compiler's history and is quite extensive. And the test for the fix is part of code review prior to accepting the PR.

[FortranFan]

Thank you @Ron_Green and @Barbara_P_Intel for your comments, they help to understand the situation greatly.  The image you provided @Barbara_P_Intel  appears familiar from the recent talk by @Ron_Green on IFX.  We suspected as much the ICE was probably in some place during code generation, the confusion to us was why the case with `associate` construct works out whereas the one in the original post falls over.

[Barbara_P_Intel · Accepted solution]

Good news, @IanH! This ICE is fixed in the release of ifx that is planned to be available in the next few weeks. 

[Barbara_P_Intel]

@FortranFan, Intel is certainly active in many open source communities. I'm not sure where Fortran fits in.

There are two parts to the Fortran Front End, the part that is mostly shared between ifx and ifort and the intermediate code generator. Most of the ifx ICEs I see are in the intermediate code generator which is new.

This graphic shows what happens when compiling.