Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853

dbachelot · 2023-03-07T09:57:09Z

After updating to the latest version of Rust, I found that many of my projects are failing to compile at linking stage when doing size-optimized builds (cf. https://github.com/johnthagen/min-sized-rust). I found the possible nightly-to-nightly regression to be from nightly-2023-02-27 to nightly-2023-02-28. This seems to be a real issue since min-sized builds are widely used. Also I failed to reproduce this in a toy project.

To trigger that "bug" I used these compiler flags:

OPTI_FLAGS="-C link-dead-code=n -C lto=fat -C opt-level=z -C embed-bitcode=yes -C panic=abort"
OPTI_ARGS="-Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort"

# for linux you might want to use -C panic=abort to overpass another bug

RUSTFLAGS=$OPTI_FLAGS cargo +nightly build --target x86_64-unknown-linux-gnu --release $OPTI_ARGS
RUSTFLAGS=$OPTI_FLAGS XWIN_ARCH="x86_64" XWIN_CACHE_DIR="/tmp/xwin_64" cargo +nightly xwin build --target x86_64-pc-windows-msvc --release $OPTI_ARGS

Possible linked issues:

I tried to build those projects with the latest working nightly (nightly-2023-02-27) and the first non-working nightly (nightly-2023-02-28):

RustHound (https://github.com/OPENCYBER-FR/RustHound - 534 stars)
RustScan (https://github.com/RustScan/RustScan - 9.4k stars)
Helix (https://github.com/helix-editor/helix - 19.6k stars)

I expected to see this happen: build succeed in both cases.

Instead, this happened: linker errors on the first non-working nightly (nightly-2023-02-28) and compile success with the latest working nightly (nightly-2023-02-27). This show a possible regression.

For RustHound (using nightly-2023-02-28):

Compile error

   Compiling rusthound v1.1.62 (/$USER/Projets/XXX/RustHound)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/$USER/.local/bin:/$USER/.cargo/bin:/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcAWOQqQ/symbols.o" "/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps/rusthound.rusthound.4bfd0cff-cgu.3.rcgu.o" "/LIBPATH:/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/$USER/Projets/XXX/RustHound/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/$USER/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/windows_x86_64_msvc-0.42.1/lib" "/LIBPATH:/$USER/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/windows_x86_64_msvc-0.34.0/lib" "/LIBPATH:/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/build/ring-175a80523169bc78/out" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcAWOQqQ/libring-98a43d4a731d3bc1.rlib" "/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-a57aa224b6747535.rlib" "windows.lib" "windows.lib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "runtimeobject.lib" "secur32.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps/rusthound.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::ha70d088502189c5c
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h75be24e30ae66717)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h2923ea1dd2188a7b)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::h3facc516142b808f
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::hc9f2c5447bea3c19)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::ha0c8059f27d2ee43)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hc3c814c714409716
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h5da56a5404567510)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::he654838393c6dac6)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.7.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem::hb22b2448b8f01ed2)
          

error: could not compile `rusthound` due to previous error

For RustScan (using nightly-2023-02-28):

Compile error

   Compiling rustscan v2.1.1 (/$USER/Projets/XXX/RustScan)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/$USER/.local/bin:/$USER/.cargo/bin:/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcMAAVJR/symbols.o" "/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.rustscan.2fa56812-cgu.0.rcgu.o" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/wepoll-ffi-719df429f6c384f7/out" "/LIBPATH:/$USER/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/windows_x86_64_msvc-0.42.0/lib" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/ring-a690ee922a6572a9/out" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcMAAVJR/libring-188f86f2fd8f068a.rlib" "/tmp/rustcMAAVJR/libwepoll_ffi-48d31142813b117f.rlib" "/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-18ed03317118022b.rlib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "secur32.lib" "shell32.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hf83a56f591ad91c2
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::he7ed35977b0d0fac)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h00538ae7c426f37f)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hae711d779ec4e591
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h659e210b754e206f)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h970afb9c096c3a26)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::h183171ab1b2751dc
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h6c6b22f19a38a7e4)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::hb512d2478bac3150)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.7.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem::h4103159706e15559)
          

error: could not compile `rustscan` due to previous error

For Helix (using nightly-2023-02-28):

