This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/48139] __builtin_lrintf() becomes a library call, not an cvtss2si instruction


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]