Rust: 안전한 Rust의 메모리 안전 문제

cc @ rust-lang / 컴파일러
@rustbot 핑 icebreakers-llvm

릴리스 팀은 Rust 1.41 (지난 주 회의에서 간략하게 논의)에 대한 포인트 릴리스를 고려하고 있으며, 곧 PR을 얻을 수 있다면이 내용이 포함되기를 바랍니다.

안녕하세요 LLVM ICE-breakers! 이 버그는 좋은 것으로 확인되었습니다
"LLVM ICE-breaking 후보". 유용한 경우 여기에 몇 가지
이러한 종류의 버그를 해결하기위한 [지침]. 한 번 보시겠습니까?
감사! <3

cc @comex @DutchGhost @ hanna-kruppe @hdhoang @heyrutvik @ JOE1994 @jryans @mmilenko @nagisa @nikic @ Noah-Kennedy @SiavoshZarrasvand @spastorino @vertexclique @vgxbj

안정적인 1.41.0 릴리스를 사용하여 cargo run --release로 실행하면 다음과 같은 결과가 출력됩니다 (macOS 10.15 및 Ubuntu 19.10에서 테스트 됨).

나는 이것을 놀이터에서 재현 할 수 없다 . 이 프로그램은 릴리스 모드의 1.41.0에서 잘 작동합니다.

편집 : 아, 당신은 이미 그렇게 말했습니다.
또한 프로그램은 Miri에서 괜찮으므로 UB가 아니라 잘못된 컴파일 일 가능성이 높습니다.

데이터 포인트를 추가하기 위해 Linux에서 최신 야간으로이를 재현 할 수 있습니다.

[andrew<strong i="6">@krusty</strong> rust-69225]$ rustc --version
rustc 1.43.0-nightly (5e7af4669 2020-02-16)

[andrew<strong i="7">@krusty</strong> rust-69225]$ cat main.rs
fn do_test(x: usize) {
    let arr = vec![vec![0u8; 3]];

    let mut z = Vec::new();
    for arr_ref in arr {
        for y in 0..x {
            for _ in 0..1 {
                z.extend(std::iter::repeat(0).take(x));
                let a = y * x;
                let b = (y + 1) * x - 1;
                let slice = &arr_ref[a..b];
                eprintln!("{} {} {} {}", a, b, arr_ref.len(), slice.len());
                eprintln!("{:?}", slice[1 << 24]);
            }
        }
    }
}

fn main() {
    do_test(1);
    do_test(2);
}

[andrew<strong i="8">@krusty</strong> rust-69225]$ rustc -C opt-level=3 main.rs

[andrew<strong i="9">@krusty</strong> rust-69225]$ ./main
0 0 3 18446744073709551615
zsh: segmentation fault (core dumped)  ./main

Rust 1.41 안정에서 똑같은 출력으로 위의 내용을 재현 할 수있었습니다. Rust 1.40 stable에는 문제가 없습니다.

$ ./main
0 0 3 0
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 16777216', main.rs:13:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

나는 이것이 적어도 macOS 특정이 아님을 확인하는 것을 제외하고는 모두 @dfyz 의 보고서와 일치한다고 생각합니다.

• cargo-bisect-rustc 는 회귀가 2019-12-12 야간에, 특히이 커밋에서 처음 발생했다고 말합니다. 문제를 나타내지 않는 1.40.0 가이 날짜 이후에 출시 되었기 때문에 이것은 나에게 의심스러워 보입니다.

이것은 예상됩니다. 1.40.0이되었다 2019년 12월 19일에 발표 한 후 무엇을 기준으로 beta 에서 분기 된 지점, master 육주 이전합니다 (1.39.0 릴리스 시간 정도). 릴리스 채널에 대한 자세한 내용은 https://doc.rust-lang.org/book/appendix-07-nightly-rust.html 을 참조

추측해야한다면 https://github.com/rust-lang/rust/pull/67015 가 범인이라고 말할 수
Cc @ osa1 @ oli-obk @wesleywiser

핑 감사합니다. 현재 조사를 위해 빌드를 만들고 있습니다. # 67015에서 도입 된 버그 일 수 있습니다. 또 다른 가능성은 # 67015가 방금 기존 버그를 공개했다는 것입니다.

Linux에서 nightly rustc를 사용하여 segfault를 재현했지만이 config.toml로 생성 된 빌드로는 만들지 못했습니다.

[llvm]

[build]

[install]

[rust]
optimize = true
debug = true
codegen-units = 0
debug-assertions = true
debuginfo-level = 2

[target.x86_64-unknown-linux-gnu]
llvm-config = "/usr/bin/llvm-config-9"

[dist]

033662dfbca088937b9cdfd3d9584015b5e375b2의 회귀

@rustbot 라벨 수정 : -E-needs-bisection

@ osa1 debug-assertions = true 은 아마도 비난받을 것입니다. -C debug-assertions=y 로 프로그램을 컴파일하려고하면 (바닐라 야간 컴파일러로) segfault 대신 프로그램 패닉이 발생합니다.

나는 그것을 해결했다고 생각한다! a983e0590a43ed8b0f60417828efd4e79b51f494를 되 돌리면 문제가 해결됩니다. 하루 종일 저에게 범인처럼 보였지만 직장에서 테스트 할 수 없었습니다. :) 누군가가이 문제에 대한 PR을 가장 잘 만드는 방법을 도와 줄 수 있습니까? 가장 좋은 방법은 실패해야하는 테스트 케이스를 추가하는 것이라고 생각하지만 이것은 매우 플랫폼에 특화된 것 같습니다. 그래서 결국 좋은 생각이 아닐까요? 여기에 어떤 아이디어가 있습니까? 감사!

(이것은 이미 OP에 의해 양분되었습니다)

debug-assertions 을 끈 상태에서 로컬 빌드로 이것을 재현했습니다 (@ hellow554에 감사드립니다).

롤업의 일부 PR은 그 이후로 모든 것을 rustfmt -ed했기 때문에 되돌릴 때 충돌을 일으키지 만이 문제는 # 67174 때문이라고 생각합니다.

편집 : 우리가 동시에 @shahn을 찾은 것 같습니다 :)

@lqd 예, 이것은 위에서 참조한 커밋을 포함하는 문제입니다. 그것이 범인입니다.

경우 다른 데이터 포인트를 추가하기 위해, 문제가 사라질 codegen-units 이하 (함께 방출 프로파일을 가정 또는 3으로 설정되어 incremental=false ). 즉, codegen-units 가 4 이상일 때 재현 할 수 있습니다.

panic_bounds_check 대한 호출은 LLVM 점프 스레딩 통과 후 사라집니다. LLVM 9에서 opt를 사용하여 문제를 재현 할 수 있지만 LLVM 10에서는 그렇지 않습니다.

그래서 저는 1 단계 rustc ( ./x.py build -i --stage 1 )를 체크 아웃하고 빌드하고, # 67174없이 libstd ( ./x.py build -i --stage 1 --keep-stage 0 src/libstd )를 다시 빌드하고, 다음과 같이 segfaulting 프로그램을 다시 컴파일했습니다. 4 개의 codegen 단위 ( rustc +stage1 -C opt-level=3 -C codegen-units=4 main.rs ). 예상대로 이로 인해 segfault가 사라졌습니다. # 67174를 다시 적용하면 segfault가 반환됩니다.

이것은 이제 그들이 사용하는 표준 라이브러리에서만 다른 두 개의 컴파일러가 있음을 의미합니다. 이 컴파일러를 GOOD (segfault 없음) 및 BAD (segfault)라고합시다.

