KernelCI discussions
 help / color / mirror / Atom feed
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
>>
>>
>> 
>>
>>
>>
> 
> 
> 

      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