LLVM 14.0.1 Schedule and Release Updates

LLVM Project
1

Hi,

Here is the proposed schedule for the 14.0.1 Release:

April 19: 14.0.1-rc1
May 17:   14.0.1-rc2
May 31:   14.0.1-final

Also, to help track the status of 14.0.1 (and future releases) I’ve created a GitHub project that gives a nice overview of all the current issues and their status. The workflow is still the same as before, if you want a commit backported, file an issue and add it to the LLVM 14.0.1 Release Milestone, you don’t need to add issues to the new project, I will take care of that part. Let me know if there are any questions.

2 Likes
2

Hi,

Thanks for putting up the proposed schedule and for creating a GitHub project to provide this overview – I think this is really awesome! I was not aware of some of the tools provided by GitHub to track projects, and will look into using them more for libc++.

We shipped LLVM 14 with an unfortunate regression in std::span which makes adoption of LLVM 14 somewhat difficult in large code bases. Long story short, some valid code won’t compile anymore, and while workarounds exist, it’s a bit painful and it really shouldn’t be necessary since the code is 100% fine from a user’s perspective. This is my fault, I let that slip into the release, did not realize it was going to have the impact it has, and my fixes missed the final RC by a couple of days. Had I known the impact, I would have made this a release blocker.

We do have a workaround on the release/14.x branch already, but it missed the last release candidate. With the proposed release schedule, we would have to wait until May 31st for this issue to be fixed. Instead, I would like to express support for the release schedule changes you proposed here some time ago, and I wonder whether there would be interest for switching to this new process for the LLVM 14 release.

If that were to happen, it would reduce the time to get this fix to our users from 12 weeks to roughly 2 weeks, which would be really awesome. Thoughts?

Thanks,
Louis

3

I was never able to actually implement the schedule changes, because I didn’t feel like we had enough automated testing in place. This has changed, though, and we now have 11 buildbots testing the release branch, so I feel comfortable implementing this new schedule if there is still support for it. My only concern is that making this decision at this point in the release cycle may catch users off guard, but on the other hand we haven’t finalized the release schedule yet, and maybe it’s not all that big of a change. There are certainly a lot of benefits to moving to the new schedule.

4

Tagging some of the release testers to see how they feel about this.

@rorth @tobiashieta @amy-kwan @androm3da @rovka @quinnlp @DimitryAndric @sylvestre @hansw2000

5

Yeah - I don’t have a huge problem with it since I have automated my release process pretty well now. So I say :+1:

6

+1, I’m fine with switching.

7

Sounds good to me.

8

My primary concern for 14.0.1 is whether there are plans to switch back to -DLLVM_ENABLE_RUNTIMES. ninja check-all still doesn’t include the runtime checks on main, and while I have some grip on Issue #54196, I’m not there yet and cannot tell when I’ll find the time. Maybe it would be better to postpone that change (and the new runtime dir layout) to LLVM 15 to have things properly flashed out, rather than doing it in the middle of the LLVM 14 cycle?

9

Sounds good to me as well.

10

I would like to see this fixed in 14.0.x if possible. I’m not sure what the current status is of it in main.

11

Thanks Tom, this also sounds good to me.

12

I’m fine with moving forward with more point releases and no RCs. (My only concern is how much nagging I’ll get if I skip a release due to a lack of bugs that impact our packages.)

13

It has improved compared to two weeks ago, but still not right. I’ve just run two x86_64-pc-linux-gnu builds, one with

  • -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;compiler-rt;polly and another with
  • -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;polly' -DLLVM_ENABLE_RUNTIMES=compiler-rt

Test results are similar, but notably different:

  Skipped          :    74
  Unsupported      :  2870
  Passed           : 87778
  Expectedly Failed:   259
  Failed           :     4

vs. (with runtimes)

  Skipped          :    38
  Unsupported      :  2738
  Passed           : 84856
  Expectedly Failed:   257
  Failed           :     4

Several groups of tests aren’t run for the runtimes build:

    836 AddressSanitizer-Unit
      3 Builtins
    211 Builtins-i386-linux
    211 Builtins-x86_64-linux
     59 GwpAsan-Unittest
      4 Interception-Unit
     58 LLVMFuzzer-Unittest
    714 SanitizerCommon-Unit
    459 ScudoStandalone-Unit
    459 ScudoStandalone-Unit-GwpAsanTorture
     78 ThreadSanitizer-Unit
     30 XRay-x86_64-linux

I wouldn’t consider this ready for prime time, and miserably tested on top of that.

14

There seems to be a lot of support for making this change so here is a new proposed schedule:

April 11: 14.0.1
April 25: 14.0.2
May    9: 14.0.3
May   23: 14.0.4
June   7: 14.0.5
June  21: 14.0.6 (If necessary to fix critical issues with 14.0.5)

Let’s try this and see how it goes. We can always make changes (e.g. extend interval to 3 weeks) if we decide it’s not working out.

15

Please fix the library symlink lib/libclang.so.13 lib/libclang.so.

From my yesterday’s build-log (release/14.x // llvmorg-14.0.0-5-g99c0f85ef992):

$ egrep 'Build files have been written to:|libclang.so' log_tc-build.txt
501:-- Build files have been written to: /home/dileks/src/llvm-toolchain/build/stage1
3940:[3439/3749] Linking CXX shared library lib/libclang.so.14.0.1
3941:[3440/3749] Creating library symlink lib/libclang.so.13 lib/libclang.so
4565:-- Build files have been written to: /home/dileks/src/llvm-toolchain/build/stage2
7444:[2879/3427] Linking CXX shared library lib/libclang.so.14.0.1
7445:[2880/3427] Creating library symlink lib/libclang.so.13 lib/libclang.so
8336:-- Build files have been written to: /home/dileks/src/llvm-toolchain/build/stage3
11655:[3319/3427] Linking CXX shared library lib/libclang.so.14.0.1
11656:[3320/3427] Creating library symlink lib/libclang.so.13 lib/libclang.so
16

This is intentional, cf. libclang produced by 14.0.0.rc1 has wrong so-number · Issue #54004 · llvm/llvm-project · GitHub

17

The lack of a version bump on libclang.so due to no ABI changes is breaking at least one FreeBSD port when built against LLVM 14. It should be easy enough to work around, but I wonder if it wouldn’t make sense to install a libclang.so.14 symlink (at least in our local package) to simplify the mapping between llvm dependency and libclang version for things that aren’t finding libclang via cmake or the like.

18

I think this is reasonable, can you file an issue for this an assign it to me?

19

https://github.com/llvm/llvm-project/issues/54853

20

I just noticed these are all Mondays and I meant for them to be Tuesdays, so I’m going to make each release 1 day later.