title: Is the definition of "volatile" this volatile, or is GCC having some standard compliancy problems?
body: <p>I need a function that (like SecureZeroMemory from the WinAPI) always zeros memory and doesn't get optimized away, even if the compiler thinks the memory is never going to accessed again after that. Seems like a perfect candidate for volatile. But I'm having some problems actually getting this to work with GCC. Here is an example function:</p>
  
  <pre><code>void volatileZeroMemory(volatile void* ptr, unsigned long long size)
  {
      volatile unsigned char* bytePtr = (volatile unsigned char*)ptr;
  
      while (size--)
      {
          *bytePtr++ = 0;
      }
  }
  </code></pre>
  
  <p>Simple enough. But the code that GCC actually generates if you call it varies wildly with the compiler version and the amount of bytes you're actually trying to zero. <a href="https://godbolt.org/g/cMaQm2">https://godbolt.org/g/cMaQm2</a></p>
  
  <ul>
  <li>GCC 4.4.7 and 4.5.3 never ignore the volatile.</li>
  <li>GCC 4.6.4 and 4.7.3 ignore volatile for array sizes 1, 2, and 4.</li>
  <li>GCC 4.8.1 until 4.9.2 ignore volatile for array sizes 1 and 2.</li>
  <li>GCC 5.1 until 5.3 ignore volatile for array sizes 1, 2, 4, 8.</li>
  <li>GCC 6.1 just ignores it for any array size (bonus points for consistency).</li>
  </ul>
  
  <p>Any other compiler I have tested (clang, icc, vc) generates the stores one would expect, with any compiler version and any array size. So at this point I'm wondering, is this a (pretty old and severe?) GCC compiler bug, or is the definition of volatile in the standard that imprecise that this is actually conforming behavior, making it essentially impossible to write a portable "SecureZeroMemory" function?</p>
  
  <p>Edit: Some interesting observations.</p>
  
  <pre><code>#include &lt;cstddef&gt;
  #include &lt;cstdint&gt;
  #include &lt;cstring&gt;
  #include &lt;atomic&gt;
  
  void callMeMaybe(char* buf);
  
  void volatileZeroMemory(volatile void* ptr, std::size_t size)
  {
      for (auto bytePtr = static_cast&lt;volatile std::uint8_t*&gt;(ptr); size-- &gt; 0; )
      {
          *bytePtr++ = 0;
      }
  
      //std::atomic_thread_fence(std::memory_order_release);
  }
  
  std::size_t foo()
  {
      char arr[8];
      callMeMaybe(arr);
      volatileZeroMemory(arr, sizeof arr);
      return sizeof arr;
  }
  </code></pre>
  
  <p><a href="https://godbolt.org/g/v8lMjG">The possible write from callMeMaybe() will make all GCC versions except 6.1 generate the expected stores.</a> Commenting in the memory fence will also make GCC 6.1 generate the stores, although only in combination with the possible write from callMeMaybe().</p>
  
  <p>Someone has also suggested to flush the caches. <a href="http://codepad.org/1yC7a8J8">Microsoft does <strong>not</strong> try to flush the cache at all in "SecureZeroMemory".</a> The cache is likely going to be invalidated pretty fast anyway, so this is probably not be a big deal. Also, if another program was trying to probe the data, or if it was going to be written to the page file, it would always be the zeroed version.</p>
  
  <p>There are also some concerns about GCC 6.1 using memset() in the standalone function. The GCC 6.1 compiler on godbolt might a broken build, as GCC 6.1 seems to generate a normal loop (like 5.3 does on godbolt) for the standalone function for some people. (Read comments of zwol's answer.)</p>