Clang-11.0.0 Miscompiled SQLite

If I understand correctly, everything is working as intended: a fuzzer caught a bug in an unreleased version of clang. The title makes it sound like somebody fucked up pretty badly.

Question for any low-level optimizing compiler engineers here: I obviously realize these are all important, but in your judgment, how much of making an error-free compiler would you say is about having a comprehensive test suite, vs. having <i>very</i> careful software engineers, vs. having extremely thorough code reviews, vs. something else? Put another way, if you were to lose one of these, which ones do you think would have the most&#x2F;least negative impact (or be the easiest&#x2F;hardest to make up for with other things) in terms of the correctness of the final product?

These sorts of bugs are more common than you may think! Here’s gcc miscompiling fish shell: <a href="https:&#x2F;&#x2F;github.com&#x2F;fish-shell&#x2F;fish-shell&#x2F;issues&#x2F;6962" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;fish-shell&#x2F;fish-shell&#x2F;issues&#x2F;6962</a>

I don&#x27;t understand trying to use the trunk version of a under-development compiler. Would you use the binaries built from an unstable compiler in production?<p>Given that here we talk about SQLite, what&#x27;s the advantage to use clang 11 instead of a previous version?

Clang 11 hasn&#x27;t been released yet, right?

Given that it&#x27;s SQLite, this is likely a compiler bug. However, the code given is insufficient to demonstrate a compiler bug. Given:<p><pre><code> c = pMem-&gt;flags; sqlite3VdbeMemRelease(pMem); pMem-&gt;flags = MEM_Str|MEM_Term|(c&amp;(MEM_AffMask|MEM_Subtype)); </code></pre> You could have say:<p><pre><code> sqlite3VdbeMemRelease(struct foo pMem) { *(some_other_type *)&amp;pMem-&gt;flags = bar; } </code></pre> In which case the C aliasing rules would allow the compiler to assume that the assignment through &quot;some_other_type&quot; does not affect the assignment through whatever type pMem-&gt;flags is.<p>I have seen this bug happen before, when compilers got better at inlining, where it was something like<p><pre><code> void getAddressOfSomething(intptr_t *address); ... char *p; getAddressOfSomething((intptr_t *)&amp;p) *p=foo </code></pre> The compiler could reorder the \*p=foo line to be before the getAddressOfSomething call for the same reason.<p>TL;DR: Turn of strict aliasing via compiler flags (-fno-strict-aliasing on gcc) if you ever type-pun anywhere without using a union.

<p><pre><code> c = pMem-&gt;flags; sqlite3VdbeMemRelease(pMem); pMem-&gt;flags = MEM_Str|MEM_Term|(c&amp;(MEM_AffMask|MEM_Subtype)); </code></pre> &#x27;pMem-&gt;flags&#x27; is a u16[1]. Shouldn&#x27;t it be copied to &#x27;c&#x27;. How can &#x27;sqlite3VdbeMemRelease&#x27; alter the value of &#x27;c&#x27;.<p>[1]<a href="https:&#x2F;&#x2F;github.com&#x2F;smparkes&#x2F;sqlite&#x2F;blob&#x2F;8caf9219240123fbe6cff67b1e0da778c62d7621&#x2F;src&#x2F;vdbeInt.h#L148" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;smparkes&#x2F;sqlite&#x2F;blob&#x2F;8caf9219240123fbe6cf...</a>

Holy cow, this happened at -O1. This doesn&#x27;t seem like the sort of optimization that should be possible at such a low level. I&#x27;ve run into plenty of trouble with higher level optimization flags in compilers before, but this is wild.

I see several references in this thread to &quot;a bug in Clang that is already fixed&quot;, but I can&#x27;t see anywhere where anyone references this bug.<p>Can anyone point to the bug report (and&#x2F;or fix) in Clang?

Why would OSFuzz send the bug report to SQLite instead of Clang?

So... if I&#x27;m understanding correctly, you&#x27;re accessing released memory? How is this anything but undefined behaviour?