Optimization problem ifort 11.1?

[castellg]

Hi, here is my problem. I have a subroutine that crashes (floating point error), but if I add a print* command line inside an "if loop" it works (see below). Moreover, the subroutine works when compiled with the -debug option.

It is a fairly simple subroutine, but the only strange thing could be that most variables are global (through a named common block) and not local.

I am running Ifort 11.1 under linux in an intel dual processor 64 bit computer.

Thanks for any comment!

--------------------

This is an extract of the subroutine.

--------------------

The common block:

common/KUEXT1/S_z_oct(num_grains,2*max_num_layers+1,num_octa_sys),

&Cnum(num_grains,2*max_num_layers+1,4),

&Elem_pos(num_elem,5)

common/KUEXT2/FIP_gl(num_grains,2*max_num_layers+1,num_octa_sys),

& FIP_elem(num_elem,num_octa_sys),

& gamma_dot_element(num_elem,num_octa_sys),

& gamma_cum_element(num_elem,num_octa_sys)

---------- and the loop that does not work if the print* line is commented.

do j=1,4

do i=1,2*max_num_layers+1

do k=1,num_grains

c print*, "Cnum=", Cnum(k,i,j), "grain", k, "level", i, "plane",j

if ( Cnum(k,i,j) .gt. 1.3 ) then

FIP_gl(k,i,3*j-2)=FIP_gl(k,i,3*j-2)/Cnum(k,i,j)

FIP_gl(k,i,3*j-1)=FIP_gl(k,i,3*j-1)/Cnum(k,i,j)

FIP_gl(k,i,3*j)= FIP_gl(k,i,3*j)/Cnum(k,i,j)

end if

end do

end do

end do

[mecej4]

Some of the symptoms do suggest the possibility of an optimizer-related Heisenbug. However, it is the nature of such bugs that their existence depends on many factors that are not at all made evident upon inspection of a code extract. Usually, if the compiler is doing something it should not, one needs a complete "reproducer", i.e., a self-contained short program that exhibits the same symptoms as your full program but is small enough to be suitable for others to compile and run.

[TimP]

What is posted looks as if it would vectorize, in the absence of the print. This would make more demands on program correctness, the crucial details lying outside of what you have posted.

[jimdempseyatthecove]

Try:

allocate(Cnum(num_grains+3, 2*max_num_layers+1, 4))
do j=1,4
do i=1,2*max_num_layers+1
do k = num_grains+1, num_grains+3
Cnum(k, i, j) = 1.0
end do
end do
end do

See if that "fixes" the floating point error
The above is assuming you are using REAL(4). If Cnum is REAL(8), then allocate to +1 and set the +1elements

Jim Dempsey

[castellg]

HI again. So, the problem with providing the entire code is that this is a subroutine run by a commercial software (ABAQUS), and I don't have access to the main code. However, this are the things I tried:

1) I created a mock main program to call the subroutine and it seems to work OK. Thus, my only option is to keep trying with the original scheme.

2) I went back to the initial configuration with the bug, and I defined Cnum as real*4 instead of real*8 (which was defined with an implicit definition). With only this modification the subroutine works! Any idea why?

3) I tried the allocation thing, but I am not sure why it didnt work. I added the allocatable and allocate definitions, expanded the range to num_grains+1 (real*8) and defined Cnum for those additional elements, but I had an error.

So, if it is useful I can paste the entire subrutine, but I don't have access to the code that calls it. Shall I paste the whole thing?

Thanks!!

Gustavo