나는 그 발견이 4 _unoptimized_ *.ll 에 의해 생성 된 파일 GOOD ( -C no-prepopulate-passes ) 꽤 많이 있습니다에 의해 생성 된 것과 같은 BAD (유일한 차이점 함수 이름에 다른 임의의 ID가있는 것을 보았습니다. 그러나 _optimized_ *.ll 파일 ( -C no-prepopulate-passes 아님)은 크게 다릅니다. 나는 어떤 식 으로든 컴파일러 전문가는 아니지만 컴파일되는 프로그램이 두 경우 모두 똑같기 때문에 두 컴파일러 모두 똑같고 유일한 차이점은 미리 컴파일 된 표준 라이브러리에 있다는 것입니다. I _think_ LTO가 관련 될 수 있습니다. .

실제로 -Z thinlto=no , -C lto=no , -C lto=yes , -C lto=thin 중 하나를 통과하면 (이 시점에서는 확실하지 않지만 모든 양식을 -C lto 의 BAD , segfault가 다시 한 번 사라집니다.

여기서 LTO가 잘못되었을 가능성이 있습니까?

테스트 케이스를 읽었습니다. 되 돌리는 커밋을 읽었습니다. 나는 아직도 무슨 일이 일어나고 있는지에 대해 가장 안개가 낀다. 무엇이 고장 났습니까?

무엇이 고장 났습니까?

나는이 시점에서 누구도 정확히 무엇이 고장 났는지 확실히 말할 수 있다고 생각하지 않지만, 내 잠정적 인 분석은 이것입니다. (다음을 소금으로 가져 가십시오. 저는 Rust 팀이나 LLVM 팀에 속해 있지 않습니다. 컴파일러를 조작하고 LLVM IR을 응시하는 것입니다.)

• 표준 라이브러리에서 Layout::repeat() 의 한 줄 에서 오버플로 검사를 제거하여 결국이 메모리가 안전하지 않게되었습니다. 수학적으로 여기에 체크하지 않은 덧셈을 사용하는 것은 완벽하게 안전해야합니다.이 함수 (및 Layout::pad_to_align() )의 주석이 이유를 설명합니다.
• 문제를 보여주는 내 코드 샘플은이 함수를 호출하지도 않지만 명시 적으로 Vec 를 사용합니다. Vec::reserve_internal() 를 암시 적으로 사용하고 차례로 Layout::repeat() 호출합니다 .
• Layout::repeat() 는 #[inline] 로 표시되며 GOOD 와 BAD 사이의 유일한 관련 차이점은이 함수가 do_test() 인라인되는지 여부입니다. 아니. 예를 들어, 오버플로 검사를 복원하면 인라인이 금지되고 문제가 해결됩니다. #[inline] 속성을 제거하면 동일한 효과가 발생합니다. LTO를 비활성화하면 라이브러리 기능에 대한 인라인이 비활성화되고 문제가 다시 수정됩니다.

이것이 사실이라면 (다시 말씀 드리지만, 위 사항에 대해 100 % 확신하지 못합니다) 이는 일부 불량 LLVM 통과 또는 통과 조합이 인라인 후 IR을 잘못 최적화한다는 것을 의미합니다. 이것이 제가 현재 조사하려고하는 것입니다.하지만 슬프게도 GOOD 와 BAD 사이의 IR 차이가 적당하기 때문에 (적어도 저와 같은 비 LLVM-ICE-breaker에게는) 쉽지 않습니다. 큰. 잘못된 버전이 panic_bounds_check 생략 한 것처럼 보이지만 여전히 그 이유를 정확히 모르겠습니다.

또한 @tmiasko 의 의견에서 영감을 받아 다른 LLVM 버전으로 rustc를 컴파일하려고했는데 LLVM 10rc1이 문제를 해결하는 것처럼 보입니다 (내가 시도한 최신 결함 LLVM 버전은 9.0.1입니다). 9.0.1과 10rc1 사이에 관련 커밋이 보이지 않기 때문에 Jump Threading 패스가 비난받을 것 같지 않습니다.

Layout::repeat() 변경 사항을 되 돌리는 것이 관련없는 버그의 특정 발생

Layout :: repeat () 변경을 되 돌리는 것이 관련되지 않은 버그의 특정 발생 한 가지 증상 만 숨기는 경우 되 돌리는 것이 정말 올바른 일입니까?

다음과 같은 경우 괜찮을 수 있다고 생각합니다.

• 변경 사항이 배송됩니다.
• 버그를 훨씬 더 쉽게 트리거하여 많은 사용자에게 영향을줍니다.
• 제대로 고치는 데 시간이 오래 걸립니다.

이것이 보류되면 변경 사항을 되돌리고 사용자 차단을 해제하기 위해 부 릴리스를 제공 한 다음 (버그가 여전히 존재하더라도 변경 사항없이 잘 작동 함) 실제 버그에 집중합니다.

다른 컴파일러에서 나는 실제로 이것을 한 것을 기억합니다. 릴리스 브랜치의 변경 사항을 되돌 렸지만 마스터가 아닌 (좋은 방법이 아니며 나중에 문제가 발생 함) 새로운 마이너 릴리스를 출시했습니다. 그런 다음 실제 버그를 수정했습니다.

어쨌든 버그의 우선 순위가 지정되고 수정되고 버그를 훨씬 쉽게 트리거하는 커밋이 버그 수정 자체가 아니라면 지금은 버그를 되 돌리는 데 아무런 문제가 없습니다.

그래서 질문은,이 버그가 정말 트리거하기 쉬운가요? 지금까지 더 최소화하려는 시도 (예 : 겉보기에 사소한 for _ in 0..1 루프 풀기)가 재현되지 않는 다소 관련된 테스트 케이스가 포함 된 보고서가 있습니다.

나는 버그가 유발하기 쉽지 않다고 생각합니다. 특히 불행한 것 같습니다.

어쨌든 @shahn 이 Layout::new() 변경 사항을 되돌리기 위해 겪은 수고에 대해 정말 감사하지만 IMO에서 되 돌리는 것은이 경우에 옳은 일이 아닙니다. 내 추론 ( @SimonSapin이 말한 것

• Layout::repeat() 에서 오버플로 검사를 제거하면 LLVM이 릴리스 빌드에서 Vec::reserve() 를 인라인 할 수 있습니다. 어떤 경우에는 좋은 성능 향상을 제공 할 수 있습니다 (물론 측정해야하지만).
• 말 그대로 libcore/alloc.rs ( Layout::pad_to_align() )의 이전 함수는 확인되지 않은 추가의 동일한 패턴을 사용하고이를 가능하게하는 것을 설명하는 동일한 주석을 사용합니다. Layout::repeat() 에서 오버플로 검사를 복원하지만 Layout::pad_to_align() 에서는 복원하지 않는 것이 정말 이상해 보입니다.
• 누군가가이 문제에 대해 정말로 차단 된 경우 (확실히 아닙니다) stdlib 변경을 포함하지 않는 다른 해결 방법이 많이 있습니다 (예 : ThinLTO 비활성화, 최적화 수준 변경, 코드 생성 단위 수 감소).

이 특정 엣지 케이스 또는 디버거 푸를 추적하기 위해 특정 세부 사항으로 패닉하도록 사전 조건으로 불변의 릴리스 포함 방어 적 주장을 로컬로 던질 수 있습니까? 나는 특정 조건에서 통과하는 확인되지 않은 계산 일 것입니다.

그런 다음 추적 할 때 (방금 배운 LLVM 어딘가에 ty @dyfz) 회귀 테스트 케이스가 멋져서 다시 발생하지 않습니다. 🙏

LLVM IR 재생기 : https://gist.github.com/comex/881074b1bcc545e299e65527c719eef4

opt bconfused.ll -scalar-evolution -loop-idiom -scalar-evolution -indvars -S -O3 -o - | grep xprint 합니다. 괄호 안이 i64 -1 이면 버그가있는 최적화가 발생한 것입니다. 그렇지 않다면 ... 없을 수도 있지만 확신하기는 어렵습니다.

LLVM에서 Induction Variable Simplification 패스의 일부로 nuw 를 add nuw i64 %x, -1 잘못 추가 한 것 같습니다. x 는 함수에 대한 인수이고 nuw 는 서명되지 않은 랩이 없음을 의미하므로 인수가 보장되지 않는 함수의 지점에서 인수가 0이라고 효과적으로 주장합니다.

Bisecting (편집 : LLVM 9에서 LLVM 10으로, @tmiasko 는 영향을받지

commit 58e8c793d0e43150a6452e971a32d7407a8a7401
Author: Tim Northover <[email protected]>
Date:   Mon Sep 30 07:46:52 2019 +0000

    Revert "[SCEV] add no wrap flag for SCEVAddExpr."

    This reverts r366419 because the analysis performed is within the context of
    the loop and it's only valid to add wrapping flags to "global" expressions if
    they're always correct.

    llvm-svn: 373184

r366419 (위의 커밋이 되 돌리는 커밋)가 Rust가 사용하는 LLVM 9.0 브랜치에 포함되어 있기 때문에 유망 해 보입니다.

T- 컴파일러 분류 : 다음 상황 요약 을 기반으로하는 P- 중간 :

pnkfelix : # 69225의 나머지 작업 항목은 1. 수정 LLVM (58e8c793d0e43150a6452e971a32d7407a8a7401을 선택하거나 LLVM 10으로 업그레이드) 한 다음 2. PR # 67174를 읽었습니다.
pnkfelix : 그러나 이것들 중 어느 것도 나에게 우선 순위가 높은 항목이라고 생각하지 않습니다.
pnkfelix : 적어도이 LLVM 버그는 다른 LLVM 코드 생성 버그보다 더 좋거나 나쁘게 보이지 않습니다. @simulacrum이 방금 말한 것입니다.

업데이트 : PR # 67759에서 LLVM 10으로 업그레이드 시도 중

업데이트 2 : 어떤 이유로 든 원본을 체리로 선택했기 때문에 되돌리기 커밋을 맹목적으로 체리로 선택하는 것은 현명하지 않을 수 있습니다. 따라서 복귀는 의도하지 않은 다운 스트림 효과를 가질 수 있습니다. 적어도 결과를 이해하지 않고 시도해서는 안됩니다. (LLVM 10으로 업그레이드하려는 노력을 감안할 때, 대부분의 노력이 낭비 될 수 있으므로 되돌리기를 전혀 선택하지 않아야합니다 ...)

원래 커밋은 체리를 따랐습니까? 적어도 나에게 명확하지 않은 @comex 의 코멘트에서 ( "Lust가 사용하는 LLVM 9.0 브랜치에 포함되어있다"는 것은 LLVM 9.0의 일부일 수도 있음을 의미 할 수도 있습니다).

문제의 커밋은 함수 호출에 단일 매개 변수를 추가하고 문자 그대로 it is safe [in this case] to add SCEV::FlagNSW 라고 말하는 매우 지역적이고 작은 변경 사항 입니다 (코드에서 판단 할 때 새 매개 변수도 SCEV::FlagNUW ). 그래서 이것이 바로 이것이 오 최적화의 원인이라고 생각합니다. 이 매개 변수를 제거 (예 : (void)getAddRecExpr(getAddExpr(StartVal, Accum, Flags), Accum, L, Flags); 를 (void)getAddRecExpr(getAddExpr(StartVal, Accum), Accum, L, Flags); )하면 문제가 해결되었음을 확인할 수 있습니다.

더욱이,이 문제가있는 커밋은 체리를 뽑지 _ 않았습니다 _. 단지 불운 일뿐입니다. 9.0.0이 생성 된 후 복귀가 발생한 것처럼 보이므로 업스트림 9.0.0 에는 여전히 문제가되는 매개 변수가 있습니다. 되돌리기 는 어떤 이유로 든 9.0.1로 백 포트 에는 되돌리기가 있습니다.

여기에 nsw 또는 nuw 를 추가하는 것이 실제로 안전하지 않은 이유를 설명 하는 주석 이 있습니다. 이것에 대해 LLVM 개발자와 이야기하는 것이 좋을 것 같지만, 되돌림을 선택하면이 문제가 해결되고 너무 작고 독립적이기 때문에 의도하지 않은 효과가 전혀 발생하지 않을 것이라고 생각합니다.

PS @comex 의 근본 원인에 대한 엄청난 명성. 환상적인 직업.

FWIW https://github.com/llvm/llvm-project/commit/58e8c793d0e43150a6452e971a32d7407a8a7401 이 체리 선택에 안전하다는 것을 확인할 수 있으며 보수적 인 변경입니다. SCEV nowrap 플래그의 문제에 대한 자세한 내용은 https://lists.llvm.org/pipermail/llvm-dev/2019-September/135195.html을 참조하십시오.

# 67174를 되 돌린 후에도 문제를 재현 할 수있는 방법을 찾은 것 같습니다. 다음은 Windows, Linux 및 macOS에서 # 67174로 되 돌린 최신 야간을 사용하여 안정적으로 segfault하는 약간 더 길지만 여전히 안전한 프로그램입니다.

fn do_test(x: usize) {
    let mut arr = vec![vec![0u8; 3]];

    let mut z = vec![0];
    for arr_ref in arr.iter_mut() {
        for y in 0..x {
            for _ in 0..1 {
                z.reserve_exact(x);
                let iterator = std::iter::repeat(0).take(x);
                let mut cnt = 0;
                iterator.for_each(|_| {
                    z[0] = 0;
                    cnt += 1;
                });
                let a = y * x;
                let b = (y + 1) * x - 1;
                let slice = &mut arr_ref[a..b];
                slice[1 << 24] += 1;
            }
        }
    }
}

fn main() {
    do_test(1);
    do_test(2);
}

Windows :

PS> rustup run nightly rustc --version
rustc 1.43.0-nightly (6d0e58bff 2020-02-23)
PS> rustup run nightly cargo run --release
    Finished release [optimized] target(s) in 0.01s
     Running `target\release\rust-segfault.exe`
error: process didn't exit successfully: `target\release\rust-segfault.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

리눅스 :

$ rustup run nightly rustc --version
rustc 1.43.0-nightly (6d0e58bff 2020-02-23)
$ rustup run nightly cargo run --release
    Finished release [optimized] target(s) in 1.13s
     Running `target/release/rust-segfault`
Segmentation fault (core dumped)

맥 OS:

λ rustup run nightly rustc --version
rustc 1.43.0-nightly (6d0e58bff 2020-02-23)
λ rustup run nightly cargo run --release
    Finished release [optimized] target(s) in 0.01s
     Running `target/release/rust-segfault`
[1]    24331 segmentation fault  rustup run nightly cargo run --release

이 프로그램은 codegen 단위의 수에 의존하지 않으므로 Playground 에서도 segfault (안정, 베타 및 야간)합니다. 또한 LLVM 9에 연결된 마스터 (# 67174가 되 돌린 상태)에서 rustc 를 컴파일하여이를 재현했습니다.

기본 LLVM 버그는 여전히 동일하므로 LLVM 10으로 업그레이드하거나 LLVM 수정을 선택하면 segfault가 사라집니다.

무슨 일이 일어나고 있는지 이해했으면 좋겠어요. 잘못 캐시 된 SCEV 값에서 비롯된 추가 nuw 때문에 경계 검사가 제거 된 것처럼 보입니다 ( @nikic이 연결된 스레드의 C 프로그램 cnt 변수 제거)이 매우 다르게 보이는 LLVM IR로 이어지고 문제가 사라진다는 것입니다.

내 인상은 1.41.1이 방금 # 69359 (내 부분의 타이밍이 좋지 않음)에서 마무리 되었기 때문에이 시점에서 할 수있는 일이 많지 않다는 것입니다. LLVM 문제에 대한 더 자세한 설명과 함께 Layout::repeat() 의 주석 을 업데이트하는 것이 적어도 좋은 생각입니까? 그렇다면 PR을 보낼 수 있습니다.

내 인상은 1.41.1이 방금 # 69359 (내 부분의 타이밍이 좋지 않음)에서 마무리 되었기 때문에이 시점에서 할 수있는 일이 많지 않다는 것입니다.

1.41.1에 포함 된 패치로 문제가 실제로 해결되지 않으면 새 수정 사항을 백 포트하고 릴리스를 다시 빌드할지 여부를 재고해야합니다. 이 릴리스 팀 회의하지에 백 포트 LLVM 수정에 합의했지만, 나는 개인적으로 다른 새의 PoC이 주제에 대한 다른 논의를 보증 할 수 생각합니다.

cc @ Mark-Simulacrum @ rust-lang / release

@dfyz 우리는 LLVM 픽스가 백 포트 된 1.41.1의 또 다른 빌드를 얻으려고 노력할 것입니다.

FWIW, 저에게 새로운 재현 기는 안정적인 1.38.0 및 이전 버전에서 예상대로 작동하지만 ( index out of bounds ) 1.39.0 이상에서는 segfault입니다. 1.38과 1.39 사이의 LLVM에는 많은 차이가 없지만 (https://github.com/rust-lang/llvm-project/compare/71fe7ec06b85f612fc0e4eb4134c7a7d0f23fac5...8adf9bdccfefb8d03f0e8db3bgen012fb41da1580a4) 길을 따라도.

새 재생산 기는 안정적인 1.38.0에서 예상대로 작동합니다 (범위를 벗어난 인덱스).

나는 (실수로) 1.38.0에서 -C codegen-units=1 설정이 segfault를 재현한다는 것을 발견했습니다. 1.37.0은 나에게 안전 해 보입니다 (내가 시도한 옵션 조합이 segfault를 생성하지 않음).

1.37.0은 LLVM 8을 사용합니다.
흥미롭게도 1.37.0과 1.38.0 ( -C codegen-units=1 ) 사이의 LLVM IR 차이는 한 줄에 불과합니다.

- %71 = icmp eq {}* %70, null
+ %71 = icmp ule {}* %70, null

( %70 는 <core::slice::IterMut<T> as core::iter::traits::iterator::Iterator>::next() 의 결과에서 파생 됨)

이것만으로도 LLVM을 속여 nuw 를 add nuw i64 %x, -1 있습니다.

1.37.0은 나에게 안전 해 보입니다 (내가 시도한 옵션 조합이 segfault를 생성하지 않음).

그것은 LLVM 8을 사용하고 있으므로 비난받는 SCEV 변경이 전혀 존재해서는 안됩니다.

LLVM 8을 사용하고 있습니다.

혼란스러워서 죄송합니다 (LLVM 버전을 확인하지도 않은 한 줄 차이로 줄이게되어 너무 기뻤습니다).

우리는 LLVM 수정 사항이 포함 된 새로운 1.41.1 아티팩트를 준비했습니다. 다음을 사용하여 로컬에서 테스트 할 수 있습니다.

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

https://github.com/rust-lang/rust/issues/69225#issuecomment -586941455에서 핑

[triagebot]이 문제는 핑된 컴파일러 팀의 개입없이 성공적으로 해결되었습니다.
좋은 Bretty.

1.41.1이 나왔으니 마침내이 문제를 해결할 때가 된 것 같습니다.