ICE on valid code: concatenation with a parameter in `write`

[V-T]

Consider the following minimal example:

module m
    interface operator(//)
        procedure::ics,sci
    end interface

contains
    pure function ics(i,s)result(r)
        integer,intent(in)::i
        character(len=*),intent(in)::s
        character(len=:),allocatable::r
        character(len=11)::b
        write(b,'(i0)')i
        r=trim(b)//s
    end

    pure function sci(s,i)result(r)
        character(len=*),intent(in)::s
        integer,intent(in)::i
        character(len=:),allocatable::r
        character(len=11)::b
        write(b,'(i0)')i
        r=s//trim(b)
    end

    function s(i)result(r)
        integer,intent(in)::i
        character(len=:),allocatable::r
        integer,parameter::w=0
        character(len=11)::b
        write(b,'(i'//w//')')i
        r=trim(b)
    end
end

program p
    use m
    print*,s(42)
end

Attempts to compile this code with ifx 2025.2.0 result in "error #5633: **Internal compiler error: segmentation violation signal raised**". gfortran compiles this code correctly without any issue. The problematic line is `write(b,'(i'//w//')')i` in function `s` and namely the string concatenation with parameter `w`. If `w` is not a parameter or the concatenation happens outside of `write`, no ICE happens.

This ICE also happens on a smaller (albeit invalid) example:

integer::i
integer,parameter::w=0
character(len=11)::b
write(b,'(i'//w//')')i
end

 I wasn't able to check whether this ICE also happens on the newest version of ifx.

[Steve_Lionel]

26.0.0 does not ICE on your larger example, but it does complain about the same invalid code as in the small one, as w is an integer and you can't concatenate that. If I change w to be a character with the value '3', it's happy.

[V-T]

I don't have ifx 2026.0.0 currently, so I'd like to clarify your statement about `write(b,'(i'//w//')')i` being invalid. In the bigger example, I define an interface for `operator(//)` that allows concatenation of `character` with `integer`. So this line in the bigger example is valid. gfortran compiles it into a correctly behaving executable. However, you claim that ifx 2026.0.0 complains about this line. Isn't it a compiler bug then?

[Steve_Lionel]

My apologies - I overlooked the defined operator. I agree that it should compile without errors.