Skip to content

Commit cdcce3b

Browse files
committed
Auto merge of #26919 - alexcrichton:msvc-turn-off-unwinding, r=brson
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
2 parents d0d3707 + 813cfa5 commit cdcce3b

File tree

2 files changed

+8
-31
lines changed

2 files changed

+8
-31
lines changed

Diff for: src/librustc_trans/trans/base.rs

+7-9
Original file line numberDiff line numberDiff line change
@@ -753,15 +753,13 @@ pub fn invoke<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
753753
}
754754

755755
pub fn need_invoke(bcx: Block) -> bool {
756-
if bcx.sess().no_landing_pads() {
757-
return false
758-
}
759-
760-
// Currently 32-bit MSVC unwinding is not super well implemented in LLVM, so
761-
// we avoid it entirely.
762-
if bcx.sess().target.target.options.is_like_msvc &&
763-
bcx.sess().target.target.arch == "x86" {
764-
return false
756+
// FIXME(#25869) currently unwinding is not implemented for MSVC and our
757+
// normal unwinding infrastructure ends up just causing linker
758+
// errors with the current LLVM implementation, so landing
759+
// pads are disabled entirely for MSVC targets
760+
if bcx.sess().no_landing_pads() ||
761+
bcx.sess().target.target.options.is_like_msvc {
762+
return false;
765763
}
766764

767765
// Avoid using invoke if we are already inside a landing pad.

Diff for: src/librustc_trans/trans/glue.rs

+1-22
Original file line numberDiff line numberDiff line change
@@ -22,9 +22,8 @@ use middle::lang_items::ExchangeFreeFnLangItem;
2222
use middle::subst;
2323
use middle::subst::{Subst, Substs};
2424
use middle::ty::{self, Ty};
25-
use trans::adt::GetDtorType; // for tcx.dtor_type()
2625
use trans::adt;
27-
use trans::attributes;
26+
use trans::adt::GetDtorType; // for tcx.dtor_type()
2827
use trans::base::*;
2928
use trans::build::*;
3029
use trans::callee;
@@ -44,7 +43,6 @@ use trans::type_::Type;
4443
use arena::TypedArena;
4544
use libc::c_uint;
4645
use syntax::ast;
47-
use syntax::attr::InlineAttr;
4846

4947
pub fn trans_exchange_free_dyn<'blk, 'tcx>(cx: Block<'blk, 'tcx>,
5048
v: ValueRef,
@@ -252,25 +250,6 @@ fn get_drop_glue_core<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>,
252250

253251
update_linkage(ccx, llfn, None, OriginalTranslation);
254252

255-
// FIXME: Currently LLVM has a bug where if an SSA value is created in one
256-
// landing pad and then used in another it will abort during
257-
// compilation. The compiler never actually generates nested landing
258-
// pads, but this often arises when destructors are inlined into
259-
// other functions. To prevent this inlining from happening (and thus
260-
// preventing the LLVM abort) we mark all drop glue as inline(never)
261-
// on MSVC.
262-
//
263-
// For more information about the bug, see:
264-
//
265-
// https://llvm.org/bugs/show_bug.cgi?id=23884
266-
//
267-
// This is clearly not the ideal solution to the problem (due to the
268-
// perf hits), so this should be removed once the upstream bug is
269-
// fixed.
270-
if ccx.sess().target.target.options.is_like_msvc {
271-
attributes::inline(llfn, InlineAttr::Never);
272-
}
273-
274253
ccx.stats().n_glues_created.set(ccx.stats().n_glues_created.get() + 1);
275254
// All glue functions take values passed *by alias*; this is a
276255
// requirement since in many contexts glue is invoked indirectly and

0 commit comments

Comments
 (0)