Weaselab - C++

Make clangd check your asserts even with -DNDEBUG

Andrew Noyes — Fri, 21 Aug 2026 00:00:00 +0000

When you configure a CMake project with -DCMAKE_BUILD_TYPE=Release</code>, CMake adds -DNDEBUG</code> to every compile command, and that flag lands in your compile_commands.json</code>. assert</code> is a no-op when NDEBUG</code> is defined, so clangd treats the body of every assert(...)</code> as dead code: no autocomplete, no type checking, no diagnostics. But when you're editing code, you want asserts typechecked no matter what build type you have configured.</p>

The fix is a .clangd</code> file at the root of your project that strips -DNDEBUG</code> for clangd only, without touching your actual build:</p>

C</span>ompileFlags</span>:</span></span>
  R</span>emove</span>:</span> [</span>-D</span>NDEBUG</span>]</span></span></code></pre>🔗</a>
Toy example</h2>
CMakeLists.txt</code>:</p>
cmake_minimum_required</span>(</span>VERSION</span> 3.20)</span></span>
project</span>(toy CXX)</span></span>
set</span>(CMAKE_CXX_STANDARD 17)</span></span>
set</span>(CMAKE_EXPORT_COMPILE_COMMANDS </span>ON</span>)</span></span>
add_executable</span>(toy main.cpp)</span></span></code></pre>
main.cpp</code> contains a deliberate type error inside</em> an assert:</p>
#</span>include</span> <</span>cassert</span>></span></span>
#</span>include</span> <</span>vector</span>></span></span>
</span>
int</span> main</span>(</span>)</span> {</span></span>
    std</span>::</span>vector</span><</span>int</span>></span> v</span>;</span></span>
    assert</span>(</span>v</span>.</span>size</span>(</span>)</span> ==</span> "</span>oops</span>"</span>)</span>;</span></span>
}</span></span></code></pre>
Configure a Release build so the compile database carries -DNDEBUG</code>:</p>
cmake</span> -</span>S</span> .</span> -</span>B</span> build</span> -</span>G</span> Ninja</span> -</span>DCMAKE_BUILD_TYPE=Release</span></span></code></pre>🔗</a>
Before</h2>
With no .clangd</code> file, clangd picks up -DNDEBUG</code> from the compile database, skips the assert body, and reports zero errors:</p>
$ clangd --check=main.cpp</span></span>
I Compile command from CDB is: ... -O3 -DNDEBUG -std=gnu++17 ... -c main.cpp</span></span>
I All checks completed, 0 errors</span></span></code></pre>🔗</a>
After</h2>
Add the .clangd</code> file above. clangd now drops -DNDEBUG</code> from the compile command, the assert becomes live, and the type error surfaces:</p>
$ clangd --check=main.cpp</span></span>
I Loading config file at .../.clangd</span></span>
I Compile command from CDB is: ... -O3 -std=gnu++17 ... -c main.cpp</span></span>
E [typecheck_comparison_of_pointer_integer] Line 6: comparison between pointer and integer ('size_type' (aka 'unsigned long') and 'const char *')</span></span>
I All checks completed, 1 errors</span></span></code></pre>
The Release build is unchanged; only the editor now sees the code you actually wrote inside asserts.</p>



