This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, i386]: Implement lrint and llrint as x87 intrinsic function, TAKE 2
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: ubizjak at gmail dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 17 Aug 2006 15:06:53 +0200
- Subject: Re: [PATCH, i386]: Implement lrint and llrint as x87 intrinsic function, TAKE 2
- References: <42426D53.3080703@kss-loka.si> <84fc9c000608170209x44402141k231ee6738298131e@mail.gmail.com> <20060817143944.toghshayoz8co8so@ssl.kss.si>
On 8/17/06, Uros Bizjak <uros.bizjak@kss-loka.si> wrote:
Quoting Richard Guenther <richard.guenther@gmail.com>:
>> This patch implements lrint and llrint as x87 instrinsic function. This
>> patch fits into BUILT_IN_LLRINT and BUILT_IN_LRINT middle-level
>> infrastructure that was jus comitted to mainline.
> Was there a particular reason to use these only if
> flag_unsafe_math_optimizations?
They don't set errno when argument is too large.
That would be !flag_errno_math. flag_unsafe_math_optimizations doesn't care
about errno. The builtin expanders in builtins.c care about emitting extra code
if flag_errno_math is true, so backend patterns do not need to care about
errno (which is my understanding).
So, is the lrint expansion computing wrong values in certain
conditions? If not,
we should drop flag_unsafe_math_optimizations from the expander and the insns.
Richard.