https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=lcnr/rustc-dev-guide 2025-08-13T16:43:02+00:00 2025-08-13T16:43:02+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-08-13T16:43:02+00:00 urn:sha1:a6146fddcf87653df30cb3b8a99ce2784b4de055 [AVR] Changed data_layout This change is required when https://github.com/llvm/llvm-project/commit/97f0ff0c80407adee693436b44e55ededfcd5435 gets included in the Rust llvm tree, because it changes the AVR data-layout 2025-08-13T04:18:43+00:00 bors bors@rust-lang.org 2025-08-13T04:18:43+00:00 urn:sha1:b1b26b834d85e84b46aa8f8f3ce210a1627aa85f Set dead_on_return attribute for indirect arguments Set the dead_on_return attribute (added in LLVM 21) for arguments that are passed indirectly, but not byval. This indicates that the value of the argument on return does not matter, enabling additional dead store elimination. From LangRef: > This attribute indicates that the memory pointed to by the argument is dead upon function return, both upon normal return and if the calls unwinds, meaning that the caller will not depend on its contents. Stores that would be observable either on the return path or on the unwind path may be elided. > > Specifically, the behavior is as-if any memory written through the pointer during the execution of the function is overwritten with a poison value upon function return. The caller may access the memory, but any load not preceded by a store will return poison. > > This attribute does not imply aliasing properties. For pointer arguments that do not alias other memory locations, noalias attribute may be used in conjunction. Conversely, this attribute always implies dead_on_unwind. > > This attribute cannot be applied to return values. This fixes parts of https://github.com/rust-lang/rust/issues/96497. 2025-08-12T06:33:27+00:00 Tom Vijlbrief tvijlbrief@gmail.com 2025-08-11T09:19:47+00:00 urn:sha1:2563e4a7ffe47e93c69283c14e6d660b08834cf1 2025-08-11T10:39:23+00:00 Nikita Popov npopov@redhat.com 2025-08-08T10:39:30+00:00 urn:sha1:ebef9d7f6387fb0541a0dab48d1cd1f86556df04 Set the dead_on_return attribute (added in LLVM 21) for arguments that are passed indirectly, but not byval. This indicates that the value of the argument on return does not matter, enabling additional dead store elimination. 2025-08-09T04:59:28+00:00 Scott McMurray scottmcm@users.noreply.github.com 2025-08-09T04:59:28+00:00 urn:sha1:8831c5b9946561a37dc7ee6fd826ef1470e8f380 2025-08-08T19:22:47+00:00 Trevor Gross t.gross35@gmail.com 2025-08-08T19:22:47+00:00 urn:sha1:660bf919dc5dec96d319cce59702b0355bd8452c Enable f16 and f128 on targets that were fixed in LLVM21 LLVM21 fixed the new float types on a number of targets: * SystemZ gained f16 support https://github.com/llvm/llvm-project/pull/109164 * Hexagon now uses soft f16 to avoid recursion bugs https://github.com/llvm/llvm-project/pull/130977 * Mips now correctly handles f128 (actually since LLVM20) https://github.com/llvm/llvm-project/pull/117525 * f128 is now correctly aligned when passing the stack on x86 https://github.com/llvm/llvm-project/pull/138092 Thus, enable the types on relevant targets for LLVM > 21.0.0. NVPTX also gained handling of f128 as a storage type, but it lacks support for basic math operations so is still disabled here. try-job: dist-i586-gnu-i586-i686-musl try-job: dist-i686-linux try-job: dist-i686-msvc try-job: dist-s390x-linux try-job: dist-various-1 try-job: dist-various-2 try-job: dist-x86_64-linux try-job: i686-gnu-1 try-job: i686-gnu-2 try-job: i686-msvc-1 try-job: i686-msvc-2 try-job: test-various 2025-08-08T19:22:44+00:00 Trevor Gross t.gross35@gmail.com 2025-08-08T19:22:44+00:00 urn:sha1:6fa6a854cd791e9efa813e9b18cd1a5337ded971 atomicrmw on pointers: move integer-pointer cast hacks into backend Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere. This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely. Cc ```@nikic``` -- this is the best we can do right now, right? Fixes https://github.com/rust-lang/rust/issues/134617 2025-08-08T02:52:57+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-08-08T02:52:57+00:00 urn:sha1:432a4f27fe5f1703af0277cd6b2e855ec47996f4 Prevent name collisions with internal implementation details The implementation of the linkage attribute inside extern blocks defines symbols starting with _rust_extern_with_linkage_. If someone tries to also define this symbol you will get a symbol conflict or even an ICE. By adding an unpredictable component to the symbol name, this becomes less of an issue. Spawned from the discussion at [#t-compiler > About static variables `_rust_extern_with_linkage_*`](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/About.20static.20variables.20.60_rust_extern_with_linkage_*.60) cc `@ywxt` Fixes https://github.com/rust-lang/rust/issues/144940 2025-08-08T02:52:54+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-08-08T02:52:54+00:00 urn:sha1:562222b73765a326fa800a075814deaf627874df coverage: Remove all unstable support for MC/DC instrumentation Preliminary support for a partial implementation of “Modified Condition/Decision Coverage” instrumentation was added behind the unstable flag `-Zcoverage-options=mcdc` in 2024. These are the most substantial PRs involved: - rust-lang/rust#123409 - rust-lang/rust#126733 At the time, I accepted these PRs with relatively modest scrutiny, because I did not want to stand in the way of independent work on MC/DC instrumentation. My hope was that ongoing work by interested contributors would lead to the code becoming clearer and more maintainable over time. --- However, that MC/DC code has proven itself to be a major burden on overall maintenance of coverage instrumentation, and a major obstacle to other planned improvements, such as internal changes needed for proper support of macro expansion regions. I have also become reluctant to accept any further MC/DC-related changes that would increase this burden. That tension has resulted in an unhappy impasse. On one hand, the present MC/DC implementation is not yet complete, and shows little sign of being complete at an acceptable level of code quality in the foreseeable future. On the other hand, the continued existence of this partial MC/DC implementation is imposing serious maintenance burdens on every other aspect of coverage instrumentation, and is preventing some of the very improvements that would make it easier to accept expanded MC/DC support in the future. While I know this will be disappointing to some, I think the healthy way forward is accept that I made the wrong call in accepting the current implementation, and to remove it entirely from the compiler. 2025-08-07T20:34:49+00:00 Trevor Gross tmgross@umich.edu 2025-08-06T08:57:14+00:00 urn:sha1:cdb299c0d8463d7e66b680e93c8d0d7258fc7643 LLVM21 fixed the new float types on a number of targets: * SystemZ gained f16 support https://github.com/llvm/llvm-project/pull/109164 * Hexagon now uses soft f16 to avoid recursion bugs https://github.com/llvm/llvm-project/pull/130977 * Mips now correctly handles f128 (actually since LLVM20) https://github.com/llvm/llvm-project/pull/117525 * f128 is now correctly aligned when passing the stack on x86 https://github.com/llvm/llvm-project/pull/138092 Thus, enable the types on relevant targets for LLVM > 21.0.0. NVPTX also gained handling of f128 as a storage type, but it lacks support for basic math operations so is still disabled here.