Package survey

How much of the C in filnix's ports builds with nanofil alone, and what stops the rest. Unlike the program checks (PLAN.md, M4), the survey is not part of the Nix check and fixes nothing: it measures.

Method

survey/default.nix defines nanofilize, a package adapter over the Fil-C staging package set: the package's CC is survey/cc.sh, which hands every compile of C to nanofil-cc, one source at a time (a compile-and-link cc -o x x.c, as configure's probes do, too). Preprocessing, assembling and linking go to filcc, since they compile no C. A C compile nanofil-cc cannot take (-S, or C on stdin or in a file without a .c suffix) is logged as a fallback and refused, never compiled by clang, so a package builds with nanofil alone or fails. C++ still goes to filcc and is counted (survey/cxx.sh). Libraries a package links with are the staging set's, built by filcc; each package's own checkPhase and installCheckPhase run as the port runs them.

The survey runs on the campaign service at https://nix.swa.sh/ (docs/campaign-service.md), which keeps every build's time, machine, outcome and complete log. survey/run.py manifest takes the packages ports.nix names and sets aside those that do not evaluate, those whose sources hold more than half as many C++ files as C files, those with no C sources, and the slow ones (slow in survey/default.nix: emacs30, libgcrypt). Each of the rest becomes two roots, ref.NAME (filcc) and nf.NAME (nanofil), which is only tried where filcc's build succeeds. run.py report writes survey/survey.tsv and the table below from the campaign's results. From swa:

campaignctl submit nanofil-survey --opt plain     # at origin/main; or --rev REV, --opt=-O, --opt="-O --no-vectors"
campaignctl list                                  # or https://nix.swa.sh/
python3 nanofil/survey/run.py report CAMPAIGN-ID  # survey.tsv, survey-OPT.tsv and the tables below
nix build -f nanofil/survey nf.zlib               # one, by hand
python3 nanofil/survey/run.py --report            # tables from survey.tsv
campaignctl submit bench                          # the slow packages, one at a time, local, rebuilt

A campaign's page at /c/ID/survey shows each package's filcc and nanofil builds side by side, with build times and the machine that built them; times compare only within one machine. Builds already in the store are reused, and only bin/ and src/ of nanofil enter the nanofil builds, so a survey after a compiler change rebuilds only those.

"filcc" and "nanofil" say tests pass when the build ran its own tests and they passed, built when it has none (or the port skips them), tests fail when the build failed in a check phase, and fails in PHASE otherwise. The first error is the first of nanofil's own messages, the wrapper's refusal, configure's verdict, or a compiler or make error, in that order.

Results

The survey of 2026-10-30 at 746154d, the first run through the campaign service (20261030-1136-nanofil-survey-746154d-plain), sets emacs30 and libgcrypt aside as slow (see above) and covers the other 207 C packages. filcc builds 200 of them, and nanofil alone builds 160, as at 6bc0f74. x264 is not among them: its common/x86/util.h declares a union with an __m128 i member under #ifdef __SSE__, so plain mode refuses it (common/macroblock.c:1521: no member named i) and it builds only with --vectors. The 6bc0f74 survey counted it as built from an output that a vectors-on build had left in the store, so that survey's true count is 160, not 161. btrfs-progs gets past __builtin_cpu_init to its SSE2 BLAKE2b. The table's timings are wall-clock seconds on the named builder (igloo or chapel), which are not comparable across machines.

The survey of 2026-10-30, at 6bc0f74: of the 300 packages ports.nix names, 209 are C. filcc builds 202 of them. Of those 202, nanofil alone builds 160 (79%, x264 corrected, see above; 144 at dd2ffee, 141 at a8e17b3, 137 at d3f1858, 130 at d91dd5e), compiling 44,903 objects. The 60 among them whose ports run tests pass them, as filcc's builds do. Two build but fail their tests: libressl's DTLS ssltest, on timing, and nspr (fegetround at link).

New since dd2ffee: asm that filcc traps on now compiles to filcc's trap (4379478), and cpuid, xgetbv, rdtsc, rdtscp, lfence, sfence and pause compile to checked asm_fixed (f20ffe5, ba3d7a6), which takes the inline-asm row from 31 to 3. fstrm, nettle, libmbim, parted, physfs and rhash build and pass their tests; binutils, cogl, elfutils, gettext, kbd, libblake3, pcre2, util-linux and zlib-ng build; cryptsetup now passes its tests. libgcrypt gets past its asm and its plain build hits the 90-minute timeout in its tests, as emacs30 does in its lisp stage (libgcrypt builds and passes at -O). No package regressed.

With --vectors (GNU vector types and the SSE through SSE4.2 and PCLMULQDQ intrinsics, off by default; 16620be), ghostscript, libopus and libtiff also pass their tests and kittydoom, libpq, xz and zstd build, plain and at -O, for 168 of 202 (x264 with them). The other vector packages stop at __builtin_ia32_shufpd (fftw, flac), the SSE4.2 string compares (bind, gtk4), 32-byte vectors (libdeflate, libwebp), long double classification (redis) and __int128 (tor).

The -O survey at b7a9651 built 154 of 202; its four -O-only failures (gsl, libgit2, netcdf, unbound) build and pass their tests since c7e94e8.

Causes

Each failure counts once, under its first error. Removing that cause gets a package to its next error, not necessarily to a build.

Vector types are now the largest row (16); --vectors builds seven of them (see above), and the release default stays off until the rest are measured. The 3 inline-asm packages left need asm filcc checks and runs natively (openssh's sarw, openssl-sarcasm's divq) or openssl's .filc_unsafe_export. Of the 10 other syntax or typing gaps, x264's is a vector type reported as a missing member, four are __int128 or GNU complex literals (1.0iF), two glibc's link.h, and quickjs's __builtin_frame_address(0), which stays out by decision.

Two rows are not syntax: a test suite that fails with no compiler error to point at (timing-dependent test, below) and a build that hits the 90-minute limit (build timeout).

libressl's one failing test is timing-dependent, not a miscompile. Its ssltest runs both ends of each DTLS handshake in one process, and a DTLS peer retransmits its flight when its 1 s timer expires; with RSA key exchange the server's private-key decryption falls inside that window. Without -O nanofil's code for libcrypto's Montgomery multiplication (bn/bn_mont.c, word helpers that return through pointers to locals) takes 0.541 s for one 1024-bit CRT half, against 0.139 s for filcc -O0, 0.044 s for nanofil -O and 0.004 s for the port's filcc -O3, so the two halves overrun the timer and the client reports an unexpected message. Every other test passes, TLS and the ECDHE and DHE DTLS ciphers included. Swapping object files with a filcc build pins it to bn_mont.c, whose results are correct (Montgomery products and exponentiation checked against BN_mod_mul over moduli of 2 to 640 bits), and ssltest passes when only bn_mont.o is built with nanofil -O. The survey builds with the port's own flags, so this stays a failure; run.py marks it timing-dependent test.