From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5750 invoked by alias); 28 Jul 2017 18:32:07 -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 5639 invoked by uid 89); 28 Jul 2017 18:32:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=offer X-HELO: mail-qk0-f174.google.com Received: from mail-qk0-f174.google.com (HELO mail-qk0-f174.google.com) (209.85.220.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Jul 2017 18:32:03 +0000 Received: by mail-qk0-f174.google.com with SMTP id x191so56851012qka.5 for ; Fri, 28 Jul 2017 11:32:03 -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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Bn/rqEBlljpnPhPkQUI4CAmf7F20FAXdPvMNCv8dHr0=; b=Qv+Sl5rUMsyoMc/QDvFaMJ7R/UiwIxEsdNeHrTW2J/Uv1aCPFVgfNNzDk+VRc7UG9g 9AOiiv0NSAqOrknB6NuElkrvfkWuBDDW0Ut9B0sWsubMrka4gq85a9aubz1Evu/0lj4N KwhKaD3fHxn9uWbqWUAtMeNN7leFdGs3mOQb0oEh7pE077KvQO8ppLgxzIXasgWRnLNz iZm8B1cOLkeq5AsEH6gRdsvOFSCbKLEchuDwW59CpZcQ7NZ/CNGlukZ3u020L4M5A0Cy FwDz1PImt5shOH9MKhuQu7LwzfuGTLy4O0aPDwle4+VMCnqUs5qRWH8isl3zCl6tij6b eeMg== X-Gm-Message-State: AIVw110egIU243NAMjGXqdOKCFQv7MPCtBzA3nrdg38KNDhYmP60/vbE 3GvdI1yyUgBlcMBu X-Received: by 10.55.27.83 with SMTP id b80mr10721631qkb.148.1501266721923; Fri, 28 Jul 2017 11:32:01 -0700 (PDT) Received: from localhost.localdomain (75-171-229-159.hlrn.qwest.net. [75.171.229.159]) by smtp.gmail.com with ESMTPSA id v140sm15607213qka.74.2017.07.28.11.32.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 11:32:01 -0700 (PDT) Subject: Re: [PATCH 00/17] RFC: New source-location representation; Language Server Protocol To: David Malcolm , gcc-patches@gcc.gnu.org References: <1500926714-56988-1-git-send-email-dmalcolm@redhat.com> <60f8f910-5ddb-0aaa-d6d1-7da6af104b59@gmail.com> <1501252100.10760.105.camel@redhat.com> From: Martin Sebor Message-ID: Date: Fri, 28 Jul 2017 18: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: <1501252100.10760.105.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg01937.txt.bz2 Thanks for the explanation (snipped). >>> * C++: add a fix-it hint to -Wsuggest-final-methods >> >> To answer your call for other ideas below: There are other >> suggestions that GCC could offer to help improve code, including >> >> * to add the const qualifier to function pointer and reference >> arguments (including member functions) > > When there's a mismatch? Consider e.g. > > void test (const char *dst, char *src) > { > memcpy (dst, src, 1024); > } > > warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from > pointer target type [-Wdiscarded-qualifiers] > memcpy (dst, src, 1024); > ^~~ > note: expected ‘void *’ but argument is of type ‘const char *’ > void test (const char *dst, char *src) > ^~~~~ > ------ > (here I've added the underlining of the "const" and the fix-it hint > suggestion deletion of "const" on param aren't). This would be useful as well but... > > plus we could add: > > warning: argument 2 could be marked as 'const' > void test (const char *dst, char *src) > > ^~~~~~~~~~ > const char * src ... the latter is what I meant. It's common to forget to declare a pointer (or reference) argument const even when it doesn't change the object it refers to. Suggesting the const keyword would help drive const correctness and even expose optimization opportunities (e.g., with the restrict suggestion below, but also in other contexts). This could be extended beyond function arguments and to private class members and perhaps even local (and static global) variables. > > >> * to add restrict where appropriate (especially to const pointer >> and reference arguments) > > When is it appropriate? Is this something that we can infer? Broadly, declaring a pointer argument restrict is appropriate whenever it's not used to access the same object as another pointer whose value wasn't derived from the first pointer. It shouldn't be too hard to infer the simple cases in the alias oracle. The main benefit I see is for out-of-line functions that take their arguments by const pointer or const reference. By declaring the arguments restrict GCC can assume that the function doesn't change the pointed-to object (otherwise it must assume that every such function casts the constness away and changes the object). This optimization isn't implemented yet. > > >> * to delete or default the default copy ctor or copy assignment >> operator if/when it would benefit > > Nice idea; is there a way we can tell when this is appropriate? Suggesting to delete a copy ctor/assignment should be doable in the middle-end by analyzing the ctor and dtor for paired calls to functions that acquire and release some resource (e.g., memory via new and delete). A class that does that but that doesn't define a dedicated copy ctor or assignment can be misused to create a copy of an object and have the same resource released more than once. This is quite a common mistake to make. The second case (defaulted functions) should be detectable by analyzing the special functions' semantics and determining whether or not they are the same as those of the defaulted function. Defaulting the special function would then help make objects of the class usable in more contexts and more efficiently (especially if the special functions were defined out of line). Martin