https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77776
--- Comment #6 from Matthias Kretz <kretz at kde dot org> --- (In reply to Marc Glisse from comment #4) > Your "reference" number seems strange. Why not do the computation with > double (or long double or mpfr) or use __builtin_hypotf? Note that it > changes the value. Doh. (I didn't know the builtin exists. But use of (long) double should have been a no-brainer.) I guess my point was the precision of the input to sqrt not the result of sqrt. The sqrt makes that error almost irrelevant, though. My numerical analysis skills are not good enough to argue for what approach is better. But intuitively, keeping the information of the `amax` mantissa for the final multiplication around might actually make that approach slightly better (if the input to the sqrt were precise that wouldn't be true, though - but it never is). > How precise is hypot supposed to be? I know it is supposed to try and avoid > spurious overflow/underflow, but I am not convinced that it should aim for > correct rounding. That's a good question for all of <cmath> / <math.h>. Any normative wording on that question would be (welcome) news to me. AFAIK precision is left completely as QoI. So, except for the Annex F requirements (which we can drop with -ffast-math), let's implement all of <cmath> as `return 0;`. ;-) > (I see that you are using clang in that godbolt link, with gcc I need to > mark the global variables with "extern const" to get a similar asm) Thanks for the hint. I switched to clang when GCC started to produce code instead of constants in the asm. (I also like the unicode identifier support in clang ;-))
