This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Run libm tests separately for each function


* Joseph Myers:

> On Fri, 17 Feb 2017, Florian Weimer wrote:
>
>> * Joseph Myers:
>> 
>> > Any comments?  Especially regarding the use of iterators; there is
>> > existing precedent (in elf/Makefile) for using o-iterator.mk as a
>> > generic iterator with object-suffixes-left set to something other than
>> > a list of object suffixes, but maybe there should be a differently
>> > named iterator for such generic uses?
>> 
>> Does this patch depend on another change?  I get a build failure on
>> x86-64:
>> 
>> In file included from ../sysdeps/x86_64/fpu/test-double-libmvec-alias-mod.c:25:0,
>>                  from ../sysdeps/x86_64/fpu/test-double-libmvec-alias-avx512-mod.c:1:
>> ../sysdeps/x86_64/fpu/test-libmvec-alias-mod.c: In function ‘init_arg’:
>> ../sysdeps/x86_64/fpu/test-libmvec-alias-mod.c:33:3: error: implicit declaration of function ‘GLRO’ [-Werror=implicit-function-declaration]
>>    CHECK_ARCH_EXT;
>>    ^
>
> That's not one of the tests affected by my patch.  I see that with current 
> unmodified sources and suspect Zack's header changes.

Right, it's the change to sysdeps/x86_64/fpu/math-tests-arch.h in:

commit ceaa98897cb717685bb3b51a81d733b64340bb19
Author: Zack Weinberg <zackw@panix.com>
Date:   Thu Feb 16 17:31:42 2017 -0500

    Add missing header files throughout the testsuite.

I'm not simply reverting this for now because I don't know the exact
direction Zack wants to move in, but we'll probably have to do this
soon in case a real fix doesn't appear.

>> My immediate concern is that o-iterator.mk appears to have quadratic
>> behavior in the number of elements.  I'd like to run some build-time
>> benchmarks to ensure that this has no excessive build-time impact.
>
> Note that o-iterator.mk is used with object-suffixes-left containing at 
> most 17 elements (libm-tests-base, on x86_64; would be 20 elements with 
> float128 support added on x86_64), not with it containing anything 
> involving the 121 functions under test.

Ah, this certainly explains why make performance isn't abysmal with
this change.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]