This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove alpha specific fmax, fmin to fix sNaN handling [BZ #20947]
- From: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 1 Jan 2018 16:00:41 +0100
- Subject: Re: [PATCH] Remove alpha specific fmax, fmin to fix sNaN handling [BZ #20947]
- Authentication-results: sourceware.org; auth=none
- References: <20171231163825.9768-1-aurelien@aurel32.net> <7f8e7304-a9b0-9925-62bd-b916a10a4a98@linaro.org>
On 2017-12-31 17:37, Adhemerval Zanella wrote:
>
>
> On 31/12/2017 14:38, Aurelien Jarno wrote:
> > Various fmax and fmin function implementations mishandle sNaN
> > arguments:
> >
> > (a) When both arguments are NaNs, the return value should be a qNaN,
> > but sometimes it is an sNaN if at least one argument is an sNaN.
> >
> > (b) Under TS 18661-1 semantics, if either argument is an sNaN then the
> > result should be a qNaN (whereas if one argument is a qNaN and the
> > other is not a NaN, the result should be the non-NaN argument).
> > Various implementations treat sNaNs like qNaNs here.
> >
> > One way to fix that is to detect the sNaN and add a special case. That
> > said there is no FPU instruction to do that, so it requires transfering
> > the FP value to an integer register and testing bits. This becomes quite
> > complicated so it's probably better to just use the generic versions of
> > these functions which just do that through issignaling.
> >
> > Changelog:
> > [BZ #20947]
> > * sysdeps/alpha/fpu/s_fmax.S: Remove file.
> > * sysdeps/alpha/fpu/s_fmaxf.S: Likewise.
> > * sysdeps/alpha/fpu/s_fmin.S: Likewise.
> > * sysdeps/alpha/fpu/s_fminf.S: Likewise.
>
> LGTM. I think other alpha math functions suffers from similar issue (ceil and
> floor at lest).
Thanks for the review. ceil and floor have already been fixed in commits
062e53c195 and 65cc568cf5. What is left are many issues with the
exceptions, mostly "Inexact" ones, but they are more difficult to fix.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net