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
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.
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.
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
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.
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.
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.