- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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>
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The fix for this issue is available in the latest PSXE 2017 Update 4 release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Works OK In 18.0.0.124 [IA-32]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@andrew: Thanks for checking. May not be worth losing F1 help to go to 18. May wait for F1 before jumping to 18.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@andrew: Thanks, that's a little cleaner than my work-around of moving the character parameter to inside subroutine "thingy".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So I have to give a minor apology for some of my comments above. Per FortranFan's suggestion, I tried to create a small project which demonstrated that my code is still broken. Andrew_4619 is correct that the Parameter bug is fixed in Intel FORTRAN Composer 2018. However, the compiler gives another ICE with C0000005 as the error code on the next line. A topic thread with two sample codes that another forum user created is at:
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/746478
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page