[PATCH v2 1/6] math: Add support for auto static math tests
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Fri Mar 22 17:46:53 GMT 2024
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
>>
>> 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.
More information about the Libc-alpha
mailing list