<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 December 2016 at 16:39, Robinson, Paul via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Consider the following source:<br>
<br>
  struct C { C() = default; C(const C&); int n; };<br>
  const C c1 = C();<br>
<br>
then run it through `clang -emit-llvm -std=c++11`,<br>
and I see the following relevant bits:<br>
<br>
  %struct.C = type { i32 }<br>
  @_ZL2c1 = internal global %struct.C zeroinitializer, align 4<br>
  define internal void @__cxx_global_var_init() {{.*}} {<br>
  entry:<br>
    call void @llvm.memset.p0i8.i64(i8* bitcast (%struct.C* @_ZL2c1 to i8*),<br>
      i8 0, i64 4, i32 4, i1 false)<br>
    ret void<br>
  }<br>
<br>
<br>
The question is: Why the memset?  Doesn't 'zeroinitializer'<br>
do the exact same thing?</blockquote><div><br></div><div>Initialization of C++ globals is performed in two stages:</div><div><br></div><div> * in the first stage ("static initialization"), </div><div>    -- if the object has a constant initializer (which C() is not, see <a href="http://wiki.edg.com/pub/Wg21issaquah2016/CoreWorkingGroup/cwg_active.html#1452">http://wiki.edg.com/pub/Wg21issaquah2016/CoreWorkingGroup/cwg_active.html#1452</a>), then object is initialized to that constant value ("constant intiialization")</div><div>    -- otherwise is initialized to zero ("zero-initialization").</div><div> * in the second stage ("dynamic initialization", which is skipped if the first stage used constant initialization or if no initializer is provided for a scalar type), the initializer is run.</div><div><br></div><div>What you're seeing here is a direct application of these rules to your program.</div><div><br></div><div>C++ allows dynamic initialization to be converted to constant initialization if the initialization doesn't have side-effects (more or less), and Clang uses that permission to remove some dynamic initializers, but we don't happen to do so in this case (in either C++03 or C++11). That's a QoI bug (and core issue 1452 may make it a correctness bug). Either way, we should fix it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't see the memset with C++03.</blockquote><div><br></div><div>The input is not valid C++03 code, due to the "= default;", and our allowance of that construct in C++03 as an extension does something a bit strange: the C++11 initialization rules say that -- because C::C() is not user-provided -- we first zero-initialize the entire entire object and then call the no-op constructor, which is why you get a memset. However, the C++03 initialization rules are slightly different, and don't require C() to zero-initialize in this case prior to running the constructor (you only get the implicit zero-initialization for C() in C++03 if the class doesn't declare any constructors at all).</div><div><br></div><div>I think our =default-in-C++03 extension is actually broken here, and we should emit the memset in both languages. Given:</div><div><br></div><div>  struct A { A() = default; int n; };</div><div>  int f() { A a = A(); return a.n; }</div><div><br></div><div>... this should be guaranteed to return 0 even in C++03 mode. (Right now it compiles to 'ret undef' in C++03.)</div></div></div></div>