Update to LLVM 9 trunk #62592

nikic · 2019-07-11T17:41:18Z

Following the preparatory changes in #62474, this updates the LLVM submodule to https://github.com/rust-lang/llvm-project/tree/rustc/9.0-2019-07-12 and:

Changes the LLVM Rust bindings to account for the new SubtargetSubTypeKV.
Adjusts a codegen test for the new form of the byval attribute that takes a type.
Makes a PGO codegen test more liberal with regard to order and linkage.
Builds InstrProfilingPlatformWindows.c as part of libprofiler_builtins.
Moves registration of additional passes (in particular sanitizers) to the end of the module pass manager.
Disables LLDB on builders.

r? @alexcrichton

rust-highfive · 2019-07-11T17:41:30Z

⚠️ Warning ⚠️

These commits modify submodules.

cuviper · 2019-07-11T17:53:24Z

Can you also update the branch name in .gitmodules?
(useful for git submodule update --remote src/llvm-project)

nikic · 2019-07-11T17:58:12Z

@cuviper Done!

alexcrichton · 2019-07-11T18:55:32Z

This looks like it's moving the submodule to 56b8425750e78974fcc8c64429739bc8c2d84f08 which exists but the tip of https://github.com/rust-lang/llvm-project/commits/rustc/9.0-2019-07-08 is rust-lang/llvm-project@bd791b5, was there perhaps a forgotten push to the branch?

nikic · 2019-07-11T19:21:14Z

@alexcrichton The submodule points to the tip of rust-lang/llvm-project#19. If you prefer you can merge that first and I'll update the reference here. I don't have push access to the llvm-project repo.

alexcrichton · 2019-07-11T19:24:57Z

@bors: r+ p=1

Er oops sorry forgot about that! I pushed that commit up to avoid creating an extra merge commit and we should be good to go now :)

I'm gonna raise the priority of this since it's highly likely to bounce at least once due to llvm issues, and we should weed those out ASAP. Note that this is also likely to time out while the sccache caches are populated.

bors · 2019-07-11T19:24:58Z

📌 Commit 4aeffb28c1a7b9b5c13712e0097a18e6981cd87e has been approved by alexcrichton

bors · 2019-07-11T20:37:41Z

⌛ Testing commit 4aeffb28c1a7b9b5c13712e0097a18e6981cd87e with merge ee77050c65f1ea1c37f81e6429e78c6fded991d7...

bors · 2019-07-11T21:54:51Z

💔 Test failed - checks-azure

nikic · 2019-07-11T22:01:55Z

Linker error on macos:

Undefined symbols for architecture x86_64:
  "___isOSVersionAtLeast", referenced from:
  llvm::sys::fs::copy_file(llvm::Twine const&, llvm::Twine const&) in librustc_llvm-c1fd4cbc1eee8759.rlib(Path.cpp.o)
ld: symbol(s) not found for architecture x86_64

alexcrichton · 2019-07-11T22:07:29Z

Hm so I've seen that for the longest time in the macOS_static build of curl-rust on azure. I've never been able to track it down further beyond the usage of __builtin_available around here. I suspect this is coming out of https://github.com/rust-lang/llvm-project/blob/56b8425750e78974fcc8c64429739bc8c2d84f08/llvm/lib/Support/Unix/Path.inc#L1157 which is presumably a recent change to OSX.

This is very likely related to our usage of MACOSX_DEPLOYMENT_TARGET in one way or another, although that could also just be a wild guess. The easiest fix would be to just patch that out and not worry about it

nikic · 2019-07-11T22:58:41Z

The correct solution here is probably to either link compiler-rt into librustc_llvm on darwin, or maybe include os_version_check.c in https://github.com/rust-lang-nursery/compiler-builtins/blob/5e06435c291211a6443d3b29b948faa3ccaaa180/build.rs#L199. But I don't have a macos system to test, so I'll probably go with patching it out...

nikic · 2019-07-12T14:17:47Z

Updated submodule to include rust-lang/llvm-project#21.

alexcrichton · 2019-07-12T14:23:20Z

@bors: r+ delegate+

bors · 2019-07-12T14:23:22Z

✌️ @nikic can now approve this pull request

bors · 2019-07-12T14:23:23Z

📌 Commit 37be9dbde72f5d81ef0ac2b1b6d4163e5ef12d8d has been approved by alexcrichton

nikic · 2019-07-12T15:09:54Z

Another submodule update to include rust-lang/llvm-project#20.

@bors r=alexcrichton

golddranks · 2019-07-23T00:28:50Z

@nikic What's the reason building LLDB was disabled? I can't find any rationale in this thread.

nikic · 2019-07-23T07:48:24Z

@golddranks This was discussed in rust-lang/llvm-project#19. However, I think the decision might have been made on an incorrect premise, that we're not shipping lldb via rustup. It looks like that's true for Linux, but we did ship it on apple targets, such as https://rust-lang.github.io/rustup-components-history/x86_64-apple-darwin.html.

As the rust lldb patches currently don't have a maintainer, I don't think we'd want to bring those back, but possibly we should be shipping a vanilla LLDB build for those targets where we used to ship something previously? Not sure what the benefit of doing that over just using a system LLDB is though.

alexcrichton · 2019-07-23T15:53:29Z

FWIW despite being shipped in rustup it still wasn't really operational or hooked up anywhere. The binary wasn't code-signed so I don't think it worked without extra privileges, and nothing was hooked up to the binary that was installed and the binary was very deeply buried in the sysroot (not added to PATH) or anything. It still effectively (AFAIK) was unused and not well tested. The original purpose was to start down a road of shipping LLDB but it ended up not making a lot of progress, so this saves time in rebasing and on CI while we figure out a different way to move forward.

