This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/3] Add more tests for trunc.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Matt Turner <mattst88 at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 25 May 2016 10:46:34 +0000
- Subject: Re: [PATCH 2/3] Add more tests for trunc.
- Authentication-results: sourceware.org; auth=none
- References: <1464139950-31943-1-git-send-email-mattst88 at gmail dot com> <1464139950-31943-2-git-send-email-mattst88 at gmail dot com>
On Tue, 24 May 2016, Matt Turner wrote:
> Some implementations of truncf(x) add 2**23 to x with the rounding mode
> set to truncate before subtracting 2**23 to produce the truncated
> result. Unfortunately this doesn't work for odd values of x greater than
> 2**23, since the result of the addition is inexact and the parity bit is
> lost by the rounding step. The same problems apply to implementations of
> trunc on other floating-point data types.
I think the same tests should be added for all of ceil, floor, round,
trunc if not already present.
> + TEST_f_f (trunc, 0x1p63 + 1, 0x1p63 + 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> TEST_f_f (trunc, 0x1p64, 0x1p64, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> TEST_f_f (trunc, 0x1p65, 0x1p65, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> TEST_f_f (trunc, 0x1p105, 0x1p105, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> + TEST_f_f (trunc, 0x1p105 + 1, 0x1p105 + 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> TEST_f_f (trunc, 0x1p106, 0x1p106, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> TEST_f_f (trunc, 0x1p107, 0x1p107, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> TEST_f_f (trunc, 0x1p112, 0x1p112, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
> + TEST_f_f (trunc, 0x1p112 + 1, 0x1p112 + 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
These need to suffix the constants with 'L' so that they actually test
what's intended for long double. And doing arithmetic like that in
libm-test.inc makes manipulation to change suffixes, as in
<https://sourceware.org/ml/libc-alpha/2016-05/msg00474.html>, harder. So
I think it's better to write all the constants explicitly without
arithmetic (0x1.000002p23L, 0x1.0000000000001p52L,
0x1.0000000000000002p63L, 0x1.000000000000000000000000008p105L,
0x1.0000000000000000000000000001p112L).
--
Joseph S. Myers
joseph@codesourcery.com