goldilocks-aes: build on 32bit archs (no __uint128_t there) - #10210
Merged
ThomasWaldmann merged 1 commit intoAug 25, 2026
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #10210 +/- ##
==========================================
- Coverage 87.25% 87.25% -0.01%
==========================================
Files 102 102
Lines 18430 18440 +10
Branches 2832 2834 +2
==========================================
+ Hits 16082 16090 +8
- Misses 1642 1643 +1
- Partials 706 707 +1 ☔ View full report in Codecov by Harness. |
gcc/clang only provide __uint128_t on 64bit targets, so the field
multiply's widening 64x64 -> 128 product broke the build on armhf,
i386 and friends:
goldilocks_aes_impl.c:85:5: error: unknown type name '__uint128_t'
Wrap the wide multiply in gl_mul_wide() and give it a portable
fallback built from four 32x32 -> 64 multiplies, used where
__SIZEOF_INT128__ is undefined. Both compute the same product, so
cut points - and thus dedup - stay identical on all architectures;
32bit machines just run this one chunker slower (it is not the
default chunker anyway).
Defining BORG_GL_NO_INT128 forces the fallback on 64bit, so the
32bit path can be tested there: the chunker testsuite (including the
unchanged-chunkpoints known-answer test) passes either way.
ThomasWaldmann
force-pushed
the
goldilocks-32bit
branch
from
August 25, 2026 17:05
a1ab824 to
d7b1cd5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The goldilocks-aes chunker fails to compile on 32bit architectures
(reported for the Ubuntu armhf build of 2.0.0b23, thanks LocutusOfBorg):
gcc/clang only offer
__uint128_ton 64bit targets. The Goldilocks fieldmultiply needs the full 128bit product of two 64bit values, and these two
places were the only users of the type in the whole tree - in that armhf
build log they are also the only errors, everything else compiles fine.
Rather than making the chunker unavailable on 32bit, this wraps the wide
multiply in
gl_mul_wide()with a portable fallback built from four32x32 -> 64 multiplies, used where
__SIZEOF_INT128__is undefined. Bothcompute the same product, so cut points - and thus dedup - are identical
on all architectures; 32bit machines just run this one chunker slower
(and it is not the default chunker anyway).
Defining
BORG_GL_NO_INT128forces the fallback also on 64bit, so the32bit path can be tested on a normal machine.
Verification:
-DBORG_GL_NO_INT128(forced 32bit path):src/borg/testsuite/chunkers/passes, including the known-answer testtest_chunkpoints_goldilocks_aes_unchanged- same chunk points.__uint128_toverthe interesting edge cases plus 20M random operand pairs: no mismatch.
(
-Wall -Wextra -Wpointer-arith -Wstrict-prototypes).Not verified here: an actual build on a 32bit machine.