Skip to content

netbsd/riscv64.rs: make changes so that this builds again.#4886

Merged
tgross35 merged 1 commit intorust-lang:mainfrom
he32:netbsd-riscv64-fix
Jan 6, 2026
Merged

netbsd/riscv64.rs: make changes so that this builds again.#4886
tgross35 merged 1 commit intorust-lang:mainfrom
he32:netbsd-riscv64-fix

Conversation

@he32
Copy link
Contributor

@he32 he32 commented Dec 19, 2025

Description

These are changes which appear to be required to get this file to build (and cross-build) again.
Admittedly, some of the additions are based on error messages emitted by the rustc compiler.

Sources

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@he32 he32 marked this pull request as draft December 19, 2025 18:44
@he32 he32 marked this pull request as ready for review December 19, 2025 23:00
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Dec 19, 2025
...to something which also passes the upstream automated checks.
Pull request submitted at
  rust-lang/libc#4886
@he32 he32 marked this pull request as draft December 26, 2025 10:57
@he32 he32 marked this pull request as ready for review December 26, 2025 23:59
@he32
Copy link
Contributor Author

he32 commented Dec 27, 2025

Not sure how those two failing CI jobs can be related to my proposed changes...

@rustbot

This comment has been minimized.

he32 added a commit to he32/libc that referenced this pull request Dec 29, 2025
…finition.

This is already part of pull request
  rust-lang#4886
which is yet to be applied.
@he32
Copy link
Contributor Author

he32 commented Dec 29, 2025

Not sure how those two failing CI jobs can be related to my proposed changes...

Evidently caused by what I had not done (merged upstream 'main' branch into mine).

Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the breakage, thank you for the PR!