Compile error

   Compiling helix-tui v0.6.0 (/$USER/Projets/XXX/Helix/helix-tui)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/$USER/.local/bin:/$USER/.cargo/bin:/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcIC5pT0/symbols.o" "/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps/hx.hx.97f34d47-cgu.12.rcgu.o" "/LIBPATH:/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/$USER/Projets/XXX/Helix/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/$USER/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/windows_x86_64_msvc-0.42.1/lib" "/LIBPATH:/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/build/tree-sitter-2a9907837c51abd5/out" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcIC5pT0/libtree_sitter-846e7dfbf9fccdfd.rlib" "/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-15b4049fca2c0d34.rlib" "windows.lib" "ntdll.lib" "legacy_stdio_definitions.lib" "windows.lib" "kernel32.lib" "advapi32.lib" "ole32.lib" "oleaut32.lib" "bcrypt.lib" "windows.lib" "advapi32.lib" "cfgmgr32.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "runtimeobject.lib" "shell32.lib" "shlwapi.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps/hx.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hc27fcf92225fa76d
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::hde1da1a440758e53)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h69f3e9a4cec906c3)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hc09440a623908dd2
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h8fa431404ce61bc8)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h66ae3ce6d28d7dc9)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hcee917ca27ced0ac
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h51b6ed721278058c)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h337b670af4036651)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.7.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem::hc40953c0c14b372c)
          

error: could not compile `helix-term` due to previous error

Please note that I used windows cross compilation builds as an example, ~~but same thing can happen with other targets (even when not cross-compiling)~~. Also note that the linking errors can be different regarding the selected target.

After some more tests with Linux (and checking this issue), I found that we need to add -C panic=abort to overpass another linking issue (cf. #107016 (comment)). This doesn't resolve the issue for Windows cross-compilation however.

The text was updated successfully, but these errors were encountered:

tmiasko · 2023-03-07T10:40:03Z

A few things you could try:

Use -Csymbol-mangling-version=v0 (for more informative symbol names, not because it will fix the issue in itself).
Build with -Ccodegen-units=1

Add #[inline] annotation to the following function in the core (and then clean & rebuild)

rust/library/core/src/convert/mod.rs

Lines 781 to 783 in 8f9e09a

    
           fn try_from(value: U) -> Result<Self, Self::Error> { 
        
               Ok(U::into(value)) 
        
           }

If the last suggestion helps, please mention this in rust-lang/compiler-builtins#491.

dbachelot · 2023-03-07T10:46:18Z

I tested 1&2 and got:

Compile error

   Compiling rustscan v2.1.1 (/home/$USER/Projets/XXX/RustScan)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/home/$USER/.local/bin:/home/$USER/.cargo/bin:/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustc3sx4fq/symbols.o" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.rustscan.73ae6a84-cgu.0.rcgu.o" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/wepoll-ffi-719df429f6c384f7/out" "/LIBPATH:/home/$USER/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/windows_x86_64_msvc-0.42.0/lib" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/ring-a690ee922a6572a9/out" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustc3sx4fq/libring-7aca1892b1101c44.rlib" "/tmp/rustc3sx4fq/libwepoll_ffi-b138a1eba95895ba.rlib" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-83400d04a98abbd8.rlib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "secur32.lib" "shell32.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u32>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i32 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u32 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u8>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i8 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u8 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u16>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i16 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u16 as compiler_builtins::int::Int>::wrapping_shl)
          

error: could not compile `rustscan` due to previous error

