This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] sparc: remove ceil, floor, trunc sparc specific implementations
On 2016-08-01 14:57, David Miller wrote:
> From: Aurelien Jarno <aurelien@aurel32.net>
> Date: Mon, 1 Aug 2016 23:50:25 +0200
>
> > On 2016-08-01 14:44, David Miller wrote:
> >> From: Aurelien Jarno <aurelien@aurel32.net>
> >> Date: Mon, 1 Aug 2016 15:24:22 +0200
> >>
> >> > The ceil, floor and trunc functions on sparc do not fully follow the
> >> > standard and trigger an inexact exception when presented a value which
> >> > is not an integer. Since glibc 2.24 this causes a few tests to fail,
> >> > for instance:
> >>
> >> Carlos, this specific patch fixes most of the math failures on sparc,
> >> could we get this into the release?
> >
> > I think you should ask Adhemerval instead.
> >
> >> Aurelien, it looks like we have the same exact issue with nearbyint on
> >> sparc, right?
> >
> > I don't see the issue on nearbyint here. What is the issue exactly?
>
> Maybe only the vis3 variant shows the problem:
>
> Failure: nearbyint (sNaN): Exception "Invalid operation" not set
> Failure: nearbyint (-sNaN): Exception "Invalid operation" not set
> Failure: nearbyint_downward (sNaN): Exception "Invalid operation" not set
> Failure: nearbyint_downward (-sNaN): Exception "Invalid operation" not set
> Failure: nearbyint_towardzero (sNaN): Exception "Invalid operation" not set
> Failure: nearbyint_towardzero (-sNaN): Exception "Invalid operation" not set
> Failure: nearbyint_upward (sNaN): Exception "Invalid operation" not set
> Failure: nearbyint_upward (-sNaN): Exception "Invalid operation" not set
Hmm, that was supposed to be fixed by commit 2cbec36566. The failure is
actually different, here the exception is supposed to be set and it is
not.
Is it on sparc32? It looks like my patch is wrong for sparc32, as it
tests for sNaN before the value has been moved to the floating point
register. I guess I didn't notice because my test machine is a 64-bit
one, and depending on how you configure the 32-bit build, it consider it
as a cross-build and skip some tests, like this one.
Now about the fix itself, we have to move the check before the fsr is
saved and after the value has been moved to the floating point register,
which is not something easy to do without breaking the whole code. One
option would be to do it after loading the fsr at the end, the other one
would be to use the generic version.
> >> And that leaves the fdim failures, which are probably a similar
> >> problem.
> >
> > Yes, I am currently working on the fdim issue, to see if we should apply
> > the same strategy or fix it.
Well it starts to be late here, I am afraid it will be for tomorrow.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net