Change:
There are no nightlies between 4-30 and 5-03, unfortunately. Based on the commit log from github, I believe is the range of commits that could be responsible.
I can't reproduce the error with . Edit: No repro with the mentioned nightly either.
It reproduces consistently on three particular macOS build machines that Servo uses. I can't actually reproduce it locally. I am attempting to bisect rustc on an affected machine to figure out the cause.
What are the macOS and Xcode versions of those build machines? Maybe it's caused by Xcode 7 again.
(Darwin 14.5.0 = OS X Yosemite 10.10.5)
what instruction is it failing on? My guess is it's a , which would make this the same issue as e.g. , caused by Xcode <8 having broken TLS alignment.
FWIW this historically has looked to be an issue with OSX's linker. Newer versions of Xcode appear to have a fixed linker as this bug doesn't manifest when Rust programs are linked with newer versions of Xcode
While the underlying bug might be in the linker, programs that used to compile correctly with an older rustc version don’t anymore. lists "OSX (10.7+, Lion+)" as tier 1, but XCode 8 is only available on 10.11.5+. Are we dropping support for older versions?
oh I'm not saying we shouldn't fix this, it's moreso that at this point in time no one knows how to fix this other than (a) using an updated Xcode or (b) compiling with . If there's a better fix we'd definitely add it!
This sounds very very good to know, thanks! It’s much easier than upgrading the OS on Servo’s CI. I’ll try it today.
As to knowing how to fix it, bisecting to a single PR would be a start. Is there an easier way to use CI builds than forging S3 URLs and extracting a couple tarballs manually?
Both allow bisecting by commit hash, though if the regression happens 90 to 168 days ago the tarballs may have already been deleted from S3.
... is , "Set opt-level to 3"
Awesome thanks for the bisection Also cc for that commit. For the build error you had above, was that a clean build? I think you'll have to recompile some of the C objects. For the bisection result my guess would be that it's a legitimate optimization being performed which the linker or something along the way doesn't handle. I'm not sure what though? I would personally be ok backing out the opt-level=3 change as well.
The / error above was when running directly, without Cargo (with ).
I think this would probably work around the bug, but adding a test so that it doesn’t regress again is tricky since the Travis-CI config uses newer XCode than versions that are affected according to
Note: On LLVM 6, adds two additional passes to : Maybe we could isolate to one of these passes but we need to find a faster reproducer besides recompiling the whole compiler to stage1.
Reverting in has worked around the issue for now. Should we keep this open for finding a more targeted work-around?
Can you reproduce on today's nightly on older OSX machines when compiling with LTO? If so I think that's definitely a reason to keep this issue
Adding this: does cause segfaults to come back: But I’m not seeing anything in the rustc command for LTO…
It's weird but you'll want to configure the bench profile
Alright, this time I get but still no segfault:
bah! In that case seems safe to close as we can't reproduce easily then
I encountered a similar situation on macOS with the XCode 9.3 and project: branch: compile with

Discussion:
unsafe { let g = get_static(cx, def_id); <del> let v = match ::mir::codegen_static_initializer(cx, def_id) { </del> <ins> let (v, alloc) = match ::mir::codegen_static_initializer(cx, def_id) { </ins> Ok(v) => v, // Error has already been reported Err(_) => return,

if attr::contains_name(attrs, "thread_local") { llvm::set_thread_local_mode(g, cx.tls_model); <ins> // Do not allow LLVM to change the alignment of a TLS on macOS. // // By default a global's alignment can be freely increased. // This allows LLVM to generate more performant instructions // e.g. using load-aligned into a SIMD register. // // However, on macOS 10.10 or below, the dynamic linker does not // respect any alignment given on the TLS (radar 24221680). // This will violate the alignment assumption, and causing segfault at runtime. // // This bug is very easy to trigger. In `println!` and `panic!`, // the `LOCAL_STDOUT`/`LOCAL_STDERR` handles are stored in a TLS, // which the values would be `mem::replace`d on initialization. // The implementation of `mem::replace` will use SIMD // whenever the size is 32 bytes or higher. LLVM notices SIMD is used // and tries to align `LOCAL_STDOUT`/`LOCAL_STDERR` to a 32-byte boundary, // which macOS's dyld disregarded and causing crashes // (see issues #51794, #51758, #50867, #48866 and #44056). // // To workaround the bug, we trick LLVM into not increasing // the global's alignment by explicitly assigning a section to it // (equivalent to automatically generating a `#[link_section]` attribute). // See the comment in the `GlobalValue::canIncreaseAlignment()` function // of `lib/IR/Globals.cpp` for why this works. // // When the alignment is not increased, the optimized `mem::replace` // will use load-unaligned instructions instead, and thus avoiding the crash. // // We could remove this hack whenever we decide to drop macOS 10.10 support. if cx.tcx.sess.target.target.options.is_like_osx { let sect_name = if alloc.bytes.iter().all(|b| *b == 0) { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_bss0") } else { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_data0") }; llvm::LLVMSetSection(g, sect_name.as_ptr()); } </ins> } base::set_link_section(cx, g, attrs);

pub fn codegen_static_initializer<'a, 'tcx>( cx: &CodegenCx<'a, 'tcx>, def_id: DefId) <del> -> Result<ValueRef, Lrc<ConstEvalErr<'tcx>>> </del> <ins> -> Result<(ValueRef, &'tcx Allocation), Lrc<ConstEvalErr<'tcx>>> </ins> { let instance = ty::Instance::mono(cx.tcx, def_id); let cid = GlobalId {

ConstValue::ByRef(alloc, n) if n.bytes() == 0 => alloc, _ => bug!("static const eval returned {:#?}", static_), }; <del> Ok(const_alloc_to_llvm(cx, alloc)) </del> <ins> Ok((const_alloc_to_llvm(cx, alloc), alloc)) </ins> } impl<'a, 'tcx> FunctionCx<'a, 'tcx> {

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // ignore-tidy-linelength // only-macos // no-system-llvm // min-llvm-version 6.0 // compile-flags: -O #![crate_type = "rlib"] #![feature(thread_local)] // CHECK: @STATIC_VAR_1 = internal thread_local unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4 #[no_mangle] #[allow(private_no_mangle_statics)] #[thread_local] static mut STATIC_VAR_1: [u32; 8] = [0; 8]; // CHECK: @STATIC_VAR_2 = internal thread_local unnamed_addr global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4 #[no_mangle] #[allow(private_no_mangle_statics)] #[thread_local] static mut STATIC_VAR_2: [u32; 8] = [4; 8]; #[no_mangle] pub unsafe fn f(x: &mut [u32; 8]) { std::mem::swap(x, &mut STATIC_VAR_1) } #[no_mangle] pub unsafe fn g(x: &mut [u32; 8]) { std::mem::swap(x, &mut STATIC_VAR_2) } </ins>

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // only-x86_64 // no-prefer-dynamic // compile-flags: -Ctarget-feature=+avx -Clto fn main() {} </ins>