[PATCH] D68115: Zero initialize padding in unions

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D68115#1962863 <https://reviews.llvm.org/D68115#1962863>, @jfb wrote:

> In D68115#1962833 <https://reviews.llvm.org/D68115#1962833>, @rsmith wrote:
>
> > I think the majority opinion expressed on this review at this point favors not guaranteeing zero-initialization except where required by the relevant standard. That'd also be consistent with our stance on trivial auto variable initialization in general.
>
>
> Sorry, I didn't express myself well: if trivial auto-var init is on, then I want initialization of union padding to also be on. I think this is exactly compatible with what you want, as is says nothing of the behavior when trivial auto-var init is not on.
>
> > I'm not yet sure about whether we want separate controls for this and for `-ftrivial-auto-init`, or whether from a user's perspective there's really only one question: should bits left uninitialized be `undef`, guaranteed zero, or guaranteed to be filled with a pattern -- independent of whether they're padding bits? (And related, do we actually want control over zeroing union padding in all cases or only for trivial automatic variables? And do we want control over zeroing or pattern-filling objects allocated with `new` with trivial initialization?)
>
> Trivial auto-var init should always initialize all stack padding, and should not also initialize heap padding. There should be separate controls for heap padding, in part because this interacts with the allocator (whereas stack initialization does not).


That sounds reasonable to me. So the behavior we're looking for is:

- If `-ftrivial-auto-init` is off, then we guarantee to zero padding when the language spec requires it, and otherwise provide no such guarantee.
- If `-ftrivial-auto-init=zeroes` then we guarantee to zero padding within structs and unions with automatic storage duration, when that padding would otherwise be left uninitialized.
- If `-ftrivial-auto-init=pattern` then we guarantee to pattern-fill padding within structs and unions with automatic storage duration, when that padding would otherwise be left uninitialized (and will provide the zeroes required by the language rule when that is the required behavior).

[One possible tweak: for the `pattern` case, should we guarantee that the uninitialized padding will be pattern-filled? It would be simpler if we guaranteed it to be *either* zero- or pattern-filled; that way we can provide a conservatively-correct approximation by zero-filling whenever we're unsure.]

And we do not initially provide any guarantees as to what happens to padding within objects of other storage durations beyond what the language spec requires. (We might at some point in the future, but that would be behind a separate flag from `-ftrivial-auto-init`.) I'd be happy with that approach. Does that address everyone's concerns?

If so, how do we make progress on this? @vitalybuka, are you interested in doing the work to track whether padding should be zeroed in `APValue`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68115/new/

https://reviews.llvm.org/D68115