Internal Compiler Error with 15.0.1.148

[David_DiLaura1]

Steve, Colleagues,

I installed Update 1 for release 15.0 and now several files containing multiple subroutines no longer compile. The code is stable, has not been modified in a very long time, and compiled without incident in the last version of 14 and with the initial release of 15.0.  I generate both IA32 and x64 versions. There is no compiler error generating the IA32 version. For the simple code I list below I get the following when I compile for x64:

EXPR_ABS.MS128(t204_425)
 FATAL ERROR   : Compiler Internal Error
ifort: error #10273: Fatal error in C:\PROGRA~1\Intel\CO8318~1\bin\ia32_intel64\fortcom, terminated by 0x2

subroutine shaft_planes( verts1, verts2, shaft_plane, num_planes )
real(4) verts1(3,4), verts2(3,4), testvector(3,4,4), edges1(3,4), edges2(3,4), shaft_plane(4,8), possible(3)
integer(4) num_planes

edges1 = cshift(verts1,1,2)-verts1
edges2 = cshift(verts2,1,2)-verts2
!test vectors: from verts1 to verts2
do i=1,4
	do j=1,4
		testvector(:,i,j)=verts2(:,j)-verts1(:,i)
	end do
end do
MaxNumPlanes = num_planes
num_planes = 0
! planes will be hinged on the 4 edges of verts1
do i=1,4
	!find a vertex of verts2 that forms bounding plane with edge i of verts1
	verts2_loop: &
	do j=1,4
		! proposed plane normal for edge i of verts1 forms the 3 coeffs of (x,y,z) in the plane equation
		possible(1) =  edges1(2,i)*testvector(3,i,j)-edges1(3,i)*testvector(2,i,j)
		possible(2) =-(edges1(1,i)*testvector(3,i,j)-edges1(3,i)*testvector(1,i,j))
		possible(3) =  edges1(1,i)*testvector(2,i,j)-edges1(2,i)*testvector(1,i,j)
		! reject vertex j of verts2 if it is colinear with edge i of verts1
		if( all(abs(possible) < 1.0e-4) ) cycle verts2_loop
		! if we get here, we have a valid shaft plane. calc constant coeff in plane equation
		num_planes = num_planes + 1
		possible = possible/sqrt( possible(1)**2+possible(2)**2+possible(3)**2 )
		shaft_plane(1:3,num_planes) = possible
		shaft_plane(4,num_planes) = dot_product( possible,verts1(:,i))
		exit
		!if we've filled the quota of planes, return
		if(num_planes==MaxNumPlanes) return
	end do verts2_loop
end do
return
end subroutine shaft_planes

With an infinity of putzing, I found that the offending line is 25; the test of the absolute values of all the components of the vector possible. If this line is commented out, the routine compiles.

I am running Win7 32 (but notice I'm producing code for x64) in Visual Studio 2010. I'm asking for full optimization. The settings I using result in the following command line for the compiler (as reported by VS):

 /nologo /debug:full /O3 /Qvec-threshold:0 /free /Qopenmp /Qopt-report:5 /Qopt-report-phase:openmp /fpe:0 /module:"Release 2.8x64 OMP\\" /object:"Release 2.8x64 OMP\\" /Fd"Release 2.8x64 OMP\vc100.pdb" /traceback /check:none /libs:static /threads /c

These settings are project-wide and since other routines are threaded, I have OpenMP 'on'. 

Optimization /O2 or /O3 triggers the internal error. If I disable optimization with /Od, there is no internal error. Can you verify this problem?  Should I return to the initial release of 15.0?

David

[Steven_L_Intel1]

I can verify the error - /fpe:0 seems to be implicated (in that I don't get the error without it). If you require /fpe:0 for this source file, then feel free to revert to the 15.0.0 compiler. I will report this to the developers on Monday.

[Michel]

I also ran into a internal compiler error yesterday, in my case it was after I added /Qopt-report:5

Michel.

[Steven_L_Intel1]

Michel, please start a new thread for your problem and provide us with a test case. "Internal compiler error" can have many causes - and it's always a compiler bug underneath. 

[Steven_L_Intel1]

David, your case is escalated as issue DPD200363885. The vectorizer is doing something wrong. If you need to revert to 15.0.0 in order to make progress, then do that. Maybe you could compile this one source without /fpe:0 as an alternative.

[David_DiLaura1]

Steve,

Thanks for the update. Rather than revert, I'll compile this one piece without /fpe:0 since, as you pointed out, that gets a clean compile. That also means we can stick with the 15.1 redistributable package, since it isn't clear that we can mix packages from different updates.

David

[Steven_L_Intel1]

You can always use a newer redistributable package.

[Steven_L_Intel1]

This problem has been fixed in our sources. It ought to appear in update 2, planned for February, but I don't yet have confirmation of that.

[David_DiLaura1]

Steve,

Many thanks for following up. Glad it's fixed. This prompts another question: We have begun to distribute threaded code and so must include the OpenMP dll from the larger Intel Fortran redistribution package in our own installer. In the past, our installer has included individual pieces of code compiled with different updates -- depending on when the update become available and when we find bugs. Will it be necessary to (re)compile all code with the same updated compiler, since (as I understand it) the Intel redistribution package changes with each update?

David

[Steven_L_Intel1]

No, you don't have to recompile (except in extraordinary circumstances that are always called out in the release notes.) An exception is if you use /Qipo - that requires that all sources be compiled with the exact same version.