Bug Report

[Blane_J_]

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 ?

[Kevin_D_Intel · Accepted solution]

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.

[Blane_J_]

Thanks Kevin, I'm using Intel(R) Visual Fortran Compiler XE 15.0.5.280, Maybe it's time to upgrade to 16 perhaps.

[Kevin_D_Intel]

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.

[Blane_J_]

All right, I'll try 15.0 Update 6 at first then.

[mecej4]

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.

[FortranFan]

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"?

[Blane_J_]

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.

[Blane_J_]

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.

[Kevin_D_Intel]

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)

[FortranFan]

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

[IanH]

ICE aside, I'd strongly recommend that the code in #1 use standard conforming syntax.

[Blane_J_]

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 ?

[Blane_J_]

ianh wrote:

ICE aside, I'd strongly recommend that the code in #1 use standard conforming syntax.

More specific, please ?

[Blane_J_]

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.

[IanH]

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.)

[Blane_J_]

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.