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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
