From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10245 invoked by alias); 7 Oct 2007 20:06:31 -0000 Received: (qmail 10236 invoked by uid 22791); 7 Oct 2007 20:06:31 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 07 Oct 2007 20:06:23 +0000 Received: (qmail 19019 invoked from network); 7 Oct 2007 20:06:21 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Oct 2007 20:06:21 -0000 Message-ID: <47093C37.9000501@codesourcery.com> Date: Sun, 07 Oct 2007 20:06:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jakub Jelinek CC: Jason Merrill , Alexandre Oliva , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] Don't clear DECL_BUILT_IN_CLASS/DECL_FUNCTION_CODE when redeclaring a builtin if types match References: <20071002114954.GC2625@devserv.devel.redhat.com> <47091AAA.4000605@codesourcery.com> <20071007190829.GQ2625@devserv.devel.redhat.com> In-Reply-To: <20071007190829.GQ2625@devserv.devel.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00382.txt.bz2 Jakub Jelinek wrote: >>> The C FE always keeps DECL_BUILT_IN_CLASS when types match, even when >>> newdecl defines a function. >>> But the C++ FE doesn't do this: >>> if (new_defines_function) >> The standard does prohibit redefining these functions. But, in >> practice, people would be surprised if they did this: >> >> /* Nobody should use memcpy, I think it's evil! */ >> extern "C" void memcpy (void *, void *, size_t) { abort (); } >> >> void f() { >> memcpy (...); >> } > > If you do this, then you really want to use -fno-builtin-memcpy. > Clearing DECL_BUILT_IN_CLASS in duplicate_decls will just mean > that the behavior will be different in CUs where you define this > non-conforming memcpy and other CUs linked into your program. Yes, you may want to use -fno-builtin-memcpy in other translation units. But, it certainly seems likely to lead to user confusion if overriding a standard library function (let's not call these "builtins" -- __builtin_memcpy is a "builtin", but "memcpy" is a standard library function) is ignored by the compiler. One of the things I'm concerned about is ability for users to bring code to GCC from other compilers. I'm certain that code exists that overrides definitions of standard library functions. Your suggestion would make the compiler ignore the plain meaning of the user's code and I think that's a bad thing. > As I said in the mail, I'm ATM primarily not concerned about performance > - glibc always uses always_inline gnu_inline functions for this stuff - but > that adding an __asm ("...") redirect to the function will no longer result > in the needed behavior - it will not have any effect on the __builtin_* > functions. We could argue about how GLIBC could best implement its checking code, but that's GLIBC's business. :-) I do agree that the call to __builtin_snprintf in your builtin10.C example should end up calling mysnprintf, if not expanded inline by the compiler because the semantics of __builtin_x is that if it cannot expand inline, then it calls the function whose *source* name is "x" -- and whose assembler name is whatever assembler name we would normally associate with "x". But, that doesn't mean that a user declaration of "x" should be marked as builtin. Instead, I think it means that the code that expands builtins needs to be able to find the function with the matching source name, and use that to find the corresponding assembly name. Perhaps when the user declares a replacement for a standard library routine we need to update a table mapping builtins to FUNCTION_DECLs. I also agree that the C and C++ front-ends should be consistent in their handling of this situation. That's more important than whatever semantic decision we end up making. So, I think the C and C++ maintainers need to get together and see if we can get consensus on what semantics we want. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713