Comment on lines +17 to +45
s_no_extra_traits! {
pub union __fpreg {
pub u_u64: u64,
pub u_d: c_double,
impl core::cmp::PartialEq for __fpreg {
fn eq(&self, other: &__fpreg) -> bool {
unsafe { self.u_u64 == other.u_u64 || self.u_d == other.u_d }
}
}

cfg_if! {
if #[cfg(feature = "extra_traits")] {
impl PartialEq for __fpreg {
fn eq(&self, other: &Self) -> bool {
unsafe { self.u_u64 == other.u_u64 }
}
impl core::cmp::Eq for __fpreg {}
impl core::marker::Copy for __fpreg {}
impl core::clone::Clone for __fpreg {
fn clone(&self) -> __fpreg {
*self
}
}
impl hash::Hash for __fpreg {
fn hash<H: hash::Hasher>(&self, state: &mut H) {
unsafe {
self.u_u64.hash(state);
}
impl Eq for __fpreg {}
impl hash::Hash for __fpreg {
fn hash<H: hash::Hasher>(&self, state: &mut H) {
unsafe { self.u_u64.hash(state) };
}
}
}
impl core::fmt::Debug for __fpreg {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
unsafe {
f.debug_struct("__fpreg")
.field("u_u64", &self.u_u64)
.field("u_d", &self.u_d)
.finish()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add back the s_no_extra_traits and cfg wrappers for __fpreg? You can just make it match

s_no_extra_traits! {
pub union fpreg_t {
pub d: c_double,
pub f: c_float,
}
}
cfg_if! {
if #[cfg(feature = "extra_traits")] {
impl PartialEq for fpreg_t {
fn eq(&self, _other: &fpreg_t) -> bool {
unimplemented!("traits")
}
}
impl Eq for fpreg_t {}
impl hash::Hash for fpreg_t {
fn hash<H: hash::Hasher>(&self, _state: &mut H) {
unimplemented!("traits")
}
}
}
}
.

Comment on lines +40 to +50
pub(crate) const _ALIGNBYTES: usize = size_of::<c_long>() - 1;
pub(crate) const _ALIGNBYTES: usize = 0xf;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have a source for this? Per https://github.com/NetBSD/src/blob/29216014b5d25ec3b457bbca2bb2bc6a80d7a1fd/sys/arch/riscv/include/cdefs.h#L6 it looks like the existing definition is correct.

(If you could add source links to the PR description for all changes here, that would be great)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could still use some context here

@rustbot
Copy link
Collaborator

rustbot commented Jan 3, 2026

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@he32 he32 requested a review from tgross35 January 4, 2026 15:23
Comment on lines 25 to 54
if #[cfg(feature = "extra_traits")] {
impl PartialEq for __fpreg {
fn eq(&self, other: &Self) -> bool {
unsafe { self.u_u64 == other.u_u64 }
impl core::cmp::PartialEq for __fpreg {
fn eq(&self, other: &__fpreg) -> bool {
unsafe { self.u_u64 == other.u_u64 || self.u_d == other.u_d }
}
}
impl core::cmp::Eq for __fpreg {}
impl core::marker::Copy for __fpreg {}
impl core::clone::Clone for __fpreg {
fn clone(&self) -> __fpreg {
*self
}
}
impl Eq for __fpreg {}
impl hash::Hash for __fpreg {
fn hash<H: hash::Hasher>(&self, state: &mut H) {
unsafe { self.u_u64.hash(state) };
unsafe {
self.u_u64.hash(state);
}
}
}
impl core::fmt::Debug for __fpreg {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
unsafe {
f.debug_struct("__fpreg")
.field("u_u64", &self.u_u64)
.field("u_d", &self.u_d)
.finish()
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should verify this builds with --features extra_traits. s_no_extra_traits adds a Clone, Copy, and Debug impl so I suspect it will fail.

Comment on lines +26 to +33
impl core::cmp::PartialEq for __fpreg {
fn eq(&self, other: &__fpreg) -> bool {
unsafe { self.u_u64 == other.u_u64 || self.u_d == other.u_d }
}
}
impl core::cmp::Eq for __fpreg {}
impl core::marker::Copy for __fpreg {}
impl core::clone::Clone for __fpreg {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add the core::cmp prefix, it's in libc's prelude

Comment on lines -26 to +30
impl PartialEq for __fpreg {
fn eq(&self, other: &Self) -> bool {
unsafe { self.u_u64 == other.u_u64 }
impl core::cmp::PartialEq for __fpreg {
fn eq(&self, other: &__fpreg) -> bool {
unsafe { self.u_u64 == other.u_u64 || self.u_d == other.u_d }
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave this body as-is, not having a false positive for ints is more important than indicating the -0==0 case for floats. Also matches other similar impls.

Or replace it with unimplemented! like the source I linked, these traits exist to fit in API signatures but they're going away in 1.0.

Comment on lines +40 to +50
pub(crate) const _ALIGNBYTES: usize = size_of::<c_long>() - 1;
pub(crate) const _ALIGNBYTES: usize = 0xf;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could still use some context here

@he32
Copy link
Contributor Author

he32 commented Jan 5, 2026

I could still use some context here

Oh? I thought I quoted from the gcc sources to adequatly address this. But to repeat in another way:

Gcc's riscv.h file (https://github.com/NetBSD/src/blob/trunk/external/gpl3/gcc/dist/gcc/config/riscv/riscv.h line 213)

/* There is no point aligning anything to a rounder boundary than this.  */
#define BIGGEST_ALIGNMENT 128

However, this is measured in bits, and gets converted to the predefined __BIGGEST_ALIGNMENT__ macro via
(https://github.com/NetBSD/src/blob/trunk/external/gpl3/gcc/dist/gcc/cppbuiltin.cc line 170):

  cpp_define_formatted (pfile, "__BIGGEST_ALIGNMENT__=%d",
			BIGGEST_ALIGNMENT / BITS_PER_UNIT);

which ends up as 16. This results in an __ALIGNBYTES value of 15 or 0xf via

#define __ALIGNBYTES    ((size_t)(__BIGGEST_ALIGNMENT__ - 1U))

(from /usr/include/machine/cdefs.h, visible via https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/cdefs.h)

@tgross35
Copy link
Contributor

tgross35 commented Jan 5, 2026

Did you mean the comment in 7b39a6f? I did see that but a source link still helps in case there's nuance to be aware of. Makes sense though, that's the same source I linked but I incorrectly assumed __BIGGEST_ALIGNMENT__ was a byte value.

If you could instead change to

pub(crate) const __BIGGEST_ALIGNMENT__: usize = 128;
pub(crate) const _ALIGNBYTES: usize = __BIGGEST_ALIGNMENT__ - 1;

I think that would be best since it mirrors the source.

@he32
Copy link
Contributor Author

he32 commented Jan 5, 2026

If you could instead change to

pub(crate) const __BIGGEST_ALIGNMENT__: usize = 128;
pub(crate) const _ALIGNBYTES: usize = __BIGGEST_ALIGNMENT__ - 1;

I think that would be best since it mirrors the source.

Actually, no, that is wrong. Internally in gcc, BIGGEST_ALIGNMENT is measured in bits. You need to divide by "bits-per-byte" before subtracting one to get the correct value for _ALIGNBYTES. Instead perhaps something like

// gcc for riscv64 defines `BIGGEST_ALIGNMENT`, but it's mesured in bits.
pub(crate) const __BIGGEST_ALIGNMENT_IN_BITS__: usize = 128;
// `_ALIGNBYTES` is measured in, well, bytes.
pub(crate) const _ALIGNBYTES: usize = (__BIGGEST_ALIGNMENT_IN_BITS__ / 8) - 1;

I assume I don't need to comment the literal 8...

Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to mention the division but that's what I meant. Thanks for the updates, LGTM but could you please squash?

@he32 he32 force-pushed the netbsd-riscv64-fix branch from 42f0450 to ac428c7 Compare January 6, 2026 06:05
@rustbot

This comment has been minimized.

@he32
Copy link
Contributor Author

he32 commented Jan 6, 2026

Forgot to mention the division but that's what I meant. Thanks for the updates, LGTM but could you please squash?

OK. I tried, but not only am I a rust newbie, I'm evidently also a git newbie, so what I thought would be one commit ended up as two for some reason or other. Do you want me to make another stab at squashing them back to one?

@tgross35 tgross35 force-pushed the netbsd-riscv64-fix branch from ac428c7 to ef16e3e Compare January 6, 2026 07:04
 * Use the same type names as used by the native libc, to allow
   more self-tests to succeed
 * Remove un-needed imports, uncovered by libc's "cargo test"
 * Compute _ALIGNBYTES the same way gcc does.

Verified by

 * Running (and passing) the libc self-tests "natively"
   on an emulated NetBSD/riscv64 system.
 * Cross-built rust 1.92.0 with this file in place for riscv64
   in the vendored libc-0.2.17{5,6,7} versions, targeting
   NetBSD/riscv64.

[ extracted this commit from the two in the PR - Trevor ]
@tgross35 tgross35 force-pushed the netbsd-riscv64-fix branch from ef16e3e to 8005136 Compare January 6, 2026 07:05
@rustbot
Copy link
Collaborator

rustbot commented Jan 6, 2026

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@tgross35 tgross35 enabled auto-merge January 6, 2026 07:06
@tgross35
Copy link
Contributor

tgross35 commented Jan 6, 2026

Forgot to mention the division but that's what I meant. Thanks for the updates, LGTM but could you please squash?

OK. I tried, but not only am I a rust newbie, I'm evidently also a git newbie, so what I thought would be one commit ended up as two for some reason or other. Do you want me to make another stab at squashing them back to one?

No worries, I took care of it :) it looks like you squashed the __pthread_spin_t commit with one of this PR's commits then squashed the rest , but the pthread bit was already applied as d4dd6d8.

For reference I just re-split the commits into pthread and the rest (git reset $(git merge-base HEAD main), then 2x git add -p followed by git commit to select hunks of the diff to add to a new commit) and then rebased. Probably also would have figured itself out with only a rebase, I just didn't realize what had happened at first.

Thanks for the patch!

@tgross35 tgross35 added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Jan 6, 2026
@tgross35 tgross35 added this pull request to the merge queue Jan 6, 2026
Merged via the queue into rust-lang:main with commit e9b8fa5 Jan 6, 2026
91 of 99 checks passed
tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Jan 8, 2026
 * Use the same type names as used by the native libc, to allow
   more self-tests to succeed
 * Remove un-needed imports, uncovered by libc's "cargo test"
 * Compute _ALIGNBYTES the same way gcc does.

Verified by

 * Running (and passing) the libc self-tests "natively"
   on an emulated NetBSD/riscv64 system.
 * Cross-built rust 1.92.0 with this file in place for riscv64
   in the vendored libc-0.2.17{5,6,7} versions, targeting
   NetBSD/riscv64.

[ extracted this commit from the two in the PR - Trevor ]

(backport <rust-lang#4886>)
(cherry picked from commit e9b8fa5)
@tgross35 tgross35 mentioned this pull request Jan 8, 2026
github-merge-queue bot pushed a commit that referenced this pull request Jan 8, 2026
 * Use the same type names as used by the native libc, to allow
   more self-tests to succeed
 * Remove un-needed imports, uncovered by libc's "cargo test"
 * Compute _ALIGNBYTES the same way gcc does.

Verified by

 * Running (and passing) the libc self-tests "natively"
   on an emulated NetBSD/riscv64 system.
 * Cross-built rust 1.92.0 with this file in place for riscv64
   in the vendored libc-0.2.17{5,6,7} versions, targeting
   NetBSD/riscv64.

[ extracted this commit from the two in the PR - Trevor ]

(backport <#4886>)
(cherry picked from commit e9b8fa5)
@tgross35 tgross35 added stable-applied This PR has been cherry-picked to libc's stable release branch and removed stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Jan 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

O-riscv O-unix S-waiting-on-author stable-applied This PR has been cherry-picked to libc's stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants