Skip to content

cksum: only report x86 hardware features on x86 targets - #14805

Merged
sylvestre merged 1 commit into
uutils:mainfrom
ChihweiLHBird:zhiwei/fix-cksum-debug-arch-gating
Sep 25, 2026
Merged

sylvestre merged 1 commit into
uutils:mainfrom
ChihweiLHBird:zhiwei/fix-cksum-debug-arch-gating

Conversation

@ChihweiLHBird

@ChihweiLHBird ChihweiLHBird commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

Summary

cksum --debug printed the avx512, avx2 and pclmul detection lines on every target, so a build for a non-x86 architecture reported instruction sets its CPU cannot have. GNU compiles each of those lines in only where the matching implementation exists, so it prints none of them on non-x86.

This PR gates the three x86 lines on x86/x86_64, the same way the vmull line is already gated on aarch64, and splits the tests so the x86 assertions run only on x86 and a new test covers the other targets.

Example (assuming non-x86 arch)

$ cksum --debug /dev/null   # riscv64gc-unknown-linux-musl build, run under qemu-riscv64-static

Before:

avx512 support not detected
avx2 support not detected
pclmul support not detected

After, same as GNU: nothing on stderr. Output on x86-64 is unchanged.

@ChihweiLHBird
ChihweiLHBird marked this pull request as ready for review September 22, 2026 02:56
Comment thread tests/by-util/test_cksum.rs Outdated
Comment thread tests/by-util/test_cksum.rs Outdated
@xtqqczze

xtqqczze commented Sep 22, 2026 •

Copy link
Copy Markdown
Collaborator

The fix should be made also be made in src/uucore/src/lib/features/hardware.rs.

This then becomes dead code:

#[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))]
fn detect_avx512() -> bool {
    false
}

@xtqqczze

xtqqczze commented Sep 22, 2026 •

Copy link
Copy Markdown
Collaborator

GNU compiles each of those lines in only where the matching implementation exists, so it prints none of them on non-x86

GNU does not implement --debug; this claim is incorrect.

@oech3

oech3 commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

What? GNU supports --debug. If not, you are using outdated version.

@xtqqczze

xtqqczze commented Sep 22, 2026 •

Copy link
Copy Markdown
Collaborator
$ gcksum --version
cksum (GNU coreutils) 9.12
...
$ gcksum --debug /dev/null
4294967295 0 /dev/null

My mistake, --debug is supported, it just doesn't do anything.

@ChihweiLHBird
ChihweiLHBird force-pushed the zhiwei/fix-cksum-debug-arch-gating branch from 5b59a8f to 6dd4e91 Compare September 22, 2026 16:40
@ChihweiLHBird

ChihweiLHBird commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor Author

The fix should be made also be made in src/uucore/src/lib/features/hardware.rs.

This then becomes dead code:

#[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))]
fn detect_avx512() -> bool {
    false
}

It's not strictly a deadcode because detect_impl still invokes it. In order to clean them up, I had to refactor how detect_impl and the DETECTORS were defined.
See c3afbfd for detailed change. But I am not confident that this is the best design because it makes detect_avx512 only available for compiler on x86... Let me know what's the team's decision and I will follow.

@codspeed

codspeed Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 40 untouched benchmarks
⏩ 404 skipped benchmarks1


Comparing ChihweiLHBird:zhiwei/fix-cksum-debug-arch-gating (9d0fbc5) with main (b54bd05)

Open in CodSpeed

Footnotes

  1. 404 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

Comment thread src/uucore/src/lib/features/hardware.rs Outdated
Comment thread src/uucore/src/lib/features/hardware.rs Outdated
Comment thread src/uucore/src/lib/features/hardware.rs Outdated
@ChihweiLHBird
ChihweiLHBird force-pushed the zhiwei/fix-cksum-debug-arch-gating branch 2 times, most recently from 085eff8 to 7a4574c Compare September 22, 2026 20:13
Comment thread src/uucore/src/lib/features/hardware.rs Outdated
(HardwareFeature::Sse2, detect_sse2),
];

// The NEON implementations these features select (for example bytecount's

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

ARM Neon is fully supported in big-endian mode, would it make sense not to exclude it here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thank you! Is it better now?

@ChihweiLHBird
ChihweiLHBird force-pushed the zhiwei/fix-cksum-debug-arch-gating branch from 7a4574c to c8675fd Compare September 22, 2026 20:49
Comment thread src/uucore/src/lib/features/hardware.rs Outdated
(HardwareFeature::Sse2, detect_sse2),
];

// bytecount's aarch64 SIMD code, used by wc, is only built for little-endian

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

uucore is a separately published crate, so what wc builds isn't really its concern; these features also appear to be used by cksum. I'd err on the side of portability unless little-endian is an actual requirement of the detection itself.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

So what would you suggest as a comment here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

So removing target_endian?

@xtqqczze xtqqczze Sep 22, 2026 •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

So removing target_endian?

@sylvestre wdyt?

@github-actions

Copy link
Copy Markdown

GNU testsuite comparison:

Skipping an intermittent issue tests/date/resolution (passes in this run but fails in the 'main' branch)

Comment thread src/uucore/src/lib/features/hardware.rs Outdated
(HardwareFeature::Sse2, detect_sse2),
];

// bytecount's aarch64 SIMD code, used by wc, is only built for little-endian

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

is bytecount really the reason? detect_asimd was already little-endian only before this pr

@ChihweiLHBird ChihweiLHBird Sep 23, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I am not sure about the historic context of these. I'm also wondering what's the reason... The actual direct reason here is detect_asimd for little-endian has been gone below... and I am not sure if this (cleaning up detect_avx512 or detect_asimd) is a good design. See my comment above. I would personally prefer to tight the scope of this PR to cksum only.

Comment thread src/uucore/src/lib/features/hardware.rs Outdated
.succeeds()
.stdout_is_fixture("crc_single_file.expected")
.stderr_str_check(|stderr| {
stderr == "using vmull hardware support\n"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

accepting both strings makes the check pretty thin, can't we at least assert there is a single line?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

stderr == "some string" already asserted it's a single line.

}

#[test]
#[cfg(not(any(target_arch = "x86", target_arch = "x86_64", target_arch = "aarch64")))]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this test will never run on our CI targets, no? not sure it buys much

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

riscv64 CI runs this, which was the original purpose of this PR, to fix it for riscv64.

- { os: ubuntu-latest , target: riscv64gc-unknown-linux-musl , features: feat_os_unix_musl , use-cross: use-cross , skip-tests: true }

Comment thread src/uu/cksum/src/cksum.rs
print_feature("pclmul", features.has_pclmul());
}

// ARM aarch64

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why not gate on little-endian here too, like uucore does?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I am not sure if we should drop little endian gate. So is the decision to drop it in uucore or nor?

Comment thread src/uu/cksum/src/cksum.rs
print_feature("avx512", features.has_avx512());
print_feature("avx2", features.has_avx2());
print_feature("pclmul", features.has_pclmul());
if cfg!(any(target_arch = "x86", target_arch = "x86_64")) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

we now list the arches here, in hardware.rs and in the tests. could uucore expose the features the target can report instead?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Do you mean export FEATURE_DETECTORS?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ah I know. Working on it now

@ChihweiLHBird ChihweiLHBird Sep 24, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Lots of regressions appreared when I applied this, some due to previous defects but were hidden and will be triggered by this change...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I just restored the PR to be the original simple shape. I think we can do those hardware changes step by step in follow up PRs.

@ChihweiLHBird
ChihweiLHBird force-pushed the zhiwei/fix-cksum-debug-arch-gating branch from c8675fd to c3afbfd Compare September 23, 2026 20:37
Signed-off-by: Zhiwei Liang <zhiwei.liang@zliang.me>
@ChihweiLHBird
ChihweiLHBird force-pushed the zhiwei/fix-cksum-debug-arch-gating branch from c3afbfd to 9d0fbc5 Compare September 24, 2026 02:07
@ChihweiLHBird

ChihweiLHBird commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor Author

uucore is tooooooo complicated, and I am not an expert in this. I restored the original shape of the PR, the simple fix for cksum only. Can we can consider hardware.rs changes in the follow up PRs?

@sylvestre
sylvestre merged commit a5080ba into uutils:main Sep 25, 2026
101 checks passed
@ChihweiLHBird
ChihweiLHBird deleted the zhiwei/fix-cksum-debug-arch-gating branch September 25, 2026 05:56
@xtqqczze

Copy link
Copy Markdown
Collaborator

I'll continue with the uucore changes in #14860.

@ChihweiLHBird

Copy link
Copy Markdown
Contributor Author

I'll continue with the uucore changes in #14860.

Be aware of some regressions may exist. I am trying to address some regressions for this uucore change too, like in #14844

@xtqqczze

Copy link
Copy Markdown
Collaborator

@ChihweiLHBird I'll defer to your PR if you want to handle that?

@ChihweiLHBird

Copy link
Copy Markdown
Contributor Author

@ChihweiLHBird I'll defer to your PR if you want to handle that?

No worries, feel free to keep yours

@xtqqczze

Copy link
Copy Markdown
Collaborator

@ChihweiLHBird It's just your commit right now, up to you.

@ChihweiLHBird

Copy link
Copy Markdown
Contributor Author

@ChihweiLHBird It's just your commit right now, up to you.

Yep, no problem, I will put it up when the PR I mentioned above is finished. Thanks!

(Trying to achieve zero regression for each atomic commit/PR)

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.

4 participants