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:59:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1309061653280.8532@digraph.polyomino.org.uk> (raw)
In-Reply-To: <1378486241.5770.327.camel@ubuntu-sellcey>
On Fri, 6 Sep 2013, Steve Ellcey wrote:
> I have found that --prefix=/usr is more of a problem then a help when
> building general cross compiler toolchains. Using a prefix of /usr
> triggers various special case code in
> ports/sysdeps/unix/sysv/linux/mips/configure to put things in lib32 and
> lib64 and I don't actually want any of that so I use a prefix
> of /usr/fake instead of /usr.
Not using --prefix=/usr runs into ABI testsuite problems with bug 14664.
> The "undefined reference to `__libc_global_ctors'" has just shown up
> again in a parallel build, but it seems to go away when I rebuild. I am
> still trying to understand what is going on with this.
Since it seems to be about parallel builds and linkobj/libc.so, try with
Brooks's patch
<https://sourceware.org/ml/libc-alpha/2013-08/msg00597.html>? (Which, if
it works OK on master for a while, should probably be backported to 2.18
branch.)
> > 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.
>
> I think some flexibility here would be better. There is no floating
> point code in this routine so running all three ABI's in both hard and
> soft float modes seems like overkill to me. Testing in big and little
> endian modes would seem more likely to turn up problems then testing in
> hard and soft float.
That's why I said six rather than twelve ABI variants; floating-point
variants aren't relevant here, but the other variants are. You could
argue for full testing for three variants that cover all of o32, n32 and
n64 and both BE and LE, plus just the string/ directory tests for the
other three variants, but I think that would be the minimum.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-09-06 16:59 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
2013-09-06 16:50 ` Steve Ellcey
2013-09-06 16:59 ` Joseph S. Myers [this message]
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.1309061653280.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).