[colinrford]

The x86_64 .s assembly is written for ELF only, will not build on Intel Macs (Mach-O)

To allow building on my Intel-based Mac:

• CMakeLists.txt passes an assembler symbol BEMAN_BIG_INT_MACHO on Apple targets
• .ifdef and .ifndef guards in src/*_x86_64_*.s using BEMAN_BIG_INT_MACHO for Mach-O vs ELF
  • .type, .size, .note.GNU-stack and .section .text
  • underscores in front of global symbols, e.g. beman_big_int_multiply_long_runtime_generic -> _beman_big_int_multiply_long_runtime_generic
  • .section .rodata -> .section __TEXT,__const on Mach-O (IFMA files)
  • jmp sym@PLT -> jmp _sym on Mach-O (square IFMA tail call)

a small handful of other changes:

• .align -> .balign
  • .align means different things on x86_64 ELF vs x86_64 Mach-O, whereas .balign always means byte align
  • concretely .align 64 is 64 bytes on x86 ELF, but 2^64 on Mach-O
• .L* labels -> L* labels
  • invalid CFI advance_loc expression
  • Mach-O keeps .L labels as symbols, these will be written to the object symbol table and cause function splits
  • on x86 ELF the new labels become local symbols
• Bare macro parameters -> \param (multiply BMI2)
  • Darwin assembler doesn't substitute bare macro parameter names under .altmacro
  • e.g. in multiply BMI2 file: hi -> \hi, lo -> \lo

Alternate routes are possible via capitalization of the file ending from .s to .S (files go through C preprocessor).

Testing

• Tests build and pass* on local hardware with and without -march=native. I used Homebrew Clang 23 with the llvm-debug-module preset.
  • *With llvm-debug-module, the to_chars test traps. CharconvString.ToCharsEmptyBufferIsValueTooLarge hits a pre-existing debug assert (charconv.hpp:70)
• IFMA assembles and links but doesn't run since my machine has no AVX-512.
• assembled with clang -target x86_64-linux-gnu; .text/.rodata is byte-identical to 61b29f3 for all 6 files

CI Runner
As of now this includes a macos-15-intel Apple Clang runner that can build the library including the assembly. Apple Clang on x86_64 will seg fault compiling at least two of the tests: multi_limb_construction.test.cpp and numeric.test.cpp. It can be taken out but perhaps may be of interest for others to see where it fails.

[mborland]

In principle this seems fine. Once the CI cycles I can look into what the two segfaults are (assuming they appear in the CI).

[mborland]

I see what you're saying now; I thought you meant segfault as though we had failing tests due to bad behavior. It's instead an ICE with these old versions of Clang. I think it's best if we just skip these tests on Intel Macs.