Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustc ICE when compiling a dylib/cdylib for aarch64-apple-ios #47825

Closed
kennytm opened this issue Jan 28, 2018 · 2 comments · Fixed by #130068
Closed

rustc ICE when compiling a dylib/cdylib for aarch64-apple-ios #47825

kennytm opened this issue Jan 28, 2018 · 2 comments · Fixed by #130068
Labels
C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-ios Operating system: iOS S-needs-repro Status: This issue has no reproduction and needs a reproduction to make progress. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kennytm
Copy link
Member

kennytm commented Jan 28, 2018

Repro:

$ export RUST_BACKTRACE=1
$ echo | rustc +nightly --crate-type cdylib --target aarch64-apple-ios -
warning: dropping unsupported crate type `cdylib` for target `aarch64-apple-ios`

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic
  10: rustc_trans::base::write_metadata
  11: rustc::util::common::time
  12: rustc_trans::base::trans_crate
  13: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
  14: rustc::util::common::time
  15: rustc_driver::driver::phase_4_translate_to_llvm
  16: rustc_driver::driver::compile_input::{{closure}}
  17: <std::thread::local::LocalKey<T>>::with
  18: <std::thread::local::LocalKey<T>>::with
  19: rustc::ty::context::TyCtxt::create_and_enter
  20: rustc_driver::driver::compile_input
  21: rustc_driver::run_compiler

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.25.0-nightly (7d6e5b9da 2018-01-27) running on x86_64-apple-darwin

The same happens for 1.23-stable.

@kennytm kennytm added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-ios Operating system: iOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jan 28, 2018
@Centril Centril added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Mar 10, 2020
@Centril
Copy link
Contributor

Centril commented Mar 10, 2020

@kennytm does this still reproduce?

@kennytm
Copy link
Member Author

kennytm commented Mar 10, 2020

no repro for 1.42.0-nightly (0de96d37f 2019-12-19).

@Centril Centril added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Mar 10, 2020
@Noratrieb Noratrieb removed the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Jul 1, 2023
@lolbinarycat lolbinarycat added the S-needs-repro Status: This issue has no reproduction and needs a reproduction to make progress. label Sep 6, 2024
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 9, 2024
…jieyouxu

Test codegen when setting deployment target

Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang#129342, rust-lang#129367 and rust-lang#129369. See rust-lang#129432 for the bigger picture.

Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```

The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205.
- `armv7k-apple-watchos`, failed to link, see rust-lang#130071.
- `arm64e-apple-ios`, failed to link, see rust-lang#130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030.

But all of this is as it was before this PR.

Fixes rust-lang#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.

Split out from rust-lang#129342, see that for a little bit of the review that this has gone through already.

r? petrochenkov

`@rustbot` label O-apple
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 9, 2024
…jieyouxu

Test codegen when setting deployment target

Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang#129342, rust-lang#129367 and rust-lang#129369. See rust-lang#129432 for the bigger picture.

Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```

The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205.
- `armv7k-apple-watchos`, failed to link, see rust-lang#130071.
- `arm64e-apple-ios`, failed to link, see rust-lang#130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030.

But all of this is as it was before this PR.

Fixes rust-lang#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.

Split out from rust-lang#129342, see that for a little bit of the review that this has gone through already.

r? petrochenkov

``@rustbot`` label O-apple
@bors bors closed this as completed in fd938c7 Sep 9, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 9, 2024
Rollup merge of rust-lang#130068 - madsmtm:deployment-target-test, r=jieyouxu

Test codegen when setting deployment target

Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang#129342, rust-lang#129367 and rust-lang#129369. See rust-lang#129432 for the bigger picture.

Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```

The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205.
- `armv7k-apple-watchos`, failed to link, see rust-lang#130071.
- `arm64e-apple-ios`, failed to link, see rust-lang#130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030.

But all of this is as it was before this PR.

Fixes rust-lang#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.

Split out from rust-lang#129342, see that for a little bit of the review that this has gone through already.

r? petrochenkov

```@rustbot``` label O-apple
RalfJung pushed a commit to RalfJung/miri that referenced this issue Sep 10, 2024
Test codegen when setting deployment target

Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang/rust#129342, rust-lang/rust#129367 and rust-lang/rust#129369. See rust-lang/rust#129432 for the bigger picture.

Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```

The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205.
- `armv7k-apple-watchos`, failed to link, see rust-lang/rust#130071.
- `arm64e-apple-ios`, failed to link, see rust-lang/rust#130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030.

But all of this is as it was before this PR.

Fixes rust-lang/rust#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.

Split out from rust-lang/rust#129342, see that for a little bit of the review that this has gone through already.

r? petrochenkov

```@rustbot``` label O-apple
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-ios Operating system: iOS S-needs-repro Status: This issue has no reproduction and needs a reproduction to make progress. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants