From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55431 invoked by alias); 15 Jan 2016 18:44:42 -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 54783 invoked by uid 89); 15 Jan 2016 18:44:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=hongjiuluintelcom, hongjiu.lu@intel.com, front-end X-HELO: mail-qk0-f172.google.com Received: from mail-qk0-f172.google.com (HELO mail-qk0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 15 Jan 2016 18:44:40 +0000 Received: by mail-qk0-f172.google.com with SMTP id s5so8896381qkd.0 for ; Fri, 15 Jan 2016 10:44:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KxB1WL4aoev1o1i0GBr4m5G6mvJfMONXC3vXLnaEYwE=; b=FsMAPqVuTigaNLaneKEsswv4ba4zi+EoUmFhk9DoiQqI51aR+qo0hyZfDp6RaaKZl5 tGajMpCBjveRRaCR7MAZLLXW74qGI0tqYn0PnEGdtNMtilRIrJukworfoW69NrCznbmP DDcKIzqX4YF7irTL2okfAy7nWkWG3R1lD++jXH6S4gwyd+be76T0yAJ7SWBu4nee8eeE GtR4tHxomUYL0/C6VDch436C/KsYscm3ZQ0IPHlla1z2qCrY9w4HeNgdDGWd2clqJ8TY DYnHQjGi0nU5gxoqiBlpPUOo2OlEdkBhFtMizYsARWVMa9/u9FZv9gvyJDBt/H8O52YZ 37gw== X-Gm-Message-State: ALoCoQnfZ8XzeF7eVJvhhhA72njD83cemTQ9hWzpclEZBwbTGdzgJc9IappeE/dCbQ15aqbJU1oKRq327wxgXxz6Gf7mKdRGmQ== MIME-Version: 1.0 X-Received: by 10.55.27.98 with SMTP id b95mr15454695qkb.51.1452883478052; Fri, 15 Jan 2016 10:44:38 -0800 (PST) Received: by 10.55.169.199 with HTTP; Fri, 15 Jan 2016 10:44:37 -0800 (PST) In-Reply-To: <5626D034.6000306@redhat.com> References: <20151014162146.GA24833@intel.com> <5626D034.6000306@redhat.com> Date: Fri, 15 Jan 2016 18:44: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: Bernd Schmidt Cc: Richard Biener , GCC Patches , Jason Merrill Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01130.txt.bz2 On Tue, Oct 20, 2015 at 4:37 PM, Bernd Schmidt wrote: > On 10/15/2015 12:37 PM, H.J. Lu wrote: >> >> 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 built= in >>>> function fall back on, we should honor the explicit visibility on the >>>> the C library function. > > >>> Doesn't the C++ FE have the same issue? >>> >> >> Unlike gcc, visibility triggers a warning in g++: >> >> 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*, c= onst >> void*, size_t)=E2=80=99 >> [hjl@gnu-tools-1 pr67220]$ > > > I see no good reason for C and C++ to have different behaviour here. It > looks like the C++ frontend sets DECL_VISIBILITY_SPECIFIED to 1 for > builtins, causing the above behaviour. Cc'ing Jason, but I think the C++ > frontend should be changed not to set D_V_S and have the same changes as = the > C frontend for merging the visibilities. > What should we do with C++ front-end? --=20 H.J.