From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Steve Ellcey <sellcey@mips.com>
Cc: <libc-ports@sourceware.org>
Subject: Re: [patch, mips] Improved memset for MIPS
Date: Fri, 06 Sep 2013 16:09:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1309061603380.8532@digraph.polyomino.org.uk> (raw)
In-Reply-To: <1378483039.5770.302.camel@ubuntu-sellcey>
On Fri, 6 Sep 2013, Steve Ellcey wrote:
> On Fri, 2013-09-06 at 14:30 +0000, Joseph S. Myers wrote:
> > On Thu, 5 Sep 2013, Steve Ellcey wrote:
> >
> > > Tested with the glibc and gcc testsuites and by doing some standalone
> > > performance measurements.
> >
> > Has the glibc testsuite been run without regressions for all six
> > combinations of (o32, n32, n64) with (big-endian, little-endian)?
>
> No. I did most of my testing outside of the glibc testsuite because I
> find the glibc testsuite difficult to run, see
> https://sourceware.org/ml/libc-help/2013-08/msg00040.html for some of my
> problems/questions. I don't believe I have ever managed to do a clean
You'll need to debug the problems as they indicate something wrong with
your build environment. It's always advised to configure glibc with
--prefix=/usr rather than some other prefix (but there is no requirement
that the dynamic linker actually be installed during testing, you can
ignore the -dynamic-linker= path), and your other error indicates some
inconsistency regarding NO_CTORS_DTORS_SECTIONS.
If you see more failures than are described at
<https://sourceware.org/glibc/wiki/Release/2.18>, you should investigate
them as well.
The expectation is that the glibc testsuite is the normal way to test
patches before submission, and string function patches like this need it
to be run for all six relevant ABI variants.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-09-06 16:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 17:06 Steve Ellcey
2013-09-06 0:40 ` Mike Frysinger
2013-09-06 15:42 ` Steve Ellcey
2013-09-06 4:18 ` Carlos O'Donell
2013-09-06 16:03 ` Steve Ellcey
2013-09-06 17:12 ` Carlos O'Donell
2013-09-06 23:33 ` Steve Ellcey
2013-09-07 2:38 ` Carlos O'Donell
2013-09-10 20:31 ` Steve Ellcey
2013-09-10 21:01 ` Carlos O'Donell
2013-09-10 21:14 ` Steve Ellcey
2013-09-10 22:35 ` Carlos O'Donell
2013-09-10 22:38 ` Carlos O'Donell
2013-09-07 5:46 ` Andreas Schwab
2013-09-06 14:31 ` Joseph S. Myers
2013-09-06 15:58 ` Steve Ellcey
2013-09-06 16:09 ` Joseph S. Myers [this message]
2013-09-06 16:50 ` Steve Ellcey
2013-09-06 16:59 ` Joseph S. Myers
2013-09-06 17:43 ` Steve Ellcey
2013-09-06 18:57 ` Brooks Moses
2013-09-18 17:41 ` Steve Ellcey
2013-09-19 15:25 ` Carlos O'Donell
2013-09-19 17:02 ` Steve Ellcey
2013-09-20 16:43 ` Joseph S. Myers
2013-09-20 17:32 ` Steve Ellcey
2013-12-12 22:19 ` Andrew Pinski
2013-12-13 0:01 ` Carlos O'Donell
2013-12-13 0:14 ` Steve Ellcey
2013-12-13 0:22 ` Andrew Pinski
2013-12-13 4:40 ` Carlos O'Donell
2013-09-06 16:59 ` Steve Ellcey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1309061603380.8532@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=sellcey@mips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).