[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240109195652.GA1253215@dev-arch.thelio-3990X>
Date: Tue, 9 Jan 2024 12:56:52 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Miguel Ojeda <ojeda@...nel.org>, Kees Cook <keescook@...omium.org>,
"Gustavo A . R . Silva" <gustavo@...eddedor.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH] Compiler Attributes: counted_by: bump compiler versions
On Tue, Jan 09, 2024 at 08:42:24PM +0100, Miguel Ojeda wrote:
> On Tue, Jan 9, 2024 at 4:32 PM Nathan Chancellor <nathan@...nel.org> wrote:
> >
> > It is still possible in theory for this feature to make clang-18, as the
> > release/18.x branch is not scheduled to be cut until the fourth Tuesday
> > in January, which is two weeks from now. I don't have a good feeling for
> > how close that pull request is to being mergeable though, so this is
> > fine for now. I assume this won't go to Linus immediately so we would
> > have time to change it if necessary.
>
> Yeah, I was wondering about the deadline too. If LLVM's `-rc1` is the
> latest time possible to merge it, we can wait the couple weeks (which
> are conveniently the merge window) and I apply it afterwards with the
> result :)
If I understand the doucmentation at [1] correctly, the first round of
testing starts with -rc1 and ends with -rc2, so if the feature is not
merged by -rc2, it won't make that release cycle. I think counted_by
might be a hard sell even after -rc1 because the feature is not exactly
small but it is also not expansive (it is relatively self contained
from what I can tell). So I think your plan is reasonable.
Another alternative would be to split this patch in to three distinct
patches, not sure if that would be overkill for this though.
1. Update the clang review link from reviews.llvm.org to github.com
2. Update the GCC version from 14 to 15.
3. Update the Clang version from 18 to 19.
The first two patches could be picked up immediately and the third one
could be sat on to see how the review and acceptance process works out
over the next couple of weeks. Up to you/Sergey. Thanks for taking a
look!
[1]: https://llvm.org/docs/HowToReleaseLLVM.html#release-process-summary
Cheers,
Nathan
Powered by blists - more mailing lists