[PATCH] D46241: [CodeGen] Recognize more cases of zero initialization

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.


================
Comment at: lib/CodeGen/CGExprConstant.cpp:1403
+  if (auto *IL = dyn_cast_or_null<InitListExpr>(Init)) {
+    if (InitTy->isConstantArrayType()) {
+      for (auto I : IL->inits())
----------------
sepavloff wrote:
> rjmccall wrote:
> > Do you actually care if it's an array initialization instead of a struct/enum initialization?
> If this code is enabled for for records too, some tests start to fail. For instance, the code:
> ```
> union { int i; double f; } u2 = { };
> ```
> produces output:
> ```
> %union.anon = type { double }
> @u2 = global %union.anon zeroinitializer, align 4
> ```
> while previously it produced:
> ```
> @u2 = global { i32, [4 x i8] } { i32 0, [4 x i8] undef }, align 4
> ```
> The latter looks more correct.
Hmm.  In C++, a static object which isn't constant-initialized is zero-initialized, which is required to set any padding bits to zero (N4640 [dcl.init]p6) in both structs and unions.  In C, a static object which doesn't have an initializer also has all any padding bits set to zero (N1548 6.7.9p10).  Now, this object has an initializer (that acts as a constant-initializer in C++), so those rules don't directly apply; but I would argue that the intent of the standards is not that padding bits become undefined when you happen to have an initializer.  So I actually think the `zeroinitializer` emission is more correct.


Repository:
  rC Clang

https://reviews.llvm.org/D46241