user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Auto merge of #26919 - alexcrichton:msvc-turn-off-unwinding, r=brson

Browse source 
There are a number of problems with MSVC landing pads today:

* They only work about 80% of the time with optimizations enabled. For example when running the run-pass test suite a failing test will cause `compiletest` to segfault (b/c of a thread panic). There are also a large number of run-fail tests which will simply crash.
* Enabling landing pads caused the regression seen in #26915.

Overall it looks like LLVM's support for MSVC landing pads isn't as robust as we'd like for now, so let's take a little more time before we turn them on by default.


Closes #26915
This commit is contained in:
bors 2015-07-10 12:40:25 +00:00
commit cdcce3ba44
2 changed files with 8 additions and 31 deletions
Download patch file Download diff file Expand all files Collapse all files

16
src/librustc_trans/trans/base.rs
View file

@ -753,15 +753,13 @@ pub fn invoke<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
}
pub fn need_invoke(bcx: Block) -> bool {
if bcx.sess().no_landing_pads() {
return false
}
// Currently 32-bit MSVC unwinding is not super well implemented in LLVM, so
// we avoid it entirely.
if bcx.sess().target.target.options.is_like_msvc &&
bcx.sess().target.target.arch == "x86" {
return false
// FIXME(#25869) currently unwinding is not implemented for MSVC and our
// normal unwinding infrastructure ends up just causing linker
// errors with the current LLVM implementation, so landing
// pads are disabled entirely for MSVC targets
if bcx.sess().no_landing_pads() ||
bcx.sess().target.target.options.is_like_msvc {
return false;
}
// Avoid using invoke if we are already inside a landing pad.

23
src/librustc_trans/trans/glue.rs
View file

@ -22,9 +22,8 @@ use middle::lang_items::ExchangeFreeFnLangItem;
use middle::subst;
use middle::subst::{Subst, Substs};
use middle::ty::{self, Ty};
use trans::adt::GetDtorType; // for tcx.dtor_type()
use trans::adt;
use trans::attributes;
use trans::adt::GetDtorType; // for tcx.dtor_type()
use trans::base::*;
use trans::build::*;
use trans::callee;
@ -44,7 +43,6 @@ use trans::type_::Type;
use arena::TypedArena;
use libc::c_uint;
use syntax::ast;
use syntax::attr::InlineAttr;
pub fn trans_exchange_free_dyn<'blk, 'tcx>(cx: Block<'blk, 'tcx>,
v: ValueRef,
@ -252,25 +250,6 @@ fn get_drop_glue_core<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>,
update_linkage(ccx, llfn, None, OriginalTranslation);
// FIXME: Currently LLVM has a bug where if an SSA value is created in one
// landing pad and then used in another it will abort during
// compilation. The compiler never actually generates nested landing
// pads, but this often arises when destructors are inlined into
// other functions. To prevent this inlining from happening (and thus
// preventing the LLVM abort) we mark all drop glue as inline(never)
// on MSVC.
//
// For more information about the bug, see:
//
// https://llvm.org/bugs/show_bug.cgi?id=23884
//
// This is clearly not the ideal solution to the problem (due to the
// perf hits), so this should be removed once the upstream bug is
// fixed.
if ccx.sess().target.target.options.is_like_msvc {
attributes::inline(llfn, InlineAttr::Never);
}
ccx.stats().n_glues_created.set(ccx.stats().n_glues_created.get() + 1);
// All glue functions take values passed *by alias*; this is a
// requirement since in many contexts glue is invoked indirectly and