golddranks · 2019-07-24T03:03:00Z

It seems that the lldb-preview compontent has been missing in the nightlies; we have been shipping that experimentally on macOS.

About shipping our own LLDB builds: at least we can then be sure about the interface. There was at least one example of it breaking because the command line interface changed a little ( d6e410b#diff-81ad6c936ea3b391e9adf118059012ed ) I'm not sure how much things tend to change over time, but shipping our own LLDB would at least guarantee that it works with the scripts.

However, I didn't know that we used to patch LLDB. Do you have any idea to what extent the functionality of the scripts depends on the patches? How big the patches are and is there any chances of upstreaming at least some, or are we doomed to play catch up if we support LLDB? Edit: Missed @alexcrichton 's comment. Huh, I guess I'm gonna double check what binary rust-lldb uses!

Related PR: rust-lang/rust#62592

bootstrap: remove lldb dist packaging The lldb-preview rustup package is missing on every single target, and has never been shipped beyond x86_64-apple-darwin. It was removed in rust-lang#62592 which landed around a year ago, and there's not been demand that we re-enable it since, so we're now removing support entirely to cleanup the code a bit. The hope is that this will also kill the useless "lldb-preview" row on https://rust-lang.github.io/rustup-components-history/.

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple*

rust-highfive assigned alexcrichton Jul 11, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 11, 2019

nikic mentioned this pull request Jul 11, 2019

Prepare for LLVM 9 update #62474

Merged

nikic force-pushed the actually-update-llvm branch from 462bab4 to 4aeffb2 Compare July 11, 2019 17:57

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 11, 2019

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 11, 2019

nikic force-pushed the actually-update-llvm branch from 4aeffb2 to 37be9db Compare July 12, 2019 14:16

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 12, 2019

nikic force-pushed the actually-update-llvm branch from 37be9db to 96050fe Compare July 12, 2019 15:09

cuviper mentioned this pull request Jul 18, 2019

Update to LLVM 9 rust-lang/llvm-project#19

Merged

mati865 mentioned this pull request Jul 18, 2019

Compile times suddenly extremly high #62567

Closed

jonas-schievink mentioned this pull request Jul 18, 2019

Recent nightly versions break thumb* targets #62781

Closed

alexcrichton mentioned this pull request Jul 19, 2019

Updating LLD to use bulk memory for threads rustwasm/wasm-bindgen#1631

Closed

golddranks mentioned this pull request Jul 23, 2019

Fix some sanity checks #61890

Merged

gnzlbg mentioned this pull request Jul 25, 2019

libcore fails to compile for thumbv6m-none-eabi #62932

Closed

mati865 mentioned this pull request Jul 26, 2019

Segfault compiling libc on armv7-unknown-linux-gnueabihf #62896

Closed

golddranks mentioned this pull request Aug 1, 2019

Remove the mention of LLDB from RELEASES.md #63192

Closed

Mark-Simulacrum mentioned this pull request Aug 7, 2019

Link errors on MSVC Nightly since around 2019-07-13 #63361

Closed

12101111 mentioned this pull request Sep 12, 2019

Undefined symbol _fltused when compiling to x86_64-unknown-uefi #62785

Closed

wangrunji0408 added a commit to rcore-os/rCore that referenced this pull request Sep 23, 2019

revert Rust toolchain to nightly-2019-07-15 to avoid LLVM bug on mips

f1642ec

Related PR: rust-lang/rust#62592

ehuss mentioned this pull request Mar 9, 2020

Compiler incorrectly assumes int will never be one #69841

Closed

Mark-Simulacrum mentioned this pull request May 9, 2020

bootstrap: remove lldb dist packaging #72058

Merged

ehuss mentioned this pull request Nov 15, 2020

debuginfo/pretty-std-collections.rs test sometimes fails on macOS #78665

Closed

ehuss mentioned this pull request Feb 6, 2021

lldb hashmap pretty printer broken #81814

Closed

madsmtm mentioned this pull request Mar 18, 2025

Implement __isPlatformVersionAtLeast and __isOSVersionAtLeast rust-lang/compiler-builtins#794

Closed

madsmtm mentioned this pull request Mar 25, 2025

Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols #138944

Open

workingjubilee added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label May 26, 2025

Update to LLVM 9 trunk #62592

Update to LLVM 9 trunk #62592

Uh oh!

Conversation

nikic commented Jul 11, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Jul 11, 2019

Uh oh!

cuviper commented Jul 11, 2019

Uh oh!

nikic commented Jul 11, 2019

Uh oh!

alexcrichton commented Jul 11, 2019

Uh oh!

nikic commented Jul 11, 2019

Uh oh!

alexcrichton commented Jul 11, 2019

Uh oh!

bors commented Jul 11, 2019

Uh oh!

bors commented Jul 11, 2019

Uh oh!

bors commented Jul 11, 2019

Uh oh!

nikic commented Jul 11, 2019

Uh oh!

alexcrichton commented Jul 11, 2019

Uh oh!

nikic commented Jul 11, 2019

Uh oh!

nikic commented Jul 12, 2019

Uh oh!

alexcrichton commented Jul 12, 2019

Uh oh!

bors commented Jul 12, 2019

Uh oh!

bors commented Jul 12, 2019

Uh oh!

nikic commented Jul 12, 2019

Uh oh!

golddranks commented Jul 23, 2019

Uh oh!

nikic commented Jul 23, 2019

Uh oh!

alexcrichton commented Jul 23, 2019

Uh oh!

golddranks commented Jul 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

nikic commented Jul 11, 2019 •

edited

Loading

golddranks commented Jul 24, 2019 •

edited

Loading