From: "Mathieu Acher" <mathieu.acher@irisa.fr>
To: kernelci <kernelci@groups.io>, groeck@google.com
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Arnd Bergmann <arnd@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Sedat Dilek <sedat.dilek@gmail.com>,
Miguel Ojeda <ojeda@kernel.org>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Kees Cook <keescook@chromium.org>, Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Arvind Sankar <nivedita@alum.mit.edu>,
Ilie Halip <ilie.halip@gmail.com>,
clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: Minimum supported version of LLVM
Date: Tue, 2 Feb 2021 00:52:12 +0100 (CET) [thread overview]
Message-ID: <1665674197.5891394.1612223532194.JavaMail.zimbra@irisa.fr> (raw)
In-Reply-To: <CABXOdTeQQv1kVF9uvU2DPf8ddWd6tzunVmjoGz77eOgbiQgOvA@mail.gmail.com>
Hi,
My 2 cents here. I've experimented a bit with older versions of the kernel (4.13, 4.15, 4.16) and gcc 8 over tinyconfig/defconfig.
It leads to some issues:
https://github.com/TuxML/tuxml/issues/30
https://github.com/TuxML/tuxml/issues/31
https://github.com/TuxML/tuxml/issues/32
There is also an interesting bug report by Nathan specifically about 4.14:
https://lkml.org/lkml/2019/4/22/794
My conclusion is that gcc 8 has difficulties for kernel version <= 4.16.
There are some patches here and there.
It seems working on 4.17 though.
Incidentally or not: Linux 4.17 has been released on 3 June 2018, gcc 8.1 on May 2018 ;)
> Can you think of a case where an old compiler must be
> used for older versions of kernel sources?
Yes (see above) and I've not tested on randconfig, which may lead to further bugs/incompatibilities.
I'm also wondering: is it worth testing 4.14 (LTS) with versions of gcc >= 8?
As it is a LTS, it seems useful/needed, but it's a bit technical I would say (patch integration, comprehension of older gcc incompatibilities/bugs, etc.)
Best,
--
Dr. Mathieu ACHER, Associate Professor
Univ Rennes, Inria, CNRS, IRISA, France (DiverSE team)
http://www.mathieuacher.com/
----- Mail original -----
> De: "Guenter Roeck via groups.io" <groeck=google.com@groups.io>
> À: "kernelci" <kernelci@groups.io>, "Nick Desaulniers" <ndesaulniers@google.com>
> Cc: "Arnd Bergmann" <arnd@kernel.org>, "Nathan Chancellor" <nathan@kernel.org>, "Sedat Dilek" <sedat.dilek@gmail.com>,
> "Miguel Ojeda" <ojeda@kernel.org>, "Lukas Bulwahn" <lukas.bulwahn@gmail.com>, "Kees Cook" <keescook@chromium.org>,
> "Marco Elver" <elver@google.com>, "Dmitry Vyukov" <dvyukov@google.com>, "Arvind Sankar" <nivedita@alum.mit.edu>, "Ilie
> Halip" <ilie.halip@gmail.com>, "clang-built-linux" <clang-built-linux@googlegroups.com>
> Envoyé: Mardi 2 Février 2021 00:30:33
> Objet: Re: Minimum supported version of LLVM
> On Mon, Feb 1, 2021 at 1:19 PM Nick Desaulniers via groups.io <ndesaulniers=
> google.com@groups.io> wrote:
>
>> On Fri, Jan 29, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> >
>> > I'm actually more worried about the reverse: as there is six year
>> > long-term support for kernels, do we expect to be able to build
>> > the oldest kernel with the latest version of llvm at the end of that?
>> >
>> > E.g. would a linux-5.4 that today can be built with clang-8 through
>> > clang-12 allow being built with clang-8 through clang-21 at the
>> > end of its life in 2025, or do we assume that LTS kernel users also
>> > have to use old compilers?
>>
>> I would think so. The newer compiler should always be better or an
>> improvement. Can you think of a case where an old compiler must be
>> used for older versions of kernel sources? Stable has said they will
>> always accept patches for newer toolchain support.
>>
>
> v4.4.y, v4.9.y, and v4.14.y require old versions of gcc for some
> architectures.
> New versions of gcc don't work for all architectures either, even
> in the latest kernel, thanks to a variety of gcc bugs. See
> https://github.com/groeck/linux-build-test/blob/master/bin/stable-build-arch.sh
> for details.
>
> Maybe clang/llvm is going to be better, but I would not bet on it. Maybe we
> should archive this exchange and, 10 years from now, dig it out and have
> a good laugh (sorry, my sarcasm is strong today).
>
> Guenter
>
>
>> --
>> Thanks,
>> ~Nick Desaulniers
>>
>>
>>
>>
>>
>>
>
>
>
prev parent reply other threads:[~2021-02-01 23:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 21:20 Minimum supported version of LLVM Nathan Chancellor
2021-01-29 21:59 ` Tom Stellard
2021-01-29 22:00 ` Miguel Ojeda
2021-01-29 22:26 ` Fangrui Song
2021-01-29 23:35 ` Arnd Bergmann
2021-01-30 1:23 ` Nathan Chancellor
2021-02-01 21:19 ` Nick Desaulniers
2021-02-01 21:40 ` Arnd Bergmann
2021-02-01 23:30 ` Guenter Roeck
2021-02-01 23:52 ` Mathieu Acher [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1665674197.5891394.1612223532194.JavaMail.zimbra@irisa.fr \
--to=mathieu.acher@irisa.fr \
--cc=arnd@kernel.org \
--cc=clang-built-linux@googlegroups.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=groeck@google.com \
--cc=ilie.halip@gmail.com \
--cc=keescook@chromium.org \
--cc=kernelci@groups.io \
--cc=lukas.bulwahn@gmail.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nivedita@alum.mit.edu \
--cc=ojeda@kernel.org \
--cc=sedat.dilek@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox