Using rustc with an LLVM compiled with `-Os` results in SIGSEGVs/infinite loops

[ErichLoew]

Summary

Command used

<CMAKE_ARGS="-DCMAKE_CXX_FLAGS_RELEASE=-Os -DCMAKE_C_FLAGS_RELEASE=-Os" ./x.py install --jobs 32>

Expected behaviour

Actual behaviour

./x.py install fails with SIGSEGV 11 at compiling the core builtins.

1. I recompiled whole CLANG 24 toolchain with -Os
2. This conflicts with recompiling the rust toolchain latest.
3. Root cause: rust toolchain is compiled hard coded with -O3; this conflicts with the VTable based interfacing to the compiler and LLVM backend.
   In addition the -O3 is deeply hidden inside of src/bootstrap/src/core/build_steps/llvm.rs::configure_llvm().
   In addition there is no mechanism via bootstrap.toml and/or env variables available to convince the toolchain to compile with -Os instead of -O3.

See for details the attached 20260802 ARCH Report.pdf.

Bootstrap configuration (bootstrap.toml)

<config>

Operating system et al

OS: OpenSUSE Leap 15.2
Kernel: Linux Korn55 7.1.4-Woessel-CL #1 SMP PREEMPT Thu Jul 23 00:07:04 CEST 2026 x86_64 GNU/Linux
Compilers:

