topic Quote:Johannes wrote: in Intel® Fortran Compiler

ICE with 17.4 and OO feature test - solved with PSXE 2018 up2

Johannes_Rieke — Mon, 07 Aug 2017 14:07:26 GMT

Hi all,

I played around with OO features to get familiar with it and stumbled over an ICE with PSXE 2017 update 4 (cp. attached build log).

1>------ Build started: Project: OO_Test_polymorph, Configuration: Debug x64 ------
1>Compiling with Intel(R) Visual Fortran Compiler 17.0.4.210 [Intel(R) 64]...
1>mod_fruit.f90
1>fortcom: Fatal: There has been an internal compiler error (C0000005).
1>compilation aborted for D:\02_Fortran\99_test\OO_Test_polymorph\mod_fruit.f90 (code 1)
1>smod_fruit.f90
1>OO_Test_polymorph.f90.

My test code is based on the example from Mark Leair 'Object-Oriented Programming in Fortran 2003 Part 2: Data Polymorphism' (https://gist.github.com/n-s-k/de4af7ce6cc8f2c85e4b33cedb51fd88), but I had to rework it, because of the license terms in the example header. The ICE does not occur in the original code from link above, but on a modified version of it.

Here it is:

submodule (mod_fruit) smod_fruit
  implicit none
  
  contains
  
  module subroutine initialize(fruit, color, filled, weight, price, diameter, misc)
    ! initialize shape objects
    class(fruit_t) :: fruit
    integer :: color
    logical :: filled
    integer :: weight
    integer :: price
    integer, optional :: diameter
    integer, optional :: misc

    fruit%color  = color
    fruit%filled = filled
    fruit%weight = weight
    fruit%price  = price
    
    select type (fruit)
    type is (fruit_t)
          ! no further initialization required
    class is (apple)
        ! rectangle or square specific initializations
        if (present(diameter))  then
           fruit%diameter = diameter
        else
           fruit%diameter = 0
        endif
        if (present(misc)) then
            fruit%misc = misc
        else
            fruit%misc = 0
        endif
    class default
      ! give error for unexpected/unsupported type
         stop 'initialize: unexpected type for sh object!'
    end select
    
    return
    
  end subroutine initialize
  
  
  !module function constructor(color, filled, weight, price)
  !      implicit none
  !      type(fruit_t) :: constructor
  !      integer :: color
  !      logical :: filled
  !      integer :: weight
  !      integer :: price
  !      call constructor%initialize(color, filled, weight, price)
  !      return
  !end function constructor
  
  
end submodule

module mod_fruit
  
  implicit none
  
  private

  type, public ::  fruit_t
      private
      integer :: color
      logical :: filled
      integer :: weight
      integer :: price
  contains
      private
      procedure :: initialize
  end type fruit_t
  
  type, extends(fruit_t), public :: apple
      private
      integer :: diameter
      integer :: misc
  end type apple
  
  type, extends(apple), public :: pi
  end type pi
  
  
  public :: constructor
  
  interface 
    module subroutine initialize(fruit, color, filled, weight, price, diameter, misc)
          implicit none
          class(fruit_t) :: fruit
          integer :: color
          logical :: filled
          integer :: weight
          integer :: price
          integer, optional :: diameter
          integer, optional :: misc
    end subroutine
  end interface
    
  ! this version works fine
  !interface 
  !  module function constructor(color, filled, weight, price)
  !      implicit none
  !      type(fruit_t) :: constructor
  !      integer :: color
  !      logical :: filled
  !      integer :: weight
  !      integer :: price
  !  end function constructor
  !end interface
  
  contains
  
  ! this version throws an ICE 'fortcom: Fatal: There has been an internal compiler error (C0000005).'
  function constructor(color, filled, weight, price)
        implicit none
        type(fruit_t) :: constructor
        integer :: color
        logical :: filled
        integer :: weight
        integer :: price
        call constructor%initialize(color, filled, weight, price)
        return
  end function constructor

end module

program OO_Test_polymorph
  use mod_fruit
  implicit none

  ! Variables
  type(fruit_t) :: my_fruit
  
  my_fruit = constructor(color=1,filled=.true.,weight=3, price=4)
  
end program OO_Test_polymorph

If the function 'constructor' is contained in the module mod_fruit, the ICE occurs. If only the interface is present and the function is placed in the submodule smod_fruit, the program runs fine. Is it forbidden to name a function constructor? What is wrong here.

Best regards, Johannes

Quote:Johannes wrote:

FortranFan — Mon, 07 Aug 2017 18:15:37 GMT

Johannes wrote:

.. What is wrong here...

An Intel Fortran compiler bug, unfortunately. And the bug is present in compiler 18.0 Beta update 1 as well. It'll be good if you can submit an incident at the Intel's Online Service Center.

As far as I can tell, the code looks alright but besides an ICE is always a compiler error.

Hi,

Johannes_Rieke — Tue, 08 Aug 2017 08:38:09 GMT

Hi,

I submitted the ICE to Intel's Online Service Center. The case number is 02992524, in case it helps anyone, maybe only interesting for the Intel experts here.

It costs about 10 minutes to file the things in Online Service Center, if you're not familiar with the web interface. But if it helps to getter better products...

@FortranFan: Thanks for your comment. Bad to hear, that 18 beta update 1 is also affected. Hopefully Intel can fix this before the official release of PSXE 2018 (in September/October ?).

Best regards, Johannes

Quote:johannes k. wrote:

Devorah_H_Intel — Fri, 11 Aug 2017 22:18:00 GMT

johannes k. wrote:

Hi,

I submitted the ICE to Intel's Online Service Center. The case number is 02992524, in case it helps anyone, maybe only interesting for the Intel experts here.

It costs about 10 minutes to file the things in Online Service Center, if you're not familiar with the web interface. But if it helps to getter better products...

Thank you, Johannes! Absolutely, it helps to improve our software products.

Hi all, the Intel support has

Johannes_Rieke — Wed, 16 Aug 2017 07:00:36 GMT

Hi all, the Intel support has confirmed the issue with an ICE for the above mentioned example for PSXE 2017 update 4, PSXE 2018 beta update 1 and for the latest build. The tracking ID is CMPLRS-45114. Thanks for the quick feedback. Definitely a plus for the OSC.

Hi, PSXE 2018 update 1 solved

Johannes_Rieke — Mon, 04 Dec 2017 16:46:52 GMT

Hi, PSXE 2018 update 1 solved the ICE issue, as I was informed by OSC. Unfortunately, I get another error now. Taking smod_fruit and the main program unchanged from the 1st post and changing mod_fuit to:

module mod_fruit
  
  implicit none
  
  private

  type, public ::  fruit_t
      private
      integer :: color
      logical :: filled
      integer :: weight
      integer :: price
  contains
      procedure :: initialize
  end type fruit_t
  
  type, extends(fruit_t), public :: apple
      private
      integer :: diameter
      integer :: misc
  end type apple
  
  type, extends(apple), public :: pi
  end type pi
  
  
  public :: constructor
  
  interface 
    module subroutine initialize(fruit, color, filled, weight, price, diameter, misc)
          implicit none
          class(fruit_t) :: fruit
          integer :: color
          logical :: filled
          integer :: weight
          integer :: price
          integer, optional :: diameter
          integer, optional :: misc
    end subroutine
  end interface
    
  !! this version works fine
  !interface 
  !  module function constructor(color, filled, weight, price, diameter, misc)
  !      implicit none
  !      type(fruit_t) :: constructor
  !      integer :: color
  !      logical :: filled
  !      integer :: weight
  !      integer :: price
  !      integer, optional :: diameter
  !      integer, optional :: misc
  !  end function constructor
  !end interface
  
  contains
  
  ! this version throws an ICE 'fortcom: Fatal: There has been an internal compiler error (C0000005).'
  ! UPDATE from PSXE 2018 update 1, no ICE occurs but: 
  !   1>error LNK2019: unresolved external symbol INITIALIZE referenced in function MOD_FRUIT_mp_CONSTRUCTOR
  !   1>x64\Debug\OO_Test_polymorph.exe : fatal error LNK1120: 1 unresolved externals
  function constructor(color, filled, weight, price)
        implicit none
        type(fruit_t) :: constructor
        integer :: color
        logical :: filled
        integer :: weight
        integer :: price
        call constructor%initialize(color, filled, weight, price)
        return
  end function constructor

end module

I don't understand the link error:

1>mod_fruit.obj : error LNK2019: unresolved external symbol INITIALIZE referenced in function MOD_FRUIT_mp_CONSTRUCTOR
1>x64\Debug\OO_Test_polymorph.exe : fatal error LNK1120: 1 unresolved externals

I did not change the interface nor the submodule for the initialize subroutine. The version where 'intitialize' and 'constructor' are both in the submodule and both have the interfaces in mod_fuit works still fine. Is there something wrong with public and private?

Quote:johannes k. wrote:

FortranFan — Mon, 04 Dec 2017 21:47:00 GMT

johannes k. wrote:

..I don't understand the link error:
1>mod_fruit.obj : error LNK2019: unresolved external symbol INITIALIZE referenced in function MOD_FRUIT_mp_CONSTRUCTOR
1>x64\Debug\OO_Test_polymorph.exe : fatal error LNK1120: 1 unresolved externals
I did not change the interface nor the submodule for the initialize subroutine. The version where 'intitialize' and 'constructor' are both in the submodule and both have the interfaces in mod_fuit works still fine. Is there something wrong with public and private?

@Johannes,

Chalk it up as another Intel Fortran compiler bug; it seems to now have some issue with including symbols of MODULE procedures in the mod files.

In your code if you replace the MODULE SUBROUTINE 'Initialize' with a contained procedure in your mod_fruit module itself, then the program builds fine

I suggest you submit another incident at the Intel OSC.

@FortranFan: Many thanks for

Johannes_Rieke — Tue, 05 Dec 2017 08:17:53 GMT

@FortranFan: Many thanks for your check. Your help is always welcome!

@all I reopened the ticket in OSC and will share the answers.

I will test, what gfortran 7.x will make of my code.

Hi,

Johannes_Rieke — Tue, 05 Dec 2017 17:20:28 GMT

Hi,

it seems to be a bug in PSXE 2018 update 1. gfortran-7.2 compiles and runs fine with the code above:

-------------- Build: Debug in OO_Test (compiler: GNU Fortran Compiler 7.2)---------------

gfortran-7.2 -Jobj/Debug/ -Wextra -Wall -fcheck=all  -g     -c /Fortran/OO_Test/mod_fruit.f90 -o obj/Debug/Dokumente/Fortran/OO_Test/mod_fruit.o
gfortran-7.2 -Jobj/Debug/ -Wextra -Wall -fcheck=all  -g     -c /Fortran/OO_Test/smod_fruit.f90 -o obj/Debug/Dokumente/Fortran/OO_Test/smod_fruit.o
gfortran-7.2 -Jobj/Debug/ -Wextra -Wall -fcheck=all  -g     -c /Fortran/OO_Test/OO_Test_polymorph.f90 -o obj/Debug/Dokumente/Fortran/OO_Test/OO_Test_polymorph.o
gfortran-7.2  -o bin/Debug/OO_Test obj/Fortran/OO_Test/mod_fruit.o obj/Fortran/OO_Test/smod_fruit.o obj/Fortran/OO_Test/OO_Test_polymorph.o   
Output file is bin/Debug/OO_Test with size 16,74 KB
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))

