- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, I have encountered an Internal compiler error when compiling with codes below:
type :: test integer(1) :: a integer(1) :: b end type test type(test), parameter :: const = test(Z"7f", Z"80") end
The complier tells:
101004_2054 catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
But when codes changed to these:
integer(1), parameter :: max = Z"7f" integer(1), parameter :: min = Z"80" type :: test integer(1) :: a integer(1) :: b end type test type(test), parameter :: const = test(Z"7f", Z"80") end
It's just fine and no error occurred. Any suggestions ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The internal error should not happen and this issue may already be fixed. I cannot reproduce the internal error with the latest 16.0 Update 2 compiler:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.180 Build 20160204
If you have an earlier compiler version then you may need to consider upgrading or use a source code modification like what you showed as a temporary work around to avoid the error with your current compiler until you can upgrade.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The internal error should not happen and this issue may already be fixed. I cannot reproduce the internal error with the latest 16.0 Update 2 compiler:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.180 Build 20160204
If you have an earlier compiler version then you may need to consider upgrading or use a source code modification like what you showed as a temporary work around to avoid the error with your current compiler until you can upgrade.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Kevin, I'm using Intel(R) Visual Fortran Compiler XE 15.0.5.280, Maybe it's time to upgrade to 16 perhaps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I cannot reproduce the error with the Intel(R) 64 - 15.0 Update 5:
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.3.208 Build 20150407
I do not have the IA-32 15.0 Update 5 installed to try that. I tried both the Intel(R) 64 and IA-32 15.0 Update 6 and cannot reproduce the error with either of those.
Maybe I'm not matching your compiler options or compiler exactly, I'm not sure. Maybe you don't have a take the leap to 16.0 but rather just to 15.0 Update 6 but I can't say for sure without first reproducing the error.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All right, I'll try 15.0 Update 6 at first then.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hold your horses! It so happens that I still have 15.0.5.280, and for the first program of #1 it gave
c:\lang>ifort blane.f90 Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 15.0.5.280 Build 20150805 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 12.00.31101.0 Copyright (C) Microsoft Corporation. All rights reserved. -out:blane.exe -subsystem:console -incremental:no blane.obj c:\lang>
I suspect that your compiler installation has been corrupted in some way. Or, your source code may contain some invisible characters that cause the ICE, and we can look into this if you attach a zipped-up copy of the source file instead of displaying it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
Hold your horses! ..
That sounds right! What I notice is the internal compiler error (ICE) when /debug option is applied i.e., the ICE doesn't occur without it, for example with the Release configuration in Visual Studio. With /debug, I encounter the ICE with both Intel 17.0 compiler beta and compiler 16.0, update 2.
Now even with /debug on, the ICE disappears when the integer components of type test are moved up to kind 2 or the default kind (4) instead of leaving it at OP's value of kind 1. So the ICE is perhaps related to a possible integer overflow during named constant assignment with the structure constructor with a BOZ value of Z"80"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
I suspect that your compiler installation has been corrupted in some way. Or, your source code may contain some invisible characters that cause the ICE, and we can look into this if you attach a zipped-up copy of the source file instead of displaying it.
However, the source code I compiled was just like I wrote above. I tried with 16 update 2 (both ia32 and intel64) and no error came out, so this may have been fixed in that release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortranFan wrote:
Now even with /debug on, the ICE disappears when the integer components of type test are moved up to kind 2 or the default kind (4) instead of leaving it at OP's value of kind 1. So the ICE is perhaps related to a possible integer overflow during named constant assignment with the structure constructor with a BOZ value of Z"80"?
Since Z"80" and Z"7F" represent the minimum and maximum of integer(1) respectively, are assignment possible to cause integer overflow error ? I am a little confused here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I reproduced this now with just /Zi with the 16.0 Update 2 (and 17.0 Beta FortranFan noted) using the original 8-line test case. I'm still gathering the details to forward to Development. I'll note the internal tracking id soon.
C:\> ifort /Zi /c u628073.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.180 Build 20160204 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. 101004_2042 catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for u628073.f90 (code 1)
(Internal tracking id: DPD200410335)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Blane J. wrote:
Quote:
FortranFan wrote:
Now even with /debug on, the ICE disappears when the integer components of type test are moved up to kind 2 or the default kind (4) instead of leaving it at OP's value of kind 1. So the ICE is perhaps related to a possible integer overflow during named constant assignment with the structure constructor with a BOZ value of Z"80"?
Since Z"80" and Z"7F" represent the minimum and maximum of integer(1) respectively, are assignment possible to cause integer overflow error ? I am a little confused here.
Try this:
program p use, intrinsic :: iso_fortran_env, only : I1 => int8, output_unit implicit none write( output_unit, fmt="(*(g0))") "Range of I1: ", -huge(0_i1), " to ", huge(0_i1) write( output_unit, fmt="(g0,z0)") "128 in hexadecimal format: ", 128 write( output_unit, fmt="(g0,z0)") "min(I1) in hexadecimal format: ", -huge(0_i1) stop end program p
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ICE aside, I'd strongly recommend that the code in #1 use standard conforming syntax.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortranFan wrote:
Try this:
program p use, intrinsic :: iso_fortran_env, only : I1 => int8, output_unit implicit none write( output_unit, fmt="(*(g0))") "Range of I1: ", -huge(0_i1), " to ", huge(0_i1) write( output_unit, fmt="(g0,z0)") "128 in hexadecimal format: ", 128 write( output_unit, fmt="(g0,z0)") "min(I1) in hexadecimal format: ", -huge(0_i1) stop end program p
Hi, HUGE intrinsic would return the appropriate maximum value of an integer or a real data type, but I think the minimum is still uncertain since there's not an equivalent TINY intrinsic for integer type. Are there any relevant standard functions ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ianh wrote:
ICE aside, I'd strongly recommend that the code in #1 use standard conforming syntax.
More specific, please ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kevin Davis (Intel) wrote:
I reproduced this now with just /Zi with the 16.0 Update 2 (and 17.0 Beta FortranFan noted) using the original 8-line test case. I'm still gathering the details to forward to Development. I'll note the internal tracking id soon.
C:\> ifort /Zi /c u628073.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.180 Build 20160204 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. 101004_2042 catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for u628073.f90 (code 1)
(Internal tracking id: DPD200410335)
Hi, I reproduced ICE with Intel(R) Visual Fortran Compiler XE 15.0.6.285 (both ia-32 and intel 64) with debug mode:
------ Build started: Project: Test, Configuration: Debug|Win32 ------ Compiling with Intel(R) Visual Fortran Compiler XE 15.0.6.285 [IA-32]... Test.f90 101004_2054 catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for D:\Project\Test\Test.f90 (code 1) with options: /nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc140.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c =================================================== ------ Build started: Project: Test, Configuration: Debug|x64 ------ Compiling with Intel(R) Visual Fortran Compiler XE 15.0.6.285 [Intel(R) 64]... Test.f90 101004_2054 catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for D:\Project\Test\Test.f90 (code 1) with options: /nologo /debug:full /Od /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc140.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c
But not an error information on release mode for both.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Blane J. wrote:
Quote:
ianh wrote:
ICE aside, I'd strongly recommend that the code in #1 use standard conforming syntax.
More specific, please ?
The syntax rules only permit a BOZ literal constant as an argument to certain intrinsic functions, or as a constant in a data statement. A conforming variant of the second code fragment in #1 could be:
integer(1), parameter :: max = INT(Z"7f",1) integer(1), parameter :: min = INT(Z"80",1) type :: test integer(1) :: a integer(1) :: b end type test type(test), parameter :: const = test(INT(Z"7f",1), INT(Z"80",1)) end
From the perspective of the standard, a BOZ literal constant in isolation has no type or kind - it is really just a compact form of logical bits. The places where a BOZ literal constant are permitted to appear all result in an unambiguous and natural specification of the resulting type, kind and interpretation of the bits.
(An internal compiler error is still an error with the compiler that needs to be fixed, but I cannot trigger the internal compiler error if I use the standard conforming syntax. Because the syntax is not conforming you may find that when that internal compiler error is fixed, the resulting fixed compiler simply rejects your code. On the other hand, there are Intel compiler extensions that probably come into play here, the details of which I am not familiar with.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ianh wrote:
Quote:
The syntax rules only permit a BOZ literal constant as an argument to certain intrinsic functions, or as a constant in a data statement.
I just reviewed the standard and found it's just like what you said. The use of BOZ literal constant in the first fragment of #1 may turn out to be irrgular, and your example works fine with my compiler, thanks lanH.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page