PCFC11

Compilation model

PCFC11 is a compact C compiler derived from Rui Ueyama’s chibicc, designed for exclusive distribution with PyCForge.

The compiler performs preprocessing, parsing, type analysis, optimization and x64 assembly generation. GCC-compatible external tools assemble and link its output and supply the platform runtime. Linux x86-64 and Windows x64 have separate data-model and calling-convention profiles.

Optimizations preserve observable effects, target widths and signedness. Floating-point reassociation and implicit fast-math transformations are not enabled. Analyses that exceed their supported scope or resource budget retain the established compilation path.

Independent compiler comparisons, native execution, mixed-compiler object tests, self-compilation and compiler sanitizers provide complementary evidence. Full ISO C11 conformance and production reliability have not been established; the machine interface explicitly reports full_conformance_verified: false.

Language and target behavior

-std=c11 selects the C11 language mode. It does not certify every C11 constraint, library requirement or required diagnostic. The gnu11 mode is also accepted; broad GCC language and command-line parity is not promised.

Integer constant contexts reject evaluated comma expressions while preserving valid unevaluated numeric subexpressions. Linux variable-length array bounds retain their effects; VLA typedefs capture their size at declaration and reuse it. Static initializers reject discarded operands that require runtime effects or reads. Pure-constant comma initializers remain a documented PCFC11 extension in both language modes, outside strict C11 compliance.

Generic selection. All _Generic association expressions are type-checked; the control and unselected expressions are not evaluated. Variable-length array controls decay to pointers, nested variably modified association types are rejected, and a control matching multiple associations receives a diagnostic. Fixed and variable-length array types use compatible element types, requiring equal bounds when both are integer constants. Runtime size requirements still apply; no dynamic compatibility checks are inserted. This does not complete the generic-selection or compatible-type audit.

Target profiles

Windows foreign objects using long double must agree with the binary64 profile; compatible GCC objects may require -mlong-double-64. Long-double CRT formatting and arbitrary foreign objects are not qualified.

Windows currently diagnoses VLAs, alloca, emitted thread-local objects, local alignment above 16 bytes and ELF PIC mode as unsupported. ARM64, macOS, MSVC-hosted builds, C++ interoperability and vector calling conventions are outside the current qualified targets.

Qualification methods and coverage

Tests compare output, diagnostics, exit status, file effects and selected machine-code properties against independent expectations. Generated arithmetic answers use Python integer arithmetic; GCC references check executable C behavior. Pinned Csmith and upstream software provide additional input diversity.

Counts below use distinct units. A fixture can run under several compilers, targets and optimization levels. Phases, fixtures, configurations and numerical comparisons must not be added together as a single test total.

Compiler sanitizer tests instrument the compiler process using AddressSanitizer, UndefinedBehaviorSanitizer and floating-cast-overflow checks. Leak detection is disabled for the process-lifetime allocation model. Separately sanitized GCC reference programs do not imply instrumentation of PCFC11-generated applications.

External numerical qualification covers Linux OpenBLAS LP64 with real CBLAS and LAPACKE sgesv/dgesv calls. The installed library supplies its optimized kernels. Native Windows external-library, real ILP64 and complete LAPACK qualification are not established.

Optimization behavior and measured execution

All six benchmark kernels pass their checksum checks. In this Windows run, PCFC11 -O1 has a lower median execution time than -O0 on every kernel. GCC -O2 has a lower median on five kernels. The loop-constants medians are effectively tied and their sample ranges overlap. Unsigned sample ranges also overlap; several O1 timings show noticeable variability.

Read the ratios: O0 ÷ O1 measures PCFC11’s optimization benefit within this version; a value above 1 means O1 was faster. O1 ÷ GCC compares elapsed time; a value above 1 means PCFC11 took longer. The division kernel’s 24.63× internal ratio still leaves O1 taking 6.52× GCC’s time.

Measurement method

