[2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/pl...

Some more fun stories:

- Game projects default to using SIMD so for example SDL and STB you always need to pass -DSDL_DISABLE_IMMINTRIN_H and -DSTB_NO_SIMD

- math.h's NAN usually fall back to (0.0f / 0.0f), which will print "-nan" with printf, some projects test suite fail because of it (they expected "nan").

- NetBSD's sys/cdefs.h straight up #error's if you don't pretend to be GCC or PCC.

- Some projects can't compile without __attribute__((always_inline)) because they use it on non-static functions.

- Many projects probe -fvisibility in the build system and pass -fvisibility=hidden to compile, but in the headers they gate __attribute__((visibility(default))) behind __GNUC__ checks, so you'll get missing symbols.

- Some projects use if(0) { undefined_function() } to fake static_assert(), there is even a bug report from QEMU to Clang because it failed to optimize in -O0 a certain `if` written this way.

- Even if you define __STDC_NO_VLA__, projects might fall back to alloca() code path that's untested and broken (python and jemalloc both had this problem, already reported)

- Valkey has broken __builtin_ctzll fallback nobody noticed (reported).

- Zig's C bootstrap path expects the compiler to have GCC/Clang-tier optimization and stack overflows if you don't (reported).

- I contributed stdatomic.h code path for Ruby just to compile it with slimcc, pretty sure it's still the only user of the code path.

- I implemented __has_extension in the hope that projects can use it to query gnu_asm; but SQLite broke because they use __has_extension(c_atomic) to query GNU atomics builtin, but c_atomic actually is meant for C11 _Atomic (IMO they should use __has_builtin)

Having attempted to implement it correctly in slimcc, there are indeed some edge cases[1][2] that justify not adapting it fully.

[1] Unordered side effects; evaluation of expressions with overlapped destination is implementation defined but not listed as such (the wording in standard is "can potentially not be evaluated").

[2] Both GCC and Clang still get this wrong in 2026: https://github.com/llvm/llvm-project/issues/190858

There could theoretically be instruction selection passes that are biased toward rare instructions, specialized for fuzzing hardware, I'm surprised Intel doesn't already do that.

IMO when the intended usage is AOT with an external assembler, which is another subprocess, text-based IO is actually the more natural approach.

[1] https://github.com/dstogov/rcc

[2] https://codeberg.org/lsof/antcc

[3] https://github.com/tyfkda/xcc

[1] https://github.com/asibahi/paella/blob/main/writeup/c19.md#u...

On tcc, the most common dealbreaker is no thread local support, having independent assembler/linker is a wonderful feat but not being feature parity with binutils could lead to build failure, contributors generally less willing to support the correct behavior for ABI, C standards and GCC extensions.

I hope these don't sound like a diss, if I had been better at reading its coding style I would definitely try to contribute to mob branch.

It is also important to have more independent implementations of the C standard, not only to sort out dark corners in the specification (current WG14 have been doing great), but to prevent it turning into GCC-Clang power struggle.