From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24781 invoked by alias); 10 Sep 2013 20:31:17 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 24771 invoked by uid 89); 10 Sep 2013 20:31:17 -0000 Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 10 Sep 2013 20:31:17 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,NO_RECEIVED,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: multi.imgtec.com Message-ID: <1378844980.5770.378.camel@ubuntu-sellcey> Subject: Re: [patch, mips] Improved memset for MIPS From: Steve Ellcey To: Carlos O'Donell CC: Date: Tue, 10 Sep 2013 20:31:00 -0000 In-Reply-To: <522A9197.9000601@redhat.com> References: <93a232b5-9d0b-4a27-bbb5-16e3ae7c4b89@BAMAIL02.ba.imgtec.org> <522957A4.2030400@redhat.com> <1378483403.5770.307.camel@ubuntu-sellcey> <522A0CF8.8040008@redhat.com> <1378510388.5770.346.camel@ubuntu-sellcey> <522A9197.9000601@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2013_09_10_21_31_03 X-SW-Source: 2013-09/txt/msg00078.txt.bz2 On Fri, 2013-09-06 at 22:38 -0400, Carlos O'Donell wrote: > No, libgcc won't matter unless you do cancellation, and libstdc++ doesn't > matter because it's not a C++ application. You'll just get glibc using > the versions of those from the related prefix directories. I don't think > it should be making any difference here. > > You've certainly got your share of weird environment issues :-) > > Cheers, > Carlos. As an FYI, I think I have figured out my testing problems. I normally build cross toolchains by building binutils; gcc (using --without-headers); glibc; then a final GCC. When building on a MIPS machine I was doing the same thing and then going back to the glibc object directory and running 'make check' or 'make bench'. I think the problem with this was that the GCC now in my path (the final GCC) is not the same GCC that I used to build glibc (the initial --without-headers GCC). This seemed to trigger a partial rebuild of glibc along with building the tests and that in turn caused all sorts of weird problems. If I build the toolchain, then build a new glibc using the final GCC and run 'make check' or 'make bench' in that glibc object directory I get just the expected MIPS failures. Now that I can see the results of 'make bench' I do have a question, what is the difference between the results in bench-memset.out and bench-memset-ifunc.out? MIPS doesn't yet support IFUNC. It looks like the results in the two files are pretty close, so maybe they are identical runs on machines with no IFUNC? Steve Ellcey sellcey@mips.com