Each kernel uses 250,000 work items per round and equal work across its three variants. A GCC-built timing harness uses Windows QueryPerformanceCounter. Warmups precede five samples, with variant order reversed on alternating samples. PCFC11 compiles its own kernels; the harness is linked separately without link-time optimization.

Calibration targets 0.1 seconds for the fastest variant while bounding estimated slowest-variant samples to two seconds. Several variants remain below the target, especially division, where the slow O0 build caps the common workload. Host load and short-run variation limit strong comparative conclusions.

Command and diagnostic contract

PCFC11 uses GCC-compatible assembly/linking tools and the target runtime. The Windows profile uses MinGW-w64 UCRT64. Compiler builds and validation scripts use 64-bit Python 3.11+; Python is not the C parser or code generator. Bundled headers are resolved relative to the compiler executable.

Command examples

pcfc11 --info-json
pcfc11 -std=c11 -O1 -c example.c -o example.o
pcfc11 -std=c11 -O1 -S example.c -o example.s
pcfc11 --diagnostics-json -Wall -Wextra -fsyntax-only example.c

Diagnostics

-Werror promotes enabled warnings; category-specific controls override group controls, and equal-specificity controls use the last setting. Unknown warning names are errors. --help-warnings lists the supported subset. This is not the full GCC or Clang warning inventory.

JSON warning records add code, option and promoted. Consumers must tolerate absent category codes on mandatory errors and additive fields. Columns are one-based byte offsets. The tested promoted-warning failures preserve existing outputs, but a multi-file command does not roll back earlier successful translation units.

Generated C compatibility

PCFC11’s compatibility corpus contains 49 pinned C programs generated by PyCForge 1.3.57. The corpus samples Runtime and Typed behavior including calls, closures, inheritance, containers, numeric limits, Unicode, modules and file effects.

PCFC11 O0/O1 and GCC O0/O2 builds are compared with Python execution and the corpus’s explicit runtime contracts. One signed-64 overflow fixture follows PyCForge’s bounded-integer contract rather than Python’s arbitrary-precision result.

Fixture compatibility is scoped to the recorded generated C. It does not establish compatibility with every future converter version or validate a GUI, installer or wheel. Application integration requires its own version-matched qualification.

Limits that affect use

• Optimization: only O0/O1 are implemented. The analysis IR is bounded integer analysis with AST emission; it is not a full SSA backend. There is no general live-range allocator, automatic SIMD, implicit fast math, PGO or LTO.
• Integer IR budgets: at most 64 eligible locals, 512 blocks, 4,095 value/effect instructions, 32,768 scanned AST nodes and depth 256 per function. Copy, constant, known-bit and value-number analyses have bounded work. Failure or an exceeded budget produces no substitutions from that analysis.
• Registers: eligible integer objects can use up to four dedicated callee-saved registers. Pointer, floating, address-exposed, volatile and atomic objects retain their established locations.
• Windows runtime: VLAs, alloca, emitted thread-local objects and local alignment above 16 bytes are unsupported. Runtime headers are a limited UCRT bridge, not an arbitrary Windows SDK implementation.
• Numerics: complete floating-environment, rounding, exceptional-value and external-library coverage is unverified. External BLAS dimension widths must match the actual header/library ABI; standalone 64-bit dimension tests do not qualify an ILP64 library.
• Isolation: process separation does not provide a security sandbox. PCFC11 is not a fully reentrant in-process library or a hardened service for hostile inputs.

Finite passing tests do not prove absence of miscompilation. No full ISO C11 conformance, MISRA compliance, independent certification or safety-critical suitability claim is made.

Standards references and origin

PCFC11 derives from chibicc by Rui Ueyama and contributors and retains MIT licensing and attribution. Upstream chibicc is not claimed to maintain or endorse PCFC11. Separate PyCForge, Csmith and upstream qualification inputs retain their own notices and are not linked into the compiler executable.

• WG14 N1570 — public C11 committee draft
• Microsoft — x64 calling convention

These external references describe language and platform contracts. Their inclusion is not certification of PCFC11. This page is a self-contained specification; its content and navigation do not require a source repository or package directory.