Explain safety for vec.set_len(0)
#1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
scottmcm
pushed a commit
that referenced
this pull request
Sep 19, 2020
* Fix `const-display.rs` XPATH queries * Add `issue_76501.rs` test file * Rename issue_76501.rs to issue-76501.rs
scottmcm
pushed a commit
that referenced
this pull request
Nov 30, 2020
``` Benchmark #1: ./raytracer_cg_clif_pre Time (mean ± σ): 9.553 s ± 0.129 s [User: 9.543 s, System: 0.008 s] Range (min … max): 9.438 s … 9.837 s 10 runs Benchmark #2: ./raytracer_cg_clif_post Time (mean ± σ): 9.463 s ± 0.055 s [User: 9.452 s, System: 0.008 s] Range (min … max): 9.387 s … 9.518 s 10 runs Summary './raytracer_cg_clif_post' ran 1.01 ± 0.01 times faster than './raytracer_cg_clif_pre' ```
scottmcm
pushed a commit
that referenced
this pull request
Nov 30, 2020
Don't print thread ids and names in `tracing` logs Before: ``` 2:rustc INFO rustc_interface::passes Pre-codegen 2:rustcTy interner total ty lt ct all 2:rustc Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0% 2:rustc Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0% 2:rustc Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0% 2:rustc RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0% 2:rustc Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0% 2:rustc FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0% 2:rustc Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0% 2:rustc Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0% 2:rustc Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc total 1326 0.2% 0.1% 0.0% 0.0% 2:rustcInternalSubsts interner: rust-lang#437 2:rustcRegion interner: rust-lang#355 2:rustcStability interner: #1 2:rustcConst Stability interner: #0 2:rustcAllocation interner: #0 2:rustcLayout interner: #0 ``` After: ``` INFO rustc_interface::passes Post-codegen Ty interner total ty lt ct all Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0% Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0% Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0% RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0% Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0% FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0% FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0% Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0% GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0% Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0% Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0% Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0% Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0% total 1326 0.2% 0.1% 0.0% 0.0% InternalSubsts interner: rust-lang#437 Region interner: rust-lang#355 Stability interner: #1 Const Stability interner: #0 Allocation interner: #0 Layout interner: #0 ``` Closes rust-lang#78931 r? ``@oli-obk``
scottmcm
pushed a commit
that referenced
this pull request
Nov 30, 2020
Don't run `resolve_vars_if_possible` in `normalize_erasing_regions` Neither `@eddyb` nor I could figure out what this was for. I changed it to `assert_eq!(normalized_value, infcx.resolve_vars_if_possible(&normalized_value));` and it passed the UI test suite. <details><summary> Outdated, I figured out the issue - `needs_infer()` needs to come _after_ erasing the lifetimes </summary> Strangely, if I change it to `assert!(!normalized_value.needs_infer())` it panics almost immediately: ``` query stack during panic: #0 [normalize_generic_arg_after_erasing_regions] normalizing `<str::IsWhitespace as str::pattern::Pattern>::Searcher` #1 [needs_drop_raw] computing whether `str::iter::Split<str::IsWhitespace>` needs drop #2 [mir_built] building MIR for `str::<impl str>::split_whitespace` #3 [unsafety_check_result] unsafety-checking `str::<impl str>::split_whitespace` rust-lang#4 [mir_const] processing MIR for `str::<impl str>::split_whitespace` rust-lang#5 [mir_promoted] processing `str::<impl str>::split_whitespace` rust-lang#6 [mir_borrowck] borrow-checking `str::<impl str>::split_whitespace` rust-lang#7 [analysis] running analysis passes on this crate end of query stack ``` I'm not entirely sure what's going on - maybe the two disagree? </details> For context, this came up while reviewing rust-lang#77467 (cc `@lcnr).` Possibly this needs a crater run? r? `@nikomatsakis` cc `@matthewjasper`
scottmcm
pushed a commit
that referenced
this pull request
Feb 20, 2021
HWAddressSanitizer support # Motivation Compared to regular ASan, HWASan has a [smaller overhead](https://source.android.com/devices/tech/debug/hwasan). The difference in practice is that HWASan'ed code is more usable, e.g. Android device compiled with HWASan can be used as a daily driver. # Example ``` fn main() { let xs = vec![0, 1, 2, 3]; let _y = unsafe { *xs.as_ptr().offset(4) }; } ``` ``` ==223==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefdeffff0050 at pc 0xaaaad00b3468 READ of size 4 at 0xefdeffff0050 tags: e5/00 (ptr/mem) in thread T0 #0 0xaaaad00b3464 (/root/main+0x53464) #1 0xaaaad00b39b4 (/root/main+0x539b4) #2 0xaaaad00b3dd0 (/root/main+0x53dd0) #3 0xaaaad00b61dc (/root/main+0x561dc) rust-lang#4 0xaaaad00c0574 (/root/main+0x60574) rust-lang#5 0xaaaad00b6290 (/root/main+0x56290) rust-lang#6 0xaaaad00b6170 (/root/main+0x56170) rust-lang#7 0xaaaad00b3578 (/root/main+0x53578) rust-lang#8 0xffff81345e70 (/lib64/libc.so.6+0x20e70) rust-lang#9 0xaaaad0096310 (/root/main+0x36310) [0xefdeffff0040,0xefdeffff0060) is a small allocated heap chunk; size: 32 offset: 16 0xefdeffff0050 is located 0 bytes to the right of 16-byte region [0xefdeffff0040,0xefdeffff0050) allocated here: #0 0xaaaad009bcdc (/root/main+0x3bcdc) #1 0xaaaad00b1eb0 (/root/main+0x51eb0) #2 0xaaaad00b20d4 (/root/main+0x520d4) #3 0xaaaad00b2800 (/root/main+0x52800) rust-lang#4 0xaaaad00b1cf4 (/root/main+0x51cf4) rust-lang#5 0xaaaad00b33d4 (/root/main+0x533d4) rust-lang#6 0xaaaad00b39b4 (/root/main+0x539b4) rust-lang#7 0xaaaad00b61dc (/root/main+0x561dc) rust-lang#8 0xaaaad00b3578 (/root/main+0x53578) rust-lang#9 0xaaaad0096310 (/root/main+0x36310) Thread: T0 0xeffe00002000 stack: [0xffffc0590000,0xffffc0d90000) sz: 8388608 tls: [0xffff81521020,0xffff815217d0) Memory tags around the buggy address (one tag corresponds to 16 bytes): 0xfefcefffef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffef90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffeff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0xfefceffff000: a2 a2 05 00 e5 [00] 00 00 00 00 00 00 00 00 00 00 0xfefceffff010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Tags for short granules around the buggy address (one tag corresponds to 16 bytes): 0xfefcefffeff0: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. =>0xfefceffff000: .. .. c5 .. .. [..] .. .. .. .. .. .. .. .. .. .. 0xfefceffff010: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags Registers where the failure occurred (pc 0xaaaad00b3468): x0 e500efdeffff0050 x1 0000000000000004 x2 0000ffffc0d8f5a0 x3 0200efff00000000 x4 0000ffffc0d8f4c0 x5 000000000000004f x6 00000ffffc0d8f36 x7 0000efff00000000 x8 e500efdeffff0050 x9 0200efff00000000 x10 0000000000000000 x11 0200efff00000000 x12 0200effe000006b0 x13 0200effe000006b0 x14 0000000000000008 x15 00000000c00000cf x16 0000aaaad00a0afc x17 0000000000000003 x18 0000000000000001 x19 0000ffffc0d8f718 x20 ba00ffffc0d8f7a0 x21 0000aaaad00962e0 x22 0000000000000000 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000ffffc0d8f650 x30 0000aaaad00b3468 ``` # Comments/Caveats * HWASan is only supported on arm64. * I'm not sure if I should add a feature gate or piggyback on the existing one for sanitizers. * HWASan requires `-C target-feature=+tagged-globals`. That flag should probably be set transparently to the user. Not sure how to go about that. # TODO * Need more tests. * Update documentation. * Fix symbolization. * Integrate with CI
scottmcm
pushed a commit
that referenced
this pull request
Aug 25, 2021
Otherwise, we can get into a situation where you have a subtype obligation `#1 <: #2` pending, #1 is constrained by `check_casts`, but #2` is unaffected. Co-authored-by: Niko Matsakis <[email protected]>
scottmcm
pushed a commit
that referenced
this pull request
Nov 12, 2021
Specialize array cloning for Copy types Because after PR 86041, the optimizer no longer load-merges at the LLVM IR level, which might be part of the perf loss. (I'll run perf and see if this makes a difference.) Also I added a codegen test so this hopefully won't regress in future -- it passes on stable and with my change here, but not on the 2021-11-09 nightly. Example on current nightly: <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=1f52d46fb8fc3ca3ac9f097390085ffa> ```rust type T = u8; const N: usize = 3; pub fn demo_clone(x: &[T; N]) -> [T; N] { x.clone() } pub fn demo_copy(x: &[T; N]) -> [T; N] { *x } ``` ```llvm-ir ; playground::demo_clone ; Function Attrs: mustprogress nofree nosync nounwind nonlazybind uwtable willreturn define i24 `@_ZN10playground10demo_clone17h98a4f11453d1a753E([3` x i8]* noalias nocapture readonly align 1 dereferenceable(3) %x) unnamed_addr #0 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* `@rust_eh_personality` { start: %0 = getelementptr [3 x i8], [3 x i8]* %x, i64 0, i64 0 %1 = getelementptr inbounds [3 x i8], [3 x i8]* %x, i64 0, i64 1 %.val.i.i.i.i.i.i.i.i.i = load i8, i8* %0, align 1, !alias.scope !2, !noalias !9 %2 = getelementptr inbounds [3 x i8], [3 x i8]* %x, i64 0, i64 2 %.val.i.i.i.i.i.1.i.i.i.i = load i8, i8* %1, align 1, !alias.scope !2, !noalias !20 %.val.i.i.i.i.i.2.i.i.i.i = load i8, i8* %2, align 1, !alias.scope !2, !noalias !23 %array.sroa.6.0.insert.ext.i.i.i.i = zext i8 %.val.i.i.i.i.i.2.i.i.i.i to i32 %array.sroa.6.0.insert.shift.i.i.i.i = shl nuw nsw i32 %array.sroa.6.0.insert.ext.i.i.i.i, 16 %array.sroa.5.0.insert.ext.i.i.i.i = zext i8 %.val.i.i.i.i.i.1.i.i.i.i to i32 %array.sroa.5.0.insert.shift.i.i.i.i = shl nuw nsw i32 %array.sroa.5.0.insert.ext.i.i.i.i, 8 %array.sroa.0.0.insert.ext.i.i.i.i = zext i8 %.val.i.i.i.i.i.i.i.i.i to i32 %array.sroa.5.0.insert.insert.i.i.i.i = or i32 %array.sroa.5.0.insert.shift.i.i.i.i, %array.sroa.0.0.insert.ext.i.i.i.i %array.sroa.0.0.insert.insert.i.i.i.i = or i32 %array.sroa.5.0.insert.insert.i.i.i.i, %array.sroa.6.0.insert.shift.i.i.i.i %.sroa.4.0.extract.trunc.i.i.i.i = trunc i32 %array.sroa.0.0.insert.insert.i.i.i.i to i24 ret i24 %.sroa.4.0.extract.trunc.i.i.i.i } ; playground::demo_copy ; Function Attrs: mustprogress nofree norecurse nosync nounwind nonlazybind readonly uwtable willreturn define i24 `@_ZN10playground9demo_copy17h7817453f9291d746E([3` x i8]* noalias nocapture readonly align 1 dereferenceable(3) %x) unnamed_addr #1 { start: %.sroa.0.0..sroa_cast = bitcast [3 x i8]* %x to i24* %.sroa.0.0.copyload = load i24, i24* %.sroa.0.0..sroa_cast, align 1 ret i24 %.sroa.0.0.copyload } ```
scottmcm
pushed a commit
that referenced
this pull request
May 9, 2022
author Preston From <[email protected]> 1645164142 -0600 committer Preston From <[email protected]> 1650005351 -0600
scottmcm
pushed a commit
that referenced
this pull request
May 29, 2022
author Preston From <[email protected]> 1645164142 -0600 committer Preston From <[email protected]> 1650005351 -0600
scottmcm
pushed a commit
that referenced
this pull request
Jan 13, 2023
…aces, r=jyn514 Only deduplicate stack traces for good path bugs Fixes rust-lang#106267 Restores backtraces for `bug!` and `delay_span_bug` after rust-lang#106056. Only `delay_good_path_bug` needed its backtraces to be deduplicated, since it spits out the backtrace where it was created when it's being emitted. Before: ``` error: internal compiler error: /home/ubuntu/rust2/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) } note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.68.0-dev running on x86_64-unknown-linux-gnu query stack during panic: #0 [typeck] type-checking `<impl at /home/ubuntu/test.rs:7:1: 7:34>::trigger` #1 [typeck_item_bodies] type-checking all item bodies #2 [analysis] running analysis passes on this crate end of query stack error: aborting due to 2 previous errors ``` Hmm... that's a little bare. After: ``` error: internal compiler error: /home/ubuntu/rust2/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) } thread 'rustc' panicked at 'Box<dyn Any>', /home/ubuntu/rust2/compiler/rustc_errors/src/lib.rs:1599:9 stack backtrace: 0: 0x7ffb5b41bdd1 - std::backtrace_rs::backtrace::libunwind::trace::h26056f81198c6594 at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5 1: 0x7ffb5b41bdd1 - std::backtrace_rs::backtrace::trace_unsynchronized::hacfb345a0c6d5bb1 at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x7ffb5b41bdd1 - std::sys_common::backtrace::_print_fmt::h18ea6016ac8030f3 at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:65:5 3: 0x7ffb5b41bdd1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he35dde201d0c2d09 at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:44:22 4: 0x7ffb5b4a0308 - core::fmt::write::h094ad263467a053c at /home/ubuntu/rust2/library/core/src/fmt/mod.rs:1208:17 5: 0x7ffb5b43caf1 - std::io::Write::write_fmt::hd47b4e2324b4d9b7 at /home/ubuntu/rust2/library/std/src/io/mod.rs:1682:15 6: 0x7ffb5b41bbfa - std::sys_common::backtrace::_print::h43044162653a17fc at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:47:5 7: 0x7ffb5b41bbfa - std::sys_common::backtrace::print::hc8605da258fa5aeb at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:34:9 8: 0x7ffb5b3ffb87 - std::panicking::default_hook::{{closure}}::h9e37f23f75122a15 9: 0x7ffb5b3ff97b - std::panicking::default_hook::h602873a063f84da2 at /home/ubuntu/rust2/library/std/src/panicking.rs:286:9 10: 0x7ffb5be192b2 - <alloc[48d7b30605060536]::boxed::Box<dyn for<'a, 'b> core[672e3947e150d6c6]::ops::function::Fn<(&'a core[672e3947e150d6c6]::panic::panic_info::PanicInfo<'b>,), Output = ()> + core[672e3947e150d6c6]::marker::Send + core[672e3947e150d6c6]::marker::Sync> as core[672e3947e150d6c6]::ops::function::Fn<(&core[672e3947e150d6c6]::panic::panic_info::PanicInfo,)>>::call at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9 11: 0x7ffb5be192b2 - rustc_driver[f5b6d32d8905ecdd]::DEFAULT_HOOK::{closure#0}::{closure#0} at /home/ubuntu/rust2/compiler/rustc_driver/src/lib.rs:1204:17 12: 0x7ffb5b4000d3 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hfd13333ca953ae8e at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9 13: 0x7ffb5b4000d3 - std::panicking::rust_panic_with_hook::h45753e10264ebe7e at /home/ubuntu/rust2/library/std/src/panicking.rs:692:13 14: 0x7ffb5e8b3a63 - std[3330b4673efabfce]::panicking::begin_panic::<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>::{closure#0} [... FRAMES INTENTIONALLY OMITTED BECAUSE GITHUB GOT ANGRY ...] 186: 0x7ffb5bea5554 - <std[3330b4673efabfce]::thread::Builder>::spawn_unchecked_::<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1} at /home/ubuntu/rust2/library/std/src/thread/mod.rs:549:30 187: 0x7ffb5bea5554 - <<std[3330b4673efabfce]::thread::Builder>::spawn_unchecked_<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1} as core[672e3947e150d6c6]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} at /home/ubuntu/rust2/library/core/src/ops/function.rs:250:5 188: 0x7ffb5b433968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::he8b26fc22c6f51ec at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9 189: 0x7ffb5b433968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h5cf9cbe75a8c3ddc at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9 190: 0x7ffb5b41199c - std::sys::unix::thread::Thread::new::thread_start::h2d6dd4455e97d031 at /home/ubuntu/rust2/library/std/src/sys/unix/thread.rs:108:17 191: 0x7ffb5441b609 - start_thread 192: 0x7ffb5b282133 - clone 193: 0x0 - <unknown> note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.68.0-dev running on x86_64-unknown-linux-gnu query stack during panic: #0 [typeck] type-checking `<impl at /home/ubuntu/test.rs:7:1: 7:34>::trigger` #1 [typeck_item_bodies] type-checking all item bodies #2 [analysis] running analysis passes on this crate end of query stack error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0601`. ```
scottmcm
pushed a commit
that referenced
this pull request
Feb 3, 2023
…u-se
Implement `SpecOptionPartialEq` for `cmp::Ordering`
Noticed as I continue to explore options for having code using `partial_cmp` optimize better.
Before:
```llvm
; Function Attrs: mustprogress nofree nosync nounwind willreturn uwtable
define noundef zeroext i1 `@ordering_eq(i8` noundef %0, i8 noundef %1) unnamed_addr #0 {
start:
%2 = icmp eq i8 %0, 2
br i1 %2, label %bb1.i, label %bb3.i
bb1.i: ; preds = %start
%3 = icmp eq i8 %1, 2
br label %"_ZN55_$LT$T$u20$as$u20$core..option..SpecOptionPartialEq$GT$2eq17hb7e7beacecde585fE.exit"
bb3.i: ; preds = %start
%.not.i = icmp ne i8 %1, 2
%4 = icmp eq i8 %0, %1
%spec.select.i = and i1 %.not.i, %4
br label %"_ZN55_$LT$T$u20$as$u20$core..option..SpecOptionPartialEq$GT$2eq17hb7e7beacecde585fE.exit"
"_ZN55_$LT$T$u20$as$u20$core..option..SpecOptionPartialEq$GT$2eq17hb7e7beacecde585fE.exit": ; preds = %bb1.i, %bb3.i
%.0.i = phi i1 [ %3, %bb1.i ], [ %spec.select.i, %bb3.i ]
ret i1 %.0.i
}
```
After:
```llvm
; Function Attrs: mustprogress nofree norecurse nosync nounwind readnone willreturn uwtable
define noundef zeroext i1 `@ordering_eq(i8` noundef %0, i8 noundef %1) unnamed_addr #1 {
start:
%2 = icmp eq i8 %0, %1
ret i1 %2
}
```
(Which <https://alive2.llvm.org/ce/z/-rop5r> says LLVM *could* just do itself, but there's probably an issue already open for that problem from when this was originally looked at for `Option<NonZeroU8>` and friends.)
scottmcm
pushed a commit
that referenced
this pull request
Apr 21, 2023
There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`): ```rust #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; ``` Before, this would give an error about duplicate versions of libc: ``` error[E0464]: multiple candidates for `rlib` dependency `libc` found --> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1 | LL | extern crate libc; | ^^^^^^^^^^^^^^^^^^ | = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta ``` Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`: ``` ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta ``` The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`. To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot. This also allows reverting the hack in rust-lang#110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true`. --- See rust-lang#108767 (comment) for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important. Fixes rust-lang#108767.
scottmcm
pushed a commit
that referenced
this pull request
Apr 21, 2023
…tlarsan68 Fix no_std tests that load libc from the sysroot when download-rustc is enabled There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`): ```rust #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; ``` Before, this would give an error about duplicate versions of libc: ``` error[E0464]: multiple candidates for `rlib` dependency `libc` found --> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1 | LL | extern crate libc; | ^^^^^^^^^^^^^^^^^^ | = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta ``` Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`: ``` ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta ``` The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`. To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot. This also allows reverting the hack in rust-lang#110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true` and some tool depends on a local change to `compiler`. --- See rust-lang#108767 (comment) for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important. Fixes rust-lang#108767.
scottmcm
pushed a commit
that referenced
this pull request
May 4, 2023
…t, r=tmiasko Encode def span for foreign return-position `impl Trait` in trait Fixes rust-lang#111031, yet another def-span encoding issue :/ Includes a smaller repro than the issue, but I can confirm it ICEs: ``` query stack during panic: #0 [def_span] looking up span for `rpitit::Foo::bar::{opaque#0}` #1 [object_safety_violations] determining object safety of trait `rpitit::Foo` #2 [check_is_object_safe] checking if trait `rpitit::Foo` is object safe #3 [typeck] type-checking `main` rust-lang#4 [used_trait_imports] finding used_trait_imports `main` rust-lang#5 [analysis] running analysis passes on this crate ``` Luckily since this only affects nightly, this desn't need to be backported.
scottmcm
pushed a commit
that referenced
this pull request
May 7, 2023
Add Terminator conversion from MIR to SMIR, part #1 This adds internal MIR TerminatorKind to SMIR Terminator conversion. r? ```@oli-obk```
scottmcm
pushed a commit
that referenced
this pull request
May 7, 2023
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#110577 (Use fulfillment to check `Drop` impl compatibility) - rust-lang#110610 (Add Terminator conversion from MIR to SMIR, part #1) - rust-lang#110985 (Fix spans in LLVM-generated inline asm errors) - rust-lang#110989 (Make the BUG_REPORT_URL configurable by tools ) - rust-lang#111167 (debuginfo: split method declaration and definition) - rust-lang#111230 (add hint for =< as <=) - rust-lang#111279 (More robust debug assertions for `Instance::resolve` on built-in traits with non-standard trait items) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
scottmcm
pushed a commit
that referenced
this pull request
May 18, 2023
Stop turning transmutes into discriminant reads in mir-opt Partially reverts rust-lang#109612, as after rust-lang#109993 these aren't actually equivalent any more, and I'm no longer confident this was ever an improvement in the first place. Having this "simplification" meant that similar-looking code actually did somewhat different things. For example, ```rust pub unsafe fn demo1(x: std::cmp::Ordering) -> u8 { std::mem::transmute(x) } pub unsafe fn demo2(x: std::cmp::Ordering) -> i8 { std::mem::transmute(x) } ``` in nightly today is generating <https://rust.godbolt.org/z/dPK58zW18> ```llvm define noundef i8 `@_ZN7example5demo117h341ef313673d2ee6E(i8` noundef %x) unnamed_addr #0 { %0 = icmp uge i8 %x, -1 %1 = icmp ule i8 %x, 1 %2 = or i1 %0, %1 call void `@llvm.assume(i1` %2) ret i8 %x } define noundef i8 `@_ZN7example5demo217h5ad29f361a3f5700E(i8` noundef %0) unnamed_addr #0 { %x = alloca i8, align 1 store i8 %0, ptr %x, align 1 %1 = load i8, ptr %x, align 1, !range !2, !noundef !3 ret i8 %1 } ``` Which feels too different when the original code is essentially identical. --- Aside: that example is different *after* optimizations too: ```llvm define noundef i8 `@_ZN7example5demo117h341ef313673d2ee6E(i8` noundef returned %x) unnamed_addr #0 { %0 = add i8 %x, 1 %1 = icmp ult i8 %0, 3 tail call void `@llvm.assume(i1` %1) ret i8 %x } define noundef i8 `@_ZN7example5demo217h5ad29f361a3f5700E(i8` noundef returned %0) unnamed_addr #1 { ret i8 %0 } ``` so turning the `Transmute` into a `Discriminant` was arguably just making things worse, so leaving it alone instead -- and thus having less code in rustc -- seems clearly better.
scottmcm
pushed a commit
that referenced
this pull request
May 25, 2023
Fixes rust-lang#111510 and complements rust-lang#106547 by adding support for encoding type parameters and also by transforming trait objects' traits into their identities before emitting type checks.
scottmcm
pushed a commit
that referenced
this pull request
May 25, 2023
CFI: Fix encode_ty: unexpected Param(B/#1) Fixes rust-lang#111510 and complements rust-lang#106547 by adding support for encoding type parameters and also by transforming trait objects' traits into their identities before emitting type checks.
scottmcm
pushed a commit
that referenced
this pull request
Jun 10, 2023
…iler-errors Use `load`+`store` instead of `memcpy` for small integer arrays I was inspired by rust-lang#98892 to see whether, rather than making `mem::swap` do something smart in the library, we could update MIR assignments like `*_1 = *_2` to do something smarter than `memcpy` for sufficiently-small types that doing it inline is going to be better than a `memcpy` call in assembly anyway. After all, special code may help `mem::swap`, but if the "obvious" MIR can just result in the correct thing that helps everything -- other code like `mem::replace`, people doing it manually, and just passing around by value in general -- as well as makes MIR inlining happier since it doesn't need to deal with all the complicated library code if it just sees a couple assignments. LLVM will turn the short, known-length `memcpy`s into direct instructions in the backend, but that's too late for it to be able to remove `alloca`s. In general, replacing `memcpy`s with typed instructions is hard in the middle-end -- even for `memcpy.inline` where it knows it won't be a function call -- is hard [due to poison propagation issues](https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/memcpy.20vs.20load-store.20for.20MIR.20assignments/near/360376712). So because we know more about the type invariants -- these are typed copies -- rustc can emit something more specific, allowing LLVM to `mem2reg` away the `alloca`s in some situations. rust-lang#52051 previously did something like this in the library for `mem::swap`, but it ended up regressing during enabling mir inlining (rust-lang@cbbf06b), so this has been suboptimal on stable for ≈5 releases now. The code in this PR is narrowly targeted at just integer arrays in LLVM, but works via a new method on the [`LayoutTypeMethods`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.LayoutTypeMethods.html) trait, so specific backends based on cg_ssa can enable this for more situations over time, as we find them. I don't want to try to bite off too much in this PR, though. (Transparent newtypes and simple things like the 3×usize `String` would be obvious candidates for a follow-up.) Codegen demonstrations: <https://llvm.godbolt.org/z/fK8hT9aqv> Before: ```llvm define void `@swap_rgb48_old(ptr` noalias nocapture noundef align 2 dereferenceable(6) %x, ptr noalias nocapture noundef align 2 dereferenceable(6) %y) unnamed_addr #1 { %a.i = alloca [3 x i16], align 2 call void `@llvm.lifetime.start.p0(i64` 6, ptr nonnull %a.i) call void `@llvm.memcpy.p0.p0.i64(ptr` noundef nonnull align 2 dereferenceable(6) %a.i, ptr noundef nonnull align 2 dereferenceable(6) %x, i64 6, i1 false) tail call void `@llvm.memcpy.p0.p0.i64(ptr` noundef nonnull align 2 dereferenceable(6) %x, ptr noundef nonnull align 2 dereferenceable(6) %y, i64 6, i1 false) call void `@llvm.memcpy.p0.p0.i64(ptr` noundef nonnull align 2 dereferenceable(6) %y, ptr noundef nonnull align 2 dereferenceable(6) %a.i, i64 6, i1 false) call void `@llvm.lifetime.end.p0(i64` 6, ptr nonnull %a.i) ret void } ``` Note it going to stack: ```nasm swap_rgb48_old: # `@swap_rgb48_old` movzx eax, word ptr [rdi + 4] mov word ptr [rsp - 4], ax mov eax, dword ptr [rdi] mov dword ptr [rsp - 8], eax movzx eax, word ptr [rsi + 4] mov word ptr [rdi + 4], ax mov eax, dword ptr [rsi] mov dword ptr [rdi], eax movzx eax, word ptr [rsp - 4] mov word ptr [rsi + 4], ax mov eax, dword ptr [rsp - 8] mov dword ptr [rsi], eax ret ``` Now: ```llvm define void `@swap_rgb48(ptr` noalias nocapture noundef align 2 dereferenceable(6) %x, ptr noalias nocapture noundef align 2 dereferenceable(6) %y) unnamed_addr #0 { start: %0 = load <3 x i16>, ptr %x, align 2 %1 = load <3 x i16>, ptr %y, align 2 store <3 x i16> %1, ptr %x, align 2 store <3 x i16> %0, ptr %y, align 2 ret void } ``` still lowers to `dword`+`word` operations, but has no stack traffic: ```nasm swap_rgb48: # `@swap_rgb48` mov eax, dword ptr [rdi] movzx ecx, word ptr [rdi + 4] movzx edx, word ptr [rsi + 4] mov r8d, dword ptr [rsi] mov dword ptr [rdi], r8d mov word ptr [rdi + 4], dx mov word ptr [rsi + 4], cx mov dword ptr [rsi], eax ret ``` And as a demonstration that this isn't just `mem::swap`, a `mem::replace` on a small array (since replace doesn't use swap since rust-lang#83022), which used to be `memcpy`s in LLVM changes in IR ```llvm define void `@replace_short_array(ptr` noalias nocapture noundef sret([3 x i32]) dereferenceable(12) %0, ptr noalias noundef align 4 dereferenceable(12) %r, ptr noalias nocapture noundef readonly dereferenceable(12) %v) unnamed_addr #0 { start: %1 = load <3 x i32>, ptr %r, align 4 store <3 x i32> %1, ptr %0, align 4 %2 = load <3 x i32>, ptr %v, align 4 store <3 x i32> %2, ptr %r, align 4 ret void } ``` but that lowers to reasonable `dword`+`qword` instructions still ```nasm replace_short_array: # `@replace_short_array` mov rax, rdi mov rcx, qword ptr [rsi] mov edi, dword ptr [rsi + 8] mov dword ptr [rax + 8], edi mov qword ptr [rax], rcx mov rcx, qword ptr [rdx] mov edx, dword ptr [rdx + 8] mov dword ptr [rsi + 8], edx mov qword ptr [rsi], rcx ret ```
scottmcm
pushed a commit
that referenced
this pull request
May 19, 2024
…r=Mark-Simulacrum lldb-formatters: Use StdSliceSyntheticProvider for &str &str has associated summary provider which correctly displays string values in debugger, but while working on rust-lang#124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } 1 = "World" { data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ``` After this PR it would look the following way: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } 1 = "World" { [0] = 'W' [1] = 'o' [2] = 'r' [3] = 'l' [4] = 'd' } } ```
scottmcm
pushed a commit
that referenced
this pull request
Jun 10, 2024
…-codegen-tests, r=erikdesjardins,workingjubilee Repair several `riscv64gc-unknown-linux-gnu` codegen tests Together with [email protected], we've been starting to explore improving the state of the `riscv64gc-unknown-linux-gnu` target. Additionally, I'm looking to add support for this platform in [Ferrocene](https://github.com/ferrocene/ferrocene) ([Related PR](ferrocene/ferrocene#618)). While running the test suite, we noted several tests were failing. It appears that several of the riscv64gc-unknown-linux-gnu codegen tests have not been updated in some time and seem to have experienced a small amount of bitrot. After speaking with `@workingjubilee` (as I have little expertise in LLVM codegen) I believe these changes to be correct. ### `tests/codegen/riscv-abi/call-llvm-intrinsics.rs` I believe this change does not alter what the test is testing and is harmless. ### `tests/codegen/riscv-abi/riscv64-lp64d-abi.rs` The changes largely mirrors those from loongarch64: https://github.com/rust-lang/rust/blob/550d1b4fb6de23990f4108815c3b1a9d1659e5c4/tests/codegen/loongarch-abi/loongarch64-lp64d-abi.rs#L13-L15 https://github.com/rust-lang/rust/blob/550d1b4fb6de23990f4108815c3b1a9d1659e5c4/tests/codegen/loongarch-abi/loongarch64-lp64d-abi.rs#L153-L155 https://github.com/rust-lang/rust/blob/550d1b4fb6de23990f4108815c3b1a9d1659e5c4/tests/codegen/loongarch-abi/loongarch64-lp64d-abi.rs#L259-L261 https://github.com/rust-lang/rust/blob/550d1b4fb6de23990f4108815c3b1a9d1659e5c4/tests/codegen/loongarch-abi/loongarch64-lp64d-abi.rs#L263-L267 ### `tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs` The changes largely mirror that from loongarch64 or llvm: https://github.com/rust-lang/rust/blob/550d1b4fb6de23990f4108815c3b1a9d1659e5c4/tests/codegen/loongarch-abi/loongarch64-lp64d-abi.rs#L13-L26 https://github.com/rust-lang/llvm-project/blob/5399a24c66cb6164cf32280e7d300488c90d5765/clang/test/CodeGen/RISCV/riscv64-abi.c#L612-L617 ### `tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs` The test is ignored since `-Csplit-debuginfo=unpacked` is not supported on this platform. Context can be found in rust-lang#120518. ## Reproducing the failures Using a `config.toml` with the following: ```toml # ... target = [ # ... "riscv64gc-unknown-linux-gnu", ] ``` > [!NOTE] > You may need to install a RICV-V toolchain! We get ours from [here](https://www.embecosm.com/resources/tool-chain-downloads/#riscv-linux). > > If you are using an old (20.04) Ubuntu container the compiler in the repositories (`gcc-riscv64-linux-gnu`) won't work! Run the following test suite: ```bash ./x.py test tests/codegen ``` <details> <summary>Expected output</summary> ``` ana@Autonoma:~/git/rust-lang/rust$ ./x.py test tests/codegen Building bootstrap Finished `dev` profile [unoptimized] target(s) in 0.03s WARNING: The `change-id` is missing in the `config.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations. NOTE: to silence this warning, add `change-id = 124501` at the top of `config.toml` Building stage0 library artifacts (x86_64-unknown-linux-gnu) Finished `release` profile [optimized] target(s) in 0.11s Building compiler artifacts (stage0 -> stage1, x86_64-unknown-linux-gnu) Finished `release` profile [optimized] target(s) in 0.18s Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`) Building stage1 library artifacts (x86_64-unknown-linux-gnu) Finished `release` profile [optimized] target(s) in 0.11s Building stage0 tool compiletest (x86_64-unknown-linux-gnu) Finished `release` profile [optimized] target(s) in 0.11s Testing stage1 compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu) running 652 tests iii......ii...iiiiiii...........ii..iii....i......i......i......iii...iiiii..i..i...i... 88/652 .............i............iii..iiii.....................i............................... 176/652 iiiiiii.............iiiiiiiii.iii....i.................i....................i...ii....i. 264/652 ..i........i.........i..i........iii.........i............ii................ii..i....... 352/652 ...............i...i....ii.i.....i......................ii.ii...iiiiiiiiiiiiiiiiiiiiiiii 440/652 iii....................iiiiiiiiiiiiiiii.........................iii.i..........i........ 528/652 ...i...ii...........i...ii.i..i..........i..............................ii.....ii.i..ii. 616/652 .ii................................. test result: ok. 498 passed; 0 failed; 154 ignored; 0 measured; 0 filtered out; finished in 4.76s Building stage1 library artifacts (x86_64-unknown-linux-gnu -> riscv64gc-unknown-linux-gnu) Finished `release` profile [optimized] target(s) in 0.10s Testing stage1 compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> riscv64gc-unknown-linux-gnu) running 652 tests iii......ii..iiiiiii.....i..i..i.i...i........i..i.......i......iii...iiiii..i.i....i... 88/652 .............i............iii..iiii....................i...............................i 176/652 iiiiii..............iiiiiiiii.iii.....i................i..................i.....ii....i. 264/652 ..i........i..........i.i........iii..........i...........ii................ii..i....... 352/652 ...............i...i....ii.i.....i......................i.......iii.iiiiiiiiiiiiiiiiiiii 440/652 iiii...................iiiiiiiiiiiiiiii................ [codegen] tests/codegen/riscv-abi/call-llvm-intrinsics.rs ... F ..... [codegen] tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs ... F ..iii.i. [codegen] tests/codegen/riscv-abi/riscv64-lp64d-abi.rs ... F ........i........ 528/652 ...i...ii...........i...ii..i.i..........i..............................ii.....ii.i..ii. 616/652 .ii................................. failures: ---- [codegen] tests/codegen/riscv-abi/call-llvm-intrinsics.rs stdout ---- error: verification with 'FileCheck' failed status: exit status: 1 command: "/home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--input-file" "/home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/call-llvm-intrinsics/call-llvm-intrinsics.ll" "/home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/call-llvm-intrinsics.rs" "--check-prefix=CHECK" "--check-prefix" "NONMSVC" "--allow-unused-prefixes" "--dump-input-context" "100" stdout: none --- stderr ------------------------------- /home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/call-llvm-intrinsics.rs:26:12: error: CHECK: expected string not found in input // CHECK: store float 4.000000e+00, float* %{{.}}, align 4 ^ /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/call-llvm-intrinsics/call-llvm-intrinsics.ll:1:1: note: scanning from here ; ModuleID = 'call_llvm_intrinsics.b4a95fd5831b1bb7-cgu.0' ^ /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/call-llvm-intrinsics/call-llvm-intrinsics.ll:53:2: note: possible intended match here store float 4.000000e+00, ptr %3, align 4 ^ Input file: /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/call-llvm-intrinsics/call-llvm-intrinsics.ll Check file: /home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/call-llvm-intrinsics.rs -dump-input=help explains the following input dump. Input was: <<<<<< 1: ; ModuleID = 'call_llvm_intrinsics.b4a95fd5831b1bb7-cgu.0' check:26'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found 2: source_filename = "call_llvm_intrinsics.b4a95fd5831b1bb7-cgu.0" check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3: target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128" check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4: target triple = "riscv64-unknown-linux-gnu" check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5: check:26'0 ~ 6: `@alloc_cebd5a1664be1c73eee4a1aab7937c96` = private unnamed_addr constant <{ [2 x i8] }> <{ [2 x i8] c"A\0A" }>, align 1 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7: `@alloc_bddb4fe6d67b5a5a93d73a63d68b4b9e` = private unnamed_addr constant <{ ptr, [8 x i8] }> <{ ptr `@alloc_cebd5a1664be1c73eee4a1aab7937c96,` [8 x i8] c"\02\00\00\00\00\00\00\00" }>, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8: `@0` = private unnamed_addr constant <{ [8 x i8], [8 x i8] }> <{ [8 x i8] zeroinitializer, [8 x i8] undef }>, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: check:26'0 ~ 10: ; core::ptr::drop_in_place<call_llvm_intrinsics::A> check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 11: ; Function Attrs: uwtable check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: define internal void `@"_ZN4core3ptr44drop_in_place$LT$call_llvm_intrinsics..A$GT$17hf11b50bd9b9c5359E"(ptr` noalias noundef nonnull align 1 %_1) unnamed_addr #0 { check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: start: check:26'0 ~~~~~~~ 14: ; call <call_llvm_intrinsics::A as core::ops::drop::Drop>::drop check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15: call void `@"_ZN65_$LT$call_llvm_intrinsics..A$u20$as$u20$core..ops..drop..Drop$GT$4drop17hc84a7f61b5f719bdE"(ptr` noalias noundef nonnull align 1 %_1) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16: ret void check:26'0 ~~~~~~~~~~ 17: } check:26'0 ~~ 18: check:26'0 ~ 19: ; <call_llvm_intrinsics::A as core::ops::drop::Drop>::drop check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20: ; Function Attrs: uwtable check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 21: define void `@"_ZN65_$LT$call_llvm_intrinsics..A$u20$as$u20$core..ops..drop..Drop$GT$4drop17hc84a7f61b5f719bdE"(ptr` noalias noundef nonnull align 1 %self) unnamed_addr #0 { check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22: start: check:26'0 ~~~~~~~ 23: %_3 = alloca [48 x i8], align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 24: call void `@llvm.lifetime.start.p0(i64` 48, ptr %_3) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 25: store ptr `@alloc_bddb4fe6d67b5a5a93d73a63d68b4b9e,` ptr %_3, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26: %0 = getelementptr inbounds i8, ptr %_3, i64 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 27: store i64 1, ptr %0, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 28: %1 = load ptr, ptr `@0,` align 8, !align !4, !noundef !5 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29: %2 = load i64, ptr getelementptr inbounds (i8, ptr `@0,` i64 8), align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30: %3 = getelementptr inbounds i8, ptr %_3, i64 32 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 31: store ptr %1, ptr %3, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 32: %4 = getelementptr inbounds i8, ptr %3, i64 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 33: store i64 %2, ptr %4, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34: %5 = getelementptr inbounds i8, ptr %_3, i64 16 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 35: store ptr inttoptr (i64 8 to ptr), ptr %5, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36: %6 = getelementptr inbounds i8, ptr %5, i64 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37: store i64 0, ptr %6, align 8 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 38: ; call std::io::stdio::_print check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39: call void `@_ZN3std2io5stdio6_print17h38b16d890daf9d05E(ptr` noalias nocapture noundef align 8 dereferenceable(48) %_3) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 40: call void `@llvm.lifetime.end.p0(i64` 48, ptr %_3) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41: ret void check:26'0 ~~~~~~~~~~ 42: } check:26'0 ~~ 43: check:26'0 ~ 44: ; call_llvm_intrinsics::do_call check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45: ; Function Attrs: uwtable check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 46: define void `@_ZN20call_llvm_intrinsics7do_call17h1d78694c55381316E()` unnamed_addr #0 { check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47: start: check:26'0 ~~~~~~~ 48: %0 = alloca [4 x i8], align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 49: %1 = alloca [4 x i8], align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 50: %2 = alloca [4 x i8], align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 51: %3 = alloca [4 x i8], align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 52: %_1 = alloca [0 x i8], align 1 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 53: store float 4.000000e+00, ptr %3, align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:26'1 ? possible intended match 54: call void `@llvm.lifetime.start.p0(i64` 4, ptr %2) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 55: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %2, ptr align 4 %3, i64 4, i1 false) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 56: %4 = load float, ptr %2, align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 57: call void `@llvm.lifetime.end.p0(i64` 4, ptr %2) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 58: %5 = call float `@llvm.sqrt.f32(float` %4) rust-lang#4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 59: call void `@llvm.lifetime.start.p0(i64` 4, ptr %1) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 60: call void `@llvm.lifetime.start.p0(i64` 4, ptr %0) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 61: store float %5, ptr %0, align 4 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 62: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %1, ptr align 4 %0, i64 4, i1 false) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 63: call void `@llvm.lifetime.end.p0(i64` 4, ptr %0) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64: %_2 = load float, ptr %1, align 4, !noundef !5 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 65: call void `@llvm.lifetime.end.p0(i64` 4, ptr %1) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 66: ; call core::ptr::drop_in_place<call_llvm_intrinsics::A> check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 67: call void `@"_ZN4core3ptr44drop_in_place$LT$call_llvm_intrinsics..A$GT$17hf11b50bd9b9c5359E"(ptr` noalias noundef nonnull align 1 %_1) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68: ret void check:26'0 ~~~~~~~~~~ 69: } check:26'0 ~~ 70: check:26'0 ~ 71: ; std::io::stdio::_print check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~ 72: ; Function Attrs: uwtable check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 73: declare void `@_ZN3std2io5stdio6_print17h38b16d890daf9d05E(ptr` noalias nocapture noundef align 8 dereferenceable(48)) unnamed_addr #0 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 74: check:26'0 ~ 75: ; Function Attrs: nocallback nofree nounwind willreturn memory(argmem: readwrite) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 76: declare void `@llvm.memcpy.p0.p0.i64(ptr` noalias nocapture writeonly, ptr noalias nocapture readonly, i64, i1 immarg) #1 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 77: check:26'0 ~ 78: ; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 79: declare float `@llvm.sqrt.f32(float)` unnamed_addr #2 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 80: check:26'0 ~ 81: ; Function Attrs: nocallback nofree nosync nounwind willreturn memory(argmem: readwrite) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 82: declare void `@llvm.lifetime.start.p0(i64` immarg, ptr nocapture) #3 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 83: check:26'0 ~ 84: ; Function Attrs: nocallback nofree nosync nounwind willreturn memory(argmem: readwrite) check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 85: declare void `@llvm.lifetime.end.p0(i64` immarg, ptr nocapture) #3 check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 86: check:26'0 ~ 87: attributes #0 = { uwtable "target-cpu"="generic-rv64" "target-features"="+m,+a,+f,+d,+c" } check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 88: attributes #1 = { nocallback nofree nounwind willreturn memory(argmem: readwrite) } check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89: attributes #2 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) } check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 90: attributes #3 = { nocallback nofree nosync nounwind willreturn memory(argmem: readwrite) } check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 91: attributes rust-lang#4 = { nounwind } check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 92: check:26'0 ~ 93: !llvm.module.flags = !{!0, !1, !2} check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 94: !llvm.ident = !{!3} check:26'0 ~~~~~~~~~~~~~~~~~~~~ 95: check:26'0 ~ 96: !0 = !{i32 8, !"PIC Level", i32 2} check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 97: !1 = !{i32 1, !"Code Model", i32 3} check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 98: !2 = !{i32 1, !"target-abi", !"lp64d"} check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 99: !3 = !{!"rustc version 1.80.0-dev"} check:26'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 100: !4 = !{i64 8} check:26'0 ~~~~~~~~~~~~~~ 101: !5 = !{} check:26'0 ~~~~~~~~~ >>>>>> ------------------------------------------ ---- [codegen] tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs stdout ---- error: verification with 'FileCheck' failed status: exit status: 1 command: "/home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--input-file" "/home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64f-lp64d-abi/riscv64-lp64f-lp64d-abi.ll" "/home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs" "--check-prefix=CHECK" "--check-prefix" "NONMSVC" "--allow-unused-prefixes" "--dump-input-context" "100" stdout: none --- stderr ------------------------------- /home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs:7:11: error: CHECK: expected string not found in input // CHECK: define void `@f_fpr_tracking(float` %0, float %1, float %2, float %3, float %4, float %5, float %6, float %7, i8 zeroext %i) ^ /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64f-lp64d-abi/riscv64-lp64f-lp64d-abi.ll:1:1: note: scanning from here ; ModuleID = 'riscv64_lp64f_lp64d_abi.ae8fa95bac1a0604-cgu.0' ^ /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64f-lp64d-abi/riscv64-lp64f-lp64d-abi.ll:9:1: note: possible intended match here define void `@f_fpr_tracking(float` %0, float %1, float %2, float %3, float %4, float %5, float %6, float %7, i8 noundef zeroext %i) unnamed_addr #0 { ^ Input file: /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64f-lp64d-abi/riscv64-lp64f-lp64d-abi.ll Check file: /home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs -dump-input=help explains the following input dump. Input was: <<<<<< 1: ; ModuleID = 'riscv64_lp64f_lp64d_abi.ae8fa95bac1a0604-cgu.0' check:7'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found 2: source_filename = "riscv64_lp64f_lp64d_abi.ae8fa95bac1a0604-cgu.0" check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3: target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128" check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4: target triple = "riscv64-unknown-linux-gnu" check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5: check:7'0 ~ 6: %Tricky1 = type { [1 x float] } check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7: check:7'0 ~ 8: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: define void `@f_fpr_tracking(float` %0, float %1, float %2, float %3, float %4, float %5, float %6, float %7, i8 noundef zeroext %i) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:7'1 ? possible intended match 10: start: check:7'0 ~~~~~~~ 11: %8 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: %h = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: %9 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14: %g = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15: %10 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16: %f = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17: %11 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 18: %e = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19: %12 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20: %d = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 21: %13 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22: %c = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 23: %14 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 24: %b = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 25: %15 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26: %a = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 27: call void `@llvm.lifetime.start.p0(i64` 4, ptr %15) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 28: store float %0, ptr %15, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %a, ptr align 4 %15, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30: call void `@llvm.lifetime.end.p0(i64` 4, ptr %15) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 31: call void `@llvm.lifetime.start.p0(i64` 4, ptr %14) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 32: store float %1, ptr %14, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 33: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %b, ptr align 4 %14, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34: call void `@llvm.lifetime.end.p0(i64` 4, ptr %14) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 35: call void `@llvm.lifetime.start.p0(i64` 4, ptr %13) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36: store float %2, ptr %13, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %c, ptr align 4 %13, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 38: call void `@llvm.lifetime.end.p0(i64` 4, ptr %13) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39: call void `@llvm.lifetime.start.p0(i64` 4, ptr %12) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 40: store float %3, ptr %12, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %d, ptr align 4 %12, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 42: call void `@llvm.lifetime.end.p0(i64` 4, ptr %12) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 43: call void `@llvm.lifetime.start.p0(i64` 4, ptr %11) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 44: store float %4, ptr %11, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %e, ptr align 4 %11, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46: call void `@llvm.lifetime.end.p0(i64` 4, ptr %11) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47: call void `@llvm.lifetime.start.p0(i64` 4, ptr %10) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 48: store float %5, ptr %10, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 49: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %f, ptr align 4 %10, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 50: call void `@llvm.lifetime.end.p0(i64` 4, ptr %10) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 51: call void `@llvm.lifetime.start.p0(i64` 4, ptr %9) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 52: store float %6, ptr %9, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 53: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %g, ptr align 4 %9, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 54: call void `@llvm.lifetime.end.p0(i64` 4, ptr %9) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 55: call void `@llvm.lifetime.start.p0(i64` 4, ptr %8) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 56: store float %7, ptr %8, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 57: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %h, ptr align 4 %8, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 58: call void `@llvm.lifetime.end.p0(i64` 4, ptr %8) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 59: ret void check:7'0 ~~~~~~~~~~ 60: } check:7'0 ~~ 61: check:7'0 ~ 62: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 63: define void `@f_float_s_arg(float` %0) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64: start: check:7'0 ~~~~~~~ 65: %1 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 66: %a = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 67: call void `@llvm.lifetime.start.p0(i64` 4, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68: store float %0, ptr %1, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 69: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %a, ptr align 4 %1, i64 4, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 70: call void `@llvm.lifetime.end.p0(i64` 4, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 71: ret void check:7'0 ~~~~~~~~~~ 72: } check:7'0 ~~ 73: check:7'0 ~ 74: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 75: define float `@f_ret_float_s()` unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 76: start: check:7'0 ~~~~~~~ 77: %_0 = alloca [4 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 78: store float 1.000000e+00, ptr %_0, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 79: %0 = load float, ptr %_0, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 80: ret float %0 check:7'0 ~~~~~~~~~~~~~~ 81: } check:7'0 ~~ 82: check:7'0 ~ 83: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 84: define void `@f_float_float_s_arg({` float, float } %0) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 85: start: check:7'0 ~~~~~~~ 86: %1 = alloca [8 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 87: %a = alloca [8 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 88: call void `@llvm.lifetime.start.p0(i64` 8, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89: store { float, float } %0, ptr %1, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 90: call void `@llvm.memcpy.p0.p0.i64(ptr` align 4 %a, ptr align 4 %1, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 91: call void `@llvm.lifetime.end.p0(i64` 8, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 92: ret void check:7'0 ~~~~~~~~~~ 93: } check:7'0 ~~ 94: check:7'0 ~ 95: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 96: define { float, float } `@f_ret_float_float_s()` unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 97: start: check:7'0 ~~~~~~~ 98: %0 = alloca [8 x i8], align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 99: store float 1.000000e+00, ptr %0, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 100: %1 = getelementptr inbounds i8, ptr %0, i64 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 101: store float 2.000000e+00, ptr %1, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 102: %2 = load { float, float }, ptr %0, align 4 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103: ret { float, float } %2 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~ 104: } check:7'0 ~~ 105: check:7'0 ~ 106: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 107: define void `@f_float_float_s_arg_insufficient_fprs(float` %0, float %1, float %2, float %3, float %4, float %5, float %6, i64 %7) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 108: start: check:7'0 ~~~~~~~ 109: %8 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . . . >>>>>> ------------------------------------------ ---- [codegen] tests/codegen/riscv-abi/riscv64-lp64d-abi.rs stdout ---- error: verification with 'FileCheck' failed status: exit status: 1 command: "/home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--input-file" "/home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64d-abi/riscv64-lp64d-abi.ll" "/home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/riscv64-lp64d-abi.rs" "--check-prefix=CHECK" "--check-prefix" "NONMSVC" "--allow-unused-prefixes" "--dump-input-context" "100" stdout: none --- stderr ------------------------------- /home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/riscv64-lp64d-abi.rs:7:11: error: CHECK: expected string not found in input // CHECK: define void `@f_fpr_tracking(double` %0, double %1, double %2, double %3, double %4, double %5, double %6, double %7, i8 zeroext %i) ^ /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64d-abi/riscv64-lp64d-abi.ll:1:1: note: scanning from here ; ModuleID = 'riscv64_lp64d_abi.bed282cd9c73cc17-cgu.0' ^ /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64d-abi/riscv64-lp64d-abi.ll:9:1: note: possible intended match here define void `@f_fpr_tracking(double` %0, double %1, double %2, double %3, double %4, double %5, double %6, double %7, i8 noundef zeroext %i) unnamed_addr #0 { ^ Input file: /home/ana/git/rust-lang/rust/build/x86_64-unknown-linux-gnu/test/codegen/riscv-abi/riscv64-lp64d-abi/riscv64-lp64d-abi.ll Check file: /home/ana/git/rust-lang/rust/tests/codegen/riscv-abi/riscv64-lp64d-abi.rs -dump-input=help explains the following input dump. Input was: <<<<<< 1: ; ModuleID = 'riscv64_lp64d_abi.bed282cd9c73cc17-cgu.0' check:7'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found 2: source_filename = "riscv64_lp64d_abi.bed282cd9c73cc17-cgu.0" check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3: target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128" check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4: target triple = "riscv64-unknown-linux-gnu" check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5: check:7'0 ~ 6: %Tricky1 = type { [1 x double] } check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7: check:7'0 ~ 8: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: define void `@f_fpr_tracking(double` %0, double %1, double %2, double %3, double %4, double %5, double %6, double %7, i8 noundef zeroext %i) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:7'1 ? possible intended match 10: start: check:7'0 ~~~~~~~ 11: %8 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: %h = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: %9 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14: %g = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15: %10 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16: %f = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17: %11 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 18: %e = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19: %12 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20: %d = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 21: %13 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22: %c = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 23: %14 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 24: %b = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 25: %15 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26: %a = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 27: call void `@llvm.lifetime.start.p0(i64` 8, ptr %15) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 28: store double %0, ptr %15, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %a, ptr align 8 %15, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30: call void `@llvm.lifetime.end.p0(i64` 8, ptr %15) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 31: call void `@llvm.lifetime.start.p0(i64` 8, ptr %14) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 32: store double %1, ptr %14, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 33: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %b, ptr align 8 %14, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34: call void `@llvm.lifetime.end.p0(i64` 8, ptr %14) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 35: call void `@llvm.lifetime.start.p0(i64` 8, ptr %13) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36: store double %2, ptr %13, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %c, ptr align 8 %13, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 38: call void `@llvm.lifetime.end.p0(i64` 8, ptr %13) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39: call void `@llvm.lifetime.start.p0(i64` 8, ptr %12) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 40: store double %3, ptr %12, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %d, ptr align 8 %12, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 42: call void `@llvm.lifetime.end.p0(i64` 8, ptr %12) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 43: call void `@llvm.lifetime.start.p0(i64` 8, ptr %11) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 44: store double %4, ptr %11, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %e, ptr align 8 %11, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46: call void `@llvm.lifetime.end.p0(i64` 8, ptr %11) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47: call void `@llvm.lifetime.start.p0(i64` 8, ptr %10) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 48: store double %5, ptr %10, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 49: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %f, ptr align 8 %10, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 50: call void `@llvm.lifetime.end.p0(i64` 8, ptr %10) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 51: call void `@llvm.lifetime.start.p0(i64` 8, ptr %9) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 52: store double %6, ptr %9, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 53: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %g, ptr align 8 %9, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 54: call void `@llvm.lifetime.end.p0(i64` 8, ptr %9) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 55: call void `@llvm.lifetime.start.p0(i64` 8, ptr %8) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 56: store double %7, ptr %8, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 57: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %h, ptr align 8 %8, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 58: call void `@llvm.lifetime.end.p0(i64` 8, ptr %8) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 59: ret void check:7'0 ~~~~~~~~~~ 60: } check:7'0 ~~ 61: check:7'0 ~ 62: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 63: define void `@f_double_s_arg(double` %0) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64: start: check:7'0 ~~~~~~~ 65: %1 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 66: %a = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 67: call void `@llvm.lifetime.start.p0(i64` 8, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68: store double %0, ptr %1, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 69: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %a, ptr align 8 %1, i64 8, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 70: call void `@llvm.lifetime.end.p0(i64` 8, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 71: ret void check:7'0 ~~~~~~~~~~ 72: } check:7'0 ~~ 73: check:7'0 ~ 74: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 75: define double `@f_ret_double_s()` unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 76: start: check:7'0 ~~~~~~~ 77: %_0 = alloca [8 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 78: store double 1.000000e+00, ptr %_0, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 79: %0 = load double, ptr %_0, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 80: ret double %0 check:7'0 ~~~~~~~~~~~~~~~ 81: } check:7'0 ~~ 82: check:7'0 ~ 83: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 84: define void `@f_double_double_s_arg({` double, double } %0) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 85: start: check:7'0 ~~~~~~~ 86: %1 = alloca [16 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 87: %a = alloca [16 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 88: call void `@llvm.lifetime.start.p0(i64` 16, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89: store { double, double } %0, ptr %1, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 90: call void `@llvm.memcpy.p0.p0.i64(ptr` align 8 %a, ptr align 8 %1, i64 16, i1 false) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 91: call void `@llvm.lifetime.end.p0(i64` 16, ptr %1) check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 92: ret void check:7'0 ~~~~~~~~~~ 93: } check:7'0 ~~ 94: check:7'0 ~ 95: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 96: define { double, double } `@f_ret_double_double_s()` unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 97: start: check:7'0 ~~~~~~~ 98: %0 = alloca [16 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 99: store double 1.000000e+00, ptr %0, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 100: %1 = getelementptr inbounds i8, ptr %0, i64 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 101: store double 2.000000e+00, ptr %1, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 102: %2 = load { double, double }, ptr %0, align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103: ret { double, double } %2 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 104: } check:7'0 ~~ 105: check:7'0 ~ 106: ; Function Attrs: uwtable check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 107: define void `@f_double_float_s_arg({` double, float } %0) unnamed_addr #0 { check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 108: start: check:7'0 ~~~~~~~ 109: %1 = alloca [12 x i8], align 8 check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . . . >>>>>> ------------------------------------------ failures: [codegen] tests/codegen/riscv-abi/call-llvm-intrinsics.rs [codegen] tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs [codegen] tests/codegen/riscv-abi/riscv64-lp64d-abi.rs test result: FAILED. 498 passed; 3 failed; 151 ignored; 0 measured; 0 filtered out; finished in 4.70s Some tests failed in compiletest suite=codegen mode=codegen host=x86_64-unknown-linux-gnu target=riscv64gc-unknown-linux-gnu Build completed unsuccessfully in 0:00:15 ``` </details>
scottmcm
pushed a commit
that referenced
this pull request
Jul 13, 2024
remove debug info from emitting
scottmcm
pushed a commit
that referenced
this pull request
Sep 10, 2024
better implementation of signed div_floor/ceil Tracking issue for signed `div_floor`/`div_ceil`: rust-lang#88581. This PR improves the implementation of those two functions by adding a better branchless algorithm. Side-by-side comparison of `i32::div_floor` on x86-64: ```asm div_floor_new: div_floor_old: push rax push rax test esi, esi test esi, esi je .LBB0_3 je .LBB1_6 mov eax, esi mov eax, esi not eax not eax lea ecx, [rdi - 2147483648] lea ecx, [rdi - 2147483648] or ecx, eax or ecx, eax je .LBB0_2 je .LBB1_7 mov eax, edi mov eax, edi cdq cdq idiv esi idiv esi xor esi, edi test edx, edx sar esi, 31 setg cl test edx, edx test esi, esi cmove esi, edx sets dil add eax, esi test dil, cl pop rcx jne .LBB1_4 ret test edx, edx .LBB0_3: setns cl lea rdi, [rip + .L__unnamed_1] test esi, esi call qword ptr [rip + panic...] setle dl .LBB0_2: or dl, cl lea rdi, [rip + .L__unnamed_1] jne .LBB1_5 call qword ptr [rip + panic...] .LBB1_4: dec eax .LBB1_5: pop rcx ret .LBB1_6: lea rdi, [rip + .L__unnamed_2] call qword ptr [rip + panic...] .LBB1_7: lea rdi, [rip + .L__unnamed_2] call qword ptr [rip + panic...] ``` And on Aarch64: ```asm _div_floor_new: _div_floor_old: stp x29, x30, [sp, #-16]! stp x29, x30, [sp, #-16]! mov x29, sp mov x29, sp cbz w1, LBB0_4 cbz w1, LBB1_9 mov w8, #-2147483648 mov x8, x0 cmp w0, w8 mov w9, #-2147483648 b.ne LBB0_3 cmp w0, w9 cmn w1, #1 b.ne LBB1_3 b.eq LBB0_5 cmn w1, #1 LBB0_3: b.eq LBB1_10 sdiv w8, w0, w1 LBB1_3: msub w9, w8, w1, w0 sdiv w0, w8, w1 eor w10, w1, w0 msub w8, w0, w1, w8 asr w10, w10, rust-lang#31 tbz w1, rust-lang#31, LBB1_5 cmp w9, #0 cmp w8, #0 csel w9, wzr, w10, eq b.gt LBB1_7 add w0, w9, w8 LBB1_5: ldp x29, x30, [sp], rust-lang#16 cmp w1, #1 ret b.lt LBB1_8 LBB0_4: tbz w8, rust-lang#31, LBB1_8 adrp x0, l___unnamed_1@PAGE LBB1_7: add x0, x0, l___unnamed_1@PAGEOFF sub w0, w0, #1 bl panic... LBB1_8: LBB0_5: ldp x29, x30, [sp], rust-lang#16 adrp x0, l___unnamed_1@PAGE ret add x0, x0, l___unnamed_1@PAGEOFF LBB1_9: bl panic... adrp x0, l___unnamed_2@PAGE add x0, x0, l___unnamed_2@PAGEOFF bl panic... LBB1_10: adrp x0, l___unnamed_2@PAGE add x0, x0, l___unnamed_2@PAGEOFF bl panic... ```
scottmcm
pushed a commit
that referenced
this pull request
Nov 11, 2024
The failure output is: ``` SplitVectorOperand Op #1: t51: i32 = llvm.wasm.alltrue TargetConstant:i32<12408>, t50 rustc-LLVM ERROR: Do not know how to split this operator's operand! ```
scottmcm
pushed a commit
that referenced
this pull request
Dec 14, 2024
we get these declarations ``` ; opt level 0 declare x86_intrcc void @page_fault_handler(ptr byval([8 x i8]) align 8, i64) unnamed_addr #1 ; opt level > 0 declare x86_intrcc void @page_fault_handler(ptr noalias nocapture noundef byval([8 x i8]) align 8 dereferenceable(8), i64 noundef) unnamed_addr #1 ``` The space after `i64` in the original regex made the regex not match for opt level 0. Removing the space fixes the issue. ``` declare x86_intrcc void @page_fault_handler(ptr {{.*}}, i64 {{.*}}){{.*}}#[[ATTRS:[0-9]+]] ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Couldn't leave a suggestion cause GitHub wouldn't let me... so I made a PR instead. :)