Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

LLVM ERROR: Unsupported expression in static initializer (On macOS) #89225

Open
plzin opened this issue Sep 24, 2021 · 5 comments
Open

LLVM ERROR: Unsupported expression in static initializer (On macOS) #89225

plzin opened this issue Sep 24, 2021 · 5 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@plzin
Copy link

plzin commented Sep 24, 2021

rustc seems to generate invalid/unsupported LLVM IR on macOS for release builds.
Linux and debug builds seem to be unaffected.

Code

#[allow(dead_code)] // There are warnings because some of RugInt's members are never accessed.

// This represents the arbitrary precision Integer type from the rug crate.
struct RugInt {
    pub m: i32,
    pub n: i32,
    pub o: *const i32,
}

impl RugInt {
    // Integer::new in the rug crate.
    pub const fn new() -> Self {
        const VALUE_REF: &i32 = &0x1D1E_6010;
        Self {
            m: 0,
            n: 0,
            o: VALUE_REF as *const i32,
        }
    }
}

fn main() {
    unsafe {
        // Allocate memory for an array of 32 RugInts.
        let n = 32;
        let layout = std::alloc::Layout::array::<RugInt>(n).unwrap();
        let ptr = std::alloc::alloc(layout) as *mut RugInt;

        // Initialize the array with empty RugInts.
        for i in 0..n {
            ptr.add(i).write(RugInt::new());
        }

        // Don't let the compiler remove the code by printing a value in the array.
        println!("{}", (*ptr).m);
    }
}

Meta

This issue occurs on the stable version
rustc --version --verbose:

rustc 1.55.0 (c8dfcfe04 2021-09-06)
binary: rustc
commit-hash: c8dfcfe046a7680554bf4eb612bad840e7631c4b
commit-date: 2021-09-06
host: x86_64-apple-darwin
release: 1.55.0
LLVM version: 12.0.1

as well as the most recent nightly version:

rustc 1.57.0-nightly (2b862bed9 2021-09-23)
binary: rustc
commit-hash: 2b862bed9889808b69629fd7246317189b9517a5
commit-date: 2021-09-23
host: x86_64-apple-darwin
release: 1.57.0-nightly
LLVM version: 13.0.0

Error output

cargo build --release

   Compiling bug v0.1.0 (/path/bug)
LLVM ERROR: Unsupported expression in static initializer: zext (i64 ptrtoint (<{ [4 x i8] }>* @alloc3 to i64) to i128)
error: could not compile `bug`

Initial investigation

By running cargo rustc --release -- --emit=llvm-ir to emit the LLVM, I could narrow the issue down a bit.
The faulty initializer belongs to a constant called @.memset_pattern:

@.memset_pattern = private unnamed_addr constant i128 zext (i64 ptrtoint (<{ [4 x i8] }>* @alloc3 to i64) to i128), align 16

This constant is used inside the main function in a call to memset_pattern16

call void @memset_pattern16(i8* %0, i8* bitcast (i128* @.memset_pattern to i8*), i64 512)

This function is (as far as I know) not available on Linux which explains why the bug doesn't occur on Linux.
This function seems to replace the initialization loop in the code above which explains why the bug doesn't occur on debug builds.
The optimization seems to be very sensitive: When I removed the second member in the struct, the code compiles, because the compiler unrolls the loop instead of calling memset_pattern16.

@hkratz
Copy link
Contributor

hkratz commented Sep 25, 2021

@rustbot label +I-ICE +A-llvm +O-macos +E-needs-bisection

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc O-macos Operating system: macOS I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Sep 25, 2021
@hkratz
Copy link
Contributor

hkratz commented Sep 25, 2021

Reproduces on aarch64-apple-darwin as well. Could not find a version which does not reproduce this issue.

@rustbot label -E-needs-bisection +A-codegen

@rustbot rustbot added A-codegen Area: Code generation and removed E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc labels Sep 25, 2021
@nagisa
Copy link
Member

nagisa commented Sep 25, 2021

rustc seems to generate invalid/unsupported LLVM IR

rustc does not emit memset_pattern16. Must be a LLVM optimization of some sort.

@nagisa nagisa removed the A-codegen Area: Code generation label Sep 25, 2021
@hkratz
Copy link
Contributor

hkratz commented Sep 25, 2021

I think it is done by the Loop Idiom Recognition optimization pass.

@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
@madsmtm
Copy link
Contributor

madsmtm commented Oct 10, 2024

Triage: Bisection shows that this has been fixed since nightly-2022-03-05.

Details

fetching https://static.rust-lang.org/dist/2022-03-04/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2022-03-04: 40 B / 40 B [=========================================================================================] 100.00 % 483.75 KB/s converted 2022-03-04 to 10913c0
fetching https://static.rust-lang.org/dist/2022-03-05/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2022-03-05: 40 B / 40 B [=========================================================================================] 100.00 % 314.07 KB/s converted 2022-03-05 to 9fcbc32
looking for regression commit between 2022-03-04 and 2022-03-05
fetching (via remote github) commits from max(10913c0, 2022-03-02) to 9fcbc32
ending github query because we found starting sha: 10913c0
get_commits_between returning commits, len: 10
commit[0] 2022-03-03: Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids, r=wesleywiser
commit[1] 2022-03-03: Auto merge of #94571 - matthiaskrgr:rollup-4ul5ydb, r=matthiaskrgr
commit[2] 2022-03-04: Auto merge of #94009 - compiler-errors:gat-rustdoc, r=GuillaumeGomez
commit[3] 2022-03-04: Auto merge of #94588 - Dylan-DPC:rollup-7pxd0i3, r=Dylan-DPC
commit[4] 2022-03-04: Auto merge of #94096 - cjgillot:ensure-stability, r=lcnr
commit[5] 2022-03-04: Auto merge of #94159 - erikdesjardins:align-load, r=nikic
commit[6] 2022-03-04: Auto merge of #94539 - tmiasko:string-attributes, r=nikic
commit[7] 2022-03-04: Auto merge of #94570 - shampoofactory:reopen-91719, r=workingjubilee
commit[8] 2022-03-04: Auto merge of #94612 - matthiaskrgr:rollup-2jm5wkr, r=matthiaskrgr
commit[9] 2022-03-04: Auto merge of #94494 - jonhoo:bump-autocfg, r=Mark-Simulacrum

@rustbot label E-needs-test

@rustbot rustbot added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants