From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21417 invoked by alias); 11 Apr 2013 11:29:43 -0000 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 Received: (qmail 21195 invoked by uid 48); 11 Apr 2013 11:29:41 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/56888] memcpy implementation optimized as a call to memcpy Date: Thu, 11 Apr 2013 11:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status AssignedTo Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg00968.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot | |gnu.org --- Comment #8 from Richard Biener 2013-04-11 11:29:39 UTC --- -fno-builtin-XXX does not prevent GCC from emitting calls to XXX. It only makes GCC not assume anything about existing calls to XXX. For example to avoid transforming printf to puts in extern int printf(const char *, ...); int main() { printf ("Hello World\n"); return 0; } it does not work to specify -fno-builtin-puts, but instead you need to provide -fno-builtin-printf. Note that -fno-builtin only prevents the C family parsers from recognizing XXX as builtin decls. The fact that -fno-builtin was specified or not cannot be queried in any way from the middle-end. I consider the inability to specify this to the GCC middle-end as bug but I am not going to work on it. The requirement to be able to generate calls to memset. memcpy and memmove is deep-rooted into code-expansion as well for aggregate init and assignment.