New math test failures on Fedora/33

New math test failures on Fedora/33

[H.J. Lu via Libc-alpha]

On Fedora 33, I got these new math test failures:

FAIL: math/test-double-cosh
FAIL: math/test-float32x-cosh
FAIL: math/test-float64-cosh

for i686 glibc like

Failure: cosh_upward (-0x2.c5d374p+12): Exception "Overflow" not set
Failure: cosh_upward (-0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
Failure: cosh_upward (-0x2.c5d37700c6bbp+12): Exception "Overflow" not set
Failure: cosh_upward (-0x2.c5d378p+12): Exception "Overflow" not set
Failure: cosh_upward (-0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
Failure: cosh_upward (-0x2.c679d4p+8): Exception "Overflow" not set
Failure: cosh_upward (-0xf.ffffffffffff8p+1020): Exception "Overflow" not set
Failure: cosh_upward (-0xf.fffffp+124): Exception "Overflow" not set
Failure: cosh_upward (0x2.c5d374p+12): Exception "Overflow" not set
Failure: cosh_upward (0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
Failure: cosh_upward (0x2.c5d37700c6bbp+12): Exception "Overflow" not set
Failure: cosh_upward (0x2.c5d378p+12): Exception "Overflow" not set
Failure: cosh_upward (0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
Failure: cosh_upward (0x2.c679d4p+8): Exception "Overflow" not set
Failure: cosh_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
Failure: cosh_upward (0xf.fffffp+124): Exception "Overflow" not set


-- 
H.J.

Re: New math test failures on Fedora/33

[Adhemerval Zanella via Libc-alpha]

On 11/01/2021 13:00, H.J. Lu via Libc-alpha wrote:
> On Fedora 33, I got these new math test failures:
> 
> FAIL: math/test-double-cosh
> FAIL: math/test-float32x-cosh
> FAIL: math/test-float64-cosh
> 
> for i686 glibc like
> 
> Failure: cosh_upward (-0x2.c5d374p+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c5d37700c6bbp+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c5d378p+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c679d4p+8): Exception "Overflow" not set
> Failure: cosh_upward (-0xf.ffffffffffff8p+1020): Exception "Overflow" not set
> Failure: cosh_upward (-0xf.fffffp+124): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d374p+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d37700c6bbp+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d378p+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c679d4p+8): Exception "Overflow" not set
> Failure: cosh_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
> Failure: cosh_upward (0xf.fffffp+124): Exception "Overflow" not set

This is a regression of BZ#18980 caused by 9e97f239eae1f2b1.  The original
issue was fixed by c8235dda728c445, but the patch did not add the fix for
wordsize64 version because it does not require back then (since it seems
to happen on 32-bit, at least I am seeing on i686).

This seems to fix it:

diff --git a/sysdeps/ieee754/dbl-64/e_cosh.c b/sysdeps/ieee754/dbl-64/e_cosh.c
index 4f41ca2c92..81de5ae6bd 100644
--- a/sysdeps/ieee754/dbl-64/e_cosh.c
+++ b/sysdeps/ieee754/dbl-64/e_cosh.c
@@ -33,6 +33,7 @@
 
 #include <math.h>
 #include <math_private.h>
+#include <math-narrow-eval.h>
 #include <libm-alias-finite.h>
 
 static const double one = 1.0, half=0.5, huge = 1.0e300;
@@ -80,6 +81,6 @@ __ieee754_cosh (double x)
        if(ix>=0x7ff00000) return x*x;
 
     /* |x| > overflowthresold, cosh(x) overflow */
-       return huge*huge;
+       return math_narrow_eval (huge * huge);
 }
 libm_alias_finite (__ieee754_cosh, __cosh)

Re: New math test failures on Fedora/33

[H.J. Lu via Libc-alpha]

On Mon, Jan 11, 2021 at 8:28 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 11/01/2021 13:00, H.J. Lu via Libc-alpha wrote:
> > On Fedora 33, I got these new math test failures:
> >
> > FAIL: math/test-double-cosh
> > FAIL: math/test-float32x-cosh
> > FAIL: math/test-float64-cosh
> >
> > for i686 glibc like
> >
> > Failure: cosh_upward (-0x2.c5d374p+12): Exception "Overflow" not set
> > Failure: cosh_upward (-0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
> > Failure: cosh_upward (-0x2.c5d37700c6bbp+12): Exception "Overflow" not set
> > Failure: cosh_upward (-0x2.c5d378p+12): Exception "Overflow" not set
> > Failure: cosh_upward (-0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
> > Failure: cosh_upward (-0x2.c679d4p+8): Exception "Overflow" not set
> > Failure: cosh_upward (-0xf.ffffffffffff8p+1020): Exception "Overflow" not set
> > Failure: cosh_upward (-0xf.fffffp+124): Exception "Overflow" not set
> > Failure: cosh_upward (0x2.c5d374p+12): Exception "Overflow" not set
> > Failure: cosh_upward (0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
> > Failure: cosh_upward (0x2.c5d37700c6bbp+12): Exception "Overflow" not set
> > Failure: cosh_upward (0x2.c5d378p+12): Exception "Overflow" not set
> > Failure: cosh_upward (0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
> > Failure: cosh_upward (0x2.c679d4p+8): Exception "Overflow" not set
> > Failure: cosh_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
> > Failure: cosh_upward (0xf.fffffp+124): Exception "Overflow" not set
>
> This is a regression of BZ#18980 caused by 9e97f239eae1f2b1.  The original
> issue was fixed by c8235dda728c445, but the patch did not add the fix for
> wordsize64 version because it does not require back then (since it seems
> to happen on 32-bit, at least I am seeing on i686).
>
> This seems to fix it:
>
> diff --git a/sysdeps/ieee754/dbl-64/e_cosh.c b/sysdeps/ieee754/dbl-64/e_cosh.c
> index 4f41ca2c92..81de5ae6bd 100644
> --- a/sysdeps/ieee754/dbl-64/e_cosh.c
> +++ b/sysdeps/ieee754/dbl-64/e_cosh.c
> @@ -33,6 +33,7 @@
>
>  #include <math.h>
>  #include <math_private.h>
> +#include <math-narrow-eval.h>
>  #include <libm-alias-finite.h>
>
>  static const double one = 1.0, half=0.5, huge = 1.0e300;
> @@ -80,6 +81,6 @@ __ieee754_cosh (double x)
>         if(ix>=0x7ff00000) return x*x;
>
>      /* |x| > overflowthresold, cosh(x) overflow */
> -       return huge*huge;
> +       return math_narrow_eval (huge * huge);
>  }
>  libm_alias_finite (__ieee754_cosh, __cosh)

It fixed i686.  Can you check it in?

BTW, I also saw random failure:

FAIL: misc/tst-bz21269
[hjl@gnu-skx-1 build-i686-linux]$ cat misc/tst-bz21269.out
Timed out: killed the child process
Termination time: 2021-01-11T18:13:03.494991075
Last write to standard output: 2021-01-11T18:12:43.491654736
[hjl@gnu-skx-1 build-i686-linux]$

Is this a known issue?

Thanks.

-- 
H.J.

Re: New math test failures on Fedora/33

[Adhemerval Zanella via Libc-alpha]

On 11/01/2021 15:37, H.J. Lu wrote:
> On Mon, Jan 11, 2021 at 8:28 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 11/01/2021 13:00, H.J. Lu via Libc-alpha wrote:
>>> On Fedora 33, I got these new math test failures:
>>>
>>> FAIL: math/test-double-cosh
>>> FAIL: math/test-float32x-cosh
>>> FAIL: math/test-float64-cosh
>>>
>>> for i686 glibc like
>>>
>>> Failure: cosh_upward (-0x2.c5d374p+12): Exception "Overflow" not set
>>> Failure: cosh_upward (-0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
>>> Failure: cosh_upward (-0x2.c5d37700c6bbp+12): Exception "Overflow" not set
>>> Failure: cosh_upward (-0x2.c5d378p+12): Exception "Overflow" not set
>>> Failure: cosh_upward (-0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
>>> Failure: cosh_upward (-0x2.c679d4p+8): Exception "Overflow" not set
>>> Failure: cosh_upward (-0xf.ffffffffffff8p+1020): Exception "Overflow" not set
>>> Failure: cosh_upward (-0xf.fffffp+124): Exception "Overflow" not set
>>> Failure: cosh_upward (0x2.c5d374p+12): Exception "Overflow" not set
>>> Failure: cosh_upward (0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
>>> Failure: cosh_upward (0x2.c5d37700c6bbp+12): Exception "Overflow" not set
>>> Failure: cosh_upward (0x2.c5d378p+12): Exception "Overflow" not set
>>> Failure: cosh_upward (0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
>>> Failure: cosh_upward (0x2.c679d4p+8): Exception "Overflow" not set
>>> Failure: cosh_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
>>> Failure: cosh_upward (0xf.fffffp+124): Exception "Overflow" not set
>>
>> This is a regression of BZ#18980 caused by 9e97f239eae1f2b1.  The original
>> issue was fixed by c8235dda728c445, but the patch did not add the fix for
>> wordsize64 version because it does not require back then (since it seems
>> to happen on 32-bit, at least I am seeing on i686).
>>
>> This seems to fix it:
>>
>> diff --git a/sysdeps/ieee754/dbl-64/e_cosh.c b/sysdeps/ieee754/dbl-64/e_cosh.c
>> index 4f41ca2c92..81de5ae6bd 100644
>> --- a/sysdeps/ieee754/dbl-64/e_cosh.c
>> +++ b/sysdeps/ieee754/dbl-64/e_cosh.c
>> @@ -33,6 +33,7 @@
>>
>>  #include <math.h>
>>  #include <math_private.h>
>> +#include <math-narrow-eval.h>
>>  #include <libm-alias-finite.h>
>>
>>  static const double one = 1.0, half=0.5, huge = 1.0e300;
>> @@ -80,6 +81,6 @@ __ieee754_cosh (double x)
>>         if(ix>=0x7ff00000) return x*x;
>>
>>      /* |x| > overflowthresold, cosh(x) overflow */
>> -       return huge*huge;
>> +       return math_narrow_eval (huge * huge);
>>  }
>>  libm_alias_finite (__ieee754_cosh, __cosh)
> 
> It fixed i686.  Can you check it in?

I will do it.

> 
> BTW, I also saw random failure:
> 
> FAIL: misc/tst-bz21269
> [hjl@gnu-skx-1 build-i686-linux]$ cat misc/tst-bz21269.out
> Timed out: killed the child process
> Termination time: 2021-01-11T18:13:03.494991075
> Last write to standard output: 2021-01-11T18:12:43.491654736
> [hjl@gnu-skx-1 build-i686-linux]$
> 
> Is this a known issue?

No I am aware, this tests is based on the kernel one
tools/testing/selftests/x86/ldt_gdt.c (more specifically the
do_multicpu_tests subtest) and the only difference seems kernel
one forces the sched_affinity.

Re: New math test failures on Fedora/33

[Paul Zimmermann]

       Hi,

about such failures that come out several days after the corresponding commit,
I'm surprised there is no continuous integration scheme with glibc. This would
help to detect very soon such issues.

Paul

Re: New math test failures on Fedora/33

[Adhemerval Zanella via Libc-alpha]

On 12/01/2021 04:13, Paul Zimmermann wrote:
>        Hi,
> 
> about such failures that come out several days after the corresponding commit,
> I'm surprised there is no continuous integration scheme with glibc. This would
> help to detect very soon such issues.
> 
> Paul
> 

We had buildbots setup for x86/i686 some time ago [1], but if I recall correctly
they were setup by Roland McGrath when he was a maintainer using the google
infrastructure. Since he left the project I am not sure the state of the bots.

Currently we only have aarch64/armhf that provide any meaningful information.
Maybe Tulio can give us a better idea of the current status of the powerpc
ones.

Afaik the infra of the waterfall server itself was done by Siddhesh.

I personally thing to have a working CI for at least the most usual architectures
would be a great thing, however I think we are lacking resources here.

[1] http://glibc-buildbot.reserved-bit.com/waterfall

Re: New math test failures on Fedora/33

[Siddhesh Poyarekar]

On 1/12/21 10:59 PM, Adhemerval Zanella wrote:
> Currently we only have aarch64/armhf that provide any meaningful information.
> Maybe Tulio can give us a better idea of the current status of the powerpc
> ones.
> 
> Afaik the infra of the waterfall server itself was done by Siddhesh.
> 
> I personally thing to have a working CI for at least the most usual architectures
> would be a great thing, however I think we are lacking resources here.

I only did the DNS redirect I think; the server was set up by someone 
else, either Roland or Tulio.

Siddhesh

Re: New math test failures on Fedora/33

[Tulio Magno Quites Machado Filho via Libc-alpha]

Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:

> Currently we only have aarch64/armhf that provide any meaningful information.
> Maybe Tulio can give us a better idea of the current status of the powerpc
> ones.

I lost access to the 3 servers I had a while ago.
It's been difficult to find 32-bit powerpc servers after that.

During the pandemic, I also lost access to the ansible playbooks I used to
create the controller and the ppc workers.
I've just recovered them, but I'm able to add just ppc64le and ppc64 servers.
Not optimal, but better than what we have now.

During the last 2 Cauldrons, we've also discussed improvements that are
necessary to make this BuildBot useful.
They're all still pending.

In case there is anyone willing to help, the repository is available at:
https://sourceware.org/git/?p=glibc-buildbot.git;a=summary

-- 
Tulio Magno

Re: New math test failures on Fedora/33

[Paul Zimmermann]

       Dear Tulio,

are you using the GCC compile farm (https://cfarm.tetaneutral.net/)?

Best regards,
Paul

> From: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>
> Date: Tue, 12 Jan 2021 16:14:02 -0300
> 
> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
> 
> > Currently we only have aarch64/armhf that provide any meaningful information.
> > Maybe Tulio can give us a better idea of the current status of the powerpc
> > ones.
> 
> I lost access to the 3 servers I had a while ago.
> It's been difficult to find 32-bit powerpc servers after that.
> 
> During the pandemic, I also lost access to the ansible playbooks I used to
> create the controller and the ppc workers.
> I've just recovered them, but I'm able to add just ppc64le and ppc64 servers.
> Not optimal, but better than what we have now.
> 
> During the last 2 Cauldrons, we've also discussed improvements that are
> necessary to make this BuildBot useful.
> They're all still pending.
> 
> In case there is anyone willing to help, the repository is available at:
> https://sourceware.org/git/?p=glibc-buildbot.git;a=summary
> 
> -- 
> Tulio Magno

Re: New math test failures on Fedora/33

[Adhemerval Zanella via Libc-alpha]

I am no sure if we are allowed to run buildbots on gcc compiler farm
infrastructure.

On 13/01/2021 03:34, Paul Zimmermann wrote:
>        Dear Tulio,
> 
> are you using the GCC compile farm (https://cfarm.tetaneutral.net/)?
> 
> Best regards,
> Paul
> 
>> From: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>
>> Date: Tue, 12 Jan 2021 16:14:02 -0300
>>
>> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
>>
>>> Currently we only have aarch64/armhf that provide any meaningful information.
>>> Maybe Tulio can give us a better idea of the current status of the powerpc
>>> ones.
>>
>> I lost access to the 3 servers I had a while ago.
>> It's been difficult to find 32-bit powerpc servers after that.
>>
>> During the pandemic, I also lost access to the ansible playbooks I used to
>> create the controller and the ppc workers.
>> I've just recovered them, but I'm able to add just ppc64le and ppc64 servers.
>> Not optimal, but better than what we have now.
>>
>> During the last 2 Cauldrons, we've also discussed improvements that are
>> necessary to make this BuildBot useful.
>> They're all still pending.
>>
>> In case there is anyone willing to help, the repository is available at:
>> https://sourceware.org/git/?p=glibc-buildbot.git;a=summary
>>
>> -- 
>> Tulio Magno

Re: New math test failures on Fedora/33

[Carlos O'Donell via Libc-alpha]

On 1/13/21 7:51 AM, Adhemerval Zanella via Libc-alpha wrote:
> I am no sure if we are allowed to run buildbots on gcc compiler farm
> infrastructure.

AFAIK we are not.

-- 
Cheers,
Carlos.

Re: New math test failures on Fedora/33

[Carlos O'Donell via Libc-alpha]

On 1/12/21 2:14 PM, Tulio Magno Quites Machado Filho via Libc-alpha wrote:
> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
> 
>> Currently we only have aarch64/armhf that provide any meaningful information.
>> Maybe Tulio can give us a better idea of the current status of the powerpc
>> ones.
> 
> I lost access to the 3 servers I had a while ago.
> It's been difficult to find 32-bit powerpc servers after that.
> 
> During the pandemic, I also lost access to the ansible playbooks I used to
> create the controller and the ppc workers.
> I've just recovered them, but I'm able to add just ppc64le and ppc64 servers.
> Not optimal, but better than what we have now.
> 
> During the last 2 Cauldrons, we've also discussed improvements that are
> necessary to make this BuildBot useful.
> They're all still pending.
> 
> In case there is anyone willing to help, the repository is available at:
> https://sourceware.org/git/?p=glibc-buildbot.git;a=summary

DJ and I have been discussing this as a project for 2021.

More importantly I think we need to shift this to CI/CD and integrate it
into patchwork. I want to see fails reported per-patch. Then glue the
CI/CD into that using new infrastructure (runners + builbot try bot).

I continue to feel that we need confidence to integrate new patches and
that confidence doesn't come from build bots, but comes from CI/CD during
review for reviewers assistance. I still want to get to 100 patches reviewed
in a day and I need automated help to get there.

I want to see a process where we get email back immediately into a patch
thread (consider each patch thread like a PR) and it includes a try bot
result.

Then (and this idea I attribute to Konrad Kleine from the Red Hat Platform
Tools team) I want the reviewer to interact with the try bot by email with
special commands e.g. @build build-many-glibcs, to kick off a single bmg
run with the patch in the thread that is tied to the patchwork object.
This way the reviewer is in charge of exactly which background additional
task is required to be carried out by CI/CD and report back the results
in the thread for public review.

-- 
Cheers,
Carlos.

Re: New math test failures on Fedora/33

[Carlos O'Donell via Libc-alpha]

On 1/11/21 11:00 AM, H.J. Lu via Libc-alpha wrote:
> On Fedora 33, I got these new math test failures:
> 
> FAIL: math/test-double-cosh
> FAIL: math/test-float32x-cosh
> FAIL: math/test-float64-cosh
> 
> for i686 glibc like
> 
> Failure: cosh_upward (-0x2.c5d374p+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c5d37700c6bbp+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c5d378p+12): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
> Failure: cosh_upward (-0x2.c679d4p+8): Exception "Overflow" not set
> Failure: cosh_upward (-0xf.ffffffffffff8p+1020): Exception "Overflow" not set
> Failure: cosh_upward (-0xf.fffffp+124): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d374p+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d37700c6bb2p+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d37700c6bbp+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c5d378p+12): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c679d1f73f0fcp+8): Exception "Overflow" not set
> Failure: cosh_upward (0x2.c679d4p+8): Exception "Overflow" not set
> Failure: cosh_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
> Failure: cosh_upward (0xf.fffffp+124): Exception "Overflow" not set

For completeness I see many more failures all related to ULPs though.

This email made me go back and double check.

I still see this on i686:

FAIL: math/test-double-erfc
FAIL: math/test-double-tgamma
FAIL: math/test-float32x-erfc
FAIL: math/test-float32x-tgamma
FAIL: math/test-float64-erfc
FAIL: math/test-float64-tgamma

These are all ULPs failures we need to fix for the release.
 
I see this on armv7hl:

FAIL: math/test-double-asinh
FAIL: math/test-double-cbrt
FAIL: math/test-double-cosh
FAIL: math/test-double-erfc
FAIL: math/test-double-exp
FAIL: math/test-double-sinh
FAIL: math/test-double-tgamma
FAIL: math/test-float32x-asinh
FAIL: math/test-float32x-cbrt
FAIL: math/test-float32x-cosh
FAIL: math/test-float32x-erfc
FAIL: math/test-float32x-exp
FAIL: math/test-float32x-sinh
FAIL: math/test-float32x-tgamma
FAIL: math/test-float64-asinh
FAIL: math/test-float64-cbrt
FAIL: math/test-float64-cosh
FAIL: math/test-float64-erfc
FAIL: math/test-float64-exp
FAIL: math/test-float64-sinh
FAIL: math/test-float64-tgamma
FAIL: math/test-ldouble-asinh
FAIL: math/test-ldouble-cbrt
FAIL: math/test-ldouble-cosh
FAIL: math/test-ldouble-erfc
FAIL: math/test-ldouble-exp
FAIL: math/test-ldouble-sinh
FAIL: math/test-ldouble-tgamma

These are all ULPs failures also and we need to fix them for the release.

This will all be done when we reset the ULPs.

-- 
Cheers,
Carlos.

Re: New math test failures on Fedora/33

[Paul Zimmermann]

       Dear Carlos,

> DJ and I have been discussing this as a project for 2021.
> 
> More importantly I think we need to shift this to CI/CD and integrate it
> into patchwork. I want to see fails reported per-patch. Then glue the
> CI/CD into that using new infrastructure (runners + builbot try bot).
> 
> I continue to feel that we need confidence to integrate new patches and
> that confidence doesn't come from build bots, but comes from CI/CD during
> review for reviewers assistance. I still want to get to 100 patches reviewed
> in a day and I need automated help to get there.
> 
> I want to see a process where we get email back immediately into a patch
> thread (consider each patch thread like a PR) and it includes a try bot
> result.
> 
> Then (and this idea I attribute to Konrad Kleine from the Red Hat Platform
> Tools team) I want the reviewer to interact with the try bot by email with
> special commands e.g. @build build-many-glibcs, to kick off a single bmg
> run with the patch in the thread that is tied to the patchwork object.
> This way the reviewer is in charge of exactly which background additional
> task is required to be carried out by CI/CD and report back the results
> in the thread for public review.

this looks quite promising!

> > I am no sure if we are allowed to run buildbots on gcc compiler farm
> > infrastructure.
>
> AFAIK we are not.
 
I asked people in charge of the gcc compiler farm and they told me that
glibc buildbots are welcome on the farm (Tulio and Adhemerval were in cc).

Paul

Re: New math test failures on Fedora/33

[Carlos O'Donell via Libc-alpha]

On 1/14/21 8:19 AM, Paul Zimmermann wrote:
> I asked people in charge of the gcc compiler farm and they told me that
> glibc buildbots are welcome on the farm (Tulio and Adhemerval were in cc).

That is good to hear.

In general we need:
- Runner (with services API accessible externally)
- buildbot master
- buildbot slave

And we can run them in a container.

DJ and I were talking about having some kind of ansible playbook so we
can deploy these quickly on remote systems.

-- 
Cheers,
Carlos.

New math test failures on Fedora/33

[Wilco Dijkstra via Libc-alpha]

Hi,

> These are all ULPs failures also and we need to fix them for the release.
>
> This will all be done when we reset the ULPs.

On the subject of ULPs, how about centralizing the ULP files into a single
generic file and only adding entries to target ULP files for special cases?
More of the math functions are becoming generic and so the ULPs should be
the same for most (some entries might need fma and non-fma variants of course).
Then you only need the target versions for special cases like non-standard IEEE
formats, target specific implementations with different ULPs etc.

And if there aren't that many special cases you could use a single file with
a syntax like:

Function: "acos":
float: 1            // generic case
float-alpha: 2

Cheers,
Wilco

Re: New math test failures on Fedora/33

[Paul Zimmermann]

       Dear Wilco,

> On the subject of ULPs, how about centralizing the ULP files into a single
> generic file and only adding entries to target ULP files for special cases?
> More of the math functions are becoming generic and so the ULPs should be
> the same for most (some entries might need fma and non-fma variants of course).
> Then you only need the target versions for special cases like non-standard IEEE
> formats, target specific implementations with different ULPs etc.
> 
> And if there aren't that many special cases you could use a single file with
> a syntax like:
> 
> Function: "acos":
> float: 1            // generic case
> float-alpha: 2

good idea! One question: when one does "make regen-ulps", how would it know which
value to update? For each function, we would need to tag it as "generic" or not on
each target?

By the way, "make regen-ulps" gives a diff if the new ulps are larger, but does it
also when the new ulps are smaller (for example if we improved the algorithm)?

Paul

Re: New math test failures on Fedora/33

[Andreas Schwab]

On Jan 18 2021, Wilco Dijkstra via Libc-alpha wrote:

> On the subject of ULPs, how about centralizing the ULP files into a single
> generic file and only adding entries to target ULP files for special cases?

How about ditching the ULP files altogether?  Why can't we just
generally accept the maximum valid ULP everywhere?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: New math test failures on Fedora/33

[Paul Zimmermann]

       Dear Andreas,

> How about ditching the ULP files altogether?  Why can't we just
> generally accept the maximum valid ULP everywhere?

as a user, I believe it is useful to know that the acosl function has largest known
error 1 ulp on AArch64, but 0 ulp on ARM (for example). As a developer, it would
decrease the motivation to improve a given generic function, if this would have no
impact on the documented largest known error because of some special implementation
on some exotic target.

Paul (currently improving the generic y0f function)

Re: New math test failures on Fedora/33

[Wilco Dijkstra via Libc-alpha]

Hi Andreas,

>> On the subject of ULPs, how about centralizing the ULP files into a single
>> generic file and only adding entries to target ULP files for special cases?
>
> How about ditching the ULP files altogether?  Why can't we just
> generally accept the maximum valid ULP everywhere?

Yes that is possible, and that should remove all the annoying ULP file maintenance.
I think the maximum is 10 ULP currently, so if we accepted that for all math functions
then ULP testing would be almost useless. However we could set a target for each
function using a generic ULP file. Then the ULP checker would give a warning if the ULP
is larger (so each target generates a short list of cases that could be improved). If ULP is
larger than some maximum (which could be set per math function) you would get the
existing error.

Cheers,
Wilco

Re: New math test failures on Fedora/33

[Carlos O'Donell via Libc-alpha]

On 1/18/21 10:20 AM, Wilco Dijkstra wrote:
> Hi Andreas,
> 
>>> On the subject of ULPs, how about centralizing the ULP files into a single
>>> generic file and only adding entries to target ULP files for special cases?
>>
>> How about ditching the ULP files altogether?  Why can't we just
>> generally accept the maximum valid ULP everywhere?
> 
> Yes that is possible, and that should remove all the annoying ULP file maintenance.
> I think the maximum is 10 ULP currently, so if we accepted that for all math functions
> then ULP testing would be almost useless. However we could set a target for each
> function using a generic ULP file. Then the ULP checker would give a warning if the ULP
> is larger (so each target generates a short list of cases that could be improved). If ULP is
> larger than some maximum (which could be set per math function) you would get the
> existing error.

The maximum is higher than 10 ULP on a per-architecture basis e.g. ppc64le long double.

-- 
Cheers,
Carlos.

Re: New math test failures on Fedora/33

[Andreas Schwab]

See init_max_error in math/libm-test-support.c.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: New math test failures on Fedora/33

[Florian Weimer via Libc-alpha]

* Wilco Dijkstra via Libc-alpha:

> On the subject of ULPs, how about centralizing the ULP files into a
> single generic file and only adding entries to target ULP files for
> special cases?

We've discussed this a while back for other implementation divergence:

  Dealing with target variance
  <https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00030.html>

As far as could tell at the time, the consensus was that we should use
separate files instead of consolidation in one file with some form of
conditionals.  Maybe math test data has different properties, leading to
a different outcome.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Re: New math test failures on Fedora/33

[Andreas Schwab]

On Jan 18 2021, Paul Zimmermann wrote:

> as a user, I believe it is useful to know that the acosl function has largest known
> error 1 ulp on AArch64, but 0 ulp on ARM (for example). As a developer, it would
> decrease the motivation to improve a given generic function, if this would have no
> impact on the documented largest known error because of some special implementation
> on some exotic target.

That requires that the ULP files are constantly kept uptodate, which is
never the case.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: New math test failures on Fedora/33

[Patrick McGehearty via Libc-alpha]

On 1/18/2021 8:22 AM, Wilco Dijkstra via Libc-alpha wrote:
> Hi,
>
>> These are all ULPs failures also and we need to fix them for the release.
>>
>> This will all be done when we reset the ULPs.
> On the subject of ULPs, how about centralizing the ULP files into a single
> generic file and only adding entries to target ULP files for special cases?
> More of the math functions are becoming generic and so the ULPs should be
> the same for most (some entries might need fma and non-fma variants of course).
> Then you only need the target versions for special cases like non-standard IEEE
> formats, target specific implementations with different ULPs etc.
>
> And if there aren't that many special cases you could use a single file with
> a syntax like:
>
> Function: "acos":
> float: 1            // generic case
> float-alpha: 2
>
> Cheers,
> Wilco

An interesting idea. How about having a generic ulps file that works for 
the generic
algorithms and arch-specific ulps file which only includes functions 
that have
different ulp values than the generic. If there is no arch-specific ulps 
file, then
the generic is used for all functions.  By having a separate file for 
arch-specific
cases, the generic file will be relatively stable and less likely to be 
out of date.
Only architectures with non-generic implementations will have to worry about
updating the ulps file, except when the generic algorithms change. For
those patch sets, the generic ulps file changes will also be included.

It is worth remembering the ulps file is not a guarantee that the 
function in
question never exceeds the ulps value, just that it does not exceed the 
value
for the range of inputs in the test suite. Single valued float precision 
functions
can and have been exhaustively tested but not double precision or multiple
valued functions. Different algorithms may will be sensitive to 'worst 
case' results
at different points on the number line.

As a developer, I've found the principal value of the ulps tests to 
catch gross errors
in new algorithms or configurations (i.e. accidentally using float 
precision in the
middle of a new algorithm instead of double precision). Really rare, but 
very
important to fix what it happens.

Patrick McGehearty