- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I also recommend -warn interface.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recognize that I am replying to a post that was made over four years ago. I have been trying out IFX 2024.2.0 on a number of forum posts that reported suspected optimization bugs.
The test code of this thread uses the variable LOCAL_5 before it has been assigned a value. On the next line, LOCAL_6 has the same issue.
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page