From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21134 invoked by alias); 15 Oct 2015 10:38:00 -0000 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 Received: (qmail 21124 invoked by uid 89); 15 Oct 2015 10:37:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 15 Oct 2015 10:37:58 +0000 Received: by obbzf10 with SMTP id zf10so61557034obb.2 for ; Thu, 15 Oct 2015 03:37:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.67.1 with SMTP id j1mr5261851oet.61.1444905476610; Thu, 15 Oct 2015 03:37:56 -0700 (PDT) Received: by 10.76.175.132 with HTTP; Thu, 15 Oct 2015 03:37:56 -0700 (PDT) In-Reply-To: References: <20151014162146.GA24833@intel.com> Date: Thu, 15 Oct 2015 10:38:00 -0000 Message-ID: Subject: Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions From: "H.J. Lu" To: Richard Biener Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01464.txt.bz2 On Thu, Oct 15, 2015 at 1:44 AM, Richard Biener wrote: > On Wed, Oct 14, 2015 at 6:21 PM, H.J. Lu wrote: >> By default, there is no visibility on builtin functions. When there is >> explicitly declared visibility on the C library function which a builtin >> function fall back on, we should honor the explicit visibility on the >> the C library function. >> >> There are 2 issues: >> >> 1. We never update visibility of the fall back C library function. >> 2. init_block_move_fn and init_block_clear_fn used to implement builtin >> memcpy and memset generate the library call to memcpy and memset >> directly without checking if there is explicitly declared visibility on >> them. >> >> This patch updates builtin function with explicit visibility and checks >> visibility on builtin memcpy/memset when generating library call. >> >> Tested on Linux/x86-64 without regressions. OK for trunk? > > Doesn't the C++ FE have the same issue? > Unlike gcc, visibility triggers a warning in g++: [hjl@gnu-tools-1 pr67220]$ cat memcpy.i typedef unsigned long size_t; extern void *memcpy(void *dest, const void *src, size_t n) __attribute__ ((visibility ("hidden"))); void bar (void *d, void *s, size_t n) { memcpy (d, s, n); } [hjl@gnu-tools-1 pr67220]$ make memcpy.s /export/build/gnu/gcc/build-x86_64-linux/gcc/xg++ -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -fPIC -S memcpy.i memcpy.i:2:14: warning: =E2=80=98void* memcpy(void*, const void*, size_t)= =E2=80=99: visibility attribute ignored because it conflicts with previous declaration [-Wattributes] extern void *memcpy(void *dest, const void *src, size_t n) ^ : note: previous declaration of =E2=80=98void* memcpy(void*, const void*, size_t)=E2=80=99 [hjl@gnu-tools-1 pr67220]$ Since those fallback functions are in the C library, it is very unlikely they can be hidden in C++. They are mostly likely to happen inside of the C library. --=20 H.J.