Skip to content

/rust

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

Upgrade to LLVM's 3.7 release branch #27076

Merged
merged 7 commits into from Jul 17, 2015

Conversation

Reviewers
No reviews
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
9 participants
@alexcrichton @rust-highfive @brson @bors @tamird @Manishearth @dotdash @richo @pcwalton
@alexcrichton
Copy link
Member

alexcrichton commented Jul 17, 2015

LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch.

  • This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
    which should help us bootstrap farther on 32-bit MSVC targets.
  • There is better support for writing multiple flavors of archives, allowing us
    to use the built-in LLVM support instead of the system ar on all current
    platforms of the compiler.
  • This LLVM has SafeStack support
  • An optimization patch by @pcwalton is included.
  • A number of other minor test fixes here and there.

Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...

@rust-highfive rust-highfive assigned pcwalton Jul 17, 2015

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link
Collaborator

rust-highfive commented Jul 17, 2015

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jul 17, 2015

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned pcwalton Jul 17, 2015

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Jul 17, 2015

@bors r+
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jul 17, 2015

📌 Commit 181661f has been approved by brson
@tamird

This comment has been minimized.

Sign in to view
Copy link
Contributor

tamird commented Jul 17, 2015

🎊
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jul 17, 2015

@bors: r-, turns out there's still bugs on OSX and Windows, taking some time to fix those up. So far:

  • Can't use LLVM's writeArchive for MSVC
  • Need to re-apply rust-lang/llvm@d3add25 as another bug has shown up (but different than before)

And probably one or two more on the way!

richo and others added some commits Jun 27, 2015

@richo @alexcrichton
rt: Move personality to functions from their landing pads 
This is for llvm/cc714e214298cfbf11de65b46de31900d51422cf
c55d3f1
@alexcrichton
Update LLVM 
There's a number of goodies in this LLVM update:

* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
  which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
  to use the built-in LLVM support instead of the system `ar` on all current
  platforms of the compiler.
* A number of other minor bug fixes and performance improvements to unblock
  various other pieces of work.
