Re: glibc 2.25 machine status?

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 03/02/2017 09:08, Siddhesh Poyarekar wrote:
> Hi all,
> 
> So the summary for status is now as follows:
> 
> - There are failures on SPARC32 that need fixing

It is not only for sparc32, all sparc assembly implementation requires fixes
for sNaN/qNaN distinction. I took a quick look at this and:

  1. Removing sparc assembly implementation is the straightforward fix, as
     pointed out by David.

  2. sparc default implementation [1]] is slight slower for default finite number
     compared to C code.  The advantage is shows constant performance for all
     kind of inputs, while C implementation is showers for Inf/{q,s}NaNs.  However
     it will likely get slower with the sNaN/qNaN fix since it will most likely
     requires more instructions to fix it.

  3. sparc vis3 [2] is faster than C implementation for all inputs, however as for
     2. it might get slower with the proper fix.

One option could be removing [1] and check if fixing [2] yields any performance gain
compared to [1].  Otherwise removing both is the best option.

In any way, it is a nice fix to have, but it is not a release blocker imho.

[1] sysdeps/sparc/sparc64/fpu/s_f{max,min}.S and ./sysdeps/sparc/sparc32/sparcv9/fpu/s_f{max.min}.S
[2] sysdeps/sparc/sparc64/fpu/multiarch/s_f{max,min}-vis3.S and 
    ./sysdeps/sparc/sparc32/sparcv9/fpu/multiarch/s_f{max.min}-vis3.S

> 
> - I am not clear on the resolution status of pr#20915.  It appeared
>   that there was consensus on reverting one of the hunks from commit
>   17af5da9 but there seem to be differences in that
> 
> - I have posted a tunables test case fix that I'll commit soon if
>   nobody objects
> 
> Pr 20915 is the only blocker so provided that it is resolved in time, I
> intend to cut a release this Sunday.  If the blocker is not resolved in
> time, the release will be on the day or one day after the blocker is
> resolved, depending on how it aligns with my timezone and/or my sleep
> pattern at that time.
> 
> Siddhesh
>