Change:
<del> Subproject commit 606bc11367b475542bd6228163424ca43b4dbdbc </del> <ins> Subproject commit 700fbf978e6c5bb297d12963206f7487722de480 </ins>

Discussion:
I tried compiling this code with : (Thanks to for helping me find this shorter reproducer) I expected to see this happen: (nothing, since there's no main method) a clean compile Instead, this happened: (Or, when compiling through :) : Note: this crashes on the playground on nightly (2023-12-20 ), beta (1.75.0-beta.7), and stable (1.74.1). Also crashes on aarch64-apple-darwin nightly (2023-12-19 ), beta (1.75.0-beta.7) and stable (1.74.1) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p(From since I don't have a debug build on macOS yet) </p</details
It's probably on our side since it's tripping an LLVM assert? (or is it tripped by an incorrect optimization maybe?)
Reduced:
Upstream fix:
could you please try adding and see if it still reproduces? I had thought this was cortex-m/thumb specific, but might be relevant to all ARM targets. CC: edit: Ah nikic might have already found a more specific issue, probably nevermind :)
I verified successfully that this also fixes the build for my codebase where I originally found this (by cherry-picking only your commit on top of the currently used nightly llvm branch in rust-lang/rust, ) edit Sorry, just saw your comment as I was leaving. I can try that later, but since it also reproduces on the (linux/ guessing amd64?) rust playground, I doubt this is ARM-related.
The argument doesn't seem to make a difference, neither on stable/beta, nor on nightly. Current versions (as in my initial post) all crash (with and without the flag), and the stage1 I built with fix works fine with and without the flag.
I'm confused, this code still crashes with yesterday's nightly? Could it be that the alternative fix you selected doesn't fully fix the issue I'm seeing?
I had also tested my code using your cherry-picked fix () based on llvm again, and saw the crash still happen. Apologies, I seemingly had written the comment but forgot to send.

Hm yeah, I tested my original fix against the original test case, but not the final version. Let me take another look.
New reduction: Took me a while to spot how this differs from the previous one: The branch destinations are swapped...
New upstream fix:
When cherry-picking this onto latest rust master (, llvm ), I get: Is this expected?
Are you sure the commit was picked up? The patch removes that assertion.
Reopening, the auto closing on a merge in fork seems unintentional.
yes, unintentional. If someone has a way to prevent that I'd appreciate it.
duh, forgot to commit the llvm submodule, thanks. Confirmed no crash, also builds my original project without issue.
Fixed in beta & nightly.

:
Minimized:
Reminds me of
Upstream fix:
WG-prioritization assigning priority (). label -I-prioritize +P-high

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: (additional repro notes in the README there). I have verified this causes the code to crash as it jumps into a random RAM location unexpectedly. This code does a fairly benign call to what boils down to: However, things get sorta bad. The disassembled version by ghidra looks like this: As far as I can tell for THIS reproduction, it: DOES happen on and all that I've tried later than this DOES NOT happen on and before The project updated from LLVM16 to LLVM17 on 2023-08-08, it seems -09 is the first nightly with LLVM17 Edit: I only observed it happening with fatlto, but Peter previously saw it with thinlto ONLY happens with (edit: the repro uses -Oz for debug builds, switching to -O3 in release does not repro) I've attached my specific elf file, so you can look at the same memory locations referenced in my issue This does seem tempermental, and tweaking unrelated pieces of the repro code causes it to disappear. CC
Also pushed which is the exact version used to produce the attached elf file above.
Tagging in who suggested that may address this, if we can update the LLVM17 tip. I've not done a "rebuild rustc with different LLVM submodule" before, but I'll ask around the embedded-rust folks to see if anyone can give me a hand or try it out.
FYI, with my original code base where this first showed up, I can confirm that in fact this happens with lto = "fat" or lto = "thin", but not with lto = "off".
Yep, updated the title to point to the updated assumption that this is more likely due to LR clobbering of the outliner, rather than LTO. In my attempts, lto="thin" didn't repro, but that could have been chance more than science.
What happens with ? What happens with + ?
does not repro with -Copt-level=s (well, I changed the profile) does repro with edit: with opt-level='z' I think might have mentioned the original code having problems in opt='s', though this repro is pretty sensitive to sometimes working with relatively minor changes.

