Skip to content

Conversation

@antoyo
Copy link
Contributor

@antoyo antoyo commented Nov 1, 2025

No description provided.

dianqk and others added 14 commits October 2, 2025 14:55
Currently it is possible to avoid linking the allocator shim when
__rust_no_alloc_shim_is_unstable_v2 is defined when linking rlibs
directly as some build systems need. However this requires liballoc to
be compiled with --cfg no_global_oom_handling, which places huge
restrictions on what functions you can call and makes it impossible to
use libstd. Or alternatively you have to define
__rust_alloc_error_handler and (when using libstd)
__rust_alloc_error_handler_should_panic
using #[rustc_std_internal_symbol]. With this commit you can either use
libstd and define __rust_alloc_error_handler_should_panic or not use
libstd and use #[alloc_error_handler] instead. Both options are still
unstable though.

Eventually the alloc_error_handler may either be removed entirely
(though the PR for that has been stale for years now) or we may start
using weak symbols for it instead. For the latter case this commit is a
prerequisite anyway.
In the future this should make it easier to use weak symbols for the
allocator shim on platforms that properly support weak symbols. And it
would allow reusing the allocator shim code for handling default
implementations of the upcoming externally implementable items feature
on platforms that don't properly support weak symbols.
Where supported, VSX is a 64x128b register set which encompasses
both the floating point and vector registers.

In the type tests, xvsqrtdp is used as it is the only two-argument
vsx opcode supported by all targets on llvm. If you need to copy
a vsx register, the preferred way is "xxlor xt, xa, xa".
Implemented preserves_flags on powerpc by making it do
nothing. This prevents having two different ways to mark
`cr0` as clobbered. clang and gcc alias `cr0` to `cc`.

The gcc inline documentation does not state what this does
on powerpc* targets, but inspection of the source shows
it is equivalent to condition register field `cr0`, so it
should not be added.
Add vsx register support for ppc inline asm, and implement preserves_flag option

This should address the last(?) missing pieces of inline asm for ppc:

* Explicit VSX register support. ISA 2.06 (POWER7) added a 64x128b register overlay extending the fpr's to 128b, and unifies them with the vmx (altivec) registers. Implementations details within gcc/llvm percolate up, and require using the `x` template modifier. I have updated the inline asm to implicitly include this for vsx arguments which do not specify it. ~~Support for the gcc codegen backend is still a todo.~~

* Implement the `preserves_flags` option. All ABI's, and all ISAs store their flags in `cr`, and the carry bit lives inside `xer`. The other status registers hold sticky bits or control bits which do not affect branch instructions.

There is some interest in the e500 (powerpcspe) port. Architecturally, it has a very different FP ISA, and includes a simd extension called SPR (which is not IBM's cell SPE). Notably, it does not have altivec/fpr/vsx registers. It also has an SPE accumulator register which its ABI marks as volatile, but I am not sure if the compiler uses it.
It's common to import dependencies from the sysroot via `extern crate`
rather than use an explicit cargo dependency, when it's necessary to use
the same dependency version as used by rustc itself. However, this is
dangerous for crates.io crates, since rustc may not pull in the
dependency on some targets, or may pull in multiple versions. In both
cases, the `extern crate` fails to resolve.

To address this, re-export all such dependencies from the appropriate
`rustc_*` crates, and use this alias from crates which would otherwise
need to use `extern crate`.
Restrict sysroot crate imports to those defined in this repo.

It's common to import dependencies from the sysroot via `extern crate` rather than use an explicit cargo dependency, when it's necessary to use the same dependency version as used by rustc itself. However, this is dangerous for crates.io crates, since rustc may not pull in the dependency on some targets, or may pull in multiple versions. In both cases, the `extern crate` fails to resolve.

To address this, re-export all such dependencies from the appropriate `rustc_*` crates, and use this alias from crates which would otherwise need to use `extern crate`.

See rust-lang/rust#143492 for an example of the kind of issue that can occur.
A grep for `const_usize.*align` found the same code copied to
rustc_codegen_gcc but I don't see other cases where we get this wrong.
…te,RalfJung

Fix ICE on offsetted ZST pointer

I'm not sure this is the *right* fix, but it's simple enough and does roughly what I'd expect. Like with the previous optimization to codegen usize rather than a zero-sized static, there's no guarantee that we continue returning a particular value from the offsetting.

A grep for `const_usize.*align` found the same code copied to rustc_codegen_gcc and cranelift but a quick skim didn't find other cases of similar 'optimization'. That said, I'm not convinced I caught everything, it's not trivial to search for this.

Closes rust-lang/rust#147516
@antoyo
Copy link
Contributor Author

antoyo commented Nov 1, 2025

Blocked on the next stdarch sync since this still uses the size_of intrinsic. Was fixed in rust-lang/stdarch#1947.
cc @tgross35: Do you know when the next stdarch sync is going to be done?

@thesamesam
Copy link

A sync will hopefully help #791 too.

@tgross35
Copy link
Contributor

tgross35 commented Nov 2, 2025

I haven't been doing the syncs for stdarch, only compiler-builtins. @folkertdev perhaps?

@folkertdev
Copy link
Contributor

it's overdue, I'll set it up.

@folkertdev
Copy link
Contributor

rust-lang/rust#148402 if you want to follow along

@antoyo
Copy link
Contributor Author

antoyo commented Nov 2, 2025

Thanks a lot!

@antoyo antoyo merged commit e785c50 into master Nov 4, 2025
38 checks passed
@antoyo antoyo deleted the sync_from_rust_2025_11_01 branch November 4, 2025 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.