Optimizer failure in 15.0.2

[ereisch]

I've encountered a random crash in a program that we recently set to compile with "-auto" instead of "-save".  From what I've been able to tell, in the process of unwinding the loop on line 39 of "test2.for", it seems to have some out-of-order operations where it performs a mathematical operation (line 41: UNINIT_VAR(I)-LOCAL_2) using the value in one of the UNINIT_VAR prior to being set (line 40: UNINIT_VAR(I) = -(I-1)*LOCAL_4).  The random nature of the crash was because the random stack data that was being utilized for UNINIT_VAR(I) was only occasionally containing signaling NaNs.  I was finally able to get it to reproduce reliably by initializing the local variable "UNINIT_VAR" in the attached example to a signaling NaN.

The compile line we're using is (using compiler version 15.0.2):

ifort -extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -sox -warn noalignments,general,ignore_loc,truncated_source,uncalled,usage -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -mssse3 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-speculation=strict -prec-sqrt -fp-model strict -fp-model source -fpe0 -assume protect-parens -nogen-interfaces -O2 -fPIC -m32 -o test1.o -c -auto test1.for

ifort -extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -sox -warn noalignments,general,ignore_loc,truncated_source,uncalled,usage -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -mssse3 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-speculation=strict -prec-sqrt -fp-model strict -fp-model source -fpe0 -assume protect-parens -nogen-interfaces -O2 -fPIC -m32 -o test2.o -c -auto test2.for

ifort -m32 -o flt_test test1.o test2.o

The above will produce a floating point invalid operation on line 40 of test2.for.  This does not appear to happen when using 18.0.5, but I'd like to confirm this bug was actually fixed and just didn't get "hidden" by an intervening change.

[Steve_Lionel]

Please try it with 19.1 and see what you get. There's really no point in wasting cycles on a possible bug five versions ago.

[ereisch]

I don't have 19, but I did try it with 18.0.5 and it didn't have the issue.  But again, removing or changing certain lines in the test program made it go away with 15.  I wanted to make sure this was actually resolved, and didn't just "go back in its gopher hole" because the optimizer rules kicked in slightly differently in newer versions.

[Steve_Lionel]

There's no way to find out at this point, sorry. Even when I was working for Intel support, a request to try to analyze a bug in a years-old version that was not reproducible in a newer one would be greeted with, um, laughter, yes, that's it.... 

It's not at all unusual for optimizer bugs to be sensitive to code order. You'll just have to assume that the bug was fixed until or unless you find evidence to the contrary.

[ereisch]

Ok, we'll try compiling our entire program with -init=snan and -init=arrays to see if it shows back up.  We never do this on our optimized code, but I suppose it would be good practice to make sure nothing wonky is going on.

[Steve_Lionel]

I also recommend -warn interface.

[ereisch]

Yes, we do that in our debug compilation arguments, which is done first before building the optimized executables.

Speaking of optimized binaries, I recall awhile back there was no plan to implement any pragma (or other) directives to hint to the compiler the likelihood of certain conditions (such as GCC's __builtin_expect feature).  It was suggested at the time we just use profiler-driven optimization, but for numerous reasons we can't employ that.  Is it still the case that the programmer isn't able to directly pass hints to the optimizer?

[Steve_Lionel]

No, it is not the case. There are multiple directives in this category, including ASSUME and LOOP_COUNT. (There are others.) Read about them in the Language Reference chapter on Directive Enhanced Compilation (DEC). You will, of course, need to use a more recent compiler.