From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41800 invoked by alias); 18 Sep 2017 21:21:10 -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 41297 invoked by uid 89); 18 Sep 2017 21:21:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=hatch, H*M:9479 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-io0-f193.google.com Received: from mail-io0-f193.google.com (HELO mail-io0-f193.google.com) (209.85.223.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Sep 2017 21:21:09 +0000 Received: by mail-io0-f193.google.com with SMTP id n69so768912ioi.3; Mon, 18 Sep 2017 14:21:08 -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=Nn4QJPJ3C1NHCtWhy3fzqIDoVstKE/PZZyP9EcKdvTg=; b=rCkJGChQ1HsavypkB7UrDCf0K/DKMwdaG2dBIFS15Aw6QlQDr0CItadNBAyo1L2Az8 eZ8XhIWfrD++7HsEf66u33+/N5kIsju3VNXHnRpUC++FmCkaM0eURqztYfzPVWG51brI 7//HV4LxNHJVhqGaNmi8YiaC8dP+9f5R2uYgs9Jbzi3QMMSWwQK6klwktz+7KzkmAw0l LsrGueIh72gMXWpZF/g8T0q1nlREo3jmmTSuwaBQ5kfmgdApMM5EKvyFfx+thCt2otca Yj6O/wMr12T3x9xiNPH/TPtlRs0EsRaSGh/LvF0vC34z1RBEzO4L4yHGcnhLUqFOOt5J tX+Q== X-Gm-Message-State: AHPjjUjUPR1BJs5RizEZLTPEHiy3BNjp/Okn5Di7gLISEvWJzuYaa0j6 PK1aoIIeGN5Ngygc X-Google-Smtp-Source: AOwi7QAS3h/VsW3tuiUEgjQIa/bOhEpkgnJ7SzDZL97+ugl37ZRkUfOXNPdx/Ia4uVkZltMKObligw== X-Received: by 10.202.221.132 with SMTP id u126mr7972311oig.242.1505769666923; Mon, 18 Sep 2017 14:21:06 -0700 (PDT) Received: from localhost.localdomain (174-16-109-244.hlrn.qwest.net. [174.16.109.244]) by smtp.gmail.com with ESMTPSA id e71sm2180085oih.37.2017.09.18.14.21.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 14:21:05 -0700 (PDT) Subject: Re: [PATCH] detect incompatible aliases (PR c/81854) To: Joseph Myers References: Cc: Gcc Patch List , Jonathan Wakely , libstdc++ From: Martin Sebor Message-ID: <3b4c0fe1-9479-dd5c-341d-91a608bb76cc@gmail.com> Date: Mon, 18 Sep 2017 21:21: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/msg01202.txt.bz2 On 09/12/2017 10:17 AM, Joseph Myers wrote: > On Thu, 17 Aug 2017, Martin Sebor wrote: > >> + || (prototype_p (t1) >> + && prototype_p (t2) >> + && !types_compatible_p (t1, t2)))) > > Why the restriction to prototyped types? I'd expect a warning for an > alias between unprototyped functions of types int () and void (), for > example. Or for an alias between void () and void (char), as a function > with a char argument is not compatible with a non-prototype function in C. > Is this an issue with the problem being diagnosed at a point where the > langhooks for language-specific type compatibility rules aren't available? > If that's preventing diagnosing incompatibility involving unprototyped > functions, then the patch is OK. It's meant as an escape hatch. It allows declaring compatibility symbols, for example by the libstdc++ _GLIBCXX_3_4_SYMVER macro defined in libstdc++-v3/src/c++98/compatibility.cc. The macro is used to declare compatibility functions of all sorts of incompatible types. The originally posted patch had libstdc++ disable the warning for the file with the symbols but Jonathan preferred this solution. It could perhaps be tightened up to detect some of the cases on your list but I'm not sure it's worth the effort and added complexity. Let me know if you feel differently (or have a different suggestion), otherwise I will go ahead and commit the patch as is. Thanks Martin