From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4164 invoked by alias); 6 May 2009 16:37:40 -0000 Received: (qmail 3735 invoked by uid 48); 6 May 2009 16:36:25 -0000 Date: Wed, 06 May 2009 16:37:00 -0000 Message-ID: <20090506163625.3734.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/32667] builtin operator= generates memcpy with overlapping memory regions In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ppluzhnikov at google dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00490.txt.bz2 ------- Comment #5 from ppluzhnikov at google dot com 2009-05-06 16:36 ------- (In reply to comment #3) > Note that this is likely not a problem in practice as > memcpy (p, p, sizeof (*p)) is difficult to implement > in a way that would make it not work. >>From Julian Seward: JS> AIUI, POSIX says the src==dst case is not allowed (along with all other JS> overlapping cases) because (eg) on PowerPC, it is possible to make a high JS> performance memcpy that preallocates the destination area in D1 using JS> dcbz instructions, which create the line in D1 and fill it full of JS> zeroes. This avoids dragging the destination line up the memory JS> hierarchy only to completely overwrite it with stuff from the source. JS> JS> Result is however that if the src and dst overlap, in any way, including JS> completely, then this causes zeroes to be written into the src area (!) JS> which is certainly not what you want. This bug is likely fixed by: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00932.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667