[cfe-dev] C++11 doing double zero initialization?

[Robinson, Paul via cfe-dev]

Excellent, thanks!

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith
Sent: Tuesday, December 20, 2016 6:08 PM
To: Robinson, Paul
Cc: cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] C++11 doing double zero initialization?

On 20 December 2016 at 17:47, Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
OK, thanks.  "My program" is actually test/CodeGenCXX/global-init.cpp which is expecting not to see the memset.
Given the '=default-in-C++03' bug, I'll make it work on both 03 and 11, and leave a FIXME about it.

As of r290229, we now produce the C++11 result in C++03 too, and I've fixed that test for you :)

Thanks,
--paulr

From: metafoo at gmail.com<mailto:metafoo at gmail.com> [mailto:metafoo at gmail.com<mailto:metafoo at gmail.com>] On Behalf Of Richard Smith
Sent: Tuesday, December 20, 2016 5:07 PM
To: Robinson, Paul
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] C++11 doing double zero initialization?

On 20 December 2016 at 16:39, Robinson, Paul via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Consider the following source:

  struct C { C() = default; C(const C&); int n; };
  const C c1 = C();

then run it through `clang -emit-llvm -std=c++11`,
and I see the following relevant bits:

  %struct.C = type { i32 }
  @_ZL2c1 = internal global %struct.C zeroinitializer, align 4
  define internal void @__cxx_global_var_init() {{.*}} {
  entry:
    call void @llvm.memset.p0i8.i64(i8* bitcast (%struct.C* @_ZL2c1 to i8*),
      i8 0, i64 4, i32 4, i1 false)
    ret void
  }


The question is: Why the memset?  Doesn't 'zeroinitializer'
do the exact same thing?

Initialization of C++ globals is performed in two stages:

 * in the first stage ("static initialization"),
    -- if the object has a constant initializer (which C() is not, see http://wiki.edg.com/pub/Wg21issaquah2016/CoreWorkingGroup/cwg_active.html#1452), then object is initialized to that constant value ("constant intiialization")
    -- otherwise is initialized to zero ("zero-initialization").
 * 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.

What you're seeing here is a direct application of these rules to your program.

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.

I don't see the memset with C++03.

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).

I think our =default-in-C++03 extension is actually broken here, and we should emit the memset in both languages. Given:

  struct A { A() = default; int n; };
  int f() { A a = A(); return a.n; }

... this should be guaranteed to return 0 even in C++03 mode. (Right now it compiles to 'ret undef' in C++03.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161221/c3519784/attachment.html>