From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31812 invoked by alias); 20 Sep 2017 21:32:25 -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 31771 invoked by uid 89); 20 Sep 2017 21:32:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:209.85.223.196, H*RU:209.85.223.196 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-io0-f196.google.com Received: from mail-io0-f196.google.com (HELO mail-io0-f196.google.com) (209.85.223.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 21:32:23 +0000 Received: by mail-io0-f196.google.com with SMTP id g32so3214958ioj.1; Wed, 20 Sep 2017 14:32:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=W33Qk9nqIlF2EUkORDLWA3OlLIpy5dJ84Q4LMZWBMOc=; b=riTC0I3csgtejRvXozeeI/44C2VZhkYjZW15eF0pLTZYc3rA8xYyhvXAH9CJihPOIF 0HwTath4A5WL0MQ0Fp9LQnzpeajpMWzNNTOx666dQ6Nz34TnwVOTgqgrLKyD0LZgCaUB dzCj/0O/8mONycHFru0nfUl5uj+JoAIkDcGaII1ozq2RHacCipD+1G4szk+daOHFCHkB keJits7wBAT04MQ0G1sxf0pKgR8bXTIfV/caE1+ca7cz6TyEtrNXS+xIRl50uIFU1i5O DQNgJMYME/2Glg8yaTsBIWmXxQYs5Hy2p+7jPCwg1BMXRVbCfSdtoqDo5xgSITOp52Rg 3q2A== X-Gm-Message-State: AHPjjUjz/LkmXGZ4UXGqVXWdA5HLFHDvraUbOllcswE1931DIhUOnMzL BxyvK/I1pGpRXhhkWNQhvZgdkw== X-Google-Smtp-Source: AOwi7QBD7a+be1ER+WePj/qD4LRU5agn1uJAVc8Q87dTr02U+GPlg4BdgWKlOTyL4yJhcp1hYjfOkA== X-Received: by 10.202.104.80 with SMTP id d77mr124726oic.156.1505943141510; Wed, 20 Sep 2017 14:32:21 -0700 (PDT) Received: from localhost.localdomain (174-16-109-244.hlrn.qwest.net. [174.16.109.244]) by smtp.gmail.com with ESMTPSA id m62sm2313385oib.39.2017.09.20.14.32.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 14:32:20 -0700 (PDT) Subject: Re: [PATCH] detect incompatible aliases (PR c/81854) To: Joseph Myers References: <61673e8d-6f5c-9bc0-dcf8-75eee71f98de@gmail.com> <1505921857.2286.101.camel@cavium.com> <3d1bd511-dfe3-d965-248e-a2ec108187d5@gmail.com> <1505925525.2286.106.camel@cavium.com> <5ba5c4ce-b7bd-a7fe-fa66-298bdac6880e@gmail.com> Cc: sellcey@cavium.com, Gcc Patch List , Jonathan Wakely , libstdc++ From: Martin Sebor Message-ID: Date: Wed, 20 Sep 2017 21:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg01413.txt.bz2 On 09/20/2017 12:01 PM, Joseph Myers wrote: > On Wed, 20 Sep 2017, Martin Sebor wrote: > >> I'm not intimately familiar with the Glibc ifunc infrastructure >> to suggest a good solution here, so assuming this works my only >> idea is to suppress the warning for these builds. >> >> Joseph, do you have a better suggestion? > > Is the warning because of a declaration of memmove as aliasing > __libc_memmove being compared with the type of the __libc_memmove_ifunc > declaration (asm name __libc_memmove) rather than the __libc_memmove > declaration? If so, maybe in the non-HAVE_GCC_IFUNC case the alias should > be declared with a different type? Or should be defined inside asm in > this case (presumably with new ifunc-related macros)? The warning is because in the declaration: extern __typeof (__libc_memmove) memmove __attribute__ ((alias ("__libc_memmove"))); __typeof (__libc_memmove) is the same as the type of memmove as it should be but the type of the alias ("__libc_memmove") is that of __libc_memmove_ifunc, presumably because of the following: __typeof (__libc_memmove)* __libc_memmove_ifunc (void) __asm__ ("__libc_memmove"); I think this is because the type of "__libc_memmove" in the alias is looked up "late" after the asm above has associated its type with __libc_memmove_ifunc. Besides suppressing the warning using a pragma it can also be suppressed by declaring memove with no prototype (which would mean changing the definition of the strong_alias macro for this kind of builds as you suggest). But this would just paper over the type mismatch. I'm afraid I don't know enough about this machinery to tell what might be an appropriate fix (i.e., what would declare memove as an alias for __libc_memmove_ifunc but with the correct type), or even if there is one. Martin