LLVM loop optimization can make safe programs crash

[RalfJung]

The following snippet crashes when compiled in release mode on current stable, beta and nightly:

enum Null {}

fn foo() -> Null { loop { } }

fn create_null() -> Null {
    let n = foo();

    let mut i = 0;
    while i < 100 { i += 1; }
    return n;
}

fn use_null(n: Null) -> ! {
    match n { }
}


fn main() {
    use_null(create_null());
}

https://play.rust-lang.org/?gist=1f99432e4f2dccdf7d7e&version=stable

This is based on the following example of LLVM removing a loop that I was made aware of: https://github.com/simnalamburt/snippets/blob/master/rust/src/bin/infinite.rs.
What seems to happen is that since C allows LLVM to remove endless loops that have no side-effect, we end up executing a match that has to arms.

[ranma42]

The LLVM IR of the optimised code is

; Function Attrs: noreturn nounwind readnone uwtable
define internal void @_ZN4main20h5ec738167109b800UaaE() unnamed_addr #0 {
entry-block:
  unreachable
}

This kind of optimisation breaks the main assumption that should normally hold on uninhabited types: it should be impossible to have a value of that type.
rust-lang/rfcs#1216 proposes to explicitly handle such types in Rust. It might be effective in ensuring that LLVM never has to handle them and in injecting the appropriate code to ensure divergence when needed (IIUIC this could be achieved with appropriate attributes or intrinsic calls).
This topic has also been recently discussed in the LLVM mailing list: http://lists.llvm.org/pipermail/llvm-dev/2015-July/088095.html

[ranma42]

The LLVM IR of the optimised code is

; Function Attrs: noreturn nounwind readnone uwtable
define internal void @_ZN4main20h5ec738167109b800UaaE() unnamed_addr #0 {
entry-block:
  unreachable
}

This kind of optimisation breaks the main assumption that should normally hold on uninhabited types: it should be impossible to have a value of that type.
rust-lang/rfcs#1216 proposes to explicitly handle such types in Rust. It might be effective in ensuring that LLVM never has to handle them and in injecting the appropriate code to ensure divergence when needed (IIUIC this could be achieved with appropriate attributes or intrinsic calls).
This topic has also been recently discussed in the LLVM mailing list: http://lists.llvm.org/pipermail/llvm-dev/2015-July/088095.html

[alexcrichton]

triage: I-nominated

Seems bad! If LLVM doesn't have a way to say "yes, this loop really is infinite" though then we may just have to sit-and-wait for the upstream discussion to settle.

[alexcrichton]

triage: I-nominated

Seems bad! If LLVM doesn't have a way to say "yes, this loop really is infinite" though then we may just have to sit-and-wait for the upstream discussion to settle.

[ranma42]

A way to prevent infinite loops from being optimised away is to add unsafe {asm!("" :::: "volatile")} inside of them. This is similar to the llvm.noop.sideeffect intrinsic that has been proposed in the LLVM mailing list, but it might prevent some optimisations.
In order to avoid the performance loss and to still guarantee that diverging functions/loops are not optimised away, I believe that it should be sufficient to insert an empty non-optimisable loop (i.e. loop { unsafe { asm!("" :::: "volatile") } }) if uninhabited values are in scope.
If LLVM optimises the code which should diverge to the point that it does not diverge anymore, such loops will ensure that the control flow is still unable to proceed.
In "lucky" case in which LLVM is unable to optimise the diverging code, such loop will be removed by DCE.

[ranma42]

A way to prevent infinite loops from being optimised away is to add unsafe {asm!("" :::: "volatile")} inside of them. This is similar to the llvm.noop.sideeffect intrinsic that has been proposed in the LLVM mailing list, but it might prevent some optimisations.
In order to avoid the performance loss and to still guarantee that diverging functions/loops are not optimised away, I believe that it should be sufficient to insert an empty non-optimisable loop (i.e. loop { unsafe { asm!("" :::: "volatile") } }) if uninhabited values are in scope.
If LLVM optimises the code which should diverge to the point that it does not diverge anymore, such loops will ensure that the control flow is still unable to proceed.
In "lucky" case in which LLVM is unable to optimise the diverging code, such loop will be removed by DCE.

