From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112925 invoked by alias); 21 Oct 2015 02:33:56 -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 112813 invoked by uid 89); 21 Oct 2015 02:33:55 -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-f179.google.com Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com) (209.85.214.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 21 Oct 2015 02:33:54 +0000 Received: by obctp1 with SMTP id tp1so3862004obc.2 for ; Tue, 20 Oct 2015 19:33:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.102.33 with SMTP id fl1mr4250099oeb.11.1445394832068; Tue, 20 Oct 2015 19:33:52 -0700 (PDT) Received: by 10.76.72.3 with HTTP; Tue, 20 Oct 2015 19:33:51 -0700 (PDT) In-Reply-To: <5626D034.6000306@redhat.com> References: <20151014162146.GA24833@intel.com> <5626D034.6000306@redhat.com> Date: Wed, 21 Oct 2015 03:42: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: 2015-10/txt/msg02008.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. > > Other than that I don't see a problem with the concept. However, I also > agree that the tests should not be i386 specific. Sure. Just add target-specific scan-assembler-not. > One final question - it would seem that glibc is currently not affected by > this problem (at least I'm not seeing memcpy@plt calls in the binary on my > system), so how come this has become an issue now? > > R_386_PLT32 only shows in .o files. There are many of them in libc_pic.os. --=20 H.J.