BUG: GENERIC type bound procedure

[hakostra1]

I discovered what I believe is yet another Intel Fortran compiler bug:

MODULE test_mod
    IMPLICIT NONE

    TYPE, ABSTRACT :: base_t
        INTEGER :: flag
    CONTAINS
        PROCEDURE :: get_int
    END TYPE base_t

    TYPE, EXTENDS(base_t) :: foo_t
        REAL :: factor
    CONTAINS
        GENERIC, PUBLIC :: get_number => get_int, get_real
        PROCEDURE :: get_real
    END TYPE foo_t

CONTAINS
    SUBROUTINE get_int(this, res)
        CLASS(base_t) :: this
        INTEGER :: res

        res = this%flag
    END SUBROUTINE

    SUBROUTINE get_real(this, res)
        CLASS(foo_t) :: this
        REAL :: res

        res = this%factor
    END SUBROUTINE
END MODULE test_mod

PROGRAM test
    USE test_mod
    IMPLICIT NONE
    
    TYPE(foo_t) :: bar
    INTEGER :: ifoo
    REAL :: rfoo

    bar%flag = 1
    bar%factor = 2.0

    CALL bar%get_number(ifoo)
    CALL bar%get_number(rfoo)
    WRITE(*, *) "ifoo, rfoo: ", ifoo, rfoo
END PROGRAM test

Compiling it with any Intel Fortran compiler (ifx, ifort) gives:

error #8423: In GENERIC type bound procedure definition each binding name must be the name of a specific binding of the type.   [GET_INT]
        GENERIC, PUBLIC :: get_number => get_int, get_real
-----------------------------------------^

I tried the example with GFortran versions back to version 4.9.4 using Compiler Explorer and everything works there. No versions of ifort or ifx works, see godbolt.org.

Investigating the issue I found this 9 year old 'ifort' bug report for the exact same error:

https://community.intel.com/t5/Intel-Fortran-Compiler/generic-type-bound-proc-with-bibding-in-a-base-class/td-p/1010463

The Fortran programming language has some quirks and it's not always easy to decide what's allowed and not. Since the conclusion in 2014 was that the code was right and the compiler wrong, I assume that is the case also in 2023. I'm not a fan of reviving 9 year old discussion topics therefore I am starting a new one here as a reminder about this.

I hope that bugs reported through this forum is looked into at some point, not just left in a drawer.

[Steve_Lionel]

That old problem was reported to the developers (indeed, I'm the one who did that.) One of the current Intel folk will need to check into what happened to that report. I'll comment that even though the symptom is the same, it could be a different bug.

[hakostra1]

Thanks for the reply!

I just signed up for a trial license with NAG and tried it there as well, and the NAG compiler accept and run the code example in the first post as-is.

Also, the reproducer/example in the old 2014 post still does not compile with recent ifort or ifx.

[TobiasK]

Thanks for reporting this, I added your test to the ticket.

[hakostra1]

Thanks. I appreciate your service. It's not the most severe bug I've reported, but would be nice to see it fixed some day.

[TobiasK]

Hi, @hakostra1, @Steve_Lionel 

we finally fixed the very old bug and it's included in the 2024.2 release.

Edit:
sorry I messed up two different things:) the fix for the reported issue will be in 2024.2

[hakostra1]

Great news, thanks!!

The ifx compiler really see some major fixes this year, both with release 2024.0, the upcoming 2024.1 and in the autumn. I really appreciate the effort all of you in Intel put down in this, and also that you accept reports and fix bugs coming from the community.