ifx 2024.1.0 without any flags generates executables with illegal instructions

[V-T]

Consider the following minimal example (I couldn't reduce the example further, because every change can affect the results drastically):

module m
    interface
        function i(x)result(r)
            integer::x(:),r(SIZE(x))
        end
    end interface
    type t
        procedure(i),pointer,nopass::j
        integer::v
    contains
        procedure::s
    end type
contains
    function s(o,x,m)result(r)
        class(t)::o
        integer::x(:),r(SIZE(x))
        integer,optional::m
        r=o%v*o%j(x)
        if(PRESENT(m))m=42
    end
    subroutine k(n)
        integer::n
    end
    subroutine f()
        class(t),allocatable::o
        integer::n
        n=42
        call g(o)
        print*,o%s([42])
    contains
        subroutine g(o)
            class(t),allocatable,intent(out)::o
            print*,42
            o=t(j,1)
        end
        function j(x)result(r)
            integer::x(:),r(SIZE(x))
            r=x
        end
        subroutine h()
            call k(n)  ! replacing `n` with a literal fixes the problem
        end
    end
end

program p
    use m
    call f()
end

Compiling the code with ifx 2024.1.0 (without any flags on Ubunut 18.04.2) and executing it results either in `forrtl: severe (174): SIGSEGV, segmentation fault occurred` or `forrtl: severe (168): Program Exception - illegal instruction` error. Some simplifications of the code (like removing the optional argument `m` in the function `s`) can generate an executable that sometimes runs without any errors.

My testing showed that the reason might be at line 41 (`call k(n)`), although this line is never executed. Replacing `n` with a literal in this line fixes the problem. Maybe, ifx doesn't like that in the inner subroutine `h` a variable `n` of the outer subroutine `f` is given as an argument to another subroutine in outer scope `k`.

This is a very strange problem, because the results are not deterministic.

[Barbara_P_Intel · Accepted solution]

Thanks for taking the time to create this reproducer.

I see the SIGSEGV using 2024.1.0. 

I compiled and ran with the latest preview version of 2024.2.0. No SIGSEGV! Look for this compiler release in mid-2024.