ifx 2024.1 internal compiler error (#5633) on a bind(C) interface with two character(kind=c_char) :: x(*) dummies

[kunalKumar-13]

Summary

ifx 2024.1 aborts compiling src/system/stdlib_system.F90 with an internal compiler error when a bind(C) interface in that file declares two character(kind=c_char), intent(in) :: x(*) dummies. gfortran 10–15, intel-classic 2021.10 and every other job in the matrix compile the same source without complaint.

FAILED: [code=3] src/system/CMakeFiles/fortran_stdlib_system.dir/stdlib_system.F90.o
src/system/.../stdlib_system.F90-pp.f90: error #5633: **Internal compiler error:
segmentation violation signal raised**
ninja: build stopped: subcommand failed.

This is blocking #1208. I am opening it separately because it is a compiler problem rather than a review problem, and because eight attempts at working around it inside that PR have not helped.

What has been ruled out

Each of these was tried on #1208 and the ICE survived, so none of them is the cause:

tried	result
interface declaration on one line	ICE
interface dummy renamed off value (next to the VALUE attribute)	ICE
interface reshaped to match stdlib_set_cwd exactly	ICE
to_c_char() results held in locals rather than passed inline	ICE
automatic arrays sized from the dummy arguments	ICE
both strings passed as type(c_ptr), value + c_loc	ICE
back to plain character(kind=c_char) :: x(*), to_c_char() inline, no target, no c_loc	ICE

Two more that are sometimes suspected, checked against the tree rather than guessed:

• A dummy named value is not special here — there are 33 of them in src/, e.g. stdlib_hashmaps.f90:859, all compiling under the same job.
• A host dummy shadowed by an interface dummy is not special either — set_cwd(path, err) declares stdlib_set_cwd(path) with a dummy also called path, on master, today.

What is left

After the last change, set_environment_variable is written exactly like delete_environment_variable directly below it, and like set_cwd, make_directory, remove_directory and is_directory. The only structural difference left between it and every other C shim in the module is that its interface has two character(kind=c_char) :: x(*) dummies instead of one. That is also the only such interface in the whole source tree.

Minimal reproducer (unverified — I have no Intel compiler)

I cannot run ifx, so I have not been able to confirm this outside CI. It should take a moment for anyone who can. Expected: two.f90 aborts, one.f90 compiles.

two.f90:

module ice_two
  use, intrinsic :: iso_c_binding, only: c_char, c_null_char
  implicit none
contains
  subroutine set_two(a, b, rc)
    character(len=*), intent(in) :: a
    character(len=*), intent(in) :: b
    integer, intent(out) :: rc
    interface
      integer function shim2(x, y) bind(C, name='shim2')
        import c_char
        character(kind=c_char), intent(in) :: x(*)
        character(kind=c_char), intent(in) :: y(*)
      end function shim2
    end interface
    rc = shim2(a//c_null_char, b//c_null_char)
  end subroutine set_two
end module ice_two

one.f90 — the control, identical but with a single string dummy:

module ice_one
  use, intrinsic :: iso_c_binding, only: c_char, c_null_char
  implicit none
contains
  subroutine set_one(a, rc)
    character(len=*), intent(in) :: a
    integer, intent(out) :: rc
    interface
      integer function shim1(x) bind(C, name='shim1')
        import c_char
        character(kind=c_char), intent(in) :: x(*)
      end function shim1
    end interface
    rc = shim1(a//c_null_char)
  end subroutine set_one
end module ice_one

ifx -c one.f90   # expected: fine
ifx -c two.f90   # expected: error #5633

If two.f90 also compiles, then the trigger is something about the construct in context rather than the construct itself, and the next step is bisecting stdlib_system.F90 — which needs someone with the compiler.

The version question

CI.yml pins intel at 2024.1, while gcc runs up to 15. #1142 is a test report against ifx 2025.3, so newer Intel is in use by testers but not by CI.

If this reproduces on 2024.1 and not on a current ifx, then it is a fixed compiler bug and the choice is between contorting library source around a superseded compiler or moving the pin. I did not want to change a repo-wide CI setting from inside a feature PR, but I am happy to open that PR if you would like it — either bumping the entry or adding a second one so both are covered.

Either way it is probably worth an Intel Software Problem Report, which the ICE message itself asks for.

Reproduces on

• Build (intel, 2024.1, cmake) and Build (ubuntu-latest, intel, 2024.1, cmake), every run of Add set_environment_variable and delete_environment_variable #1208 since 9 September.
• Not on Build (ubuntu-22.04, cmake, intel-classic, 2021.10), which passes.
• Not on any gcc entry.
• master is unaffected, because no interface in it has two character(kind=c_char) :: x(*) dummies.