From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24357 invoked by alias); 14 Feb 2020 20:50:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24337 invoked by uid 89); 14 Feb 2020 20:50:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=awaiting, drives, sadly, 7.4 X-HELO: resqmta-po-07v.sys.comcast.net Received: from resqmta-po-07v.sys.comcast.net (HELO resqmta-po-07v.sys.comcast.net) (96.114.154.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Feb 2020 20:50:06 +0000 Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-07v.sys.comcast.net with ESMTP id 2gv4jSHiiEIvH2huWjfRsq; Fri, 14 Feb 2020 20:50:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1581713404; bh=SG3M9vbuXjLYLa+MQl1TUvCdQViJ+rZk5t7rcU6P+qM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=WqlINs4e98VXHZkCQQHv4TyCkmMlTuNSqvfbXJIOCxOv9AaitPp8iT73XVevDwR1a g5ak6ExHzCzyidsjqD5h1oZWvn3Jamlz5t5cP0YhXJ0Fv/x8TDZxLdemxyO70eccCC RwtvMc+Gc6FK4sbiZn3OYbnEZCjC/z7KZRdGcDokW5q9kBRfmwcYqFKuNpZOdhJ+3w ai4uYd8mc6gs6aOVw941xcWhY1/7OvNCTaiz/lmoojDmXT5b2MqaQZXB3VY6/fG0do pgYTclk+m2C5NlAsd4EzaAZpnrQsMCNsRVDL5tBJopJX5dbc704dycHdi8MetYl8as McpN0OY4k0/0g== Received: from [IPv6:2601:640:4000:fcbb:c9c9:31a8:ceb7:ab81] ([IPv6:2601:640:4000:fcbb:c9c9:31a8:ceb7:ab81]) by resomta-po-05v.sys.comcast.net with ESMTPA id 2huQjUMF0OfMQ2huTjeQza; Fri, 14 Feb 2020 20:50:03 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: GCC selftest improvements From: Mike Stump In-Reply-To: Date: Fri, 14 Feb 2020 20:50:00 -0000 Cc: Gabriel Dos Reis , Andrew Dean , David Malcolm , "gcc@gcc.gnu.org" , "ro@CeBiTec.Uni-Bielefeld.DE" , Jason Merrill , Jonathan Wakely Content-Transfer-Encoding: quoted-printable Message-Id: <2B0B79B1-A56F-43CE-92E9-F4AAC48D7117@comcast.net> References: To: Jeff Law X-SW-Source: 2020-02/txt/msg00134.txt.bz2 On Oct 28, 2019, at 12:40 PM, Jeff Law wrote: > I'd really like to see us move to C++11 or beyond. Sadly, I don't think > we have any good mechanism for making this kind of technical decision > when there isn't consensus. I'll just point out that we do have good mechanisms in place. Consensus bu= ilding is a nice way of doing things, but, when that fails, we can punt to = a well established reviewer to just make a decision, because sometimes a ma= de decision is better than failing to make a decision, which, itself, is a = decision. It that should fail for any reason, anyone should feel free to p= unt to the SC. Generally we don't use them this way, but, I think it's rea= sonable to do this if all the maintainers are shy about this or need guidan= ce. For example, the current policy is to pick the minimum gcc version of all t= he current LTS release of all the distributions/OSes. I could propose this= be the policy to the SC, then they could, if they wanted to, agree with th= e policy, then we can document the policy, and then a reviewer can approve = a doc patch to say that gcc X or newer is required, whenever the new X is t= he oldest among the then current set of distributions/OSes. The policy dri= ves expectations, and drives approvals to bump. Now, that's just a recomme= ndation. A reviewer might have a reason to not bump the tools, and that's = ok as well. No reviewer should feel bad, approving a bump when that bump f= ollows the policy however. If I apply the current policy, [ checking around ] My 18.04 has 7.4 in it.= Centos 8 has 8.2. It would seem that a bump to 7.4 should be fine, now. = I didn't look at other distributions, but we can go through the list, and = on the basis of what version is in the current LTS/OS, contemplate the bump= the the minimum of all of them. That's basically the status quo policy. Now, people do like to hold onto old OSes and old machines. And we cater t= o them by having old releases that can drop onto their system and just run.= For example, I have a 14.04 machine, that's still awaiting 20.04 to upgra= de to, but thats because I want to cater even to very old releases (all LTS= releases that are not EOL), cause doing this is very cheap. I manage this= by dropping a gcc 9 onto the box so that I have a known, not that old comp= iler. Presto, all my software can now use gcc 9 features and not worry abo= ut it. So, I'd propose bumping the minimum to 7.4 if people want to update. Peopl= e can comment what release fedora, arch, SUSE and so on have. Since 7.4 ha= s c++17 in it (non-default), accepting patches that turn on c++17 in that c= ompiler isn't unreasonable, but that's orthogonal to the version bump. My = old Apple has c++17 on it. Don't have a windows box, but google seems to s= uggest that their tools support c++17. I think we should pick not on the basis something unspecific, rather, I'd l= ist the 3 5 or 9 systems we check against, and then pick the minimum of the= m. Above I picked 7.4 because it's on 18.04. I think this makes for a be= tter policy as it's predicable, stable, and in 100 years, I don't think I s= ee the need to change the policy.