Pointer to submodule: There has been an internal compiler error (C0000005).

[Daniel_Dopico]

1>fortcom: Fatal: There has been an internal compiler error (C0000005).

The mentioned error is obtained with the following piece of code in an Intel Parallel Studio XE 2017 Update 2 (I also attach the code and compilation results).

MODULE parent_module548963
    IMPLICIT NONE
    !> Abstract interfaces
    ABSTRACT INTERFACE
        SUBROUTINE proc_void()
        END SUBROUTINE proc_void
    END INTERFACE
   
    !> Procedure pointer
    PROCEDURE(proc_void),POINTER::ini_acel=>null()
   
    !> Submodule subroutine interface
    INTERFACE
        MODULE SUBROUTINE ini_acel_augHamilton()
        END SUBROUTINE ini_acel_augHamilton
    END INTERFACE

CONTAINS
    !C************************************************************
    !> Subroutine pointing the procedure pointer to the submodule subroutine
    SUBROUTINE finaliza_modelo
        INI_acel=>INI_acel_augHamilton
    END SUBROUTINE finaliza_modelo
END MODULE parent_module
!C************************************************************
!C************************************************************

!C************************************************************
!C************************************************************
SUBMODULE (parent_module) submod1
IMPLICIT NONE
CONTAINS
!C************************************************************
MODULE SUBROUTINE ini_acel_augHamilton()
    PRINT *,'Inside ini_acel_augHamilton'
END SUBROUTINE ini_acel_augHamilton

END SUBMODULE submod1
!C************************************************************
!C************************************************************

!C************************************************************
!C************************************************************
PROGRAM main
    USE parent_module
   
    CALL INI_ACEL_augHamilton
    CALL ini_acel
END PROGRAM main
   

[Kevin_D_Intel · Accepted solution]

Thank you for the defect report and convenient reproducer. I reproduced and reported this to our Developers.

(Internal tracking id: CMPLRS-42761)

[Daniel_Dopico]

I checked the code with the Parallel Studio XE 2018 and the bug seems corrected, isn't it?

[andrew_4619]

Daniel Dopico wrote:
I checked the code with the Parallel Studio XE 2018 and the bug seems corrected, isn't it?

We can only make assumptions on this based on the compiler behaviour because intel thinks it is too much effort to include in the release notes a list of issue tracking numbers that are closed by that particular release . If you think that is a bit meh then you are not alone. 

A developer working on a particular must release the solution into working versions for future release, so it would not seem that hard (in my simplistic thinking) to just note the tracking ID against that code set and to paste that list into the release notes when the release is made.....

[Daniel_Dopico]

Yes Andrew, I agree with you. I am paying quite a bit for this compiler and I would expect some more information about a bug that I need to get fixed. But instead of this I need to eagerly install the new version hoping that the functionality that I need to continue sharing code with my gfortran colleagues, is already working.

This is my second try, I installed 2017 update 4 and it was not fixed and no information was offered (I had to request it) and now no information with the 2018 release either.

[mecej4]

As we know from some of our own programs, a bug that had remained hidden for years may surface again when the code is recompiled with a new version of the compiler or with slightly different code generation options than those used in the past. In the same way, there is a difference between having a compiler bug resolved as a result of specific countermeasures taken by the compiler vendor rather than having that bug going back into hiding when a new compiler version is released.

Therefore, having a list of tracking IDs, titles and status strings ("fixed", "being addressed" and "unresolved", for example) will be quite helpful to users of the Intel compilers.

[FortranFan]

There may be another problem too if anyone from Intel Fortran team is reading this.  It is with incidents submitted by users themselves at the Online Service Center (OSC).  The status of these incidents also does not appear, at least to me, to be updated at a reasonable frequency.  That is, the status of the incidents can remain 'open' well past the time they are fixed in a compiler release (or update) and the users can remain unaware of the enhancements, similar to what OP is stating in Quote #5 above.  This can lead to an "opportunity cost" for the users and possibly Intel too.

As readers may know, Intel currently expects users to submit incidents by themselves at OSC.  But it's unclear if the development team or the customer interface team then updates the incidents soon after any development or bug-fixing effort on the incident occurs.  Or at least when the compiler changes to fix the issue finally get absorbed into BETA or a final release or update which can be long after the user had originally submitted the incident.

Can Intel team look into this aspect of their work process?  That is, if Daniel Dopico was following the OSC method back in May, Daniel would have submitted an incident toward this ICE and would have received a tracking ID to remain abreast of any developments by Intel Support/Development on the issue.  But if the status remained 'Open' and the incident remained dormant, Daniel Dopico would not have known if the issue was fixed in compiler 18.0.  Such dormancy is the state I'm noticing with many incidents I have myself submitted.  Hence I wonder about how and when users are getting informed with the new system.

Sure, one can say it is better for users to find their issues are getting resolved even if they are not being informed about it (and be 'pleasantly' surprised when a new release appears) than when the bugs never get fixed.  But users expect more and better from Intel!

[Devorah_H_Intel]

Daniel Dopico wrote:

I checked the code with the Parallel Studio XE 2018 and the bug seems corrected, isn't it?

I checked with development and yes, this bug was fixed in this release.