From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49853 invoked by alias); 17 Jul 2017 17:16:32 -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 49829 invoked by uid 89); 17 Jul 2017 17:16:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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=(unknown), hundred, engineers 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; Mon, 17 Jul 2017 17:16:27 +0000 Received: by mail-qk0-f174.google.com with SMTP id d78so125827620qkb.1 for ; Mon, 17 Jul 2017 10:16:27 -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=mz8vNivX8blPLApDSvgrWdSKqViMSsIZ5rnjf38jegY=; b=AGI1AftAcApk4Z2Dj0+LP1npKlk0d2/B56CkWr8HJ2QPcV+1djpDNMH58L04iPKB2X bV5S0Yv/rp/2KFpyjuw0PYQBkVRdYL/V5b9M483noic3q6AbH9wNc0fK02UyLeB2gqQP aYaXOtaKqya2MeDlSRAGJQlW8bDsCMenTJyK77XZxd7BwJ/zEc4KuMC2NgavFGLqoHP7 SHhkOyXsacrsiC4ewLhS8pXiZybbPi0AthRvXYRzJiZWMqOXs9mW9yVfWPXQqERcfX3Q IGhk9ZiLJgMbATCtxaowbl/Tkfcu668UwmcY2rrLtlt6nvDEuWpBkBjTLG2WokjZ6fzZ HxpQ== X-Gm-Message-State: AIVw110N6HtUdJy4WJW8CCoxsLMjXRo13th32xCcdU9Y0nKGV0clCNZ7 DQRPhH4o3/V/kR9h X-Received: by 10.55.81.198 with SMTP id f189mr29823979qkb.82.1500311785523; Mon, 17 Jul 2017 10:16:25 -0700 (PDT) Received: from localhost.localdomain (75-171-229-159.hlrn.qwest.net. [75.171.229.159]) by smtp.gmail.com with ESMTPSA id k22sm7988559qtf.26.2017.07.17.10.16.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 10:16:24 -0700 (PDT) Subject: Re: [PATCH] gcc/doc: list what version each attribute was introduced in To: "Daniel P. Berrange" , gcc-patches@gcc.gnu.org References: <20170706132518.GO3988@redhat.com> From: Martin Sebor Message-ID: Date: Mon, 17 Jul 2017 17:16: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: <20170706132518.GO3988@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00992.txt.bz2 On 07/06/2017 07:25 AM, Daniel P. Berrange wrote: > There are several hundred named attribute keys that have been > introduced over many GCC releases. Applications typically need > to be compilable with multiple GCC versions, so it is important > for developers to know when GCC introduced support for each > attribute. > > This augments the texi docs that list attribute keys with > a note of what version introduced the feature. The version > information was obtained through archaeology of the GCC source > repository release tags, back to gcc-4_0_0-release. For > attributes added in 4.0.0 or later, an explicit version will > be noted. Any attribute that predates 4.0.0 will simply note > that it has existed prior to 4.0.0. It is thought there is > little need to go further back in time than 4.0.0 since few, > if any, apps will still be using such old compiler versions. A few years ago I created something like this for command line options. I used a script to download the GCC manual for each version, extract new command line options from the index, and tabulate them. > > Where a named attribute can be used in many contexts (ie the > 'visibility' attribute can be used for both functions or > variables), it was assumed that the attribute was supported > in all use contexts at the same time. > > Future patches that add new attributes to GCC should be > required to follow this new practice, by documenting the > version. I think this is great material. I don't have a strong opinion on where it belongs (the manual, the Wiki, or somewhere else), but given how tedious it can be to get at this information I think having it available somewhere in some form could be quite useful. (I specifically needed it in a tabular form, with option names on left and versions in columns.) Martin PS The version information isn't just used by engineers writing code (where I agree that having a portable API to query it would be more robust than copying it from a static page). In my experience, it's also used to drive decisions about adopting different versions of GCC or versions of other compilers that aim to be (near) 100% GCC compatible (such as Intel ICC).