Regression "ifx" 2022.1.0 20220316 with file "open()"

[scivision]

I am experiencing a new regression with Intel LLVM "ifx" Fortran compiler that is new in 2022.1.0 20220316 release. This worked in several previous Intel releases, including "ifx" with 2022.0 releases. This now fails on Windows and Linux with "ifx"

Here is a minimal example that fails to build. The issue appears to be the "open(file=)" where a "character(:), allocatable" function is given for the filename to avoid using an additional auxiliary variable. This works on all other compilers including "ifx" less than 2022.1.0 20220316.

program a

open(10, file=hello())

contains

function hello()
  character(:), allocatable :: hello
  hello = "hello"
end function hello

end program

The ICE on Linux:

$ ifx dummy.f90
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x146f4ea]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x10f84dd]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x1156992]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x1156ac0]
/usr/lib64/libc.so.6(+0x4ead0)[0x7f7c7e1a5ad0]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0xe8d718]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x1189506]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11842fc]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11a89b3]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11a9042]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11ab3bf]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11a89b3]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11a5dba]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11a89b3]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x1055476]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x1054c04]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0x11fb612]
/usr/lib64/libc.so.6(__libc_start_main+0xf3)[0x7f7c7e191ca3]
/opt/intel/oneapi/compiler/2022.1.0/linux/bin-llvm/xfortcom[0xe701e9]

dummy.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 dummy.f90 (code 3)

$ ifx --version
ifx (IFORT) 2022.1.0 20220316
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

 The ICE on Windows:

> ifx dummy.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.1.0 Build 20220316
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

xfortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for dummy.f90 (code 1)

[scivision]

This also has regression (fails to compile) in place of "open" in program above using "character(:), allocatable" function:

inquire(file=hello())

However, other character intrinsics do work with the "hello()" character(:), allocatable function as expected, such as index(), scan(), verify(). Just open() and inquire() are regression that I know of.

[Igor_V_Intel]

Thank you for reporting this regression to use. I checked that the bug is still in the latest compiler build, however, it was not in 2021.0.

I am escalating it to the development team.

[Igor_V_Intel]

Thank you. The problem is escalated and should be fixed in the upcoming compiler updates.

[Igor_V_Intel · Accepted solution]

The bug s fixed in latest compiler version released as a part of oneAPI 2023.0 bundle.

[JohnNichols]

Never in my wildest dream would I think to code like this hello and open function, what happens if hello is recursive, etc.. 

[andrew_4619]

Nothing happens assuming the recursion is not infinite it unwinds and returns a value.

pi = 3.14_8
g = 'The value of pi='
write(*,'(A)') trim(g)//d2string(pi)//' aproximately'
write(*,'(A)') trim(g)//d2string(pi,'(F0.2)')//' aproximately'

! d2string is a function that returns a double as an allocatable string to
! a default or optionally specified format. 

 I find functions that return allocatable strings are very useful like the above string building function. Much more flexible and neater than declaring a string to write to and then manipulating that.

[JohnNichols]

good idea actually, never occurred to me, can say I never remember running across the idea in a book.  But maybe I was not paying attention.   Although the file open procedure I use was written in 1987 and still works so why fix that which works.