jiebi/CodeConvo huggingface dataset:
Code change:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

Related discussion:
text: <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>
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: self.cx } <del> fn do_not_inline(&mut self, _llret: RValue<'gcc>) { </del> <ins> fn apply_attrs_to_cleanup_callsite(&mut self, _llret: RValue<'gcc>) { </ins> unimplemented!(); }
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: unsafe { llvm::LLVMBuildZExt(self.llbuilder, val, dest_ty, UNNAMED) } } <del> fn do_not_inline(&mut self, llret: &'ll Value) { llvm::Attribute::NoInline.apply_callsite(llvm::AttributePlace::Function, llret); </del> <ins> fn apply_attrs_to_cleanup_callsite(&mut self, llret: &'ll Value) { // Cleanup is always the cold path. llvm::Attribute::Cold.apply_callsite(llvm::AttributePlace::Function, llret); // In LLVM versions with deferred inlining (currently, system LLVM < 14), // inlining drop glue can lead to exponential size blowup, see #41696 and #92110. if !llvm_util::is_rust_llvm() && llvm_util::get_version() < (14, 0, 0) { llvm::Attribute::NoInline.apply_callsite(llvm::AttributePlace::Function, llret); } </ins> } }
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: pub fn LLVMRustVersionMinor() -> u32; pub fn LLVMRustVersionPatch() -> u32; <ins> pub fn LLVMRustIsRustLLVM() -> bool; </ins> pub fn LLVMRustAddModuleFlag(M: &Module, name: *const c_char, value: u32); pub fn LLVMRustMetadataAsValue<'a>(C: &'a Context, MD: &'a Metadata) -> &'a Value;
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: } } <ins> /// Returns `true` if this LLVM is Rust's bundled LLVM (and not system LLVM). pub fn is_rust_llvm() -> bool { // Can be called without initializing LLVM unsafe { llvm::LLVMRustIsRustLLVM() } } </ins> pub fn print_passes() { // Can be called without initializing LLVM unsafe {
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: let llret = bx.call(fn_ty, fn_ptr, &llargs, self.funclet(fx)); bx.apply_attrs_callsite(&fn_abi, llret); if fx.mir[self.bb].is_cleanup { <del> // Cleanup is always the cold path. Don't inline // drop glue. Also, when there is a deeply-nested // struct, there are "symmetry" issues that cause // exponential inlining - see issue #41696. bx.do_not_inline(llret); </del> <ins> bx.apply_attrs_to_cleanup_callsite(llret); </ins> } if let Some((ret_dest, target)) = destination {
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: ) -> Self::Value; fn zext(&mut self, val: Self::Value, dest_ty: Self::Type) -> Self::Value; <del> fn do_not_inline(&mut self, llret: Self::Value); </del> <ins> fn apply_attrs_to_cleanup_callsite(&mut self, llret: Self::Value); </ins> }
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: extern "C" uint32_t LLVMRustVersionMajor() { return LLVM_VERSION_MAJOR; } <ins> extern "C" bool LLVMRustIsRustLLVM() { #ifdef LLVM_RUSTLLVM return true; #else return false; #endif } </ins> extern "C" void LLVMRustAddModuleFlag(LLVMModuleRef M, const char *Name, uint32_t Value) { unwrap(M)->addModuleFlag(Module::Warning, Name, Value);
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: <ins> // no-system-llvm: needs #92110 // compile-flags: -Cno-prepopulate-passes #![crate_type = "lib"] // This test checks that drop calls in unwind landing pads // get the `cold` attribute. // CHECK-LABEL: @check_cold // CHECK: call void {{.+}}drop_in_place{{.+}} [[ATTRIBUTES:#[0-9]+]] // CHECK: attributes [[ATTRIBUTES]] = { cold } #[no_mangle] pub fn check_cold(f: fn(), x: Box<u32>) { // this may unwind f(); } </ins>
Code change:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

Related discussion:
text: <ins> // no-system-llvm: needs #92110 + patch for Rust alloc/dealloc functions // compile-flags: -Copt-level=3 #![crate_type = "lib"] // This test checks that we can inline drop_in_place in // unwind landing pads. // Without inlining, the box pointers escape via the call to drop_in_place, // and LLVM will not optimize out the pointer comparison. // With inlining, everything should be optimized out. // See https://github.com/rust-lang/rust/issues/46515 // CHECK-LABEL: @check_no_escape_in_landingpad // CHECK: start: // CHECK-NEXT: ret void #[no_mangle] pub fn check_no_escape_in_landingpad(f: fn()) { let x = &*Box::new(0); let y = &*Box::new(0); if x as *const _ == y as *const _ { f(); } } // Without inlining, the compiler can't tell that // dropping an empty string (in a landing pad) does nothing. // With inlining, the landing pad should be optimized out. // See https://github.com/rust-lang/rust/issues/87055 // CHECK-LABEL: @check_eliminate_noop_drop // CHECK: start: // CHECK-NEXT: call void %g() // CHECK-NEXT: ret void #[no_mangle] pub fn check_eliminate_noop_drop(g: fn()) { let _var = String::new(); g(); } </ins>
Code change:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

Related discussion:
text: pub fn span_err(&self, sp: Span, m: &str) { self.sess.span_diagnostic.span_err(sp, m) } <ins> pub fn struct_span_err(&self, sp: Span, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_err(sp, m) } </ins> pub fn span_err_help(&self, sp: Span, m: &str, h: &str) { let mut err = self.sess.span_diagnostic.mut_span_err(sp, m); err.help(h);
Code change:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

Related discussion:
text: let lo = self.span; let hi; <del> if self.check(&token::DotDot) { </del> <ins> if self.check(&token::DotDot) || self.token == token::DotDotDot { if self.token == token::DotDotDot { // Issue #46718 let mut err = self.struct_span_err(self.span, "expected field pattern, found `...`"); err.span_suggestion(self.span, "to omit remaining fields, use one fewer `.`", "..".to_owned()); err.emit(); } </ins> self.bump(); if self.token != token::CloseDelim(token::Brace) { let token_str = self.this_token_to_string();
Code change:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

Related discussion:
text: <ins> // Copyright 2017 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. #![allow(unused)] struct PersonalityInventory { expressivity: f32, instrumentality: f32 } impl PersonalityInventory { fn expressivity(&self) -> f32 { match *self { PersonalityInventory { expressivity: exp, ... } => exp //~^ ERROR expected field pattern, found `...` } } } fn main() {} </ins>
Code change:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

Related discussion:
text: <ins> error: expected field pattern, found `...` --> $DIR/issue-46718-struct-pattern-dotdotdot.rs:21:55 | 21 |             PersonalityInventory { expressivity: exp, ... } => exp |                                                       ^^^ help: to omit remaining fields, use one fewer `.`: `..` error: aborting due to previous error </ins>