================
@@ -361,6 +368,13 @@ CodeGenFunction::AddInitializerToStaticVarDecl(const
VarDecl &D,
}
return GV;
}
+ if (!getLangOpts().CPlusPlus) {
+ // In C, when an initializer is given, the Linux kernel relies on clang to
+ // zero-initialize all members not explicitly initialized, including
padding
+ // bits.
----------------
yabinc wrote:
> I suggest quoting the standard, identifying the ambiguity, and then saying
> that we've chosen to interpret it as requiring all padding in the object to
> be zeroed. Since there are multiple paths in the compiler that need this
> logic, you may want to write this in a single place and then cross-reference
> it from other places.
Done.
> I don't mind staging it in over multiple commits in principle. If you'd like
> to switch to an implementation that adds explicit padding fields when
> building the original constant, you could still stage that and only add those
> fields in certain language modes.
I am OOO next week, will try it in ConstantEmitter after that.
> We probably do need to consider it when deciding whether to memset, but
> naively I'd expect that you'd just emit little memsets for each individual
> piece of padding when we recognize that there's a gap between successive
> fields. Does that not work?
It works. Done.
https://github.com/llvm/llvm-project/pull/97121
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
