topic >>For example, if VOLCHECK is in Intel® Fortran Compiler

ifort optimizations causing unexpected floating point results

Wasif__Syed — Mon, 27 Apr 2020 22:50:02 GMT

Hello,

I recently upgraded our FORTRAN application (a finite element code) from Intel 14.0 to Intel 19.0. I also upgraded from Visual Studio 2008 to Visual Studio 2017. After the upgrade, I noticed some unexpected results from floating point operations.

I was able to narrow it down to FORTRAN optimizations. Our application uses "Maximize Speed plus Higher Level Optimizations (/O3)", where I see the problem. I didn't see the problem after disabling optimizations and didn't see these upto "Maximize Speed (/O2)". However, O3 shows the issue with Intel 19.0. This was not a problem with Intel 14.0. Here's a code snippet describing the problem:

module vol
real*8, dimension(:), allocatable::tl_vol
end module vol

if (allocated(tl_vol))then
deallocate(tl_vol)
endif
allocate(tl_vol(1:num_),STAT=IALLOC_ERR)

do n = 1,num_ !!num_ is 100000 for this case
call calc_vol(tl_vol(n)) !!This subroutine calculates tl_vol(n)
write(6,*) 'tl_vol(n)', tl_vol(n) !!Output is okay here, tl_vol is small ~E-14
volcheck = tl_vol(n) !!volcheck is 0.0 (why??)
enddo

Can someone help me understand what might be going on? Again, this is only a problem when I use O3 for FORTRAN optimization.

Thanks,

Syed

When you combine higher

mecej4 — Tue, 28 Apr 2020 11:36:00 GMT

When you combine higher levels of optimization with symbolic debugging enabled, you may expect only loose synchronization between variables and the values shown for them in the VS debugger. Similarly, you may see the highlighting of the current source line to be jumping back and forth in an annoying manner.

For example, if VOLCHECK is a scalar real, the optimizer may keep the variable entirely in a register, with no copy in memory, or may update/copy to memory only intermittently. The value shown for it (in the locals list or by hovering on the variable in the code panel) may be stale or not yet available.

If there is a compiler bug associated with /O3, you will need to run the debugger at the assembly level to establish that the bug exists.

Thanks for the reply. I don't

Wasif__Syed — Tue, 28 Apr 2020 12:02:25 GMT

Thanks for the reply. I don't only see the problem in the debugger but while running the actual application as well (x64 release executable). I confirmed this by printing out the value of VOLCHECK. VOLCHECK is used for calculations downstream, which become NaN due to it being zero.

Not much can be done until

mecej4 — Tue, 28 Apr 2020 12:28:03 GMT

Not much can be done until you are able to provide a "reproducer" -- a program that demonstrates the claimed/suspected optimization bug, while being as short as possible and can be obtained with a reasonable amount of work.

A question that surfaces with reports of optimizer bugs is: how can we be sure that the cause of the bug is the optimizer rather than an error in the source code or program logic?

Adding print statements often inhibits optimization. If your printing occurs far away from the place in the code where the bug was generated, however, such inhibition may not have occurred.

>>For example, if VOLCHECK is

jimdempseyatthecove — Tue, 28 Apr 2020 15:09:24 GMT

>>For example, if VOLCHECK is a scalar real, the optimizer may keep the variable entirely in a register, with no copy in memory, or may update/copy to memory only intermittently.

Also, with optimizations /O2 and above, if VOLCHECK is not used, the generated code will remove the statement (but the Debug symbols still remain).

Jim Dempsey