Nvfortran bug with character in class(*) subroutine

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
1

I have a problem with the newly released nvfortran 24.7. Take the following example:

PROGRAM main
    IMPLICIT NONE

    CHARACTER(len=10) :: str1
    CHARACTER(len=:), ALLOCATABLE :: str2
    CHARACTER(len=10) :: str3(2)

    CALL test_class(str1)
    CALL test_char(str1)

    ALLOCATE(CHARACTER(len=10) :: str2)
    CALL test_class(str2)
    CALL test_char(str2)

    CALL test_class(str3(1))
    CALL test_char(str3(1))

CONTAINS
    SUBROUTINE test_class(arg)
        ! Subroutine arguments
        CLASS(*), INTENT(inout) :: arg

        SELECT TYPE (arg)
        TYPE IS (CHARACTER(len=*))
            WRITE(*, *) "Length: ", LEN(arg)
        CLASS DEFAULT
            WRITE(*, *) "Not a character"
        END SELECT
    END SUBROUTINE test_class

    SUBROUTINE test_char(arg)
        ! Subroutine arguments
        CHARACTER(len=*), INTENT(inout) :: arg

        WRITE(*, *) "Length: ", LEN(arg)
    END SUBROUTINE test_char
END PROGRAM main

All compilers I tried (gfortran, ifort, ifx, nagfor) besides nvfortran works as expected and give the same result:

 Length:           10
 Length:           10
 Length:           10
 Length:           10
 Length:           10
 Length:           10

With nvfortran there seems to be a bug when an element of the the character string array str3 is passed in the CLASS(*) argument of test_class:

 Length:            10
 Length:            10
 Length:            10
 Length:            10
 Length:       4198976
 Length:            10

The exact value printed on the second last line vary from run to run and seems to be arbitrary.

This seems to be a compiler bug in nvfortran. Any comments? Thanks in advance.

2

Hi Hakostra! I’ll take a look and open an engineering report if I’m able to determine that this is a compiler issue. Thanks for letting us know!

3

Hey Hakostra - I have reported the issue to engineering as TPR#36126. When I hear back about a fix, I’ll let you know! Thanks for letting us know about the issue. And please feel free to let us know about any other issues you run into.

Cheers,

Seth.

4

Thanks for looking into this! flang-new (compiled from LLVM main repo today) can be added to the list of compilers that treat this case correctly.

1 Like