This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/48139] __builtin_lrintf() becomes a library call, not an cvtss2si instruction
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 16 Mar 2011 12:15:37 +0000
- Subject: [Bug target/48139] __builtin_lrintf() becomes a library call, not an cvtss2si instruction
- Auto-submitted: auto-generated
- References: <bug-48139-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-16 12:14:35 UTC ---
(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.