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.

Sign up for GitHub

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

Jump to bottom

codegen-units setting in Cargo.toml causes LLVM error with nightly-i686-pc-windows-msvc #36309

Closed
Boscop opened this issue Sep 6, 2016 · 10 comments
Closed

codegen-units setting in Cargo.toml causes LLVM error with nightly-i686-pc-windows-msvc #36309

Boscop opened this issue Sep 6, 2016 · 10 comments
Assignees
@michaelwoerister
Labels
A-codegen Area: Code generation E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. O-windows Operating system: Windows P-medium Medium priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Boscop
Copy link

Boscop commented Sep 6, 2016

Using the latest nightly rustc 1.13.0-nightly (cbe4de78e 2016-09-05) I'm getting this error on a project that uses euclid which uses xml-rs:
LLVM ERROR: assembler label 'L__ehtable$_ZN3xml6reader6parser10MarkupData13take_ encoding17hb15412b3bac19ec7E' can not be undefined error: Could not compile xml-rs.
This happens only when I have codegen-units = 4 in my Cargo.toml and only with the 32bit version of the toolchain, only with nightly-i686-pc-windows-msvc not with nightly-x86_64-pc-windows-msvc.
(I tested 4 configs: with/without codegen-units = 4 in Cargo.toml ⨯ 32/64 bit)
@brson brson added O-windows Operating system: Windows A-codegen Area: Code generation regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. I-wrong T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 7, 2016
@brson
Copy link
Contributor

brson commented Sep 7, 2016

cc @mw

@alexcrichton
Copy link
Member

cc @michaelwoerister

@brson
Copy link
Contributor

brson commented Sep 13, 2016

Nominating for @rust-lang/compiler triage.

@michaelwoerister
Copy link
Member

I have a dim memory of fixing this exact same problem two months ago... 😕

@michaelwoerister michaelwoerister self-assigned this Sep 14, 2016
@michaelwoerister
Copy link
Member

I knew that I had seen this problem before somewhere: #33890 (comment)

@michaelwoerister michaelwoerister mentioned this issue Sep 14, 2016
Closed
@nrc nrc added P-medium Medium priority and removed I-nominated labels Sep 15, 2016
@michaelwoerister michaelwoerister mentioned this issue Sep 16, 2016
Merged
bors added a commit that referenced this issue Sep 21, 2016
@bors
Auto merge of #36524 - michaelwoerister:trans-inline-only-on-demand, …
5cc6c6b 
…r=nikomatsakis

trans: Only instantiate #[inline] functions in codegen units referencing them

This PR changes how `#[inline]` functions are translated. Before, there was one "master instance" of the function with `external` linkage and a number of on-demand instances with `available_externally` linkage in each codegen unit that referenced the function. This had two downsides:

* Public functions marked with `#[inline]` would be present in machine code of libraries unnecessarily (see #36280 for an example)
* LLVM would crash on `i686-pc-windows-msvc` due to what I suspect to be a bug in LLVM's Win32 exception handling code, because it doesn't like `available_externally` there (#36309).

This PR changes the behavior, so that there is no master instance and only on-demand instances with `internal` linkage. The downside of this is potential code-bloat if LLVM does not completely inline away the `internal` instances because then there'd be N instances of the function instead of 1. However, this can only become a problem when using more than one codegen unit per crate.

cc @rust-lang/compiler
@brson
Copy link
Contributor

brson commented Sep 22, 2016

@michaelwoerister is this fixed?

@brson
Copy link
Contributor

brson commented Sep 22, 2016

@Boscop maybe you can check if this is fixed?

@michaelwoerister
Copy link
Member

It should be fixed but I'm not sure the fix is in nightly yet.

@pnkfelix
Copy link
Member

@michaelwoerister it should be in nightly, the most recent one is:

rustc 1.13.0-nightly (4f9812a 2016-09-21)

@pnkfelix pnkfelix added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Sep 29, 2016
@michaelwoerister
Copy link
Member

I spent some time trying to write a small test case without success. Since this is fixed for xml-rs which is cited by the original report, I'll close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michaelwoerister michaelwoerister

Labels
A-codegen Area: Code generation E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. O-windows Operating system: Windows P-medium Medium priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@alexcrichton @brson @pnkfelix @Boscop @nrc @michaelwoerister