From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7037 invoked by alias); 10 Sep 2013 21:01:34 -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 7022 invoked by uid 89); 10 Sep 2013 21:01:34 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Sep 2013 21:01:34 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8AL1TbR015589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 17:01:29 -0400 Received: from [10.3.113.159] (ovpn-113-159.phx2.redhat.com [10.3.113.159]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8AL1R89011217; Tue, 10 Sep 2013 17:01:28 -0400 Message-ID: <522F88A6.1000904@redhat.com> Date: Tue, 10 Sep 2013 21:01:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Steve Ellcey CC: libc-ports@sourceware.org Subject: Re: [patch, mips] Improved memset for MIPS 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> <1378844980.5770.378.camel@ubuntu-sellcey> In-Reply-To: <1378844980.5770.378.camel@ubuntu-sellcey> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00079.txt.bz2 On 09/10/2013 04:29 PM, Steve Ellcey wrote: > 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? You get the default implementation of __libc_ifunc_impl_list (the function used by the testing infrastructure to iterate the functions implemented as ifuncs) which adds no additional functions to the test list. You still test the usual defaults e.g. simple, builtin, and original function entry. Therefore it's the same as the non-IFUNC version with the results being the same modulo testing variance. Does that answer your question? Cheers, Carlos.