Conversation
| _args: &[OperandRef<'tcx, Self::Value>], | ||
| _is_cleanup: bool, | ||
| ) -> Self::Value { | ||
| bug!("LLVM intrinsic call not supported in SPIR-V backend: {instance:?}") |
There was a problem hiding this comment.
I think we want to use this rather than our own home-grown replacements, but didn't want to do it in this PR.
14cdf92 to
6434ab8
Compare
|
|
|
Tried to update with a patched Details |
|
Cool, I'll take a look. There were some changes in this area. |
ed2c27e to
3cce05f
Compare
|
Looks like cargo-gpu needs an update to work with this branch... I'll have a look tomorrow (and properly review this) |
|
I found a good counter argument against updating to "in the middle" nightlies: These are 4 old rust-gpu versions we no longer test cargo-gpu against due to them failing, of which 2 are broken due to using in-the-middle nightlies:
These never showed up to end users since these revs are mostly in the middle of PR #249, the edition 2025 toolchain upgrade. I've specifically chosen to test revs before and after target spec changes to make sure (past) cargo-gpu's / (now) spirv-builder's backwards compat towards older rust-gpu versions works, as these are the most likely to break. (Also this PR is also not backwards compatible, see Rust-GPU/cargo-gpu@1e4487e ci failing, will fix soon) This could also be fixed by making cargo-gpu's "rustc-codegen-spirv build" use rust-gpu's lockfile, and thus never use never deps then what we're using right now. |
9e3bb73 to
c8078ed
Compare
c8078ed to
99993ee
Compare
99993ee to
12762d7
Compare
There was a problem hiding this comment.
Had a read though it, skipping the format_args_disassembler cause that's entirely @eddyb's domain (I merely moved it to a separate mod at some point, if it shows me as having changed it).
Added some commits to make it work with cargo-gpu's backwards compat requirements.
Works for restir, nanite-at-home, rust-gpu-templates and builds nazar's abundance.
Still think we shouldn't upgrade to middle nightlies, see comment above.
tests/compiletests/ui/lang/consts/runtime-array-invalid-const-bitcast.rs
Outdated
Show resolved
Hide resolved
Revert the `const_str` reshaping and the direct `RuntimeArray` constant-loading path in `read_from_const_alloc_at`. This restores the older behavior of treating `RuntimeArray` constants as unsupported instead of trying to materialize them from Rust constant data.
Remove the compile-fail test that casts constant data to `*const RuntimeArray<T>`. We do not want to support constructing `RuntimeArray` from Rust constant data.
I don't want to optimize for In my ideal world we are tracking rustc master. Perhaps this means cargo-gpu needs to be merged into this repo so users can depend on the same rev and have it all work (but have cargo-gpu able to compile with stable). I am not sure, that then feels a bit like |
Yes, please 🙏 |
|
Let's get this PR merged and I'll have a look at merging cargo-gpu into this repo once everything propagates through. @nazar-pc and I have discussed this before and I think it's a great idea. On rustc in-the-middle nightlies, we decided to merge this and update again when 1.96.0 branches in 2 weeks |
-Ztarget-spec-json: Destabilisetarget-spec-jsonrust-lang/rust#150151