ifx 2024.1.0 confuses `result` with `bind`

[V-T]

Consider the following minimal example:

program p
    call f([42])
contains
    subroutine f(x)result(c)  ! ifx interprets `result` as `bind`
        integer::x(:),c(SIZE(x))
        c=x
        print*,c
    end
end

This code can be successfully compiled with ifx 2024.1.0. However, it has a syntax error at line 4: `result` in a `subroutine` definition. The name of the result variable can only be `c`, since ifx interprets the end of this line as `bind(c)`. Executing the compiled code prints an empty line, although an integer array should be printed.

I don't know, if this two problems are related, but even stranger behavior can be achieved with the following code:

module m
    interface
        function i(x)result(c)
            integer::x(:),c(SIZE(x))
        end
    end interface
    type t
        procedure(i),pointer,nopass::f
    end type
contains
    subroutine f()
        type(t),allocatable::o
        o=t(g)
        print*,o%f([42])
    contains
        subroutine g(x)result(c)
            integer::x(:),c(SIZE(x))
            print*,x
        end
    end
end

program p
    use m
    call f()
end

 Executing this compiled code, prints a lot of random integers and ends with a segmentation fault.

[mecej4]

The erroneous behavior that you reported for your first example code is also exhibited by the IFort compiler. Both compilers, with the /check option, produce an EXE which, when run, aborts with the message

forrtl: severe (408): fort: (33): Shape mismatch: The extent of dimension 1 of array C is 0 and the corresponding extent of array X is 1

[Barbara_P_Intel · Accepted solution]

Thank you for reporting this, @V-T. I filed a bug report, CMPLRLLVM-57640, to get an error message printed at compile time.

@mecej4, thanks for that tip! I added that info to the bug report. @V-T, will that tip help you?

We'll let you know when a fix is available.

[V-T]

I found this bug accidentally, when I was trying to produce a minimal example for another bug that affects the program I'm working on. It is a pretty obvious bug (even without any debugging compiler flags): I already noticed that something was wrong, when ifx forced me to rename the result variable to `c`. I made this post, because ifx didn't notice, what a programmer can easily notice. So the solution for me is to simply write syntactically correct code in this case.