Code doesn't compile after updating from XE2019 upd2 to upd4

[Daniel_Dopico]

I have a library which stopped compiling after updating from Parallel Studio XE2019 update 2 to Parallel Studio XE2019 update 4. I cheched it many times together with Visual Studio 2017 and updating to Visual Studio 2019 too and the result is always the same, the compilation gets stuck while compiling a particular file (always in the same file in a never ending process).

Has anyone noticed this same behavior? Has anyone reported any problem after updating? Any option different? I don't know.

Thanks.

Daniel.

[Steve_Lionel]

You're the first to mention such a thing here. I suggest using the big orange "Bug Report" button to send Intel all the files needed, along with command line used, to see if they can reproduce it. Back when I was doing support I had seen reports of that sort of behavior from time to time. You may want to experiment with command line options to see if any of them affect the behavior. The way I do this is to go to the build log and copy the command line it uses, then I paste that into a command prompt window and try it. If the problem still appears, I start removing options until I find one that changes the behavior (not always possible, but most of the time.)

[Daniel_Dopico]

I wish it was that easy, the file is part of a code with hundreds of files, some of them with thousands of lines of code.

I noticed this problem two months ago and I tried to isolate it removing files and commenting code but I did not succeed because at some point the problem dissapeared. I will give it another try.

I like this new big orange "Bug report" button. It make sense to have it here I normally ask here before sending a ticket.

Thank you, Steve.

[mecej4]

The project may have hundreds of files, but if the problem is only with compiling a specific file, as you wrote above, you only need to provide that file, its include files and the files that contain the modules that are USEd by the problem file.

[Wolf_W_ · Accepted solution]

I had a similar problem with all the 19.x compiler version, but it got worse with 19.4. The compiler gets stuck in a loop or something. It seems to be related to use statements. It gets really annoying in combination with submodules. We had to include some submodules back into the main modules to get it working again. In some cases it worked when randomly erasing "only" statements...

I reported it in April with the attached reproducer:

