Skip to content

Miscompilation with LLVM 10 and 11 with codegen-units=1 #90153

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
ehuss opened this issue Oct 22, 2021 · 3 comments
Closed

Miscompilation with LLVM 10 and 11 with codegen-units=1 #90153

ehuss opened this issue Oct 22, 2021 · 3 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug.
Milestone

Comments

@ehuss
Copy link
Contributor

ehuss commented Oct 22, 2021

As part of the bootstrap bump in #90042, we are running into an issue where the x86_64-gnu-llvm-10 CI test is failing due to some miscompilation of some code.

The bump in the bootstrap brings in a change in cargo where tests now inherit profile settings from the dev/release profiles. The standard library tests are now being built with codegen-units=1 due to this. This has unearthed a miscompilation with llvm-10. In my tests, llvm-11 also seems to have the same problem, but llvm-12 seems to work correctly.

The test that seems to be failing is test_copy_within. Somehow the optimizations are causing it to compile down to an unconditional call to the first assert_eq being a failure.

This can be reproduced on latest master with llvm-10-dev installed on Ubuntu 20:

# llvm-10 is installed with `apt install llvm-10-dev`
# Also fails with llvm-11, but not llvm-12
./configure --llvm-root=/usr/lib/llvm-10 --enable-llvm-link-shared
./x.py build library/std

cat <<EOF >> foo.rs
fn main() {
    let mut bytes = *b"Hello, World!";
    bytes.copy_within(..3, 10);
    assert_eq!(&bytes, b"Hello, WorHel");
}
EOF

./build/x86_64-unknown-linux-gnu/stage1/bin/rustc foo.rs -Copt-level=3 -Ccodegen-units=1
./foo
@ehuss ehuss added the C-bug Category: This is a bug. label Oct 22, 2021
@Mark-Simulacrum Mark-Simulacrum added this to the 1.57.0 milestone Oct 22, 2021
@ehuss
Copy link
Contributor Author

ehuss commented Oct 22, 2021

One option is to disable codegen-units=1 for that builder only, would could be roughly something like this:

diff --git a/src/ci/docker/host-x86_64/x86_64-gnu-llvm-10/Dockerfile b/src/ci/docker/host-x86_64/x86_64-gnu-llvm-10/Dockerfile
index c34198708c4..e5143930270 100644
--- a/src/ci/docker/host-x86_64/x86_64-gnu-llvm-10/Dockerfile
+++ b/src/ci/docker/host-x86_64/x86_64-gnu-llvm-10/Dockerfile
@@ -32,6 +32,10 @@ ENV RUST_CONFIGURE_ARGS \
       --enable-llvm-link-shared \
       --set rust.thin-lto-import-instr-limit=10

+# Due to a miscompilation with codegen-units=1 with llvm-10 and 11, switch to
+# the default here. This can be removed when updating to llvm-12.
+ENV DEFAULT_STD_CGU=1
+
 ENV SCRIPT python2.7 ../x.py --stage 2 test --exclude src/tools/tidy && \
            # Run the `mir-opt` tests again but this time for a 32-bit target.
            # This enforces that tests using `// EMIT_MIR_FOR_EACH_BIT_WIDTH` have
diff --git a/src/ci/run.sh b/src/ci/run.sh
index b5019d83af4..e5256e32b71 100755
--- a/src/ci/run.sh
+++ b/src/ci/run.sh
@@ -51,7 +51,9 @@ RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-sccache"
 RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --disable-manage-submodules"
 RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-locked-deps"
 RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-cargo-native-static"
-RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --set rust.codegen-units-std=1"
+if [ "$DEFAULT_STD_CGU" = ""]; then
+  RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --set rust.codegen-units-std=1"
+fi

 # Only produce xz tarballs on CI. gz tarballs will be generated by the release
 # process by recompressing the existing xz ones. This decreases the storage

@cuviper cuviper added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Oct 22, 2021
@nagisa
Copy link
Member

nagisa commented Oct 24, 2021

LLVM 12 is the minimum supported version now, so this is resolved?

@Mark-Simulacrum
Copy link
Member

Yeah, I think so -- closing.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

4 participants