Re: New tests for memcpy/memset/strlen/strcmp/strncmp

[Michael Meissner <meissner at redhat dot com>]

On Sat, Mar 09, 2002 at 10:53:26PM +0000, Joseph S. Myers wrote:
> On Sat, 9 Mar 2002, Michael Meissner wrote:
> 
> > I was optimizing the string functions in newlib to speed up some
> > common cases on the MIPS, and wrote the following tests to make sure
> > that all combnations likely to be optimized of alignments and lengths
> > are done.  I added this to the torture test suite.
> > 
> > 2002-03-09  Michael Meissner  <meissner@redhat.com>
> > 
> > 	* gcc.c-torture/execute/memcpy-2.c: New test.
> > 	* gcc.c-torture/execute/memset-1.c: New test.
> > 	* gcc.c-torture/execute/strlen-1.c: New test.
> > 	* gcc.c-torture/execute/strcmp-1.c: New test.
> > 	* gcc.c-torture/execute/strncmp-1.c: New test.
> 
> glibc also has its own tests for string functions.  It might make sense to 
> try to have a common collection of tests for corner cases (which include 
> not just alignments and lengths, but also e.g. strings at the end of a 
> page, the next page being unmapped, to test that functions in such cases 
> don't look further ahead in memory than the standard says they can).

GCC supports embedded environments that may not even have mapping hardware
available, as well as other OSes that may or may not have the appropriate calls
(including having the calls, but having bugs in them that prevents them from
being used).  Certainly such tests are useful in a hosted environment that
provides mmap capability (and I have written such tests in the past for other
environments), but they cannot go in the general GCC tests without using
something like autoconf to determine if they can be run.

> Such tests would be used then in several configurations, over several 
> optimisation options:
> 
> * To test GCC's built-in functions, with the built-in functions enabled,
> and with the string functions explicitly declared rather than including
> <string.h> (since <string.h> may have its own macro definitions).  This is
> the only case of relevance to GCC.
> 
> * To test external versions in a library, with GCC's built-in functions 
> enabled (possibly falling back to external ones).
> 
> * To test optimised versions in headers (whether macros or inlines,
> whether using inline assembler or not).

Such things would be useful, but obviously somebody has to write them.  At the
moment, I have no plans to write such tests, but maybe somebody else can write
them.  However, as I mentioned above, if such tests go in the GCC enviornment,
they need to work for all of the environments that GCC supports, not just
hosted Linux/*BSD systems, or the tests need to be stubbed out where they are
not appropriate.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@the-meissners.org	fax:   +1 978-692-4482