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


On Fri, 17 Feb 2017, Sam Ravnborg wrote:

> Hi Joseph.
> 
> (I have no knowledge on glibc build stuff, so be warned).
> 
> > This patch arranges for tests of each function to be run separately
> ...
> Previously you wrote that things took 30 minutes / 80 minutes.

That's for regenerating auto-libm-test-out-{casin,casinh,cacos,cacosh}.  
Those are (will be) checked-in files and the time to regenerate them is 
only relevant to developers adding or modifying tests of those four 
<complex.h> functions (or modifying gen-auto-libm-tests in a way that 
requires all auto-libm-test-out-* to be regenerated), not to people 
building or testing glibc.

> > +libm-tests-base-inline = $(foreach t,$(types),test-i$(t))
> 
> "-i$(t))" looks like a typing error in vi - (I know this was the 
> original syntax). So when this is anyway changed a consistent naming 
> style could be introduced.

I don't think mixing such a change in this large patch is appropriate 
(indeed, I already split some changes into 17 separate preliminary commits 
to get to this patch that didn't seem conveniently splittable further).  
Such a change in naming convention would more naturally be done separately 
(and probably combined with changing the convention used within 
libm-test-ulps files as well).

> > +	type=$${type_func%%-*}; \
> > +	func=$${type_func#*-}; \
> 
> For people that do not speak bash fluently it would be nice with a few comments here.
> As inline code often grows larger over time it can be simpler to move it all to a shell
> script and then handling comments and dealing with escapes are much simpler.
> 
> "%%" will delete the longest match from the back.
> "#" will delete the shortest match from the front.
> I wonder if you wanted to use the longest match in both cases.

No.  If matching something of the form foo-bar, shortest match in one 
place goes together with longest match in the other place to ensure proper 
results if foo or bar contains a hyphen.  (In this case they can't contain 
a hyphen, but I think using shortest at one end and longest at the other 
is the appropriate idiom unless you can't get the right semantics that 
way.)

-- 
Joseph S. Myers
joseph@codesourcery.com


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