Joseph Myers wrote: > On Mon, 8 Oct 2018, Richard Biener wrote: >> So I think it would be fine if we'd have -fno-math-errno as documented >> and then the C library would annotate their math functions according >> to whether they will ever set errno or not. Once a math function is >> const or pure it cannot ever set errno so -fno-math-errno shouldn't have >> any effect. > > Note that "will ever set errno" includes possibly setting it in the > future, since code may be built with one libm version and used with > another. So it wouldn't be correct to have a "never sets errno" attribute > on glibc logb / lround / llround / lrint / llrint / fma / remquo (missing > errno setting is a known bug).
Math functions don't require errno to be set if math_errhandling doesn't specify MATH_ERRNO. So it's certainly feasible to guarantee errno won't ever be set. It would even be feasible to decide per application whether GLIBC sets errno or not. My feeling is that errno from math functions has been dead for long enough that removing support for it from libraries is very reasonable - and many libraries have already done so. Have there been any reports of this breaking large numbers of applications? > It also wouldn't be correct to have it on > many complex.h functions, because while a requirement to set errno is > never part of their interface, they may call real functions which may set > errno (and may sometimes move from not setting it to setting it; e.g., > they call the internal exp, sincos etc. functions, which for > implementations using a wrapper do not set errno, but for implementations > without a wrapper have errno setting integrated; whether this results in > errno set by complex functions depends on details of exactly how they > handle overflow etc. cases). Math functions (with or without a wrapper) can conditionally set errno if required. You could save/restore errno in really complicated math functions, as is done for rounding modes and exception flags. For the new math functions all errno handling is already done in a single function so you could do something like: if (want_errno) set_errno (error). >> glibc has the ieee entry points but I'm not sure if it has any way >> to use those by default. Adding more entry points is a bad idea, the __finite entry points and slow wrappers are bad enough as it is. The new optimized math functions use a much more efficient and maintainable approach. Wilco
