Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28542 Discussions

ifx 2024.1.0 confuses `result` with `bind`

V-T
New Contributor I
706 Views

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.

Labels (2)
1 Solution
Barbara_P_Intel
Employee
624 Views

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.



View solution in original post

0 Kudos
3 Replies
mecej4
Honored Contributor III
675 Views

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
Employee
625 Views

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.



0 Kudos
V-T
New Contributor I
597 Views

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.

0 Kudos
Reply