[geofft]

Is this related to #18785? That one's about infinite recursion to be UB, but it sounds like the fundamental cause might be similar: LLVM doesn't consider not halting to be a side effect, so if a function has no side effects other than not halting, it's happy to optimize it away.

[geofft]

Is this related to #18785? That one's about infinite recursion to be UB, but it sounds like the fundamental cause might be similar: LLVM doesn't consider not halting to be a side effect, so if a function has no side effects other than not halting, it's happy to optimize it away.

[arielb1]

@geofft

It's the same issue.

[arielb1]

@geofft

It's the same issue.

[RalfJung]

Yes, looks like it's the same. Further down that issue, they show how to get undef, from which I assume it's not hard to make a (seemingly safe) program crash.

[RalfJung]

Yes, looks like it's the same. Further down that issue, they show how to get undef, from which I assume it's not hard to make a (seemingly safe) program crash.

[simnalamburt]

👍

[simnalamburt]

👍

[ranma42]

Crash, or, possibly even worse heartbleed https://play.rust-lang.org/?gist=15a325a795244192bdce&version=stable

[ranma42]

Crash, or, possibly even worse heartbleed https://play.rust-lang.org/?gist=15a325a795244192bdce&version=stable

[nikomatsakis]

So I've been wondering how long until somebody reports this. :) In my opinion, the best solution would of course be if we could tell LLVM not to be so aggressive about potentially infinite loops. Otherwise, the only thing I think we can do is to do a conservative analysis in Rust itself that determines whether:

1. the loop will terminate OR
2. the loop will have side-effects (I/O operations etc, I forget precisely how this is defined in C)

Either of this should be enough to avoid undefined behavior.

[nikomatsakis]

So I've been wondering how long until somebody reports this. :) In my opinion, the best solution would of course be if we could tell LLVM not to be so aggressive about potentially infinite loops. Otherwise, the only thing I think we can do is to do a conservative analysis in Rust itself that determines whether:

1. the loop will terminate OR
2. the loop will have side-effects (I/O operations etc, I forget precisely how this is defined in C)

Either of this should be enough to avoid undefined behavior.

[nikomatsakis]

triage: P-medium

We'd like to see what LLVM will do before we invest a lot of effort on our side, and this seems relatively unlikely to cause problems in practice (though I have personally hit this while developing the compiler as well). There are no backwards incomatibility issues to be concerned about.

[nikomatsakis]

triage: P-medium

We'd like to see what LLVM will do before we invest a lot of effort on our side, and this seems relatively unlikely to cause problems in practice (though I have personally hit this while developing the compiler as well). There are no backwards incomatibility issues to be concerned about.

[dotdash]

Quoting from the LLVM mailing list discussion:

 The implementation may assume that any thread will eventually do one of the following:
   - terminate
   - make a call to a library I/O function
   - access or modify a volatile object, or
   - perform a synchronization operation or an atomic operation

 [Note: This is intended to allow compiler transformations such as removal of empty loops, even
  when termination cannot be proven. — end note ]

[dotdash]

Quoting from the LLVM mailing list discussion:

 The implementation may assume that any thread will eventually do one of the following:
   - terminate
   - make a call to a library I/O function
   - access or modify a volatile object, or
   - perform a synchronization operation or an atomic operation

 [Note: This is intended to allow compiler transformations such as removal of empty loops, even
  when termination cannot be proven. — end note ]

[ranma42]

@dotdash The excerpt you are quoting comes from the C++ specification; it is basically the answer to "how it [having side effects] is defined in C" (also confirmed by the standard committee: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm ).

Regarding what is the expected behaviour of the LLVM IR there is some confusion. https://llvm.org/bugs/show_bug.cgi?id=24078 shows that there seems to be no accurate & explicit specification of the semantics of infinite loops in LLVM IR. It aligns with the semantics of C++, most likely for historical reasons and for convenience (I only managed to track down https://groups.google.com/forum/#!topic/llvm-dev/j2vlIECKkdE which apparently refers to a time when infinite loops were not optimised away, some time before the C/C++ specs were updated to allow it).

