Re: [PATCH] Fix powf overflow handling in non-nearest rounding mode

Corinna Vinschen <[email protected]> Tue, 11 Dec 2018 12:56:14 +0100

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

On Dec 10 15:04, Szabolcs Nagy wrote:
> Follows the fix in https://github.com/ARM-software/optimized-routines

> From 8ff59d2f4e0209f03c30462e9319baf4c6ba79f7 Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <[email protected]>
> Date: Mon, 10 Dec 2018 14:40:01 +0000
> Subject: [PATCH] Fix powf overflow handling in non-nearest rounding mode
> 
> The threshold value at which powf overflows depends on the rounding mode
> and the current check did not take this into account. So when the result
> was rounded away from zero it could become infinity without setting
> errno to ERANGE.
> 
> Example: pow(0x1.7ac7cp+5, 23) is 0x1.fffffep+127 + 0.1633ulp
> 
> If the result goes above 0x1.fffffep+127 + 0.5ulp then errno is set,
> which is fine in nearest rounding mode, but
> 
>   powf(0x1.7ac7cp+5, 23) is inf in upward rounding mode
>   powf(-0x1.7ac7cp+5, 23) is -inf in downward rounding mode
> 
> and the previous implementation did not set errno in these cases.
> 
> The fix tries to avoid affecting the common code path or calling a
> function that may introduce a stack frame, so float arithmetics is used
> to check the rounding mode and the threshold is selected accordingly.
> ---
>  newlib/libm/common/sf_pow.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Pushed.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (application/pgp-signature, 833 B)