http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-16 12:16:24 UTC --- (In reply to comment #3) > (In reply to comment #2) > > But the lrintf() man page says explicitly that these functions cannot set > > errno. Is this the man page being too glibc-specific, or something else? > > Yes, the manpage is glibc and/or POSIX specific. The C99 standard says > > "On a domain error, the function returns an implementation-defined value; if > the integer expression math_errhandling & MATH_ERRNO is nonezero, the integer > expression errno acquires the value EDOM; if the integer expression > math_errhandling & MATH_ERREXCEPT is nonzero, the invalid floating-point > exception is raised." > > While glibc defines both MATH_ERRNO and MATH_ERREXCEPT it does not provide > a macro math_errhandling that expands to an expression of type int as > required by C99. So GCC has do deal with both eventualities and > conservatively > treat lrintf as setting errno. > > Recent Glibc define math_errhandling as > > /* By default all functions support both errno and exception handling. > In gcc's fast math mode and if inline functions are defined this > might not be true. */ > # ifndef __FAST_MATH__ > # define math_errhandling (MATH_ERRNO | MATH_ERREXCEPT) > # endif > > thus leave it undefined if __FAST_MATH__ is true. Without -ffast-math > the glibc implementation of lrintf is non-conforming as it claims it > would set errno. This is a glibc bug. Note that GCC likes to know if the library implementation would set errno or not (or raise exceptions), GLIBC wants to know whether GCC inline expansions would do so. The user (and C99) is of course only interested in the union of both.