From the thread it is clear that there is the desire to optimise C++ code as effectively as possible (i.e. also taking into account the opportunity to remove infinite loops), but in the same thread several developers (including some that actively contribute to LLVM) have shown interest in the ability to preserve infinite loops, as they are needed for other languages.

[ranma42]

@dotdash The excerpt you are quoting comes from the C++ specification; it is basically the answer to "how it [having side effects] is defined in C" (also confirmed by the standard committee: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm ).

Regarding what is the expected behaviour of the LLVM IR there is some confusion. https://llvm.org/bugs/show_bug.cgi?id=24078 shows that there seems to be no accurate & explicit specification of the semantics of infinite loops in LLVM IR. It aligns with the semantics of C++, most likely for historical reasons and for convenience (I only managed to track down https://groups.google.com/forum/#!topic/llvm-dev/j2vlIECKkdE which apparently refers to a time when infinite loops were not optimised away, some time before the C/C++ specs were updated to allow it).

From the thread it is clear that there is the desire to optimise C++ code as effectively as possible (i.e. also taking into account the opportunity to remove infinite loops), but in the same thread several developers (including some that actively contribute to LLVM) have shown interest in the ability to preserve infinite loops, as they are needed for other languages.

[dotdash]

@ranma42 I'm aware of that, I just quoted that for reference, because one possibility to work-around this would be to detect such loops in rust and add one of the above to it to stop LLVM from performing this optimization.

[dotdash]

@ranma42 I'm aware of that, I just quoted that for reference, because one possibility to work-around this would be to detect such loops in rust and add one of the above to it to stop LLVM from performing this optimization.

[bstrie]

Is this a soundness issue? If so, we should tag it as such.

[bstrie]

Is this a soundness issue? If so, we should tag it as such.

[bluss]

Yes, following @ranma42's example, this way shows how it readily defeats array bounds checks. playground link

[bluss]

Yes, following @ranma42's example, this way shows how it readily defeats array bounds checks. playground link

[arielb1]

@bluss

The policy is that wrong-code issues that are also soundness issues (i.e. most of them) should be tagged I-wrong.

[arielb1]

@bluss

The policy is that wrong-code issues that are also soundness issues (i.e. most of them) should be tagged I-wrong.

[nikomatsakis]

So just to recap prior discussion, there are really two choices here that I can see:

