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

Possible compiler BUG: calling routine with OPTIONAL CLASS(*) arguments

hakostra1
New Contributor II
764 Views

I have the following program:

MODULE test_mod
    IMPLICIT NONE (type, external)
CONTAINS
    SUBROUTINE connect(v1, v2)
        REAL, OPTIONAL :: v1(:), v2(:)
        CALL connect_impl(v1=v1, v2=v2)
    END SUBROUTINE connect

    SUBROUTINE connect_impl(v1, v2)
        CLASS(*), OPTIONAL :: v1(:), v2(:)
        WRITE(*, *) "Success!"
    END SUBROUTINE connect_impl
END MODULE test_mod

PROGRAM test
    USE test_mod
    IMPLICIT NONE (type, external)

    REAL :: foo(10)
    foo = 3.14

    CALL connect(v1=foo)
END PROGRAM test

Compiling with 'ifx' version 2023.2.0 on Linux is fine but running it gives:

$ ifx --version -g -O0 -traceback test.F90 && ./a.out
ifx (IFX) 2023.2.0 20230721
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007F1673642520  Unknown               Unknown  Unknown
a.out              00000000004053B8  connect                     6  test.F90
a.out              000000000040562F  test                       22  test.F90
a.out              000000000040518D  Unknown               Unknown  Unknown
libc.so.6          00007F1673629D90  Unknown               Unknown  Unknown
libc.so.6          00007F1673629E40  __libc_start_main     Unknown  Unknown
a.out              00000000004050A5  Unknown               Unknown  Unknown

So the program segfaults when executed. I also tried 'ifort' and it segfaults there too.

The program compile and runs fine with all GFortran versions I tested.

As far as I see I am not violating any Fortran language standards (please net me know if I'm wrong)... My assumption here is that the Intel Fortran compilers 'ifx' and 'ifort' produce a bug in the resulting binary code.

Any comments are welcome. Thanks.

1 Solution
Barbara_P_Intel
Employee
336 Views

With the 2024.1 release both ifx and ifort print "Success!". These compilers were released last week. Please check them out!



View solution in original post

0 Kudos
6 Replies
Steve_Lionel
Honored Contributor III
742 Views

I suspect I know what is going wrong. Passing a non-polymorphic object to a polymorphic dummy argument requires run-time construction of a descriptor containing the type information. The compiler is neglecting to test for the arguments to connect being omitted before creating the descriptor.

Barbara_P_Intel
Employee
729 Views

Thank you, @hakostra1, for reporting this issue with such a nice reproducer.

I filed CMPLRLLVM-52912 reporting this bug. I'll let you know when I know more about a fix.

@Steve_Lionel, I passed your thoughts along to the Fortran team. Thanks!

 

0 Kudos
hakostra1
New Contributor II
687 Views

Thanks for the quick response. In the meantime I also checked the NAG compiler, and if I change from "IMPLICIT NONE (type, external)" to  just "IMPLICIT NONE" the code compiles and runs.

0 Kudos
Steve_Lionel
Honored Contributor III
675 Views

I also tested this with NAG (which doesn't yet support all of F2018.)

0 Kudos
Barbara_P_Intel
Employee
337 Views

With the 2024.1 release both ifx and ifort print "Success!". These compilers were released last week. Please check them out!



0 Kudos
hakostra1
New Contributor II
325 Views

Great news, thanks a lot to all of you in Intel!

0 Kudos
Reply