1. clang version 24.0.0git (https://github.com/llvm/llvm-project.git f8ebdb4dc6049f29e449a7e943b1eb914b0950ee) Target: x86_64-unknown-linux-gnu Thread model: posix
2. gcc (GCC) 17.0.0 20260727 (experimental)
   Copyright (C) 2026 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions. There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
3. ld (GNU Binutils) 2.47.20260726 Copyright (C) 2026 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty

Additional context

I described in detail my observation within the attached PDF.

20260802 ARCH Report.pdf

[bjorn3]

Root cause: rust toolchain is compiled hard coded with -O3; this conflicts with the VTable based interfacing to the compiler and LLVM backend.

The optimization level doesn't affect the ABI at all. Whatever you are seeing has a different cause.

I described in detail my observation within the attached PDF.

Why did you create a PDF rather than put everything in the issue description? I'm not going to download a random PDF.

Question: Did you use an LLM to create this issue? If so, please don't. Just write what you observed in your own words. And don't try to guess what the root cause is if you don't know how to debug it yourself. That only causes confusion.

[ErichLoew]

Hi Björn,

The optimization level doesn't affect the ABI at all. Whatever you are seeing has a different cause.

I hope this as well Here my wordings, basically the PDF content. 1. The cause is proven by empirical compilation, not guesswork. 2. Host system LLVM and GCC are compiled with -Os. 3. Rust bootstrap forces -O3 onto the in-tree LLVM bindings. 4. This causes a reproducible SIGSEGV / 100% CPU infinite loop inside WriteBackendMethods::optimize during Stage 1 on multiple distinct hardware architectures (Intel i5 & Core 2 Duo). I forced then symmetry inside function `configure_llvm()`: * cfg.define("CMAKE_CXX_FLAGS_RELEASE", "-Os"); * cfg.define("CMAKE_C_FLAGS_RELEASE", "-Os"); Observation: the desynchronization is instantly resolved, and `x.py install --jobs 16` completes with zero errors and zero warnings, achieving 100% stable binaries. Give me some time: my leap 15.6 on an historical I5 CPU (prices for fat Ryzen are actually beyond my budget) is not blazing fast 😊 * I reproduce/replay again combining “GCC 17.0.0 latest + CLANG-24 LLVM latest” with RUST toolchain build * I’ll deliver all involved files and logs if topic pops up.

Why did you create a PDF rather than put everything in the issue description? I'm not going to download a random PDF.

Simple: I read the code of conduct notes and there it is stated the BUG report shall not be flooded with details As consequence I created and attached the random PDF 😊

Question: Did you use an LLM to create this issue?

No, I discovered the topic per coincidence but now I’m eager to understand it.

If so, please don't. Just write what you observed in your own words. And don't try to guess what the root cause is if you don't know how to debug it yourself. That only causes confusion.

OK I’m now rebuilding with GCC-17.0.0 plus attached bootstrap.toml. The SIGSEGV is popping up usually during stage 2 With Best Regards, Erich P.S.: this humble mail is none LLM made. <details> <summary>Here attached my bootstrap.toml</summary> <code> change-id = "ignore" # Use different pre-set defaults than the global defaults. # # See `src/bootstrap/defaults` for more information. # Note that this has no default value (x.py uses the defaults in `bootstrap.example.toml`). profile = 'dist' [llvm] # Use the prebuilt LLVM material download-ci-llvm = true [gcc] [build] # Which triples to produce a compiler toolchain for. Each of these triples will be bootstrapped from # the build triple themselves. In other words, this is the list of triples for which to build a # compiler that can RUN on that triple. # # Defaults to just the `build` triple. host = ['x86_64-unknown-linux-gnu'] # Arguments passed to the `./configure` script, used during distcheck. You # probably won't fill this in but rather it's filled in by the `./configure` # script. Useful for debugging. configure-args = ['--host=x86_64-unknown-linux-gnu', '--prefix=/usr'] [install] # Where to install the generated toolchain. Must be an absolute path. prefix = '/usr' [rust] [dist] [target.x86_64-unknown-linux-gnu] #linker = "/usr/local/bin/clang" linker = "/usr/bin/gcc" # nothing specific rustflags = [] # We go with GCC 17.0.0 cc = "/usr/bin/gcc" cxx = "/usr/bin/g++" # And finally calling x.py like this # ./x.py build --jobs 16 </code> </details>

[workingjubilee]

• Simple: I read the code of conduct notes and there it is stated the BUG report shall not be flooded with details

You can just hide excess details behind a <details> element because Markdown is HTML

[ErichLoew]

I’ll do so Von: Jubilee ***@***.***> Gesendet: Montag, 3. August 2026 23:23 An: rust-lang/rust ***@***.***> Cc: ErichLoew ***@***.***>; Author ***@***.***> Betreff: Re: [rust-lang/rust] Cross-Language ABI Desynchronization (Vtable/Padding mismatch) in rustc_codegen_llvm during Stage 1 Bootstrap when utilizing size-optimized (-Os) host toolchains (Issue #160393) <https://avatars.githubusercontent.com/u/46493976?s=20&v=4> workingjubilee left a comment (rust-lang/rust#160393) <#160393 (comment)> * Simple: I read the code of conduct notes and there it is stated the BUG report shall not be flooded with details You can just hide excess details behind a <details> element because Markdown is HTML — Reply to this email directly, view it on GitHub <#160393?email_source=notifications&email_token=AW7UPG4XZJHAWPF7QNQ7C435ID7CDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJXGE4DOOBSGUZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5171878252> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AW7UPG5EIXKARJG4AWNTM2L5ID7CDAVCNFSNUABCKJSXA33TNF2G64TZHM3TENBXGEZDWSLTON2WKOZVGA2DGOBTGU3DOMNBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AW7UPGZJRUVUCWFR2AVDEHD5ID7CDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJXGE4DOOBSGUZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AW7UPG7DXWUUUWITF4H5EV35ID7CDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJXGE4DOOBSGUZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA> . Download it today! You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AW7UPG7DS5ZXB5GRLB4VHYT5ID7CDBFCNFSM6AAAAAC4XAY44SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACNCETFWKM4TFMFZW63VGMF2XI2DPOI.gif> Message ID: ***@***.*** ***@***.***> >

[workingjubilee]

...Well apparently the rich text formatting you used when sending the email is sufficiently good at breaking GitHub's markdown/HTML parser so that doesn't work, actually.

[workingjubilee]

@ErichLoew .pdf is an executable format and can run code when opened. While this is somewhat contained so it can't simply run completely arbitrary code, it's... a lot, and you should avoid submitting things that are not .txt files as attached items to this bug tracker because we do in fact deal with a fair amount of malware and rarely have a need for sophisticated text formats.

[workingjubilee]

I'm renaming your issue because your issue title spends a lot of time on describing what you think is the cause which is, as bjorn said, probably wrong. Code compiled at different optimization settings must adhere to the same ABI. If the binding code has its ABI changed because of an optimization setting, that's a bug in the C compilers in question.

Two Intel CPUs that postdate the 64-bit era are not significantly different enough to draw a conclusion about "multiple different architectures", but also they should not matter.

[workingjubilee]

4. This causes a reproducible SIGSEGV / 100% CPU infinite loop inside WriteBackendMethods::optimize during Stage 1 on multiple distinct hardware architectures (Intel i5 & Core 2 Duo).

You say "SIGSEGV" and "infinite loop". Those are two very different things. Please pick one.

If these behaviors are different on different microarchitectures, you have not ruled out the possibility of defective hardware.

[ErichLoew]

Hi Workingjubilee,

Very THX for improving my wording and scratching out redundant stanzas!

I'm right now rebuilding on my I5 RUSTC latest with "download-ci-llvm = false" using gcc-17.0.0 and the attached bootstrap.toml. Needs some time...