If a sentence about C++ starts with "On x86,", stop listening.
Andrew Noyes — Mon, 03 Aug 2026 00:00:00 +0000
When someone starts a sentence with "On x86," whatever follows is almost always a justification for writing code that the C++ abstract machine does not permit.</p>
The intent is usually innocent. The speaker knows that x86 has a strong memory model, that aligned stores up to a certain size are atomic in hardware, that signed integers use two's complement, and so on. They are appealing to real facts about a real CPU. Their compiler's output for their suggestion may very well be correct. The trouble is that we're not writing x86.</p>
I recently caught myself doing a version of this. I had written some SIMD code that loads a full 16-element array, masks off the unused slots, and only uses the results from the valid ones. The unused lanes are read, masked out, and discarded. Valgrind doesn't complain, since it tracks "initializedness" the way you'd expect. The compiler was generating correct assembly for it. But reading uninitialized memory is undefined behavior in C++ even if the value is never used (issue #68</a>). I had been reasoning from "what the chip does" and "what valgrind tracks" instead of from the standard. The assembly was correct, but I do want to upgrade my compiler someday.</p>
🔗</a>
The abstract machine is the only machine that matters for correctness</h1>
C++ gives you a precise set of rules for what a well-formed program means. Objects have lifetimes. Reads and writes to the same object have ordering constraints. Some operations are atomic; others are not. Signed integer overflow is undefined. The compiler is allowed to assume your program follows these rules.</p>
x86 is one possible target for that compiler. It is a good target, with many helpful properties, but none of those properties are part of the C++ contract unless the standard explicitly says so, or unless you opt into an implementation-specific extension that documents them.</p>
This matters because compilers optimize in terms of the abstract machine, not the physical one. If your program has undefined behavior, the compiler can do whatever it wants1</a></sup>, and "whatever it wants" often includes producing code that does the opposite of what you intend.</p>
🔗</a>
Examples</h1>
The following snippets were compiled with clang++ --target=x86_64-linux-gnu -fno-pic -O2 -S</code> (Ubuntu clang 21.1.8). The generated assembly is exactly what you get from a real compiler, and it is precisely the kind of output that "On x86" reasoning fails to predict.</p>
🔗</a>
"On x86, signed overflow wraps around"</h2>
x86 arithmetic instructions use two's complement, so an overflowing signed addition leaves a wrapped value in the register. C++ does not care. Signed integer overflow is undefined behavior, and the compiler is entitled to assume it cannot happen.</p>
bool</span> incr_is_greater</span>(</span>int</span> x</span>)</span> {</span></span>
    return</span> x </span>+</span> 1</span> ></span> x</span>;</span></span>
}</span></span></code></pre>incr_is_greater(</span>int</span>):</span></span>
    movb    </span>$1</span>, %</span>al</span></span>
    retq</span></span></code></pre>
You might expect this to translate to an add</code> somewhere in the output — x86 has an add</code> instruction, and the source says x + 1</code>. It doesn't appear. The compiler assumes the overflow never happens, so x + 1 > x</code> is always true and the whole thing collapses to movb $1</code>. If you were reasoning "On x86, INT_MAX + 1</code> wraps to INT_MIN</code>, and INT_MIN > INT_MAX</code> is false," you're picturing an add</code> that executes and wraps in the register — but, as established, we're not writing x86.</p>
If you actually want wraparound, use an unsigned type (which is defined to wrap in C++) or a compiler extension such as -fwrapv</code>.</p>
🔗</a>
"On x86, reads and writes don't get reordered"</h2>
The x86 memory model is Total Store Order, which is famously strong. At the chip level, ordinary aligned stores really do appear to happen in program order to each observer. That does not help you at the C++ level. The compiler is allowed to reorder ordinary reads and writes, keep them in registers, or eliminate them, as long as it does not change the observable behavior of the abstract machine. Since it can assume the absence of data races it may also assume no other thread writes to a non-atomic object being accessed in the current thread.</p>
Once your program contains a data race, the program is undefined and none of these guarantees constrain the compiler.</p>
extern</span> int</span> data</span>;</span></span>
extern</span> bool</span> ready</span>;</span></span>
</span>
void</span> writer</span>(</span>)</span> {</span></span>
    data </span>=</span> 42</span>;</span></span>
    ready </span>=</span> true</span>;</span></span>
}</span></span>
</span>
int</span> reader</span>(</span>)</span> {</span></span>
    while</span> (</span>!</span>ready</span>)</span> {</span>}</span></span>
    return</span> data</span>;</span></span>
}</span></span></code></pre>writer():</span></span>
    movl    </span>$42</span>, data(%</span>rip</span>)</span></span>
    movb    </span>$1</span>, ready(%</span>rip</span>)</span></span>
    retq</span></span>
</span>
reader():</span></span>
    movl    data(%</span>rip</span>), %</span>eax</span></span>
    retq</span></span></code></pre>
reader()</code> contains no synchronization. Its loop body performs no observable operation — no volatile</code> access, no I/O, nothing — so under the forward-progress rule2</a></sup> the compiler may assume the thread will eventually do something observable. Since nothing in the abstract machine can ever change ready</code>, the compiler concludes that ready</code> must be true already: it drops the spin loop, reads data</code> once, and returns. The while (!ready)</code> loop is gone. The x86 chip will not reorder the stores that survive, but by then the program has already been transformed into one that does not mean what you think it means.</p>
Use atomics and the memory-ordering tools the standard gives you:</p>
#</span>include</span> <</span>atomic</span>></span></span>
</span>
extern</span> int</span> data</span>;</span></span>
extern</span> std</span>::</span>atomic</span><</span>bool</span>></span> ready</span>;</span></span>
</span>
void</span> writer</span>(</span>)</span> {</span></span>
    data </span>=</span> 42</span>;</span></span>
    ready</span>.</span>store</span>(</span>true</span>,</span> std</span>::</span>memory_order_release</span>)</span>;</span></span>
}</span></span>
</span>
int</span> reader</span>(</span>)</span> {</span></span>
    while</span> (</span>!</span>ready</span>.</span>load</span>(</span>std</span>::</span>memory_order_acquire</span>)</span>)</span> {</span>}</span></span>
    return</span> data</span>;</span></span>
}</span></span></code></pre>
Only ready</code> needs to be atomic. The release store on ready</code> and the acquire load on it create a happens-before edge: once the reader observes ready == true</code>, the write to data</code> is complete. data</code> itself can stay a plain int</code> since it's not being accessed concurrently.</p>
🔗</a>
"On x86, an unaligned access is just a slower access"</h2>
The x86 ISA will handle many unaligned accesses in hardware; they are slow, not fatal. But that is only true of scalar loads. The aligned move movdqa</code> requires 16-byte alignment and the hardware faults on a misaligned address. C++ allows the compiler to assume a pointer is aligned for the type it points to, and that assumption can lead it to emit one of the faulting instructions. __m128i</code> is a 128-bit, 16-byte-aligned type, so loading it lets the compiler emit an aligned move:</p>
#</span>include</span> <</span>immintrin.h</span>></span></span>
#</span>include</span> <</span>cstdint</span>></span></span>
uint64_t</span> sumv</span>(</span>const</span> __m128i</span>*</span> p</span>)</span> {</span></span>
    __m128i v </span>=</span> *</span>p</span>;</span></span>
    return</span> (</span>uint64_t</span>)</span>_mm_cvtsi128_si64</span>(</span>v</span>)</span> +</span></span>
           (</span>uint64_t</span>)</span>_mm_cvtsi128_si64</span>(</span>_mm_srli_si128</span>(</span>v</span>,</span> 8</span>)</span>)</span>;</span></span>
}</span></span></code></pre>sumv(__m128i const*):</span></span>
    movdqa</span>  (%</span>rdi</span>), %</span>xmm0</span></span>
    pshufd</span>  $238</span>, %</span>xmm0</span>, %</span>xmm1</span></span>
    paddq</span>   %</span>xmm0</span>, %</span>xmm1</span></span>
    movq</span>    %</span>xmm1</span>, %</span>rax</span></span>
    retq</span></span></code></pre>
Both GCC and Clang emit movdqa</code> here. If you pass a pointer that is only, say, 4-byte aligned, that movdqa</code> faults — the x86 hardware requires the aligned move's operand to be 16-byte aligned and refuses to perform it on a misaligned address. A misaligned load is undefined behavior in C++, and the compiler is entitled to emit the alignment-requiring instruction on the strength of that assumption.3</a></sup></p>
🔗</a>
Is "On x86," ever OK?</h1>
Yes. The sentence is fine when it is about performance, not correctness.</p>

"On x86, the L1 cache line is 64 bytes" is a useful thing to know when laying out hot structures.</li>
"On x86, popcnt</code> has three-cycle latency on this microarchitecture" is relevant to microbenchmarks.</li>
"On x86, this loop compiles to one load, one add, and one branch per iteration" is an observation about emitted code, which you can verify and measure.4</a></sup></li>
</ul>
These statements do not make any claim about what the program means</em>. They are engineering details about how a particular machine executes a particular binary. You can use them to make code faster; you cannot use them to make undefined behavior defined.</p>
🔗</a>
What to do instead</h1>
For correctness, reason from the C++ abstract machine:</p>

Use std::atomic</code> for shared mutable state across threads.</li>
Use the standard library synchronization primitives.</li>
Avoid signed overflow, null pointer dereferences, and out-of-bounds access.</li>
Treat volatile</code> as a tool for memory-mapped IO and signal handlers, not for thread communication.</li>
When in doubt, check with ThreadSanitizer and UBSan.</li>
Do not treat a particular compiler's generated code as a correctness argument — that only holds for that compiler and that version. You do want to upgrade your compiler someday, right?</li>
</ul>
If you want x86 semantics, you can also just write x86. Put it in its own .s</code> file, obey the calling convention, and call it as an ordinary function. Then "On x86" is not a claim about how the compiler might</em> compile your C++; it is a statement about the assembly you wrote. You can also try intrinsics, but be aware that the compiler is not obligated to generate the corresponding instructions. You can also try inline assembly, but it's more difficult to get right than a standalone .s</code> file.</p>
🔗</a>
Conclusion</h1>
If a sentence about C++ starts with "On x86," it is almost certainly about to confuse hardware behavior with program semantics. That is a mistake for correctness discussions. The only legitimate uses are performance tuning, measurements on a specific target, or literally writing x86.</p>
So in practice: if the topic is correctness, stop listening.</p>



People seem to anthropomorphize the compiler as an insufferable pedant who hates their code. The truth is that an optimizing compiler is a complex piece of software that performs a pipeline of hundreds of semantically-valid-according-to-the-abstract-machine transformations on your code, and upsetting codegen is an emergent property of interactions among these transformations. There is no line of code anywhere that says "Your code is bad, and you must suffer." ↩</a></p>
</li>

The forward-progress rule ([intro.progress]) lets the implementation assume a thread will eventually perform an observable action or terminate. A spin loop whose body has no observable side effects may therefore be assumed to exit; here that means while (!ready) {}</code> gets dropped entirely. (Other standard editions have phrased or scoped this rule differently.) ↩</a></p>
</li>

Constructing this example took some trial and error. This is also a known phenomenon in the wild: a checksum routine that summed uint32_t</code> words crashed with SIGSEGV when GCC assumed four-byte alignment and used an aligned SSE load — see Peter Zemskov, "A bug story: data alignment on x86"</a>. ↩</a></p>
</li>

The compiler is not required</em> to generate the particular codegen you are picturing. The point is that, when you are only discussing performance, a missed-optimization bug report won't be dismissed on the grounds that your code has undefined behavior. ↩</a></p>
</li>
</ol>
</section>