ifx: ICE with check bounds

[Philippe31]

Hello,

I get an internal compiler error with ifx 2023.0.0 with this simple code:

> cat eoshift.f90  
FUNCTION ZA(PA)
IMPLICIT NONE
REAL, DIMENSION(:,:,:), INTENT(IN)                :: PA
REAL, DIMENSION(SIZE(PA,1),SIZE(PA,2),SIZE(PA,3)) :: ZA  
ZA(:,:,:) = EOSHIFT(PA(:,:,:),SHIFT=1,DIM=3)
END FUNCTION ZA

if I try to compile it with the -check bounds option:

> ifx -c -check bounds eoshift.f90  
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1f563ca]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1bef70e]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c55e52]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c55f80]
/lib64/libc.so.6(+0x4ad50)[0x14fb39444d50]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3afc702]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3b03395]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3b030c3]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3b0fa22]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3a98d52]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3a9b859]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x3a9a87c]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x2d22ced]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x2031303]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x2d1ad2d]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x2037cd0]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x2d1af0d]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x202fe87]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b96f59]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b955dd]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b44a74]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1d028ee]
/lib64/libc.so.6(__libc_start_main+0xef)[0x14fb3942f29d]
/home/waup/installations/applications/oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1982da9]

eoshift.f90: error #5633: **Internal compiler error: segmentation violation 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 eoshift.f90 (code 3)

Without the -check bounds option, compilation is OK.

Regards,

Philippe

[Barbara_P_Intel]

Thank you for reporting this with such a nice reproducer. Of course, the workaround is to not compile with "-check bounds".  (Wink, since emojis don't work.)

I filed a bug report, CMPLRLLVM-45802. I'll let you know when it's fixed.

[andrew_4619]

That code fails (ICE)  on IFX in Windows also,

Another work around might be:

       ! REAL, DIMENSION(SIZE(PA,1),SIZE(PA,2),SIZE(PA,3)) :: ZA  
        real, allocatable :: ZA(:,:,:)

That still works with bounds check on and is more pleasing on the eye IMO!

[JohnNichols]

FUNCTION ZA(PA)
IMPLICIT NONE
REAL, DIMENSION(:,:,:), INTENT(IN)                :: PA
REAL, DIMENSION(SIZE(PA,1),SIZE(PA,2),SIZE(PA,3)) :: ZA  
ZA(:,:,:) = EOSHIFT(PA(:,:,:),SHIFT=1,DIM=3)
END FUNCTION ZA

@Philippe31  - it helps make the code easy to read if you put the code into the code box in the editor.  

I would have to agree with Andrew. 

[jimdempseyatthecove]

Andrew,

ZA is the function name. Your code specifies (requires) that the callers returned-to variable/expression temporary be allocatable as well. In the OP's original code, the returned-to variable/expression temporary was (presumably) preallocated to the dimensions of that of the calling argument.

Note, with this function having a proper interface you can specify:

real :: ZA(:,:,:)

Jim Dempsey 

[andrew_4619]

I would presume the automatic variable (array) ZA created in the function in the OPs post will be assigned to whatever the caller assigns it to whether that be allocatable or not. It is in essence the same both methods create a temporary array in the function and return that array and array descriptor. The onus is on the caller to ensure the assignment is to a compatible array IMO.  

[JohnNichols]

Very easy to make a mistake doing this. 

[andrew_4619]

With explicit interfaces and bound checking on it is not easy to make a mistake, the compiler is your friend!

[jimdempseyatthecove]

While I agree that, should this function be called returning very large arrays, the argument may require it be allocatable (such to avoid stack overflow). However, in doing so, may also require the code explicitly allocate the array should the results be generated in the return value (e.g. DO k=1,n; DO j=1,m; DO i=1,o; ... ZA(i,j,k) = scalar) as opposed to ZA = otherArrayOfDesiresShapeAndSize.

Jim Dempsey