If someone can point me to docs that show how to build a new toolchain, including switching the LLVM version to the branch from (hoping that it Just Builds), I can likely take a look at it this weekend. Otherwise, if anyone knows how to do that quickly, and can do that + do a on and give me the produced , I can test that sooner.
As James mentioned, I believe I had reproduced it yesterday with both "s" and "z", and definitely not with 1, 2, or 3, but it was a very long session and I won't swear to it. The most obvious symptom (a hard fault) can come and go based on link order (it seems), and at one stage during minimization I had it causing a borrowrefmut() panic inside a critical section (which should be impossible). It's entirely possible that this is what I remember failing with "s". At the time I assumed they were both manifestations of the same issue (but someone later suggested an unrelated possible cause for that issue). I just tried with "s" on my full code base and it does not fail.
The bug is caused by the outliner, which is only enabled in I think (couldn't find an official source for this). Can you check if it adding also fixes it on ?
It does not reproduce with these settings
Confirmed. With lto="fat" and opt-level="z" and that RUSTFLAG (to my ) the issue does not appear.
Looks like the new PR for this issue has been merged:
Hey is there a way we can get one of the following two options done before rust 1.75? Otherwise we'll have a stable-to-stable regression for all cortex-m targets (): Pull in this new LLVM tip Make the default temporarily as a hotfix If anyone can point me to docs on how to: update the rustc repo to use the new LLVM tip build a version of the compiler with that LLVM tip So I can test whether that fix addresses the issue we saw (I expect it will!), I can do that ASAP.
The LLVM 17 update is already on stable, so I don't think this would cause a new stable regression. Together with the fact that a trivial workaround exists, I am not willing to include this in the 1.75 release.

I do plan to backport this to nightly (and the new beta) though, together with a number of other fixes.
did LLVM17 make it into 1.74? I thought it was merged after the branch point, but I am less familiar with how the release train works. I don't think we observed this in stable releases, but the repro did use nightly features, so we may just not have gotten lucky in hitting it. I can try and use some BOOTSTRAP tricks to see if I can force the repro w/ nightly features on the stable 1.74. If this does exist on 1.74 (and then 1.75), we'll need to put out a warning as the embedded-wg for everyone to use one of the workarounds, as this can be hard to detect and cause totally random crashes and unsoundness.
Ah yes, LLVM17 landed in 1.73, actually: I'll see if I can reproduce with bootstrap on 1.73/1.74.
Confirming, by using the BOOTSTRAP flag to allow nightly features: Rust 1.72.0 stable does NOT reproduce Rust 1.73.0 stable DOES reproduce Rust 1.74.0 stable DOES reproduce.
Not sure if it helps, but could we get a label? As mentioned, the regression was actually 1.72 to 1.73, but also affects 1.74 and the soon-to-be 1.75. Following up with embedded-wg for a potential advisory notice.
label regression-from-stable-to-stable
Started drafting an advisory here:
Advisory now here:
Imho this was not the right call - it is a serious bug and users could be shipping faulty firmwares if they don't see this issue in time. If a workaround exists, it should be bundled in the release until a proper fix lands. It would be safer and more efficient for all users. Furthermore, since one cannot be sure if one suffers from this bug if no problems are observed, it is hard to test if applying the workaround actually fixed anything - issues could appear only in production. At the very least, the official Rust release notes should mention this bug.
WG-prioritization assigning priority (). label -I-prioritize +P-high
What is the reason you did not want to address this for 1.75?

This bug can cause unsound behavior for all programs targeting cortex-m without any unsafe code at any time on stable. This is extremely serious in my opinion and would have been an easy fix. You could just disable the outliner by passing to LLVM for these targets until this is resolved by updating LLVM which will hopefully happen in 1.76.
I'm not a moderator, but I might suggest that this issue is not the right place to voice procedural grieviences. Nikic has made their reasoning clear above (even if you or I disagree with it), and I'd really like to avoid a pile-on here, particularly as nikic is the one doing the legwork of getting this fixed by pulling in the LLVM patches. As thumb targets are tier two, I don't believe the release team has any responsibility to "stop the world" to correct any known soundness issues, even if they do so on a best effort basis.
What I meant to say is that this issue may warrant a 1.75.1 release, as I believe it is critical enough, despite it being a tier 2 target. If not, there should at least be a public warning, such as a blog post or something similar.
is in the process of being backported