Skip to content

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

New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom
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.

# for free to join this conversation on GitHub. Already have an account? # 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