From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2080 invoked by alias); 25 Jan 2013 21:29:28 -0000 Received: (qmail 2071 invoked by uid 22791); 25 Jan 2013 21:29:27 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RP_MATCHES_RCVD,TW_CP X-Spam-Check-By: sourceware.org Received: from dns1.mips.com (HELO dns1.mips.com) (12.201.5.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Jan 2013 21:28:55 +0000 Received: from mailgate1.mips.com (mailgate1.mips.com [12.201.5.111]) by dns1.mips.com (8.13.8/8.13.8) with ESMTP id r0PLSnCF004530; Fri, 25 Jan 2013 13:28:50 -0800 X-M-MSG: Received: from exchdb01.mips.com (unknown [192.168.36.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate1.mips.com (Postfix) with ESMTP id 20D3436464F; Fri, 25 Jan 2013 13:28:45 -0800 (PST) Received: from [192.168.65.53] (192.168.65.53) by exchhub01.mips.com (192.168.36.84) with Microsoft SMTP Server id 14.2.247.3; Fri, 25 Jan 2013 13:28:44 -0800 Subject: Re: [patch, mips, memmove] Remove memmove's use of memcpy on MIPS From: Steve Ellcey To: "Joseph S. Myers" CC: In-Reply-To: References: <8eea9547-6de4-482b-833c-f552df9283d4@EXCHHUB01.MIPS.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Jan 2013 21:29:00 -0000 Message-ID: <1359149324.11963.183.camel@ubuntu-sellcey> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-EMS-Proccessed: 6LP3oGfGVdcdb8o1aBnt6w== X-EMS-STAMP: wpteFNnVTFMlOvAMoNQaTQ== 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 X-SW-Source: 2013-01/txt/msg00059.txt.bz2 On Fri, 2013-01-25 at 20:16 +0000, Joseph S. Myers wrote: > On Fri, 25 Jan 2013, Steve Ellcey wrote: > > > Rather then use a slower safer prefetch for memcpy, which would also fix > > this problem, I would like to remove the setting of MEMCPY_OK_FOR_FWD_MEMMOVE > > in memmove.c. > > Removing the MIPS memmove.c is OK. There's no point in having the file > when it doesn't define MEMCPY_OK_FOR_FWD_MEMMOVE I am hoping to improve memcpy at some point so that it will be safe to use memcpy in memmove again. Given that, do you think I should still just remove the MIPS memmove.c and recreate it later when needed or would it make sense to keep it so I can just set the macro when it is safe to do so. Steve Ellcey sellcey@mips.com