Excerpts from Jakub Jelinek via Gcc-patches's message of November 11, 2022 10:09 am: > Hi! > > Here is the floating point division fold_range implementation, > as I wrote in the last mail, we could outline some of the common parts > into static methods with descriptive names and share them between > foperator_div and foperator_mult. > > Bootstrapped/regtested on top of the earlier version of the multiplication > fold_range on x86_64-linux and i686-linux, regressions are > +FAIL: gcc.dg/pr95115.c execution test > +FAIL: libphobos.phobos/std/math/hardware.d execution test > +FAIL: libphobos.phobos_shared/std/math/hardware.d execution test
I've had some time to look at the Phobos failures, and seems to me that it's a poorly written test. pragma(inline, false) static void blockopt(ref real x) {} real a = 3.5; // Set all the flags to zero resetIeeeFlags(); assert(!ieeeFlags.divByZero); blockopt(a); // avoid constant propagation by the optimizer // Perform a division by zero. a /= 0.0L; assert(a == real.infinity); assert(ieeeFlags.divByZero); blockopt(a); // avoid constant propagation by the optimizer 1. Since this patch, that `a /= 0.0L` operation no longer appears in the final assembly - so no divide-by-zero flags are raised. 2. Whoever introduced blockopt() perhaps did not understand that `a /= 0.0L` is not safe from constant propagation just because it is surrounded by some uninlinable call. I'll fix the test in upstream, it should really be something like: pragma(inline, false) static real forceDiv(real x, real y) { return x / y; } a = forceDiv(a, 0.0L); assert(a == real.infinity); assert(ieeeFlags.divByZero); Regards, Iain.