ICE C0000005 When compiling Fortran Module with Integer Parameter Statements

[matthew_bernardnrc_g]

When using the 2017 Update 2, I get an ICE C000005  when compiling modules in my code which contain integer parameter statements at the module level and then are used within contained subroutines. In cases where it is possible, I can remove the parameter statement and the code is able to compile the module, however there are instances within my code where the integer parameters are used in case statements so those variables cannot be changed.

I will note that 2016 Update 4 is the last time the intel fortran compiler was able to compile my code. Each iteration of 2017 has introduced a new issue that has completely stopped my development. It is extremely frustrating to have to pay for a license to a code which has not functioned in nearly 6 months. Each time I update I have to completely uninstall 2017 and reinstall 2016 because for some reason the 2017 forces a significant change to the MSVS integration.

[Kevin_D_Intel]

I’m sorry to hear about your disappointing experiences with our 2017 release. We do test the compiler regularly with an extensive test suite to aid catching defects beforehand and avoid creating user experiences like yours. I’m hopeful for the past issues you have been able to provide reproducers to help us resolve those defects for you.

Would you be able to provide a small complete reproducer for this new issue that I can send to our Developers?

[matthew_bernardnrc_g]

Yes, for the past few versions I have provided Intel with reproducers. I haven't had the opportunity to test whether my past bug reports have been fixed because these new issues keep appearing.

Unfortunately, I haven't been able to create a simplified project for this compiler bug. I cant provide the whole project for my code and when I move the modules that cause the internal compiler error into their own project the code compiles successfully. If you have any suggestion for generating a useful dump I am willing to try.

[Kevin_D_Intel]

I believe another user reported and isolated the same regression that could be affecting you. More details are described in the forum post here.

Will you please check to see whether you have /debug-parameters enabled with /debug:full and if so remove/disable use of /debug-parameters to see if that avoids the internal error for your case.

[matthew_bernardnrc_g]

I modified the /debug-parameters statement and my code compiles and runs now. I believe these issue submitted by the other developer is the same issue I identified. Thank you for your help.

[Kevin_D_Intel]

Thank you for the update. It is good to hear your code now compiles and runs with 17.0 Update 2. We will keep this post updated about the status of fixing the defect with /debug-parameters.

(Internal tracking id: DPD200418283)

(Resolution Update on 05/12/2017): This defect is fixed in the Intel® Parallel Studio XE 2017 Update 4 release (ifort Version 17.0.4.210 Build 20170428 - PSXE 2017.4.051 / CnL 2017.4.210 - Windows)

[Kevin_D_Intel]

The fix for this issue is available in the latest PSXE 2017 Update 4 release.

[Ed_Martin]

I have the same ICE issue with character parameters using PSXE 2017 Update 4.

    module ice

    implicit none
    character(*), parameter :: ld='82'
    contains
    subroutine thingy
        call bob(ld)
    end subroutine thingy
    subroutine bob(I)
        character(*),intent(in) :: I
        print *, I
    end subroutine bob
    end module ice

Code from andrew_4619 modified to create example

[Lorri_M_Intel]

Hi Ed -

        Yes, unfortunately the fix that went into Update 4 did not cover character parameters.

        However, Update 5 *does* have the character parameter fix.   For Windows, the Update 5 kit launched in late October.

                            Regards --

                                         --Lorri

[Ed_Martin]

Lorri,

Installed Update 5.  No joy!  Still have the ICE. Have logged with Intel customer support.

On the plus side, Update 5 does appear to work with Visual Studio 2017 version 15.4.2

[andrew_4619]

Works OK In 18.0.0.124 [IA-32]

[Ed_Martin]

@andrew:  Thanks for checking.  May not be worth losing F1 help to go to 18. May wait for F1 before jumping to 18.

[andrew_4619]

A workaround was to put char params in a separate module e.g.

module tmpice
    implicit none
    character(*), parameter :: ld='82'
end module tmpice
  
