Skip to content

goldilocks-aes: build on 32bit archs (no __uint128_t there) - #10210

Merged
ThomasWaldmann merged 1 commit into
borgbackup:masterfrom
ThomasWaldmann:goldilocks-32bit
Aug 25, 2026
Merged

goldilocks-aes: build on 32bit archs (no __uint128_t there)#10210
ThomasWaldmann merged 1 commit into
borgbackup:masterfrom
ThomasWaldmann:goldilocks-32bit

Conversation

@ThomasWaldmann

Copy link
Copy Markdown
Member

The goldilocks-aes chunker fails to compile on 32bit architectures
(reported for the Ubuntu armhf build of 2.0.0b23, thanks LocutusOfBorg):

src/borg/chunkers/goldilocks_aes_impl.c: In function 'gl_mul_lazy':
src/borg/chunkers/goldilocks_aes_impl.c:85:5: error: unknown type name '__uint128_t'; did you mean '__uint32_t'?
   85 |     __uint128_t t = (__uint128_t)a * b;
      |     ^~~~~~~~~~~

gcc/clang only offer __uint128_t on 64bit targets. The Goldilocks field
multiply 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 four
32x32 -> 64 multiplies, used where __SIZEOF_INT128__ is undefined. Both
compute 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_INT128 forces the fallback also on 64bit, so the
32bit path can be tested on a normal machine.

Verification:

  • extension rebuilt with -DBORG_GL_NO_INT128 (forced 32bit path):
    src/borg/testsuite/chunkers/ passes, including the known-answer test
    test_chunkpoints_goldilocks_aes_unchanged - same chunk points.
  • standalone C harness comparing the fallback against __uint128_t over
    the interesting edge cases plus 20M random operand pairs: no mismatch.
  • fallback path compiles warning-free with Debian's build flags
    (-Wall -Wextra -Wpointer-arith -Wstrict-prototypes).

Not verified here: an actual build on a 32bit machine.

@codecov

codecov Bot commented Aug 25, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.25%. Comparing base (d69838c) to head (d7b1cd5).
⚠️ Report is 22 commits behind head on master.
✅ All tests successful. No failed tests found.

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.
📢 Have feedback on the report? Share it here.

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
ThomasWaldmann merged commit 79ee30c into borgbackup:master Aug 25, 2026
24 checks passed
@ThomasWaldmann
ThomasWaldmann deleted the goldilocks-32bit branch August 25, 2026 17:37
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.

1 participant