Problem with deferred bindings in abstract types in XE2019 update 5

[Daniel_Dopico]

The following code compiles in XE2019 update 2, but it doesn't compile in XE2019 update 5. Do you think that the code is conforming? It seems to me another compiler bug introduced around update 4.

MODULE fuerzas_generalizadas

IMPLICIT NONE

PRIVATE

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!   Tipo sólido fijo: suelo
TYPE SOLIDOBASE
	INTEGER::id=-1,npt=0,nvc=0
    REAL(8), DIMENSION(3):: omega=[0.d0,0.d0,0.d0]   !Velocidad angular.
END TYPE SOLIDOBASE

!   Tipo body: es básicamente un puntero privado a sólidos de distintos tipos
TYPE BODY                   !   CUERPO
	!INTEGER id
    INTEGER::kind_body=-1       ! No sirve para nada, se deja a efectos de depuración
    CLASS(SOLIDOBASE),POINTER,PRIVATE::SLD
END TYPE BODY

INTERFACE
    MODULE SUBROUTINE dealloc_genforces_naturales
    END SUBROUTINE dealloc_genforces_naturales
END INTERFACE

!!CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
!!!  DEFINICIÓN DE TIPOS DERIVADOS DE INTERFACES A RUTINAS DE GENERACIÓN Y ENSAMBLAJE DE FUERZAS, RIGIDECES Y AMORTIGUAMIENTOS GENERALIZADOS
!> Tipo derivado de interface a rutinas de generación y ensamblaje de fuerzas generalizadas
TYPE,ABSTRACT::typeBasegenForce
CONTAINS
    PRIVATE
    PROCEDURE(Template_genForce_coord),NOPASS,DEFERRED::genForce_coord
END TYPE typeBasegenForce

ABSTRACT INTERFACE
    SUBROUTINE Template_genForce_coord(cuerpo,rP,F)
        IMPORT BODY
        TYPE(BODY),INTENT(INOUT)::cuerpo
        REAL(8),DIMENSION(3),INTENT(IN)::rP,F
    END SUBROUTINE Template_genForce_coord

END INTERFACE

END MODULE fuerzas_generalizadas

!CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
SUBMODULE(fuerzas_generalizadas) fuerzas_generalizadas_naturales
IMPLICIT NONE

!> Tipo derivado de interface a genForce en naturales
TYPE,EXTENDS(typeBasegenForce)::typeNaturgenForce
CONTAINS
    PROCEDURE,NOPASS::genForce_coord
END TYPE typeNaturgenForce

CONTAINS

SUBROUTINE genForce_coord(cuerpo,rP,F)
    TYPE(BODY),INTENT(INOUT)::cuerpo
    REAL(8),DIMENSION(3)::rP,F,Cp(0:3)
    INTENT(IN) rP,F

END SUBROUTINE genForce_coord

MODULE SUBROUTINE dealloc_genforces_naturales
END SUBROUTINE dealloc_genforces_naturales
    
END SUBMODULE fuerzas_generalizadas_naturales

[FortranFan]

Yes, this looks like an Intel Fortran compiler regression to me - good test case to submit at the Intel support center.

However it appears the regression may have been introduced starting with Intel Fortran compiler version 19.0 Update 3.

[Steve_Lionel]

I'm not sure it's a bug. My reading suggests that you're required to override the deferred procedure when defining a non-abstract type. I played with this a bit and couldn't get it to work the way I thought it should. I have a problem with the binding name in the abstract type being the same as the actual procedure, but even if I changed that I couldn't get it to compile.

[FortranFan]

Steve Lionel (Ret.) (Blackbelt) wrote:

I'm not sure it's a bug. .. I have a problem with the binding name in the abstract type being the same as the actual procedure ..

It's a compiler regression and effectively a bug, the code in the original post is processed by Intel Fortran compiler 19.0 Update 2, for example.

Re: the binding name and procedure name, the BNF with type-bound procedures in the standard makes clear the procedure name is optional in all the possible scenarios involving type-bound procedures.  The standard also states:

19 1 If => procedure-name does not appear in a type-bound-proc-decl, it is as though => procedure-name had appeared
20   with a procedure name the same as the binding name

[Steve_Lionel]

Yeah, I'm a bit fuzzy on this part of the language, which is why I decided not to reply.

It isn't necessarily a regression if code that formerly compiled now gets an error. The compiler is always improving error detection. But that's ok only if the code was invalid to begin with.

[Daniel_Dopico]

Thank you very much FF and Steve. For me it's a bug, too. The deferred procedure is overriden, the code compiles with update 2 and with gFortran too. Moreover, this is the second bug I report related to the releases coming after update 2. I don't know what they are doing with the compiler, but definitely they made important changes after update 2 and not all of them good.

[Devorah_H_Intel]

This issue is being fixed as we speak. Thank you for reporting it.

[Daniel_Dopico]

I can confirm that the new Intel Parallel Studio 2020 also has this issue, i.e., all the versions released after 2019 update 2 are not working properly.

[Devorah_H_Intel]

The issue has been fixed. The fix will be included in the next update.

[Daniel_Dopico]

Thank you Devorah.

[Daniel_Dopico]

I have been informed that this issue has been fixed in versión 19.1 update 1 (2020 update 1). I am eager to see if my code compiles with this new versión because I am stuck to 2019 update 2 since september 2019.

[Steve_Lionel]

It does compile in 19.1 Update 1.

[Daniel_Dopico]

Thank you very much, Steve.