From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40634 invoked by alias); 18 Aug 2017 19:21:54 -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 40611 invoked by uid 89); 18 Aug 2017 19:21:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qk0-f193.google.com Received: from mail-qk0-f193.google.com (HELO mail-qk0-f193.google.com) (209.85.220.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Aug 2017 19:21:51 +0000 Received: by mail-qk0-f193.google.com with SMTP id q66so9597457qki.1; Fri, 18 Aug 2017 12:21:51 -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=iiEIDx6lrbRRb4F35F1GSIDswo7DestZEXx1WWzTg2k=; b=M+TrlunkzodYdqaTfiaXBiT4amDxUJEAsBTmyP/d66DjfHrH6tuE7AVK+Mk7BEE3Vv ahMvjGw+2yXm4Yx84eeoyqZB8wUk07LrmQ/hn0svC4rdHHxCBygMIzdxGudpKiESl4om nSD8N2Z7DpYngblWi6ag2sECpQ8yMXlGluFx4e/eyMOeSV5fthlWXNqmx4xwB6lXpSVd kFpMqdDyeImukP+zu2Oz8qPW+bqbZxkPb5paadKp7sQcB9g72qd4k5ouKiwVpGxtXGrC O0szvdri6V4SUFdFx5zzfeVp6rS1+VqCBYi+HAPM0kW5iZtFwkaKxxszZwwWCm42oZ1c Qrxg== X-Gm-Message-State: AHYfb5g8HzKMWsOMW4r9Z17gyvSrYVUeLCRJW0bKYjRZ6HEY/rHC7SiD M5WJuOjWpQRAZabN X-Received: by 10.55.114.194 with SMTP id n185mr14378485qkc.71.1503084109633; Fri, 18 Aug 2017 12:21:49 -0700 (PDT) Received: from localhost.localdomain (174-16-125-25.hlrn.qwest.net. [174.16.125.25]) by smtp.gmail.com with ESMTPSA id e3sm3958691qkd.82.2017.08.18.12.21.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 12:21:49 -0700 (PDT) Subject: Re: [PATCH] detect incompatible aliases (PR c/81854) To: Jonathan Wakely References: <20170818131046.GF4582@redhat.com> <9d38b17a-b458-5c9c-ee08-809f78a69c1d@gmail.com> <20170818164832.GJ4582@redhat.com> Cc: Gcc Patch List , Joseph Myers , libstdc++ From: Martin Sebor Message-ID: <2d6feada-8383-a60a-8908-07de096ba6a9@gmail.com> Date: Fri, 18 Aug 2017 21:02: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: <20170818164832.GJ4582@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01151.txt.bz2 On 08/18/2017 10:48 AM, Jonathan Wakely wrote: > On 18/08/17 08:54 -0600, Martin Sebor wrote: >> On 08/18/2017 07:10 AM, Jonathan Wakely wrote: >>> On 17/08/17 21:21 -0600, Martin Sebor wrote: >>>> Joseph, while looking into implementing enhancement your request >>>> pr81824 I noticed that GCC silently accepts incompatible alias >>>> declarations (pr81854) so as sort of a proof-concept for the >>>> former I enhanced the checking already done for other kinds of >>>> incompatibilities to also detect those mentioned in the latter >>>> bug. Attached is this patch, tested on x85_64-linux. >>>> >>>> Jonathan, the patch requires suppressing the warning in libstdc++ >>>> compatibility symbol definitions in compatibility.cc. I couldn't >>>> find a way to do it without the suppression but I'd be happy to >>>> try again if you have an idea for how. >>> >>> Doing it that way is fine, but ... >>> >>>> diff --git a/libstdc++-v3/src/c++98/compatibility.cc >>>> b/libstdc++-v3/src/c++98/compatibility.cc >>>> index 381f4c4..5f56b9e 100644 >>>> --- a/libstdc++-v3/src/c++98/compatibility.cc >>>> +++ b/libstdc++-v3/src/c++98/compatibility.cc >>>> @@ -213,6 +213,11 @@ >>>> _ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv >>>> _ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv >>>> */ >>>> >>>> +// Disable warning about declaring aliases between functions with >>>> +// incompatible types. >>>> +#pragma GCC diagnostic push >>>> +#pragma GCC diagnostic ignored "-Wattributes" >>>> + >>> >>> Could this be moved closer to the point where it's needed? >>> >>> It's not needed until after line 361, right? >> >> Sure. The other possibility that I forgot to mention is to >> declare the alias without a prototype, which in C++ looks >> like this: >> >> void foo (...); >> >> The patch would then look like this. Do you have a preference >> between these two approaches? > > If this doesn't change the generated code, but avoids the warnings > then I think I prefer this. i.e. fix the code, not just suppress the > warnings. It's the same as calling a function without a prototype in C. I rebuilt libstdc++ with this change and reran the test suite with no unexpected failures so I'll go ahead and commit this change instead. To be clear, though, this is just a suppression mechanism not unlike a cast. The ideal solution would be to declare the aliases to have the right type, e.g., using __typeof__ or decltype. I just couldn't find a way to make it work with the macros. Martin > > >> Martin >> >> diff --git a/libstdc++-v3/src/c++98/compatibility.cc >> b/libstdc++-v3/src/c++98/compatibility.cc >> index 381f4c4..b49a5ca 100644 >> --- a/libstdc++-v3/src/c++98/compatibility.cc >> +++ b/libstdc++-v3/src/c++98/compatibility.cc >> @@ -367,13 +367,13 @@ _GLIBCXX_END_NAMESPACE_VERSION >> >> #define _GLIBCXX_3_4_SYMVER(XXname, name) \ >> extern "C" void \ >> - _X##name() \ >> + _X##name(...) \ >> __attribute__ ((alias(#XXname))); \ >> asm (".symver " "_X" #name "," #name "@GLIBCXX_3.4"); >> >> #define _GLIBCXX_3_4_5_SYMVER(XXname, name) \ >> extern "C" void \ >> - _Y##name() \ >> + _Y##name(...) \ >> __attribute__ ((alias(#XXname))); \ >> asm (".symver " "_Y" #name "," #name "@@GLIBCXX_3.4.5"); >> >>