module ice
    use tmpice
    implicit none
    contains
    subroutine thingy
        call bob(ld)
    end subroutine thingy
    subroutine bob(I)
        character(*),intent(in) :: I
        print *, I
    end subroutine bob
end module ice

[Ed_Martin]

@andrew:  Thanks, that's a little cleaner than my work-around of moving the character parameter to inside subroutine "thingy".

[jimdempseyatthecove]

Mathew,

I think Andrew needs to be rewarded with a Best Answer/Response on this one as it is an elegant work around.

Jim Dempsey

[matthew_bernardnrc_g]

Jim,

While I am glad that Andrew has a work around for his code, this workaround does not work for my code. I get the same ICE for modules which only contain params and then are used in other places in the code. Not only that, the work around that we use in Intel composer 17 which is to change the compiler option for "Information for PARAMETER Constants" in the debugging section in the FORTRAN projects  from All to None no longer works in Intel Composer 2018 and our code doesn't compile at all.

I am currently waiting for 2018 update 1 to provide a status update.

[FortranFan · Accepted solution]

matthew.bernardnrc.gov wrote:

.. this workaround does not work for my code. I get the same ICE for modules which only contain params and then are used in other places in the code. ..

@Matthew,

Have you considered the following variant to the small reproducer given by Ed Martin in Quote #8 where instead of employing a named constant of CHARACTER type directly as a dummy argument, a local copy is used?  This too seems to avoid the ICE in both Intel Fortran compiler 17.0 update 4 as well as compiler 18.0:

module ice
   implicit none
   character(*), parameter :: ld='82'
contains
   subroutine thingy
      ! Suggested Workaround: use local variable(s) as dummy argument(s) instead of
      ! named constants
      character(len=:), allocatable :: s
      s = ld ! Workaround
      call bob(s)
   end subroutine thingy
   subroutine bob(I)
      character(*),intent(in) :: I
      print *, I
   end subroutine bob
end module ice

xxx>ifort /c /debug:full /debug-parameters:all /standard-semantics /warn:all /stand m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.4.210 Build 20170411
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.


xxx>

xxx>ifort /c /debug:full /debug-parameters:all /standard-semantics /warn:all /stand m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.


xxx>

[matthew_bernardnrc_g]

I have not attempted this change in our code because the burden of entry is quite high due to the large number of parameters (several hundered) in our code but I am pretty sure that this would not work for us based on my experience with this bug. A small but maybe important difference between the workaround code and my code is that almost all of our parameters are real/integer constants. We get an ICE at any line a parameter is executed so I would expect an ICE at line 9 in subroutine thingy where you set the dummy variable in your code. 

[FortranFan]

matthew.bernardnrc.gov wrote:

.. I am pretty sure that this would not work for us based on my experience with this bug. A small but maybe important difference between the workaround code and my code is that almost all of our parameters are real/integer constants. ..

@Matthew,

According to Intel staff (see Quote #9), the gap in the compiler fix toward the ICE was with named constants of the CHARACTER type.  Hence the workaround snippet that makes use of this type.

Based on your experience you say you're "pretty sure" the suggested workaround won't work.  Well, what you're indicating is a "gut feel": it would have been interesting if you could extrapolate from it and put together a small reproducer.  That might lead to more interesting discussions in this thread and possibly offer more workarounds and may be more cases for Intel Fortran team to study.

[andrew_4619]

matthew.bernardnrc.gov wrote:

.... debugging section in the FORTRAN projects  from All to None no longer works in Intel Composer 2018 and our code doesn't compile at all.I am currently waiting for 2018 update 1 to provide a status update.

Now this confuses me. The original ICE in 17 was fixed in 17.4 I recall but a variant where the parameter was of type character was missed. This was fixed in 18.0. All tests I have made in 18 support this. Do you get an ICE in 18, is that what "our code doesn't compile at all" means? If so then maybe you have found another bug or variant and it would be very helpful if you could provide a small reproducer.