From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14AC7C433DF for ; Thu, 9 Jul 2020 09:30:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EA8C820663 for ; Thu, 9 Jul 2020 09:30:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726590AbgGIJar (ORCPT ); Thu, 9 Jul 2020 05:30:47 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:40663 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726444AbgGIJar (ORCPT ); Thu, 9 Jul 2020 05:30:47 -0400 Received: from mail-qt1-f180.google.com ([209.85.160.180]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N1PLB-1kukYx37et-012nFH; Thu, 09 Jul 2020 11:30:44 +0200 Received: by mail-qt1-f180.google.com with SMTP id o38so1141868qtf.6; Thu, 09 Jul 2020 02:30:44 -0700 (PDT) X-Gm-Message-State: AOAM533iGCYVcsfLjfbLQ+hhH0hRC2iv0+NWTa+MtIg5LCFhi3og8f0O GbZDZSTJ4PiBa3B11XgDyLneCer+nyn226KYyyY= X-Google-Smtp-Source: ABdhPJya8KYSjP4Vpazo2pyPOtp1xixDd/LrBpy7KWM87TVOcxWC9KZT2AhHFlbVXr6XdAAgrM3BYamH6NXqKGbmOGs= X-Received: by 2002:ac8:4507:: with SMTP id q7mr63620552qtn.142.1594287043518; Thu, 09 Jul 2020 02:30:43 -0700 (PDT) MIME-Version: 1.0 References: <20200628182601.GA84577@gmail.com> <20200708162053.GU4800@hirez.programming.kicks-ass.net> In-Reply-To: From: Arnd Bergmann Date: Thu, 9 Jul 2020 11:30:27 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] EFI fixes To: Linus Torvalds Cc: Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , Ard Biesheuvel , Thomas Gleixner , Borislav Petkov , linux-efi Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:gf6Do5RSBjDjAUrRhYphUARohS0MGye5iw38Wi20Q7K2qIlDRP+ nAtuzPHSIWVTJJh+Y9XzbrQ8HUsjk0g+0VrrWwtlYKkk/u6VDC8dDz/567uerK+/GrHsinM nL2hlzEktiiOeAgjU/1FQUXfA4yXOpEjtYeGNUQ8lmpcPjZz+ucjQAY2G9jO5jlMrtLdyW4 pbyg1MF8u9pLnRktzZOIg== X-UI-Out-Filterresults: notjunk:1;V03:K0:30W8Tdkdp4U=:vv8aO2cKSp5Sm58Sw5kbJS epZWaWDnKpWamfcZ2cgP3VjylRAcvbfwdbiX5+12CbiA/ueKzMPMKdVTY43d6Mn5srjfqE1HQ x5sjcVN7uHeZ9+oMCeBW7eZlfiR66ZXJYZda2MvSCCy2RWTqRy35jDr93g4VvDYZmssAF3cbk uwW84mrcR+tDVIicZs8XDnM2HbLkbFNNBf5hq2qRTw2Msq78PLYeEAhkboEf6jIZGM3VLjyWc wxf1raheuYgMWzeKj/xZWPvMdsOGzlHKlQ0GMxW9z7wtmj2DdcGN2zPRMtRSt8fRe17MFeh0l ZzMRX6Bc5Q9VXPDwAtnRGTwSJH/dhEGdzuABy8NMdMVru7xjZzvESCkHWQaouov4PEe5Vt6pw pJxsCHIakhA36eaQOcecEUmPe7pq3kTzmo0e4k9dXKclPxcpGoNrMycZOMB4ttCXJFaKw19gS ADiy2dCwPcqgTyZGUTfMk0IeyBl+CkAuJoMcZbLo5H2Dg6zhQR24iStC7s4uIUHmrxX0/YsyL rQPFc2mqsh2G6OBLctad/PQBNLdS2KhC5ZoQf37k674BtpCouNLBH4B4nf2A7tkUyic0PqTXT 57KqPNUWujlJoftytHO5Mkx9s8n5DdwheSUszCioek5VlkLIcGPpgdlePpKSSmmParu0sKlZE pDezrveeuX266eXPTJyPjaLi8d08ipeZJA9p3FGoM/4br6xXASsocEdU6VCYhmk6pZU+lz3/t oHiJgzntNxDd0vbfxGUn9caV9bIaA6CZziWtvpUCeLPNnZYJfwHn/+RK71HICmIaVA8yynK0X KtoACepfSvNWIhehmMaSwkK3OfPF8ijgybLK1CPWfhVyThvGHPybAhxrA9hxAnZ97B4t4Kp Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Wed, Jul 8, 2020 at 8:00 PM Linus Torvalds wrote: > > On Wed, Jul 8, 2020 at 9:21 AM Peter Zijlstra wrote: > > > > > > It's perhaps yet another reason to just skip gcc-4.8 too, since > > > apparently 4.9 works. > > > > > > gcc-4.9 really has a lot of advantages. It's where (I think) gcc > > > basically supports all C11 things, including _Generic() but also > > > __auto_type. > > > > +1 > > > > Anybody for nay, or should we just do this? > > I'll just do it. Let's see if anybody screams with a good reason. I > hate the whole "support old compilers", it ends up not only making for > complex code, it tends to cause these unnecessary kinds of "guys, we > tested this really well, but that crazy compiler had a very particular > odd issue, and it wasn't in any test box. Cool, thanks for changing it, this is clearly a better suited compiler version. Aside from the added C11 features, this is also where a lot of the optimizations changed, so code generation is more predictable if we don't need to worry about gcc-4.8. On the flip side, gcc-4.8 was used by old enterprise distros that are still supported (SUSE 12, RHEL 7), whereas gcc-4.9 was only shipped in Debian Jessie and Android releases that are both EOL now (Android never moved beyond a buggy gcc-4.9 prerelease but now uses clang for everything). I don't see any technical reasons to go even further, but if something does come up, the users of these Long-term supported distros would be most impacted by a change: gcc-4.9: Used in Debian 8 (Jessie), EOL June 2020 gcc-5: Used in Ubuntu 16.04 (Xenial, Mint 18, ...), EOL April 2021 gcc-6: Used in Debian 9 (Stretch), EOL 2022 gcc-7: Used in SLES 15, Ubuntu 18.04 (Bionic, Mint 19, ...) gcc-8: Used in RHEL-8 (centos, oracle, ...), OpenWRT The most interesting version to require in the future would be gcc-7, which IIRC is the point at which we can just use -std=gnu99 or -std=gnu11 instead of -std=gnu89 without running into the problem with compound literals[1]. Arnd [1] https://patchwork.kernel.org/patch/11195831/