opencode-darwin-x64-baseline SIGILL on pre-Haswell CPUs — linux-x64-baseline works fine #32850

【Issue 标题建议】
opencode-darwin-x64-baseline crashes with SIGILL on pre-Haswell CPUs (AVX2 missing), while linux-x64-baseline works fine via runtime CPU detection

Environment

• Machine: Mac Pro 2013 (MacPro6,1)
• CPU: Intel Xeon E5-1680 v2 @ 3.00GHz (Ivy Bridge-EP, Q3'2013)
• macOS: 12.7.6 Monterey
• opencode version: v1.17.8 (latest)
• Install method: npm install -g opencode-ai@latest, also tested via curl -fsSL https://opencode.ai/install | bash
• VM Test: Ubuntu 26.04 on VMware Fusion (same physical CPU)

CPU Instruction Set Support

Problem

opencode-darwin-x64-baseline crashes immediately with SIGILL (illegal instruction, exit code 132) on pre-Haswell Intel CPUs that lack AVX2.

$ sysctl -n hw.optional.avx2_0
0

$ opencode --version
# No output, exit code 132 (SIGILL)

The postinstall script correctly detects no AVX2 and selects the baseline package:

$ grep -A5 'packageNames' ~/.opencode/lib/node_modules/opencode-ai/postinstall.mjs
# => prefers "opencode-darwin-x64-baseline" when AVX2 is absent

Same behavior with opencode-linux-x64-baseline (same BuildID: c30f169b...) tested on macOS via objdump analysis — confirmed the binary contains 1192+ AVX2-only instructions (e.g. vpbroadcastq with 256-bit YMM destination, vpermq).

The Surprising Contrast

In a VMware Ubuntu 26.04 VM on the same physical CPU, opencode-linux-x64-baseline works perfectly:

$ cat /proc/cpuinfo | grep flags | grep -c avx2
0            # <-- no AVX2 in the VM either!

$ opencode --version
1.17.8        # <-- works fine!

Root Cause Analysis

Both binaries share the same BuildID and embed the same Bun/JavaScriptCore runtime. The difference lies in JIT behavior:

1. Linux baseline build: JSC's FTL JIT performs runtime CPU feature detection (cpuid). If AVX2 is unavailable, it falls back to SSE4.2/AVX1 code paths.
2. macOS baseline build: The FTL JIT appears to hardcode AVX2 usage without runtime fallback, causing SIGILL on the first JIT-compiled code path.

This is not a Bun -march issue — the binary itself doesn't contain illegal instructions in startup code. The crash occurs when JSC's JIT generates AVX2 instructions assuming they are always available on macOS.

Suggested Fix

Align the macOS baseline build's JIT behavior with the Linux baseline build:

• Enable runtime CPU feature detection in JSC's FTL JIT for macOS builds
• Fall back to SSE4.2/AVX1 code paths when AVX2/FMA/BMI are unavailable
• This is consistent with Bun's documented CPU requirements stating baseline targets Nehalem (SSE4.2 only)

Why This Matters

These older Mac Pros (2013) have capable CPUs (8+ cores, 64GB+ RAM) that are still perfectly usable for development. The hardware limitation is purely in instruction set extensions. Since the Linux baseline build already proves this is a solvable problem, fixing the macOS baseline build would give these machines years of additional useful life — rather than forcing users to discard hardware that is otherwise more powerful than a modern Raspberry Pi.

Linux baseline proves it's possible. Please make macOS baseline behave the same way.