[PATCH v2 1/6] math: Add support for auto static math tests

[H.J. Lu]

On Fri, Mar 22, 2024 at 10:46 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 22/03/24 12:51, Florian Weimer wrote:
> > * Adhemerval Zanella Netto:
> >
> >> On 22/03/24 03:46, Florian Weimer wrote:
> >>> * Joseph Myers:
> >>>
> >>>> On Thu, 21 Mar 2024, Adhemerval Zanella wrote:
> >>>>
> >>>>> It basically copy the already in place rules for dynamic tests
> >>>>> for auto-generated math tests for all support types.  To avoid
> >>>>> the need to duplicate .inc files, a .SECONDEXPANSION rules is
> >>>>> adeed for the gen-libm-test.py generation.
> >>>>
> >>>> Running the autogenerated tests seems overly complicated when the goal is
> >>>> simply to verify that linking a call succeeds.
> >>>
> >>> Right.  And I would prefer if we could mark compat/otherwise non-static
> >>> symbols in the ABI lists and use those for testing static linking.
> >>>
> >>
> >> That was my first approach, but then as an experiment I enabled static
> >> build for most of math tests and unexpectedly it has shows some failures
> >> on x86_64:
> >>
> >> FAIL: math/test-float64x-acos
> >> FAIL: math/test-float64x-log10
> >> FAIL: math/test-float64x-log2
> >> FAIL: math/test-float64x-y0
> >> FAIL: math/test-float64x-y1
> >> FAIL: math/test-ldouble-acos
> >> FAIL: math/test-ldouble-log10
> >> FAIL: math/test-ldouble-log2
> >> FAIL: math/test-ldouble-y0
> >> FAIL: math/test-ldouble-y1
> >>
> >> $ cat math/test-float64x-acos.out
> >> testing _Float64x (without inline functions)
> >> Failure: acos (max_value): Exception "Overflow" set
> >> Failure: acos (-max_value): Exception "Overflow" set
> >> Failure: acos_downward (max_value): Exception "Overflow" set
> >> Failure: acos_downward (-max_value): Exception "Overflow" set
> >> Failure: acos_towardzero (max_value): Exception "Overflow" set
> >> Failure: acos_towardzero (-max_value): Exception "Overflow" set
> >> Failure: acos_upward (max_value): Exception "Overflow" set
> >> Failure: acos_upward (-max_value): Exception "Overflow" set
> >>

This new static test only checks link failure.  It doesn't check if the static
implementation is correct.  We may not have more functional coverage
for static libm in the first static libm test patch.  But the first new static
libm tests should least expose one static libm failure on x86-64.

> >> My plan was to eventually track down what might be happening here, and
> >> the currently autogenerated tests gave me a nice scaffolding to add coverage
> >> tests.
> >
> > Interesting.  On the other hand, getting --disable-shared to work and
> > just run the *entire* test suite could provide value, too.  The last
> > time we discussed this we weren't sure if we had static-specific
> > failures, but your example shows that we do.
> >
>
> The main problem imho is --disable-shared is essentially a maintainer
> option. Although some installed programs will be static linked, it is
> really useful on checking if static linking is really working as expected.
>
> And it also requires *another* build and check iteration, which duplicates
> the work required in most cases (since static libraries are still built
> on default for --enable-shared).  I tried to help a coworker on support the
> --disable-shared and I recall another potential issues was the resulting
> disk usage (and thus build requirements) was quite high due glibc poor
> organization on static build requirements.
>
> There also another complication where we will need to constantly add
> $(build-shared) and duplicate the CI work to ensure both configure
> builds are ok.
>
> So I really think we should phase-out --disable-shared and work towards
> on add more static build tests.

Agreed.  We should add one static libm functional test to each libm
functional test.  With this, the static libm link tests won't be needed.

-- 
H.J.