https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Filip Kastl from comment #6) > Removing the 'wrong-code' keyword. Talked about -Ofast SPEC miscompares > with Richi and now I understand that those aren't really miscompilations: > With -Ofast, FP computations can always have large numerical error. > > However, we still want to be able to compile and run SPEC benchmarks with > -Ofast so this is still worth looking into. Perhaps we can change something > in GCC to get rid of this numerical error. Or we find out that it makes > more sense to compile the benchmark with some additional flags or something > like that. > Im not really a FP person, so I am not sure what options are likely to bring things back in line for you. -Ofast can certainly be problematic with SPEC. Someone else can probably help there Given the nature of the change that caused this (trimming integral ranges bounds to match the bitmasks) its probable that a smaller range had some other pass make a different decision. We wont know for sure until its been reduced a bit and know where the difference is coming from.
