This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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] |
Hi! On Thu, 04 Apr 2013 21:25:52 +0200, Andreas Jaeger <aj@suse.com> wrote: > On 04/04/2013 04:59 PM, Thomas Schwinge wrote: > > On Thu, 04 Apr 2013 16:26:17 +0200, Andreas Jaeger <aj@suse.com> wrote: > >> On Thursday, April 04, 2013 16:17:45 Thomas Schwinge wrote: > >>> On Thu, 04 Apr 2013 09:38:58 +0200, Andreas Jaeger <aj@suse.com> > >> wrote: > >>>> On Wednesday, April 03, 2013 22:03:31 Thomas Schwinge wrote: > >>>>> @@ -139,7 +141,7 @@ __ieee754_pow(double x, double y) { > >>>>> > >>>>> } > >>>>> else if (qx == 0x7ff00000) > >>>>> > >>>>> return y < 0 ? 0.0 : INF.x; > >>>>> > >>>>> - return NaNQ.x; /* y not > >>>>> integer and x<0 */ + return (x - x) / (x - x); > >>>>> /* y not integer and x<0 */> > >>>> I'm not convinced of this change, the rest is fine. > >>>> > >>>> The above raises an invalid exception - but the previous code did > >>>> not. Why is this change still fine? > >>> > >>> If my code and specification reading is correct, then this is a bug in > >>> the original code, for IEEE 754-2008 says: Âpow (x, y) signals the > >>> invalid operation exception for finite x < 0 and finite non-integer > >>> yÂ, and/but this didn't matter in practice, as the wrapper code in > >>> math/w_pow.c:__pow would catch this case and handle it separately via > >>> sysdeps/ieee754/k_standard.c:__kernel_standard, case 24, raising an > >>> INVALID exception on its own. Can you confirm my reasoning? > >>> We could be adding the respective tests to libm-tests with > >>> <http://news.gmane.org/find-root.php?message_id=%3C871uaqzheb.fsf%40sc > >>> hwinge.name%3E> (or something similar) in place. > >> > >> libm-tests already checks for the invalid exception, > > > > It does, but only for the default POSIX error handing mode, which is > > provided (at least for the case we're discussing here) by > > __kernel_standard, case 24, but libm-tests does not check for the right > > exceptions being set in IEEE error handling mode, for example. > > Yes, indeed, I have now verified my reasoning/change using the following patch, which could go in as soon as the Âlibm-test: switching the error handling behavior patch (see the Gmane URL above) is in. So, strictly speaking, the __ieee754_pow change cited at the top of this email is a bug fix (though in the default POSIX error reporting behavior it is hidden by the w_pow wrapper), and I have thus filed BZ #15342, will mention that one in the NEWS file, ChangeLog snippet and and commit log, and close it right after pushing my fix. diff --git math/libm-test.inc math/libm-test.inc index d6d811c..e1369b4 100644 --- math/libm-test.inc +++ math/libm-test.inc @@ -9739,9 +9739,13 @@ pow_test (void) TEST_ff_f (pow, 0x1p-72L, minus_zero, 1); TEST_ff_f (pow, -0.1L, 1.1L, qnan_value, INVALID_EXCEPTION); + TEST_ff_f_IEEE (pow, -0.1L, 1.1L, qnan_value, INVALID_EXCEPTION); TEST_ff_f (pow, -0.1L, -1.1L, qnan_value, INVALID_EXCEPTION); + TEST_ff_f_IEEE (pow, -0.1L, -1.1L, qnan_value, INVALID_EXCEPTION); TEST_ff_f (pow, -10.1L, 1.1L, qnan_value, INVALID_EXCEPTION); + TEST_ff_f_IEEE (pow, -10.1L, 1.1L, qnan_value, INVALID_EXCEPTION); TEST_ff_f (pow, -10.1L, -1.1L, qnan_value, INVALID_EXCEPTION); + TEST_ff_f_IEEE (pow, -10.1L, -1.1L, qnan_value, INVALID_EXCEPTION); TEST_ff_f (pow, -1.01L, min_subnorm_value, qnan_value, INVALID_EXCEPTION); TEST_ff_f (pow, -1.01L, -min_subnorm_value, qnan_value, INVALID_EXCEPTION); TEST_ff_f (pow, -1.0L, min_subnorm_value, qnan_value, INVALID_EXCEPTION); GrÃÃe, Thomas
Attachment:
pgplUFqKQpvJi.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |