More testing

[bjorn3]

• Run https://github.com/dropbox/rust-brotli-decompressor
• Run https://github.com/Peltoche/lsd (hashbrown assertion failure due to Constants not correctly aligned #348, because debug assertions are disabled works as of a24a956)
• Run https://github.com/sitkevij/hex.git
• Run https://github.com/sharkdp/hexyl (works when patching ctrl+c handler, which uses threads, away (TLS support #784))
• Run https://github.com/ogham/exa (requires threads (TLS support #784))
• Test https://github.com/rust-lang/regex (requires cpuid intrinsic (faked no cpuid support by cpu) and simd (implemented enough in Simd emulation #650))
• Run https://github.com/mohanson/gameboy
• Run https://github.com/ozkriff/zemeroth (blocked on Support #[rustc_args_required_const(...)] for simd intrinsics #666, requires threads)
• Run https://gitlab.com/veloren/veloren (requires threads (TLS support #784), kind of works, but too slow to be usable)
• Run https://github.com/ozkriff/zoc
• Run https://github.com/gchp/iota
• Test https://github.com/BurntSushi/fst
• Run https://github.com/dalance/procs (requires saturating_{add,sub} for signed integers (3fcd540))
• Run https://github.com/nical/lyon examples (requires saturating_{add,sub} for signed integers (3fcd540), all but the wgpu examples tested, my graphics driver doesn't have vulkan/metal/dx* support)
• Run more applications

[bjorn3]

Does anybody know of a rust program which doesn't use threads? I want to test compiling it using cg_clif.

[memoryruins]

• simple-raytracer https://github.com/ebobby/simple-raytracer
• svgbob https://github.com/ivanceras/svgbob
• svgcleaner https://github.com/RazrFalcon/svgcleaner
• bat https://github.com/sharkdp/bat
• fd https://github.com/sharkdp/fd (only creates a job server if a flag is passed)
• fselect https://github.com/jhspetersson/fselect
• encrusted https://github.com/DeMille/encrusted
• termpix https://github.com/hopey-dishwasher/termpix

