https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.78.0 2024-03-14T19:00:18+00:00 2024-03-14T19:00:18+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-14T19:00:18+00:00 urn:sha1:722514f46626bbc1af8525f8f31c9a089f5b4f0f Copy byval argument to alloca if alignment is insufficient Fixes #122211 "Ignore whitespace" recommended. 2024-03-13T05:57:23+00:00 guoguangwu guoguangwug@gmail.com 2024-03-13T05:57:23+00:00 urn:sha1:ee8efd705b72584f7dff96a6c833b209b89d0b1e Signed-off-by: guoguangwu <guoguangwug@gmail.com> 2024-03-12T08:30:46+00:00 bors bors@rust-lang.org 2024-03-12T08:30:46+00:00 urn:sha1:5b7343b96681c93f6fe752b46d9427f9dee8f94b Rename `wasm32-wasi-preview1-threads` to `wasm32-wasip1-threads` This commit renames the current `wasm32-wasi-preview1-threads` target to `wasm32-wasip1-threads`. The need for this rename is a bit unfortunate as the previous name was chosen in an attempt to be future-compatible with other WASI targets. Originally this target was proposed to be `wasm32-wasi-threads`, and that's what was originally implemented in wasi-sdk as well. After discussion though and with the plans for the upcoming component-model target (now named `wasm32-wasip2`) the "preview1" naming was chosen for the threads-based target. The WASI subgroup later decided that it was time to drop the "preview" terminology and recommends "pX" instead, hence previous PRs to add `wasm32-wasip2` and rename `wasm32-wasi` to `wasm32-wasip1`. So, with all that history, the "proper name" for this target is different than its current name, so one way or another a rename is required. This PR proposes renaming this target cold-turkey, unlike `wasm32-wasi` which is having a long transition period to change its name. The threads-based target is predicted to see only a fraction of the traffic of `wasm32-wasi` due to the unstable nature of the WASI threads proposal itself. While I was here I updated the in-tree documentation in the target spec file itself as most of the documentation was copied from the original WASI target and wasn't as applicable to this target. Also, as an aside, I can at least try to apologize for all the naming confusion here, but this is hopefully the last WASI-related rename. 2024-03-12T05:29:05+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-12T05:29:05+00:00 urn:sha1:7b29381c8a606072f3941248cfa380ba568891d0 Update /NODEFAUTLIB comment for msvc I've tried to explain a bit more about the effects of `/NODEFAULTLIB` when using msvc link.exe (or compatible) as they're different from `-nodefaultlib` on gnu. I also removed the part about licensing as I'm not sure licensing is an issue? Or rather, it's no more or less of an issue no matter how you link msvc libraries. The license is the one you get if using VS at all and even dynamic linking includes static code (e.g. startup/shutdown code, etc). r? petrochenkov 2024-03-12T05:29:02+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-03-12T05:29:02+00:00 urn:sha1:60ab300d47c1a4923e69302fc2ea307236ef2d94 Update Windows platform support This should not be merged until Rust 1.76 but I'm told this may need an fcp in addition to [MCP 651](https://github.com/rust-lang/compiler-team/issues/651). cc ```@rust-lang/compiler``` ```@rust-lang/release``` 2024-03-11T18:31:50+00:00 Chris Denton chris@chrisdenton.dev 2024-03-11T18:12:51+00:00 urn:sha1:aeec0d1269eebb5319d798d403bd3c78f2303a23 2024-03-11T17:50:33+00:00 Chris Denton chris@chrisdenton.dev 2024-03-10T15:35:35+00:00 urn:sha1:779ac6951f8bd03e1fa5214d1637de9e5e5e8a7f 2024-03-11T16:31:41+00:00 Alex Crichton alex@alexcrichton.com 2024-03-08T02:01:45+00:00 urn:sha1:e1e9d38f5851694d9901cc5e71d84d5e7404b555 This commit renames the current `wasm32-wasi-preview1-threads` target to `wasm32-wasip1-threads`. The need for this rename is a bit unfortunate as the previous name was chosen in an attempt to be future-compatible with other WASI targets. Originally this target was proposed to be `wasm32-wasi-threads`, and that's what was originally implemented in wasi-sdk as well. After discussion though and with the plans for the upcoming component-model target (now named `wasm32-wasip2`) the "preview1" naming was chosen for the threads-based target. The WASI subgroup later decided that it was time to drop the "preview" terminology and recommends "pX" instead, hence previous PRs to add `wasm32-wasip2` and rename `wasm32-wasi` to `wasm32-wasip1`. So, with all that history, the "proper name" for this target is different than its current name, so one way or another a rename is required. This PR proposes renaming this target cold-turkey, unlike `wasm32-wasi` which is having a long transition period to change its name. The threads-based target is predicted to see only a fraction of the traffic of `wasm32-wasi` due to the unstable nature of the WASI threads proposal itself. While I was here I updated the in-tree documentation in the target spec file itself as most of the documentation was copied from the original WASI target and wasn't as applicable to this target. Also, as an aside, I can at least try to apologize for all the naming confusion here, but this is hopefully the last WASI-related rename. 2024-03-11T16:29:32+00:00 Jubilee 46493976+workingjubilee@users.noreply.github.com 2024-03-11T16:29:32+00:00 urn:sha1:e1ceadcdfeccc879ef5c1759dcc62daa2c7a6de8 LLVM Bitcode Linker: A self contained linker for nvptx and other targets This PR introduces a new linker named `llvm-bitcode-linker`. It is a `self-contained` linker that can be used to link programs in `llbc` before optimizing and compiling to native code. It will first be used internally in the Rust compiler to enable tests for the `nvptx64-nvidia-cuda` target as the original `rust-ptx-linker` is deprecated. It will then be provided to users of the `nvptx64-nvidia-cuda` target with the purpose of linking ptx. More targets than nvptx will also be supported eventually. The PR introduces a new unstable `LinkerFlavor` for the compiler. The compiler will also not be shipped with rustc but most likely instead be shipped in it's own unstable component (a follow up PR will be opened for this). This means that merging this PR should not add any stability guarantees. When more details of `self-contained` is implemented it will only be possible to use the linker when `-Clink-self-contained=+linker` is passed. <details> <summary>Original Description</summary> **When this PR was created it was focused a bit differently. The original text is preserved here in case there's some interests in it** I have experimenting with approaches to replace the ptx-linker and enable the nvptx target tests again. I think it's time to get some feedback on the approach. ### The problem The only useful linker for the nvptx target is [this crate](https://github.com/denzp/rust-ptx-linker). Since this linker performs linking on llvm bitcode it needs to track the llvm version of rustc and use the same format. It has not been maintained for 3+ years and must be considered abandoned. Over the years rust have upgraded LLVM while the linker has been left to bitrot. It is no longer in a usable state. Due to the difficulty of keeping the ptx-linker up to date outside of tree the nvptx tests was [disabled a long time ago](https://github.com/rust-lang/rust/commit/f8f9a2869cce570c994d96afb82f4162b1b44cca). It was [previously discussed](https://github.com/rust-lang/rust/pull/96842#issuecomment-1146470177) if adding the ptx-linker to the rust repo would be a possibility. My efforts in doing this stopped at getting an answered if the license would prohibit it from inclusion in the [Rust repo](https://github.com/rust-lang/rust/pull/96842#issuecomment-1148397554). I therefore concluded that a re-write would be necessary. ### The possible solution presented here The llvm tools know perfectly well how to link and optimize llvm bitcode. Each of them only perform a single task, and are therefore a bit cumbersome to call with the current linker approach rustc takes. This PR adds a simple tool (current name `embedded-linker`) which can link self contained (often embedded) programs in llvm bitcode before compiling to the target format. Optimization will also be performed if lto is enabled. The rust compiler will make a single invocation to this tool, while the tool will orchestrate the many calls to the llvm tools. ### The questions - Is having control over the nvptx linking and therefore also tests worth it to add such tool? or should the tool live outside the rust repo? - Is the approach of calling llvm tools acceptable? Or would we want to keep the ptx-linker approach of using the llvm library? The tools seems to provide more simplicity and stability, but more intermediate files are being written. Perhaps there also are some performance penalty for the calling tools approach. - What is the process for adding such tool? MCP? - Does adding `llvm-link` to the llvm-tool component require any process? - Does it require some sort of FCP to remove ptx-linker as the default linker for ptx? Or is it sufficient that using the upstream ptx-linker is broken in its current state. it is possible to use a somewhat patched version of ptx-linker. </details> 2024-03-11T16:29:32+00:00 Jubilee 46493976+workingjubilee@users.noreply.github.com 2024-03-11T16:29:32+00:00 urn:sha1:86af4d25a55718ba634b8fc0dd4f4d17508c0617 Allow targets to override default codegen backend Implements https://github.com/rust-lang/compiler-team/issues/670.