Skip to content

miscompilation with incremental + unpacked debug + macos  #108216

Open
@ehuss

Description

@ehuss

The following script illustrates a miscompilation on macOS when using incremental and unpacked debug:

I tried this code:

#!/bin/bash 

rm -rf *.o incremental foo

echo "fn main() { let a: i64 = 1 << 64; }" > foo1.rs
echo "fn main() { let a: i64 = 1 << 63; }" > foo2.rs

ARGS="--crate-name foo -C split-debuginfo=unpacked -C debuginfo=2 -C incremental=incremental"

for i in {1..20}
do
    rustc foo1.rs $ARGS && { echo "ERROR: first build should have failed"; exit 1; }
    rustc foo2.rs $ARGS || { echo "ERROR: second build should have passed"; exit 1; }
    ./foo || { echo "ERROR: executing should have passed"; exit 1; }
done

The first compilation should fail due to the overflow error:

error: this arithmetic operation will overflow
 --> src/main.rs:1:26
  |
1 | fn main() { let a: i64 = 1 << 64; }
  |                          ^^^^^^^ attempt to shift left by `64_i32`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

The second compilation should succeed since the overflow has been removed.
Then executing the binary should pass, since there is no overflow.

Instead, this happened:

Sometimes executing the binary will fail, as-if it compiled with the incorrect constant value:

thread 'main' panicked at 'attempt to shift left with overflow', foo1.rs:1:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
ERROR: executing should have passed

This doesn't happen always, although it usually happens right away (thus the reason for the loop in the script).

Testing on macOS 13.2 aarch64 and macOS 12.6.3 x86_64 with either Xcode 14 or 13.

I couldn't get it to fail on Linux.

Bisection

This appears to be a regression introduced in #87337. Presumably because before that it wouldn't write any .o files (or write anything to the incremental db) due to the error. Strangely, I cannot get it to fail with #![allow(arithmetic_overflow)], and I don't really have a theory as to why.

Metadata

Metadata

Assignees

Labels

A-incr-compArea: Incremental compilationC-bugCategory: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessO-macosOperating system: macOSP-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions