https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #13 from David Binderman <dcb314 at hotmail dot com> --- I had another look at the original source code and got this with recent gcc trunk: foundBugs $ ~/gcc/results/bin/gcc -w bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c && ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange bug998.c && ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange bug998.c && valgrind -q ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange -fsanitize=address bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange -fsanitize=undefined bug998.c && ./a.out checksum = 77A231E6 foundBugs $ Case 3 looks suspicious. I guess if I knew the which flags -O3 switches on, that aren't in -O2, I could find out which ones are causing trouble. I don't know a -O2.5 Case 4 makes it look like aliasing and loop interchange aren't at fault. Cases 5, 6 & 7 show that the usual tools find nothing wrong. Cases 6 & 7 make it looks like switching on a sanitizer makes the code work. I don't understand why that would be.
