Re: [PATCH 1/2] sparc: remove ceil, floor, trunc sparc specific implementations

[David Miller <davem at davemloft dot net>]

From: Aurelien Jarno <aurelien@aurel32.net>
Date: Tue, 2 Aug 2016 01:59:24 +0200

> On 2016-08-01 14:57, David Miller wrote:
>> >> 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.

Yes, that looks like the reason why this is happening.

> 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.

My test machine is 64-bit too, just go:

davem@patience:~/src/GIT/GLIBC/build-sparcv9$ sparc32 bash
davem@patience:~/src/GIT/GLIBC/build-sparcv9$ ../glibc/configure --prefix=/usr --build=sparcv9-linux-gnu

or similar.

Actually I don't think using "sparc32" is even necessary (it makes
uname output "sparc" instead of "sparc64"), because "--build=" means a
native build for XXX.

> 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.

I'll look into this.