From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89691 invoked by alias); 18 Nov 2019 16:45:35 -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 89459 invoked by uid 89); 18 Nov 2019 16:45:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:T5hwg@m, H*MI:sk:T5hwg@m, H*i:sk:T5hwg@m X-HELO: mail-pf1-f194.google.com Received: from mail-pf1-f194.google.com (HELO mail-pf1-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Nov 2019 16:45:13 +0000 Received: by mail-pf1-f194.google.com with SMTP id z4so10625590pfn.12 for ; Mon, 18 Nov 2019 08:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jTEeeQyGHswMc7KovQymetGM1UiDr6Zk23r5yWN6PoE=; b=kb/EYdRpyklKDAvTxR45bIeo8reTuKM59VZD7Mr7QJPCF88oB0XdN/OV85JH3BZmcA gIcf+lM9zEk1kMGFL5BB0U7PL5FAkXd+jdxpmCYujB0eLJqXqp/L5VQMLrxVEATU2G24 wUXBI/pMUsVgCXmcwtCyqIhnF8CKJTmQBkpUrBEX93Y0IgM0uO0UWUwZX+rR+YUbQsYR j4jQiYnaZXgVawbJYfyyOkxyi/yn2oHr41ikL7xZ0BpMLTffSycWr0YrsR6jBnBOWh4A NBf4lwKrUEnkSYKwT3u6WQ2QAoIcnJERRdtchxfhSc1imOlgDwXsSQWrjBGFpOHVJHA4 E+hQ== Return-Path: Received: from [192.168.0.41] (97-118-98-145.hlrn.qwest.net. [97.118.98.145]) by smtp.gmail.com with ESMTPSA id r33sm20695882pjb.5.2019.11.18.08.45.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Nov 2019 08:45:01 -0800 (PST) Subject: Re: [WIP PATCH] add object access attributes (PR 83859) To: Richard Biener Cc: Jeff Law , gcc-patches References: <056e2b5b-696c-ca69-9027-7d2369354b07@gmail.com> <3b148654-b12c-1e7c-32d2-78df9d6c70e7@gmail.com> From: Martin Sebor Message-ID: <2d4cec52-3afa-227f-9f1d-e82b948003f9@gmail.com> Date: Mon, 18 Nov 2019 16:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg01731.txt.bz2 On 11/18/19 1:36 AM, Richard Biener wrote: > On Fri, Nov 15, 2019 at 10:28 PM Martin Sebor wrote: >> >> Thanks for the suggestion. I will do that for GCC 11. I take >> Richard's point that the attributes' semantics need to be clearly >> and carefully specified before they're put to use for optimization. > > Before they are exposed to users please. It doesn't help if we > specify the same attribute for optimization later when uses are out > in the wild "guessing" at what the possible interpretation is. > > Maybe we can name your attributes maybe_readonly and friends > to clearly indicate that this is only a guess by the user so at most > usable for diagnostics but never for optimization. > > Since we have quite costly attribute lookup I also prefer something > that translates to less attributes - how about > __attribute__((diag_argspec(1, readonly), diag_argspec(2, writeonly))) > to indicate argument 1 is maybe readonly, 2 is writeonly? We can > then merge this into a single diag_arspec attribute instance we can > lookup. I can look into making a change along these lines. I'm not fond of the idea of introducing a "maybe" kind of attributes now and another parallel "for-sure" set later. My goal is to have the attributes express the same access constraints as those on the arguments to built-in string functions like memcpy or strcat (i.e., read_only only reads a pointed-to object, write_only only writes, and, for strcat, read_write both reads and writes it). Those properties are sufficiently well understood. The three attributes aren't intended to express constraints on aliasing or on the side-effects of the functions, like restrict or the const and pure attributes. To let users do more than that, some additional annotation will probably be necessary. In my WIP patch I have a no_side_effect attribute that lets functions do more than const and pure but that's still work in progress that I don't plan to submit for GCC 10. Martin > >>> >>> I don't see anything terribly concerning. Looking forward to the final >>> iteration here. >> >> Attached is a subset of the original patch that just adds the three >> attributes and uses them to do buffer overflow checking. I have >> also enhanced the detection of invalid arguments (null pointers, >> negative sizes). >> >> Retested on x86_64-linux. >> >> Martin