(on mobile and unable to confirm if all of these don't use threads)

[bjorn3]

Thanks @memoryruins! Will try them.

[bjorn3]

• https://github.com/ebobby/simple-raytracer (blocked on Support cast between u/i128 and float #668)
• https://github.com/ivanceras/svgbob (requires removal of #![deny(warnings)])
• https://github.com/RazrFalcon/svgcleaner (blocked on Support cast between u/i128 and float #668)
• https://github.com/sharkdp/bat
• https://github.com/sharkdp/fd (requires threads, even with -j 1 (TLS support #784))
• https://github.com/jhspetersson/fselect
• https://github.com/DeMille/encrusted (requires --bin encrusted)
• https://github.com/hopey-dishwasher/termpix (blocked on Support cast between u/i128 and float #668, requires threads (TLS support #784))

[bjorn3]

@memoryruins Got all but the thread requiring programs working 🎉

[jyn514]

https://crates.io/crates/c2-chacha doesn't compile (used in rand): error: at fn core::core_arch[0]::x86_64[0]::sse41[0]::_mm_insert_epi64[0]: unsupported intrinsic simd_insert

I also got warning: err opening clif file: Os { code: 36, kind: Other, message: "File name too long" }, not sure if that affects the build.

Everything else for https://github.com/jyn514/rcc works well, great work!

[jyn514]

Other misc projects:

• https://github.com/hsivonen/encoding_rs (used in reqwest)

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `2816`,
 right: `0`: faerie doesn't support addends in data section relocations yet', /home/joshua/.cargo/git/checkouts/cranelift-af8713b52459e6cd/01201b1/cranelift-faerie/src/backend.rs:245:13

Edit(@bjorn3): working as of 83f6ef1

[bjorn3]

Thanks for testing.

https://crates.io/crates/c2-chacha doesn't compile (used in rand): error: at fn core::core_arch[0]::x86_64[0]::sse41[0]::_mm_insert_epi64[0]: unsupported intrinsic simd_insert

That is https://github.com/bjorn3/rustc_codegen_cranelift/issues/669. You can edit the Cargo.toml of c2-chacha to not passthrough the simd feature to one of its dependencies as workaround.

I also got warning: err opening clif file: Os { code: 36, kind: Other, message: "File name too long" }, not sure if that affects the build.

No it doesnt. In debug mode cg_clif tries to write the clif ir of every compiled function to target/out/clif in the source dir for cg_clif. If the filename is too big, it just ignores it. You can build cg_clif in release mode to prevent writing of clif ir. That also makes it a lot faster. You will need to set the CHANNEL env var to release for cargo.sh to use the release build.

https://github.com/hsivonen/encoding_rs (used in reqwest)

Known issue. faerie (the object file writer) doesnt implement something.

[bjorn3]

• Run https://github.com/BurntSushi/ripgrep (blocked on Implement addends in data section relocations m4b/faerie#71, requires threads (TLS support #784))
• Run https://github.com/m4b/bingrep
• Run https://github.com/gahag/bgrep (release mode doesn't link: https://github.com/bjorn3/rustc_codegen_cranelift/issues/746)

[jyn514]

bingrep works on my machine, not sure what error it's giving on yours.

$ uname -a
Linux joshua-ThinkPad 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[bjorn3]

I hadnt tested any of them yet. Thanks for testing bingrep though.

[jyn514]

ripgrep fails with the same faerie error about addends in relocations. bgrep gives a whole bunch of 'undefined reference' errors at link time:

Compiling bgrep v1.0.0
[codegen mono items] start
[codegen mono items] end time: 6.034330509s
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/joshua/src/rust/rustc_codegen_cranelift/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/cargo-installgCjZJh/x86_64-unknown-linux-gnu/release/deps/bgrep-95e1d2faa1ae6220.some_file.o.rcgu.o" "-o" "/tmp/cargo-installgCjZJh/x86_64-unknown-linux-gnu/release/deps/bgrep-95e1d2faa1ae6220" "/tmp/cargo-installgCjZJh/x86_64-unknown-linux-gnu/release/deps/bgrep-95e1d2faa1ae6220.allocator_shim.o.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/tmp/cargo-installgCjZJh/x86_64-unknown-linux-gnu/release/deps" "-L" "/tmp/cargo-installgCjZJh/release/deps" "-L" "/home/joshua/src/rust/rustc_codegen_cranelift/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/tmp/rustcwOjofE/libbacktrace_sys-6dbde68fbe8a4381.rlib" "-Wl,--end-group" "/home/joshua/Documents/Programming/rust/rustc_codegen_cranelift/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-247a06f7027ddb1d.rlib" "-Wl,-Bdynamic" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /usr/local/bin/ld: /tmp/cargo-installgCjZJh/x86_64-unknown-linux-gnu/release/deps/bgrep-95e1d2faa1ae6220.some_file.o.rcgu.o: in function `core::option::Option<T>::unwrap':
          /home/joshua/Documents/Programming/rust/rustc_codegen_cranelift/build_sysroot/sysroot_src/src/libcore/macros.rs:12: undefined reference to `core::panicking::panic'
... truncated ...
/usr/local/bin/ld: /tmp/cargo-installgCjZJh/x86_64-unknown-linux-gnu/release/deps/bgrep-95e1d2faa1ae6220.allocator_shim.o.rcgu.o: in function `__rust_alloc_zeroed':
          allocator_shim.o:(.text.__rust_alloc_zeroed+0x6): undefined reference to `__rdl_alloc_zeroed'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: failed to compile `bgrep v1.0.0`, intermediate artifacts can be found at `/tmp/cargo-installgCjZJh

[bjorn3]

I can't reproduce the bgrep link error. It compiles and runs fine for me with rustc 1.40.0-nightly (2748a9fd9 2019-10-08):

$ ../cargo.sh run -- -b bgrep target/x86_64-unknown-linux-gnu/debug/bgrep
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/x86_64-unknown-linux-gnu/debug/bgrep -ob bgrep target/x86_64-unknown-linux-gnu/debug/bgrep -h`
0x632be3
0x632c0d
0x632c7b
0x632ca5
[...]

[jyn514]

Not sure what the issue is, it happens every time for me. I even tried rebuilding rustc_codegen_cranelift in release mode. Strange that it's only bgrep and not anything else.

I'm running ./cargo.sh install bgrep.

[bjorn3]

I am able to reproduce it by building bgrep in release mode. I will see if I can fix it.

For now you could use ./cargo.sh install --debug bgrep. cg_clif doesn't perform any extra optimizations in release mode anyway to workaround https://github.com/CraneStation/cranelift/issues/732.

[jyn514]

Yup installing in debug mode made it work.

[bjorn3]

Opened https://github.com/bjorn3/rustc_codegen_cranelift/issues/746 for this.

[bjorn3]

• https://github.com/leod/rendology (at least on the thread branch)

[bjorn3]

Pretty much all applications mentioned here now work. Only zemeroth doesn't work yet, because of some trouble with c2-chacha patching.

[bjorn3]

Going to close this as I don't think I have seen a misconpilation in quite a while. Pretty much all programs cg_clif can't compile right now are due to missing features rather than bugs in cg_clif. If anyone finds a program cg_clif can't handle please do report it as a new issue.