module M_OBJ
  implicit none

  type, public :: T_OBJ
      character(len=:), allocatable, public :: ch
    contains
      procedure, pass(obj_out),  public :: assignObj
      generic :: assignment(=)              => assignObj ! Works without this line

      procedure, private           :: concatObj
      generic :: operator(//)      => concatObj ! Works without this line
  end type

  type, public :: T_OBJ_CONTAINER
    class(T_OBJ), pointer :: v => null()
  end type

  interface T_OBJ
    module procedure constructor ! Works without this line
  end interface T_OBJ


contains


  elemental function constructor()
    type(T_OBJ) :: constructor
!    constructor%ch = ''
  end function constructor

  elemental subroutine assignObj(obj_out, obj_in)
    class(T_OBJ),    intent(inout) :: obj_out
    class(T_OBJ),    intent(in   ) :: obj_in
  end subroutine assignObj

  pure function concatObj(lhs, rhs)
    class(T_OBJ), intent(in   ) :: lhs
    class(T_OBJ), intent(in   ) :: rhs
    character(len=:), allocatable :: concatObj
  end function concatObj

end module M_OBJ
!===================================================================================================================================

module M_BASE_TYPE_HASH_TABLE
! 0 works, 1 does not
#define USE_ONLY 1
#if USE_ONLY
  use M_OBJ, only: T_OBJ, T_OBJ_CONTAINER
#else
  use M_OBJ
#endif
  implicit none

! 0 works, 1 does not
#define USE_SUBMODULE 1
#if USE_SUBMODULE
  interface
    module subroutine alloc_routine()
    end subroutine alloc_routine
  end interface
#else
  contains
  subroutine alloc_routine()
    implicit none

    type(T_OBJ_CONTAINER) :: sorter

    allocate(T_OBJ::sorter%v)

  end subroutine
#endif
end module M_BASE_TYPE_HASH_TABLE

#if USE_SUBMODULE
submodule (M_BASE_TYPE_HASH_TABLE) M_BASE_TYPE_HASH_TABLE_S

  contains

  module subroutine alloc_routine()
    implicit none

    type(T_OBJ_CONTAINER) :: arr

    allocate(T_OBJ :: arr%v)

  end subroutine

end submodule
#endif

[Daniel_Dopico]

mecej4 wrote:

The project may have hundreds of files, but if the problem is only with compiling a specific file, as you wrote above, you only need to provide that file, its include files and the files that contain the modules that are USEd by the problem file.

Thank you mecej4, you are right and that's still a lot of modules, submodules and lines of code. I will try to simplify the case.

Daniel.

[Daniel_Dopico]

Thank you Wolf.

It could be related because I also have organization in submodules. Let's see if they fix your problem and mine is fixed as well. Just in case I'll try to create a code and report too.

Daniel.

[Daniel_Dopico]

Finally, I end up with this piece of code which reproduces the problem (at least in my case). When I try to compile a never ending process starts. Small changes in parts of the code or further simplifications eliminate the problem (it either compiles or not), so it has to be something subtle. It should work with update 2 but not with update 4. If someone can double check that the problem exists, it would be great.

MODULE TIPOS_DERIVADOS
	IMPLICIT NONE

    TYPE,ABSTRACT::typerestric
    CONTAINS
        PROCEDURE,PASS::evaljacobian=>null_jacob
    END TYPE typerestric
    
    TYPE elementlista_restrics
        CLASS(typerestric),POINTER::RS
    END TYPE elementlista_restrics

    TYPE typelista_restrics
        TYPE(elementlista_restrics),ALLOCATABLE,DIMENSION(:)::RSS
    END TYPE typelista_restrics

    TYPE spMatrix
      contains
        procedure, private:: unaryminus
        procedure, private:: spmatsum
        procedure, private, pass(A):: scalarproduct
        generic:: operator(-) => unaryminus
        generic:: operator(*) => scalarproduct
        generic:: operator(+) => spmatsum
    END TYPE spMatrix
    
CONTAINS

    pure function unaryminus(A) result (mA)
      implicit none
      class(spMatrix), in<tent(in):: A
      type(spMatrix) mA
    end function unaryminus

    pure function scalarproduct(x, A) result (mA)
      implicit none
      real(8), intent(in):: x
      class(spMatrix), intent(in):: A
      type(spMatrix) mA
    end function scalarproduct

    pure function spmatsum(A, B) result (C)
      implicit none
      class(spMatrix), intent(in):: A, B
      type(spMatrix) C
    end function spmatsum
    
    SUBROUTINE null_jacob(RS,Fiqx)
        IMPLICIT NONE
        class(typerestric),INTENT(IN)::RS
		TYPE(spMatrix),INTENT(INOUT)::Fiqx
    END SUBROUTINE null_jacob

END MODULE TIPOS_DERIVADOS
!CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
    
!CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
MODULE restricciones_constdist
    USE TIPOS_DERIVADOS,ONLY:typerestric,spMatrix
    IMPLICIT NONE

END MODULE restricciones_constdist
!CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
    
!CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
MODULE restricciones

!USE TIPOS_DERIVADOS    !If we uncomment this line, the compiler doesn't block.
USE restricciones_constdist

IMPLICIT NONE

PRIVATE

CONTAINS

SUBROUTINE ADDrestrictolist(RS,LSRSS,handleout)
    implicit none
	CLASS(typerestric)::RS
    TYPE(typelista_restrics),TARGET::LSRSS
	CLASS(typerestric),POINTER,OPTIONAL,INTENT(OUT)::handleout
    
END SUBROUTINE ADDrestrictolist

END MODULE restricciones

[Johannes_Rieke]

Hi Dops,

I tested your code on PSXE2019U2 and U3 (after removing a typo in line 31 -> intent(in)).

PSXEU2 throws correctly an error:

D:\02_Fortran\99_test\PSXE2019U3_U4_infloop>ifort test.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.2.190 Build 20190117
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

test.f90(80): error #6457: This derived type name has not been declared.   [TYPELISTA_RESTRICS]
    TYPE(typelista_restrics),TARGET::LSRSS
---------^
test.f90(77): error #6404: This name does not have a type, and must have an explicit type.   [LSRSS]
SUBROUTINE ADDrestrictolist(RS,LSRSS,handleout)
-------------------------------^
compilation aborted for test.f90 (code 1)

PSXE2019U3 hangs (as expected U4 does) in an infinite loop. I think that's a bug introduced with U3, where the dependency checking for modules/submodules seems to be faulty. Both U2/U3 compiles fine, if you remove the restiction in line 59 to

USE TIPOS_DERIVADOS !,ONLY:typerestric,spMatrix

The error is not captured anymore in U3 (U4). For me that's a bug. You should open a ticket here, if not already done and make link to this thread.

BR, Johannes

[Daniel_Dopico]

Thank you very much, Johannes. I was waiting for confirmation before opening the ticket.

Daniel.

[Daniel_Dopico]

Done. I have just submitted the ticket. Fortunately it is easy to fix the code in order to get it working with update 4, but the problem can appear again in similar situations.

Thanks, everyone.

[Johannes_Rieke]

Hi Daniel, I'm glad, that I could help. I had misunderstood the error partially. Now re-reading the post, I tested PSXEU3 with modifying line 59 to

USE TIPOS_DERIVADOS,ONLY:typerestric,spMatrix,typelista_restrics

By this PSXE2019U2 compiles fine. However, although the code is now correct, PSXE2019U3 fails/is never proceeding. So, in addition to the not captured missing definition as shown in #9, correct code with 'only' does not compile. The latter is the more severe.

Thanks Daniel, for opening a ticket.

[Devorah_H_Intel]

Daniel Dopico wrote:

 ... I will give it another try.

I like this new big orange "Bug report" button. It make sense to have it here I normally ask here before sending a ticket.

Thank you, Steve.

Daniel, thank you for submitting the bug report and for the effort in reducing the code in question to a smaller test case.  I am glad to hear that you find the new 'bug report' button convenient.

[Daniel_Dopico]

I am glad to comment here that this bug has been fixed in next Compiler update (19.0 Update 5) coming out within 2 months.

It is really nice to have feedback from Intel about the bugs reported before a new release appears. In the past, it was quite frustrating to wait for a new release without information about wether your bug was corrected or not.

Congratulations to Intel for this feedback.