[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #9 from Rich Felker --- Indeed, I don't think the ABI says anything about this; a bug against the psABI should probably be opened.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #8 from Vincent Lefèvre --- (In reply to Rich Felker from comment #7) > Note that such an option would be nice to have anyway, for arbitrary > functions, since it's necessary for being able to call code that was > compiled with -fexcess-precision=fast from code that can't accept the > non-conforming/optimizer-unsafe behavior and safely use the return value. It > should probably be an attribute, with a flag to set the global default. For > example, __attribute__((__returns_excess_precision__)). If you're talking about arbitrary functions, they may have been implemented in languages other than C, anyway. So that's an ABI issue. If the ABI allows excess precision, then GCC must assume that excess precision is possible.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #7 from Rich Felker --- I'll inquire about it. Note that F.6 already requires this for C functions; the loophole is just that the implementation itself does not inherently have to consist of C functions. If it's determined that C won't require the library functions not bound to IEEE operations to return values representable in their nominal type, then GCC needs to be aware of whether the target libc can be expected to do so, and if not, it needs to, as a special case, assume there might be excess precision in the return value, so that (double)retval==retval can't be assumed to be true in the optimizer. Note that such an option would be nice to have anyway, for arbitrary functions, since it's necessary for being able to call code that was compiled with -fexcess-precision=fast from code that can't accept the non-conforming/optimizer-unsafe behavior and safely use the return value. It should probably be an attribute, with a flag to set the global default. For example, __attribute__((__returns_excess_precision__)).
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #6 from joseph at codesourcery dot com --- Do you have any reference to a proposal to that effect? The current wording in N2454 regarding this says "IEC 60559 requires operations with specified operand and result formats. Therefore, math functions that are bound to IEC 60559 operations (see table above) must remove any extra range and precision from arguments or results." - and glibc already implements that (on 32-bit x86, don't know the state for m68k) for the limited subset of library functions that are bound to such operatons, as well as dealing with the cases where excess range may be involved, as previously noted. But most functions are not bound to an IEEE operation and so are not covered by that requirement.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #5 from Rich Felker --- My understanding is that C2x is fixing this underspecification and will require the library functions to drop excess precision as if they used a return statement. So this really should be fixed in glibc if it's still an issue; if they accept fixing that I don't think GCC needs any action on this. I just fixed it in musl.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #4 from joseph at codesourcery dot com --- I think the glibc reasoning is: libm functions do not need to behave as if written in standard C, so in particular F.6 does not apply to them and they may return values with excess precision. Thus libm functions use math_narrow_eval (or equivalent assembler macros) in cases where there may be overflow and underflow (where excess *range* may be a problem, possibly resulting in missing errno setting), but not where there may be excess precision without excess range. (Functions with fully defined results such as sqrt still take care to avoid excess precision in their results.) However, that then implies GCC ought to know which standard library functions (only) might return with excess precision, so that casts / assignments of the results of those functions can remove that excess precision. Which is tricky, both because it should only apply to standard library functions, not to user functions where it's the user's responsibility to compile consistently with -fexcess-precision=standard, and because the IR available in the front end does not represent the ABI information that particular return types are capable of being returned with excess precision (you'd need to distinguish a function's ABI return type from its semantic return type and produce calls with the ABI return type). Or you could systematically use math_narrow_eval on all float / double function returns that might have excess range / precision (or maybe in the wrappers where wrappers are used, to avoid affecting glibc-internal uses that don't need this as well as to reduce the number of places needing changing - but if you do it in the wrappers you don't fix things for the __*_finite functions), but there would be some performance cost to doing so.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #3 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #1) > This is interesting because log2 should have already done a rounding to > double before returning. I suppose that if the C library has been built with GCC without -fexcess-precision=standard (explicitly or implied), then this rounding is not done. I've done my tests on a Debian/unstable machine (currently glibc 2.24).
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 Paul Zimmermann changed: What|Removed |Added CC||zimmerma+gcc at loria dot fr --- Comment #2 from Paul Zimmermann --- I was able to reproduce with gcc 7.2.0 and: GNU libc version: 2.24 GNU libc release: stable Paul Zimmermann
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target||i?86-*-* --- Comment #1 from Andrew Pinski --- This is interesting because log2 should have already done a rounding to double before returning. What glibc version are you using because that matters here too.