ea317e8
@alexcrichton
rustc_trans: Update LLVMBuildLandingPad signature 
The C API of this function changed so it no longer takes a personality function.
A shim was introduced to call the right LLVM function (depending on which
version we're compiled against) to set the personality function on the outer
function.

The compiler only ever sets one personality function for all generated
functions, so this should be equivalent.
7f0e733
@alexcrichton
trans: Add kind to writeArchive 
Updates our LLVM bindings to be able to write out multiple kinds of archives.
This commit also enables using LLVM instead of the system ar on all current
targets.
74e1981
@alexcrichton
trans: Clean up handling the LLVM data layout 
Turns out for OSX our data layout was subtly wrong and the LLVM update must have
exposed this. Instead of fixing this I've removed all data layouts from the
compiler to just use the defaults that LLVM provides for all targets. All data
layouts (and a number of dead modules) are removed from the compiler here.
Custom target specifications can still provide a custom data layout, but it is
now an optional key as the default will be used if one isn't specified.
Loading status checks…
958d563

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from 181661f to 958d563 Jul 17, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jul 17, 2015

@bors: r=brson 958d563

@alexcrichton alexcrichton referenced this pull request Jul 17, 2015

Closed

msvc: Support a i686-pc-windows-msvc host compiler #26602

@Manishearth

This comment has been minimized.

Sign in to view
Copy link
Member

Manishearth commented Jul 17, 2015

@bors force
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jul 17, 2015

⌛️ Testing commit 958d563 with merge 71fea82...

bors added a commit that referenced this pull request Jul 17, 2015

@bors
Auto merge of #27076 - alexcrichton:update-llvm, r=brson 
LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch.

* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
  which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
  to use the built-in LLVM support instead of the system `ar` on all current
  platforms of the compiler.
* This LLVM has SafeStack support
* An [optimization patch](rust-lang/llvm@7cf5e26) by @pcwalton is included.
* A number of other minor test fixes here and there.

Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...
71fea82
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jul 17, 2015

💔 Test failed - auto-mac-32-opt
@dotdash

This comment has been minimized.

Sign in to view
Copy link
Contributor

dotdash commented Jul 17, 2015

Depends on #27070

@alexcrichton alexcrichton referenced this pull request Jul 17, 2015

Merged

debuginfo: Fix type description generic enum discriminants. #27070

@alexcrichton
test: Ignore a failing test on LLDB 
Re-enabling it is tracked in #27089
Loading status checks…
6d96edf

@alexcrichton alexcrichton referenced this pull request Jul 17, 2015

Open

The generic-enum-with-different-disr-sizes test fails in LLDB #27089

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jul 17, 2015

@bors: r=brson 6d96edf
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jul 17, 2015

@bors: p=1
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jul 17, 2015

⌛️ Testing commit 6d96edf with merge d4432b3...

bors added a commit that referenced this pull request Jul 17, 2015

@bors
Auto merge of #27076 - alexcrichton:update-llvm, r=brson 
LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch.

* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
  which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
  to use the built-in LLVM support instead of the system `ar` on all current
  platforms of the compiler.
* This LLVM has SafeStack support
* An [optimization patch](rust-lang/llvm@7cf5e26) by @pcwalton is included.
* A number of other minor test fixes here and there.

Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...
Loading status checks…
d4432b3
@bors

@bors bors merged commit 6d96edf into rust-lang:master Jul 17, 2015
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@bors bors referenced this pull request Jul 17, 2015

Merged

Create proper debug info for functions and function pointers #27025

@alexcrichton alexcrichton deleted the alexcrichton:update-llvm branch Jul 17, 2015

@richo

This comment has been minimized.

Sign in to view
Copy link
Contributor

richo commented Jul 17, 2015

\o/

Thanks for getting us onto a new llvm (I can finally play with safestacks!) and keeping my tiny commit intact ❤️

dotdash added a commit to dotdash/rust that referenced this pull request Jul 20, 2015

@dotdash
Add a test for rust-lang#26468 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
871ccfb

@dotdash dotdash referenced this pull request Jul 20, 2015

Merged

Add a test for #26468 #27140

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 21, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
a7b766f

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 21, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
4388c00

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 21, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
a0cea5f

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 21, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
837e8a9

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 22, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
615df29

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 22, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
4c023de

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 22, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
4c66f1a

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 22, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
ec66b2d

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 22, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
7b663a8

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Jul 22, 2015

@steveklabnik
Rollup merge of rust-lang#27140 - dotdash:test-26468, r=luqmana 
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076.

Closes rust-lang#26468
0ac7438

@eddyb eddyb referenced this pull request Apr 13, 2016

Merged

Compute LLVM-agnostic type layouts in rustc. #32939

bors added a commit that referenced this pull request Apr 20, 2016

@bors
Auto merge of #32939 - eddyb:layout, r=nikomatsakis 
Compute LLVM-agnostic type layouts in rustc.

Layout for monomorphic types, and some polymorphic ones (e.g. `&T` where `T: Sized`),
can now be computed by rustc without involving LLVM in the actual process.

This gives rustc the ability to evaluate `size_of` or `align_of`, as well as obtain field offsets.
MIR-based CTFE will eventually make use of these layouts, as will MIR trans, shortly.

Layout computation also comes with a `[breaking-change]`, or two:
* `"data-layout"` is now mandatory in custom target specifications, reverting the decision from #27076.
This string is needed because it describes endianness, pointer size and alignments for various types.
We have the first two and we could allow tweaking alignments in target specifications.
Or we could also extract the data layout from LLVM and feed it back into rustc.
However, that can vary with the LLVM version, which is fragile and undermines stability.
For built-in targets, I've added a check that the hardcoded data-layout matches LLVM defaults.
* `transmute` calls are checked in a stricter fashion, which fixes #32377

To expand on `transmute`, there are only 2 allowed patterns: between types with statically known sizes and between pointers with the same potentially-unsized "tail" (which determines the type of unsized metadata they use, if any).
If you're affected, my suggestions are:
* try to use casts (and raw pointer deref) instead of transmutes
* *really* try to avoid `transmute` where possible
* if you have a structure, try working on individual fields and unpack/repack the structure instead of transmuting it whole, e.g. `transmute::<RefCell<Box<T>>, RefCell<*mut T>>(x)` doesn't work, but `RefCell::new(Box::into_raw(x.into_inner()))` does (and `Box::into_raw` is just a `transmute`)
542c7d1

bors added a commit that referenced this pull request Apr 20, 2016

@bors
Auto merge of #32939 - eddyb:layout, r=nikomatsakis 
Compute LLVM-agnostic type layouts in rustc.

Layout for monomorphic types, and some polymorphic ones (e.g. `&T` where `T: Sized`),
can now be computed by rustc without involving LLVM in the actual process.

This gives rustc the ability to evaluate `size_of` or `align_of`, as well as obtain field offsets.
MIR-based CTFE will eventually make use of these layouts, as will MIR trans, shortly.

Layout computation also comes with a `[breaking-change]`, or two:
* `"data-layout"` is now mandatory in custom target specifications, reverting the decision from #27076.
This string is needed because it describes endianness, pointer size and alignments for various types.
We have the first two and we could allow tweaking alignments in target specifications.
Or we could also extract the data layout from LLVM and feed it back into rustc.
However, that can vary with the LLVM version, which is fragile and undermines stability.
For built-in targets, I've added a check that the hardcoded data-layout matches LLVM defaults.
* `transmute` calls are checked in a stricter fashion, which fixes #32377

To expand on `transmute`, there are only 2 allowed patterns: between types with statically known sizes and between pointers with the same potentially-unsized "tail" (which determines the type of unsized metadata they use, if any).
If you're affected, my suggestions are:
* try to use casts (and raw pointer deref) instead of transmutes
* *really* try to avoid `transmute` where possible
* if you have a structure, try working on individual fields and unpack/repack the structure instead of transmuting it whole, e.g. `transmute::<RefCell<Box<T>>, RefCell<*mut T>>(x)` doesn't work, but `RefCell::new(Box::into_raw(x.into_inner()))` does (and `Box::into_raw` is just a `transmute`)
6ece144
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.