(PS: I'm currently testing 3)

dbachelot · 2023-03-07T11:11:01Z

Adding #[inline] on the try_from implementation in core doesn't seem to change anything.

tmiasko · 2023-03-07T12:11:25Z

One more suggestion: ensure that -Zshare-generics=off is used when building compiler-builtins (-C opt-level=z implies -Zshare-generics=on, which looks like the root cause of the problem here):

cargo-features = ["profile-rustflags"]

[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

(Update the profile name as appropriate).

dbachelot · 2023-03-07T12:54:26Z

Thank you, this fix the issue! Is this considered a regression or can we close the issue?

pnkfelix · 2023-03-07T20:05:53Z

The fact that we need to use a -Z flag to work around the problem implies that we cannot close the issue. -Z flags aren't available to stable Rust users.

pnkfelix · 2023-03-07T20:10:26Z

Is there a variant of this that demonstrates the problem described here without using any -Z flags at all?

pnkfelix · 2023-03-07T20:12:42Z

(if we can gain confidence that this always requires some -Z flag to be observed, then we can remove the regression labels. But I'm not confident right now; I don't think -C opt-level=z gets a terrible amount of testing in our CI....)

saethlin · 2023-03-07T22:37:22Z

FWIW, I see opt=level = "z" used a shocking amount among embedded developers (and by that I mean it seems like every single time someone links me an embedded Rust project they have set this option), and I also hear a lot of grousing from people like @thomcc about unnecessarily poor optimizations under that setting.

So even setting the present issue aside, it seems to me like we have a mismatch in the amount of use versus the amount of care or investment that's put into this behavior of this option.

thomcc · 2023-03-07T22:41:32Z

Yeah, even aside from embedded, I can only speak personally, but a very large number of the Rust projects I've worked on professionally (most of which are not embedded) compile with s or z, to help mitigate the size of compiled Rust code¹.

Either way, it would be good to test them in CI, although I can imagine that doing so might be painful.

Sadly, this sometimes causes the size to be larger than with "3"... since idiomatic Rust code heavily relies on inlining, which those opt levels avoid 😔... This is very off-topic though. ↩

dbachelot · 2023-03-08T08:36:32Z

Is there a variant of this that demonstrates the problem described here without using any -Z flags at all?

From what I tested this issue is (only) triggered by -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort since this will build compiler_builtins, core and std with provided optimizations. When used with opt-level=z this will enable share-generics by default and since compiler_builtins need to have it off to avoid linking issues with lto this trigger the compile error (maybe linked to rust-lang/compiler-builtins#491). So yeah, I think this problem will only happen when using -Z flags.

However please note that these flags are used by a lot of projects (even ones targeting stable) to make size-optimized builds (cf. https://github.com/johnthagen/min-sized-rust).

apiraino · 2023-03-08T10:15:35Z

WG-prioritization assigning priority (Zulip discussion).

I wonder if a smaller reproducible can help (seems the topic of opt. flags is somewhat wide), tentatively setting that label either.

@rustbot label -I-prioritize +P-high +E-needs-mcve

saethlin · 2023-03-08T17:33:35Z

I'm pretty sure the problem is that you are trying to use the unwinding panic runtime with panic_immediate_abort. If you pass -Cpanic=abort, things should work.

I believe this is exactly the same issue as #107016

I do not really know why unwinding panics with panic_immediate_abort ever compiled. And in any case, if you're looking for a minimally-sized artifact, you should compile with aborting panics.

dbachelot · 2023-03-08T17:52:23Z

I'm pretty sure the problem is that you are trying to use the unwinding panic runtime with panic_immediate_abort. If you pass -Cpanic=abort, things should work.

I believe this is exactly the same issue as #107016

I do not really know why unwinding panics with panic_immediate_abort ever compiled. And in any case, if you're looking for a minimally-sized artifact, you should compile with aborting panics.

As pointed out in my initial post, I removed -C panic=abort to minimize flags to a minimum, but this issue also appears when using it and cross-compiling (as discussed in the last part of my initial message). However, since I agree that it should not compile without it (another issue #107016) and that this can confuse people, I edited my message and added it

tldr; this doesn't fix the issue

saethlin · 2023-03-08T18:17:24Z

Interesting. I can get linker errors when compiling RustHound and helix without -Cpanic=abort, but with the flag, they link just fine. RustScan always seems to build.

(I'm only testing with nightly-2023-02-28)

dbachelot · 2023-03-09T07:24:38Z

Interesting. I can get linker errors when compiling RustHound and helix without -Cpanic=abort, but with the flag, they link just fine. RustScan always seems to build.

(I'm only testing with nightly-2023-02-28)

Do you have the exact compile line used? It's important to note that this seems to only happen when cross-compiling. For example, let's take RustScan:

Building for i686-unknown-linux-gnu:

Compile error

Compiling rustscan v2.1.1 (/home/$USER/Projets/XXX/RustScan)
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/home/$USER/.local/bin:/home/$USER/.cargo/bin:/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" VSLANG="1033" "cc" "-m32" "/tmp/rustcxtfFc3/symbols.o" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/rustscan-8069d2dff506ca4d.rustscan.a822f4a7-cgu.0.rcgu.o" "-Wl,--as-needed" "-L" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps" "-L" "/home/$USER/Projets/XXX/RustScan/target/release/deps" "-L" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/build/ring-b1a3c9ae3ccb6cc9/out" "-L" "/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/rustcxtfFc3/libring-a85cb11ce5dd843d.rlib" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/libcompiler_builtins-e8354e5232d2c05a.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-linux-gnu/lib" "-o" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/rustscan-8069d2dff506ca4d" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: /usr/bin/ld: /home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/libcompiler_builtins-e8354e5232d2c05a.rlib(compiler_builtins-e8354e5232d2c05a.compiler_builtins.e77cb671-cgu.0.rcgu.o): in function `<u32 as compiler_builtins::int::Int>::logical_shr':
          compiler_builtins.e77cb671-cgu.0:(.text._RNvXs4_NtCsg8UtXzRGVrx_17compiler_builtins3intmNtB5_3Int11logical_shr+0x1e): undefined reference to `<u32 as core::convert::TryInto<u32>>::try_into'
          /usr/bin/ld: /home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/libcompiler_builtins-e8354e5232d2c05a.rlib(compiler_builtins-e8354e5232d2c05a.compiler_builtins.e77cb671-cgu.0.rcgu.o): in function `<u32 as compiler_builtins::int::Int>::wrapping_shl':
          compiler_builtins.e77cb671-cgu.0:(.text._RNvXs4_NtCsg8UtXzRGVrx_17compiler_builtins3intmNtB5_3Int12wrapping_shl+0x1e): undefined reference to `<u32 as core::convert::TryInto<u32>>::try_into'
          collect2: error: ld returned 1 exit status
          
  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `rustscan` due to previous error

Building for x86_64-pc-windows-msvc:

Compile error

   Compiling rustscan v2.1.1 (/home/$USER/Projets/XXX/RustScan)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/home/$USER/.local/bin:/home/$USER/.cargo/bin:/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcAlAIfz/symbols.o" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.rustscan.73ae6a84-cgu.0.rcgu.o" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/wepoll-ffi-719df429f6c384f7/out" "/LIBPATH:/home/$USER/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/windows_x86_64_msvc-0.42.0/lib" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/ring-a690ee922a6572a9/out" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcAlAIfz/libring-7aca1892b1101c44.rlib" "/tmp/rustcAlAIfz/libwepoll_ffi-b138a1eba95895ba.rlib" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-83400d04a98abbd8.rlib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "secur32.lib" "shell32.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u32>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i32 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u32 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u8>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i8 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u8 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u16>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i16 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u16 as compiler_builtins::int::Int>::wrapping_shl)
          

error: could not compile `rustscan` due to previous error

I used those flags for compilation:

OPTI_FLAGS="-C link-dead-code=n -C lto=fat -C opt-level=z -C embed-bitcode=yes -C panic=abort -C symbol-mangling-version=v0 -C codegen-units=1"
OPTI_ARGS="-Z build-std=core,std,panic_abort -Z build-std-features=panic_immediate_abort"

Please also note that I confirm this worked prior to nightly-2023-02-28. Furthermore, we can see in #108893 the same issue which isn't about the -C panic=abort + panic_immediate_abort use case, but is more about cross compiling for embedded development. The common points among these cases are -Z build-std=std and share-generics (regarding compiler_builtins as pointed out by @tmiasko).

Work-around for [rust-lang/rust#108853][1] suggested [here][2]. Fixes undefined symbol errors in the `report-size` CI workflow. [1]: rust-lang/rust#108853 [2]: rust-lang/rust#108853 (comment)

rust-lang/rust#108853

This works around rust-lang/rust#108853 by using an `opt-level` of `3` rather than `s`. - [x] Changelog updated / no changelog update needed

cr1901 · 2023-03-26T20:49:52Z

One more suggestion: ensure that -Zshare-generics=off is used when building compiler-builtins (-C opt-level=z implies -Zshare-generics=on, which looks like the root cause of the problem here):
cargo-features = ["profile-rustflags"]

[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]
(Update the profile name as appropriate).

FWIW this does not work for me; maybe b/c I'm part of a workspace, when I put this at the top-level Cargo.toml, I get "warning: profile package spec compiler_builtins in profile release did not match any packages". On the other hand, the solution here, enabling rustflags = ["-Zshare-generics=off"] unconditionally does work.

This issue is essentially a showstopper bug for my msp430 work, so even a working unstable solution to reenable LTO like above will unblock me. If I have time, I'll do my own bisection; for some reason I'm unable to duplicate this bug on Linux on the same codebase with a nightly that's a week or two behind Windows.

dbachelot · 2023-03-27T06:43:24Z

Hi, here some precision about the workarounds:

The first workaround will disallow 'share-generics' (which is an optimization, see this) for all crates in your compilation tree: rustflags = ["-Zshare-generics=off"]. Since we want to disable the latter option when compiling compiler_builtins, this overpass the issue.
A better approach, however, allows us to just disable share-generics when compiling compiler_builtins. To do that we need to tell rustc to only pass a certain flag during compilation of the targeted crate. Here we are configuring cargo so we can't use the package manifest (the Cargo.toml file in the root folder of each package) and need to use the .cargo/config.toml file. Here, you can tell cargo to pass rustflags = ["-Zshare-generics=off"] only for the compiler_builtins package:

[unstable]
profile-rustflags = true

[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

Even if you use a workspace, you need to place this file in the root folder (more info here).

If you don't want to edit any file, for both solutions you can pass these options using the command line:

For the first workaround: cargo +nightly b -Zshare-generics=off [...]
And for the second: cargo +nightly b --config unstable.profile-rustflags=true --config profile.release.package.compiler_builtins.rustflags=['-Zshare-generics=off'] [...]

cr1901 · 2023-03-27T07:10:29Z

Okay, so the reason I got confused is: if Cargo.toml doesn't work at all, even from your workspace root, your .cargo/config.toml file needs to look something like this:

[profile.examples-fix]
inherits = "examples"

[profile.examples-fix.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

[unstable]
profile-rustflags = true

AFAICT, cargo-features = ["profile-rustflags"] is Cargo.toml only.

The example profile looks like this:

[profile.examples]
inherits = "release"
lto = "fat"
opt-level = "s"
codegen-units = 1

Adding a separate profile in config.toml allows me to use the stable compiler without getting a nice "you're using an unstable feature in stable" error, only going to nightly for targets where I'm using build-std explicitly. This is an alternate take on your command-line solution, but I like yours better. So I'll go ahead and steal yours and just leave this comment for completeness :).

cr1901 · 2023-03-31T06:51:43Z

So strangely, best we can work out, is that it all started failing in 6cb3449 which doesn't make any sense to us. But the commit before succeeds to build and this commit fails.

I did my own bisect tonight on my own codebase, thinking it was incredibly weird that this specific commit broke LTO.

But alas, I can confirm from my bisection that this is the exact commit where everything broke. I can't help but wonder if this is an LLVM bug in disguise, and this commit simply triggered an existing bug. But it's late right now, so I'll have to test that theory later.

Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. ＼（＾▽＾）／ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`

…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. ＼（＾▽＾）／ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`

…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`

Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`

…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`

wesleywiser · 2023-11-17T16:01:11Z

@tmiasko applied a work around to resolve this particular issue in PR #109983

…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`

dbachelot added the C-bug Category: This is a bug. label Mar 7, 2023

pnkfelix added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 7, 2023

estebank added regression-untriaged Untriaged performance or correctness regression. and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 7, 2023

rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Mar 7, 2023

estebank removed the regression-untriaged Untriaged performance or correctness regression. label Mar 7, 2023

pnkfelix added the regression-untriaged Untriaged performance or correctness regression. label Mar 7, 2023

gwilymk mentioned this issue Mar 8, 2023

Undefined reference in unchecked_shl function when compiling in release mode for thumbv4t-none-eabi #108893

Closed

rustbot added E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 8, 2023

apiraino added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. and removed regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Mar 9, 2023

corwinkuiper added a commit to corwinkuiper/agb-fork that referenced this issue Mar 23, 2023

workaround the rust issue

76b3aec

rust-lang/rust#108853

corwinkuiper mentioned this issue Mar 23, 2023

workaround the rust issue agbrs/agb#397

Merged

1 task

corwinkuiper added a commit to agbrs/agb that referenced this issue Mar 23, 2023

workaround the rust issue (#397)

4562c4e

This works around rust-lang/rust#108853 by using an `opt-level` of `3` rather than `s`. - [x] Changelog updated / no changelog update needed

DianQK mentioned this issue Mar 31, 2023

Fixes LTO + build-std + Oz failed to resolve undefined symbols #109821

Closed

5 tasks

DianQK mentioned this issue Apr 20, 2023

undefined reference to 'bar::add' with LTO and no_builtins #110606

Closed

pnkfelix added the A-linkage Area: linking into static, shared libraries and binaries label Jul 13, 2023

DianQK mentioned this issue Jul 21, 2023

Restore #![no_builtins] crates participation in LTO. #113923

Merged

bors closed this as completed in 8c2b577 Dec 1, 2023

gwilymk mentioned this issue Dec 5, 2023

Template fails to build with linker errors on newest nightly when using fat LTO agbrs/agb#521

Closed

cr1901 mentioned this issue Dec 8, 2023

Missing fields in SVD, e.g. WDTPW cr1901/msp430f5529#3

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853

Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853

dbachelot commented Mar 7, 2023 •

edited

Loading

tmiasko commented Mar 7, 2023

dbachelot commented Mar 7, 2023 •

edited

Loading

dbachelot commented Mar 7, 2023

tmiasko commented Mar 7, 2023

dbachelot commented Mar 7, 2023

pnkfelix commented Mar 7, 2023

pnkfelix commented Mar 7, 2023

pnkfelix commented Mar 7, 2023

saethlin commented Mar 7, 2023

thomcc commented Mar 7, 2023 •

edited

Loading

dbachelot commented Mar 8, 2023

apiraino commented Mar 8, 2023

saethlin commented Mar 8, 2023 •

edited

Loading

dbachelot commented Mar 8, 2023

saethlin commented Mar 8, 2023 •

edited

Loading

dbachelot commented Mar 9, 2023

cr1901 commented Mar 26, 2023 •

edited

Loading

dbachelot commented Mar 27, 2023 •

edited

Loading

cr1901 commented Mar 27, 2023 •

edited

Loading

cr1901 commented Mar 31, 2023

wesleywiser commented Nov 17, 2023

Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853

Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853

Comments

dbachelot commented Mar 7, 2023 • edited Loading

tmiasko commented Mar 7, 2023

dbachelot commented Mar 7, 2023 • edited Loading

dbachelot commented Mar 7, 2023

tmiasko commented Mar 7, 2023

dbachelot commented Mar 7, 2023

pnkfelix commented Mar 7, 2023

pnkfelix commented Mar 7, 2023

pnkfelix commented Mar 7, 2023

saethlin commented Mar 7, 2023

thomcc commented Mar 7, 2023 • edited Loading

Footnotes

dbachelot commented Mar 8, 2023

apiraino commented Mar 8, 2023

saethlin commented Mar 8, 2023 • edited Loading

dbachelot commented Mar 8, 2023

saethlin commented Mar 8, 2023 • edited Loading

dbachelot commented Mar 9, 2023

cr1901 commented Mar 26, 2023 • edited Loading

dbachelot commented Mar 27, 2023 • edited Loading

cr1901 commented Mar 27, 2023 • edited Loading

cr1901 commented Mar 31, 2023

wesleywiser commented Nov 17, 2023

dbachelot commented Mar 7, 2023 •

edited

Loading

dbachelot commented Mar 7, 2023 •

edited

Loading

thomcc commented Mar 7, 2023 •

edited

Loading

saethlin commented Mar 8, 2023 •

edited

Loading

saethlin commented Mar 8, 2023 •

edited

Loading

cr1901 commented Mar 26, 2023 •

edited

Loading

dbachelot commented Mar 27, 2023 •

edited

Loading

cr1901 commented Mar 27, 2023 •

edited

Loading