Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Marco Elver <elver@google.com>,
	clang-built-linux <llvm@lists.linux.dev>,
	Peter Zijlstra <peterz@infradead.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Aaron Ballman <aaron@aaronballman.com>,
	"Jose E. Marchesi" <jemarch@gnu.org>
Subject: Re: Clang/LLVM 'main' regression testing and -Wthread-safety
Date: Wed, 11 Feb 2026 12:51:39 -0700	[thread overview]
Message-ID: <20260211195139.GB3482274@ax162> (raw)
In-Reply-To: <CANiq72k6ZHbW+tnX8jjOUaj4aSMigEaH4SEkODX==OJBseKCug@mail.gmail.com>

On Wed, Feb 11, 2026 at 12:54:40PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 11, 2026 at 11:59 AM Marco Elver <elver@google.com> wrote:
> >
> > I recall there was a CI system that did this, but lost track of what's
> > the latest.
> 
> I think you may be referring to
> https://github.com/ClangBuiltLinux/continuous-integration2.

Indeed.

> By the way, some time ago I asked Aaron (Cc'd) whether we could get
> the kernel into upstream LLVM's CI system, i.e. to at least build a
> minimal kernel configuration of a fixed, tagged release for one or two
> architectures. Would that help you?
> 
> (I also suggested Jose (Cc'd) the same, for GCC.)
> 
> The idea is that it helps both sides. It serves to catch issues very
> early on (including with subtle things like diagnostics), and thus
> avoids having to play catch up later to fix them (compiler) and/or
> workaround them (kernel) in either side.
> 
> To be clear, this wouldn't replace the other CIs that run out of tree,
> like Nathan's and the tests I do for Rust stuff etc., i.e. it is not
> about catching every compiler issue or testing the kernel as a
> product.
> 
> For context, this all happened because I asked the same to upstream
> Rust and it was a success there. In that case, the goal was to catch
> issues early with the unstable features we use, but it helps with
> other things too, and thus I think it would help just the same for
> Clang and GCC. So far, we only got pinged a few times, so it has not
> been a lot of work, and it did catch a couple issues (which sometimes
> may end with a preemptive kernel patch or fixing the upstream PR).
> 
> We also did it for upstream `bindgen`, and hopefully it will happen
> for `rustc_codegen_gcc` (currently we have an out-of-tree one) and GCC
> Rust eventually.
> 
> Anyway, this is a bit of a tangent, but I thought I could raise it up
> again and see what comes out of it...

It has always been on my backburner to try and get a build of the Linux
kernel as part of LLVM's continuous integration but I have never had the
time to sit down and interface with folks to see what exactly that
entails (I figured it would involve integration with LLVM's build bot
infrastructure but I have not dug in super hard to the documentation).
An arm64 and x86_64 defconfig build would probably catch quite a bit of
initial breakage and it would be easy to pin Linux's version and only
bump it when thoroughly tested.

Cheers,
Nathan

  reply	other threads:[~2026-02-11 19:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <aYhfK3tB0X6Y_GyV@gmail.com>
     [not found] ` <177076109527.3702729.10282954256881857059.pr-tracker-bot@kernel.org>
2026-02-11 10:58   ` Clang/LLVM 'main' regression testing and -Wthread-safety Marco Elver
2026-02-11 11:54     ` Miguel Ojeda
2026-02-11 19:51       ` Nathan Chancellor [this message]
2026-02-12 12:22         ` Aaron Ballman
2026-02-12 17:01           ` Nathan Chancellor
2026-02-12 20:03           ` Miguel Ojeda
2026-02-11 19:40     ` Nathan Chancellor
2026-02-11 23:53       ` Marco Elver
2026-02-12 16:57         ` Nathan Chancellor

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=20260211195139.GB3482274@ax162 \
    --to=nathan@kernel.org \
    --cc=aaron@aaronballman.com \
    --cc=bvanassche@acm.org \
    --cc=elver@google.com \
    --cc=jemarch@gnu.org \
    --cc=llvm@lists.linux.dev \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=peterz@infradead.org \
    /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