karolherbst wrote: > Yes, this will not be merged, because the LLVM 22 release cycle has closed > and there will be no further releases. This is not a value judgement on the > importance of this issue, just a consequence of the release cycle. For issues > found after the upstream release goes EOL, backporting at the distro level is > indeed the right thing to do. In Fedora we usually accumulate a handful of > additional backports after upstream EOL (for LLVM in general -- I can't > recall an instance of us having to backport a libclc patch.) > > We probably should consider slightly extending the release cycle, to better > bridge the gap between two releases. I believe the last time this happened > was in > https://discourse.llvm.org/t/rfc-distribute-patch-releases-over-lifecycle-of-an-llvm-version/80955, > which extended the maintenance window by 6 weeks.
Yeah.. atm I'm wondering what solution to go with. I currently created a fork for libclc based on llvm 21, 21 and 23 (so distros can pick their base) which is upstream libclc + a hand full of patches to at least make sure the CL CTS doesn't trigger issues caused by something inside libclc. I can say "yeah use those patches", but then I don't know if it could break things for other users, so I can only say "it's safe to use those patches with mesa". But maybe distributions would be fine with this, because I'm not sure there are any current users of the libclc-spirv packages and mesa could just use its own patched version for the time being? There are a few issues with the 23 version, but we have still time to fix it all up, if we manage in time. https://github.com/llvm/llvm-project/pull/207264 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
