- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was creating some new code and a got an ICE in Debug build.....
Configuration: Debug|x64 ------
Compiling with Intel® Fortran Compiler Classic 2021.1.1 [Intel(R) 64]...
graphs_SUBS.f90
fortcom: Fatal: There has been an internal compiler error (C0000005).
So I downloaded and installed the latest compiler Fortran Compiler Classic 2021.4.0 [Intel(R) 64]...
and get the same problem as well as a now get and ICE in 26 other source files. There is clearly a regression. I went back to the older compiler and made a small reproducer (see below). I think the problem is referencing the module parameter that has been 'constructed'. I will have to work around it for now.
module testmod
implicit none
integer, parameter :: WS_OVERLAPPEDWINDOW = iany([int(Z'00000000'),int(Z'00C00000'),int(Z'00080000'),&
int(Z'00040000'),int(Z'00020000'),int(Z'00010000')] )
!integer, parameter :: WS_OVERLAPPEDWINDOW = 1 ! no ice
end module testmod
subroutine test()
use testmod
integer :: ifred
ifred = WS_OVERLAPPEDWINDOW
end subroutine test
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, I cannot duplicate the ICE on Windows or Linux with the 2021.4.0 compiler. Can you attach the BuildLog.htm so I can duplicate your compiler options?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ifort /nologo /debug:full /Od /debug-parameters:used test.f90
fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for test.f90 (code 1)
I had a play the debug-parameters I think is the trigger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's the "-debug-parameters used" that triggers the ICE. Thanks for your compiler options.
Now to file a bug report.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I filed CMPLRIL0-34376 for you. I'll let you know when I know more about its fix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks , note that at line 10 ifred=int(WS_OVERLAPPEDWINDOW) does not crash and ifred gets the correct value but if you hover over WS_OVER... in the debugger you do not see the correct value.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the additional information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
! file1.f90
module fred
implicit none
interface
module subroutine dnodpt( vftime )
real(8) :: vftime
end subroutine dnodpt
end interface
end module fred
!file.f90
submodule (fred) fred_SUBS
implicit none
contains
module subroutine dnodpt( vftime )
real(8) :: vftime
real(8), parameter :: rzero = 0.0_8
vftime = rzero
end subroutine dnodpt
end submodule fred_SUBS
I did a vs2022 installed and added Intel® Fortran Compiler – toolkit version: 2022.1.0, extension version 22.0.0065.17, Package ID: w_oneAPI_2022.0.0.161. The /debug-parameters:used test.f90
fortcom: Fatal: There has been an internal compiler error (C0000005). problem still exists, I had forgotten about it but when I pared down a reproducer it looked familiar and I then search and found this thread. The code above is another variation.
Any ideas when this might be fixed?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No updates on the fix yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The ICE reported when compiling fred.F90 (the second code snippet) is not at all related to the ICE with test.F90. I filed a new bug report, CMPLRIL0-34563, for Fred's ICE. I'll let you know the progress to a fix for this one, too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting, glad I reported it, I nearly didn't on the assumption it was the same thing but having created the test case I thought why not..... Thanks for the feedback.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I thought it was the same issue, too, and reported it as a second reproducer. But the compiler engineer quickly determined it was not. The second one has something to do with the symbol table.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And this is exactly why I kept trying to tell people that they were probably wrong in thinking that they had "the same problem" as someone else just because the symptom was the same. I'd always insist on a reproducer, and more often than not it was in fact a different problem.
Also, while minimal examples are great, also supply the original case if you can. Many times, I told a customer that a bug was fixed, because the cut-down test case now passed, but their full application still failed because of a different bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This might be related, or might be something different entirely:
MODULE API
INTERFACE
MODULE SUBROUTINE INTEGRATE ( XDOT ) BIND(C)
USE, INTRINSIC :: ISO_C_BINDING
IMPLICIT NONE
REAL(KIND=C_FLOAT), INTENT(IN) :: XDOT
END SUBROUTINE INTEGRATE
END INTERFACE
END MODULE API
SUBMODULE (API) INTEGRATE__
CONTAINS
MODULE PROCEDURE INTEGRATE
IMPLICIT NONE
STRUCTURE /SOME_ARRAY/
LOGICAL*1 TAG
END STRUCTURE
INTEGER*4 A
INTEGER*4 B
PARAMETER (A=100)
PARAMETER (B=16)
STRUCTURE /FOO_ARRAY/
RECORD/SOME_ARRAY/ FOO(A,B)
END STRUCTURE
END PROCEDURE INTEGRATE
END SUBMODULE INTEGRATE__
Compile with "ifort -c -g -debug-parameters" and you get an ICE. Using ifort version 2021.5.0 (also fails with 2021.4.0).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try:
integer, parameter :: WS_OVERLAPPEDWINDOW_int = &
[Z'00000000',Z'00C00000',Z'00080000',Z'00040000',Z'00020000',Z'00010000']
integer, parameter :: WS_OVERLAPPEDWINDOW = &
iany(WS_OVERLAPPEDWINDOW_int)
There was a case sometime back regarding BOZ and initialization via argument to intrinsic function. Initialization is OK, argument was not.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ereisch Your code compiles ok with ifx 2022.1.0 that is part of oneAPI HPC 2022.2. Unfortunately, ifort 2021.6.0 which is also part of oneAPI HPC 2022.2 still ICEs.
But there is some good news! I compiled it successfully with an internal version of ifort! That fix should be part of the next compiler release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes the two original issues CMPLRIL0-34376 and CMPLRIL0-34563 are still open having just tested in fort 2021.6.0. It is good to know that the end is in sight and debug-parameters can go back on.
Does anyone know why debug-parameters even exists, excluding symbols in debug by default is a strange thing to do. You get a hint from the options of a large performance penalty if there are large number of parameter constants though I suspect that is now a historical thing on no real relevance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issues you reported while using the compiler option -debug-parameters are fixed in the latest Fortran compiler, 2021.7.0. That version was released last week as part of oneAPI 2022.3.
Enjoy!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page