This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FE_INEXACT exception question (lrint function on aarch64)
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: sellcey at cavium dot com, libc-alpha <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com
- Date: Thu, 22 Jun 2017 10:07:17 +0100
- Subject: Re: FE_INEXACT exception question (lrint function on aarch64)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <1498082443.31950.66.camel@cavium.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 21/06/17 23:00, Steve Ellcey wrote:
> I have a question about floating point exceptions and the lrint function.
> While working on ILP32 mode for aarch64 I get these glibc failures in 32 bit
> mode (but not in 64 bit mode). I believe that all of these cases are
> due to aarch64 setting the FE_INEXACT exception as well as the FE_INVALID
> exception whereas the x86 sets only the FE_INVALID exception. If we
> were converting to a 64 bit long all of these would raise only the FE_INEXACT
> exception on both the x86 and aarch64 because the resulting values fit into
> a 64 bit long.
>
> My question is: Is it wrong to set the FE_INEXACT exception as long as
> one is also setting the FE_INVALID exception? If so, what standard
> (C,C++,POSIX,IEEE) requires that we not set it.
>
this is a bug that only affects ilp32 because there are
non-integer double precision values (like 0x7fffffff.8p0)
that are out of range of ilp32 long after rounding.
(the largest non-integer finite double is 0x1p52 - 0.5
which is in range of lp64 long)
so on ilp32 the rounding step raises inexact the conversion
step raises invalid (because the value is out of range)
which is incorrect, so the inline asm optimization does
not work on ilp32.