https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127824
--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Manuel López-Ibáñez from comment #4) > (In reply to Manuel López-Ibáñez from comment #3) > > Sorry, I thought I had tried -ffast-math but it seems I didn't. > > > > Clang has a new builtin to help in these cases: > > https://clang.llvm.org/docs/LanguageExtensions.html#builtin-assume- > > dereferenceable > > but it doesn't seem to make any difference here. That's not the problem here. My understanding is that Clang needs this builtin because LLVM-IR has issues with load speculation. GCC doesn't have this limitation, but the rejection isn't because of speculation of the accesses, it's about speculation of traps. i.e. we have already insured it's safe to access a and b speculatively, however lets say a[1] is a sNAN but the scalar code exits the loop at a[0] the vector code would raise the sNAN because it evaluated both a[0..1] at the same time.