Hi,

Johannes_Rieke — Thu, 07 Dec 2017 16:21:11 GMT

Hi,

had to open a new ticket. This error seems to be related to:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/752376

and

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/752348

Hi, Lorri answered in another

Johannes_Rieke — Thu, 04 Jan 2018 17:05:36 GMT

Hi, Lorri answered in another thread to a related issue (submodule is also used), that 18.0.2 might solve the bug:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/753974

We had an unfortunate bug where we were generating incorrect 'external name' requests, and I think your program ran afoul of it.

This has been fixed in the sources that will be part of 18.0 Update 2, which is coming out soon.

Sorry for the inconvenience --

--Lorri

I took your original program

Lorri_M_Intel — Tue, 16 Jan 2018 19:44:58 GMT

I took your original program from #1 and built it successfully using our current internal build for the next 18.0 update

As much as I would love to tell you when the Update 2 is coming out, I can't. All I can say is "soon".

I'll put this note in the other topic as well.

--Lorri

Dear Lorri, many thanks for

Johannes_Rieke — Wed, 17 Jan 2018 08:55:40 GMT

Dear Lorri, many thanks for your update. I highly appreciate it and it's very good to know, that update 2 solves this issue, too.

Best regards, Johannes

Hi, I can confinrm that PSXE

Johannes_Rieke — Thu, 22 Mar 2018 12:03:15 GMT

Hi, I can confinrm that PSXE 2018 update 2 solves the issues. My example works fine now. Thanks Intel team!