• Wait for LLVM to provide a solution.
• Introduce no-op asm statements wherever there may be an infinite loop or infinite recursion (#18785).

The latter is kind of bad because it can inhibit optimization, so we'd want to do it somewhat sparingly -- basically wherever we can't prove termination ourselves. You could also imaging tying it a bit more to how LLVM optimizes -- i.e., introducing only if we can detect a scenario that LLVM might consider to be an infinite loop/recursion -- but that would (a) require tracking LLVM and (b) require deeper knowledge than I, at least, possess.

[nikomatsakis]

So just to recap prior discussion, there are really two choices here that I can see:

• Wait for LLVM to provide a solution.
• Introduce no-op asm statements wherever there may be an infinite loop or infinite recursion (#18785).

The latter is kind of bad because it can inhibit optimization, so we'd want to do it somewhat sparingly -- basically wherever we can't prove termination ourselves. You could also imaging tying it a bit more to how LLVM optimizes -- i.e., introducing only if we can detect a scenario that LLVM might consider to be an infinite loop/recursion -- but that would (a) require tracking LLVM and (b) require deeper knowledge than I, at least, possess.

[gnzlbg]

Wait for LLVM to provide a solution.

What is the LLVM bug tracking this issue?

[gnzlbg]

Wait for LLVM to provide a solution.

What is the LLVM bug tracking this issue?

[oli-obk]

side-note: while true {} exhibits this behaviour. Maybe the lint should be upgraded to error-by-default and get a note stating that this currently can exhibit undefined behaviour?

[oli-obk]

side-note: while true {} exhibits this behaviour. Maybe the lint should be upgraded to error-by-default and get a note stating that this currently can exhibit undefined behaviour?

[ubsan]

Also, note that this is invalid for C. LLVM making this argument means that there is a bug in clang.

void foo() { while (1) { } }

void create_null() {
        foo();

        int i = 0;
        while (i < 100) { i += 1; }
}

__attribute__((noreturn))
void use_null() {
        __builtin_unreachable();
}


int main() {
        create_null();
        use_null();
}

This crashes with optimizations; this is invalid behavior under the C11 standard:

An iteration statement whose controlling expression is not a constant
expression, [note 156] that performs no  input/output  operations,
does  not  access  volatile  objects,  and  performs  no synchronization or
atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be   assumed   by   the
implementation to terminate. [note 157]

156: An omitted controlling expression is replaced by a nonzero constant,
     which is a constant expression.
157: This  is  intended  to  allow  compiler  transformations  such  as
     removal  of  empty  loops  even  when termination cannot be proven. 

Note the "whose controlling expression is not a constant expression" - while (1) { }, 1 is a constant expression, and thus may not be removed.

[ubsan]

Also, note that this is invalid for C. LLVM making this argument means that there is a bug in clang.

void foo() { while (1) { } }

void create_null() {
        foo();

        int i = 0;
        while (i < 100) { i += 1; }
}

__attribute__((noreturn))
void use_null() {
        __builtin_unreachable();
}


int main() {
        create_null();
        use_null();
}

This crashes with optimizations; this is invalid behavior under the C11 standard:

An iteration statement whose controlling expression is not a constant
expression, [note 156] that performs no  input/output  operations,
does  not  access  volatile  objects,  and  performs  no synchronization or
atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be   assumed   by   the
implementation to terminate. [note 157]

156: An omitted controlling expression is replaced by a nonzero constant,
     which is a constant expression.
157: This  is  intended  to  allow  compiler  transformations  such  as
     removal  of  empty  loops  even  when termination cannot be proven. 

Note the "whose controlling expression is not a constant expression" - while (1) { }, 1 is a constant expression, and thus may not be removed.

[oli-obk]

Is the loop removal an optimization pass that we could simply remove?

[oli-obk]

Is the loop removal an optimization pass that we could simply remove?

[zackw]

Repeating myself from #42009: this bug can, under some circumstances, cause the emission of an externally callable function containing no machine instructions at all. This should never happen. If LLVM deduces that a pub fn can never be called by correct code, it should emit at least a trap instruction as the body of that function.

[zackw]

Repeating myself from #42009: this bug can, under some circumstances, cause the emission of an externally callable function containing no machine instructions at all. This should never happen. If LLVM deduces that a pub fn can never be called by correct code, it should emit at least a trap instruction as the body of that function.

[steveklabnik]

This was brought up in this blog post today: https://blog.rom1v.com/2017/09/gnirehtet-rewritten-in-rust/

With a simpler reproduction: https://play.rust-lang.org/?gist=e622f8a672fbc57ecc63eb4450d2fc0a&version=stable

[steveklabnik]

This was brought up in this blog post today: https://blog.rom1v.com/2017/09/gnirehtet-rewritten-in-rust/

With a simpler reproduction: https://play.rust-lang.org/?gist=e622f8a672fbc57ecc63eb4450d2fc0a&version=stable

[sunfishcode]

The LLVM bug for this is https://bugs.llvm.org/show_bug.cgi?id=965 (opened in 2006).

[sunfishcode]

The LLVM bug for this is https://bugs.llvm.org/show_bug.cgi?id=965 (opened in 2006).

[sunfishcode]

@zackw LLVM has a flag for that: TrapUnreachable. I haven't tested this, but it looks adding Options.TrapUnreachable = true; to LLVMRustCreateTargetMachine ought to address your concern. It's likely that this has a low enough cost that it could be done by default, though I haven't made any measurements.

@oli-obk It's unfortunately not just a loop-deletion pass. The problem arises from broad assumptions, for example: (a) branches have no side effects, (b) functions that contain no instructions with side effects have no side effects, and (c) calls to functions with no side effects can be moved or deleted.

[sunfishcode]

@zackw LLVM has a flag for that: TrapUnreachable. I haven't tested this, but it looks adding Options.TrapUnreachable = true; to LLVMRustCreateTargetMachine ought to address your concern. It's likely that this has a low enough cost that it could be done by default, though I haven't made any measurements.

@oli-obk It's unfortunately not just a loop-deletion pass. The problem arises from broad assumptions, for example: (a) branches have no side effects, (b) functions that contain no instructions with side effects have no side effects, and (c) calls to functions with no side effects can be moved or deleted.

[steveklabnik]

Looks like there's a patch: https://reviews.llvm.org/D38336

[steveklabnik]

Looks like there's a patch: https://reviews.llvm.org/D38336

[bstrie]

@sunfishcode , looks like your LLVM patch at https://reviews.llvm.org/D38336 was "accepted" on October 3, can you give an update on what that means regarding LLVM's release process? What's the next step beyond acceptance, and do you have an idea of what future LLVM release will contain this patch?

[bstrie]

@sunfishcode , looks like your LLVM patch at https://reviews.llvm.org/D38336 was "accepted" on October 3, can you give an update on what that means regarding LLVM's release process? What's the next step beyond acceptance, and do you have an idea of what future LLVM release will contain this patch?

[sunfishcode]

I talked with some people offline who suggested we have an llvmdev thread. The thread is here:

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html

It's now concluded, with the result being that I need to make additional changes. I think the changes will be good, though they'll take me a little more time to do.

[sunfishcode]

I talked with some people offline who suggested we have an llvmdev thread. The thread is here:

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html

It's now concluded, with the result being that I need to make additional changes. I think the changes will be good, though they'll take me a little more time to do.

[bstrie]

Thanks for the update, and thanks so much for your efforts!

[bstrie]

Thanks for the update, and thanks so much for your efforts!

[bstrie]

Note that https://reviews.llvm.org/rL317729 has landed in LLVM. This patch is planned to have a follow-up patch which makes infinite loops exhibit defined behavior by default, so AFAICT all we need to do is wait and eventually this will be resolved for us upstream.

[bstrie]

Note that https://reviews.llvm.org/rL317729 has landed in LLVM. This patch is planned to have a follow-up patch which makes infinite loops exhibit defined behavior by default, so AFAICT all we need to do is wait and eventually this will be resolved for us upstream.

[sunfishcode]

@zackw I've now created #45920 to fix the problem of functions containing no code.

@bstrie Yes, the first step is landed, and I'm working on the second step of making LLVM give infinite loops defined behavior by default. It's a complex change, and I don't yet know how long it'll take to finish, but I'll post updates here.

[sunfishcode]

@zackw I've now created #45920 to fix the problem of functions containing no code.

@bstrie Yes, the first step is landed, and I'm working on the second step of making LLVM give infinite loops defined behavior by default. It's a complex change, and I don't yet know how long it'll take to finish, but I'll post updates here.

[jsgf]

I couldn't repro this just now: https://play.rust-lang.org/?gist=529bd5ab326f7b627e559f64d514312f&version=stable

[jsgf]

I couldn't repro this just now: https://play.rust-lang.org/?gist=529bd5ab326f7b627e559f64d514312f&version=stable

[kennytm]

@jsgf Still repro. Have you selected Release mode?

[kennytm]

@jsgf Still repro. Have you selected Release mode?

[jsgf]

@kennytm Woops, never mind.

[jsgf]

@kennytm Woops, never mind.

[japaric]

Note that https://reviews.llvm.org/rL317729 has landed in LLVM. This patch is planned to have a follow-up patch which makes infinite loops exhibit defined behavior by default, so AFAICT all we need to do is wait and eventually this will be resolved for us upstream.

It has been several months since this comment. Anyone knows if the follow-up patch happened or will still happen?

Alternatively, it seems that the llvm.sideeffect intrinsic exists in the LLVM version we are using: could we fix this ourselves by translating Rust infinite loops into LLVM loops that contain the sideeffect intrinsic?

[japaric]

Note that https://reviews.llvm.org/rL317729 has landed in LLVM. This patch is planned to have a follow-up patch which makes infinite loops exhibit defined behavior by default, so AFAICT all we need to do is wait and eventually this will be resolved for us upstream.

It has been several months since this comment. Anyone knows if the follow-up patch happened or will still happen?

Alternatively, it seems that the llvm.sideeffect intrinsic exists in the LLVM version we are using: could we fix this ourselves by translating Rust infinite loops into LLVM loops that contain the sideeffect intrinsic?