Zero initialize padding in unions

[vitalybuka]

Summary

Existing implementation puts undef into padding bits which almost always
compiled into zeroes. However with -ftrivial-auto-var-init=pattern those undefs
became 0xAA pattern and break some code. We need to zero initialized them.

C++

11.6 Initializers
6 To zero-initialize an object or reference of type T means:
(6.3) — if T is a (possibly cv-qualified) union type, its padding bits (6.7) are initialized to zero bits

8 To value-initialize an object of type T means:
(8.2) — if T is a (possibly cv-qualified) class type without a user-provided or deleted default constructor, then
the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T
has a non-trivial default constructor, the object is default-initialized;

11.6.1 Aggregates

3 When an aggregate is initialized by an initializer list as specified in 11.6.4, the elements of the initializer list
are taken as initializers for the elements of the aggregate, in order. Each element is *copy-initialized* from the
corresponding initializer-clause. If the initializer-clause is an expression and a narrowing conversion (11.6.4)

8 If there are fewer initializer-clauses in the list than there are elements in a non-union aggregate, then each
element not explicitly initialized is initialized as follows:
If the aggregate is a union and the initializer list is empty, then
(8.4) — if any variant member has a default member initializer, that member is initialized from its default
member initializer;
(8.5) — otherwise, the first member of the union (if any) is copy-initialized from an empty initializer list.

11.6.4 List-initialization
(3.3) — Otherwise, if T is an aggregate, aggregate initialization is performed
(3.4) — Otherwise, if the initializer list has no elements and T is a class type with a default constructor, the
object is value-initialized.
...
(3.10) — Otherwise, if the initializer list has no elements, the object is value-initialized

Looks like C does not require, as union is not aggregate, but a lot of code already relies on this behavior.

6.7.9 Initialization
10. If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.
If an object that has static or thread storage duration is not initialized explicitly, then:
— if it is a union, the first named member is initialized (recursively) according to these rules, and
any padding is initialized to zero bits;
21. If there are fewer initializers in a brace-enclosed list than there are elements or members of an
aggregate, or fewer characters in a string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as
objects that have static storage duration.

[vitalybuka]

clang/test/CodeGenCXX/designated-init.cpp

68

"1->0" here is suspicions

[vitalybuka]

clang/test/CodeGenCXX/designated-init.cpp

68

interesting that I can't compile it with GCC as C++

I can compile the following as C with GCC and C/C++ with Clang
struct WithOverwritePaddingWithBitfield overwrite_padding = {{1}, .a.bitfield = 3};
but even without the patch it was 0 in the last byte

[vitalybuka]

remove unused var

[hubert.reinterpretcast]

clang/test/CodeGen/init.c

197

This is C++ aggregate initialization and not value-initialization. The wording you quoted from the C++ standard is for zero-initialization, which might be part of value initialization, but you have not shown that aggregate initialization of a union involves zero-initialization of that union.

[vitalybuka]

clang/test/CodeGen/init.c

197

reading this more I don't see any evidence that either C++ or C requires padding initialization.
Reading this I expect that all function here should be equivalent https://godbolt.org/z/1O_9-e
But they are not. Clang and GCC initialized padding after the first member.

[vitalybuka]

clang/test/CodeGen/init.c

197

So if go trough "aggregates" then nothing is said about padding in union.
If we go trough "list-initialization" then value initialization should be applied, part of which is zero initialization.
If so union padding should be initialized.

[hubert.reinterpretcast]

clang/test/CodeGen/init.c

197

In C++14, the list in [dcl.init.list] starts with:
If T is an aggregate, aggregate initialization is performed.

The bullet in C++17 follows only a case for copying and then a case for string literals.

The bullet in the C++2a CD likewise, with an additional earlier bullet that also becomes aggregate initialization.

It is in C++11 where an empty list gets value-initialization treatment, and the next bullet goes to aggregate initialization.

The inline comment was not added to an empty list case.

[vitalybuka]

clang/test/CodeGen/init.c

197

So if I understand you (and what I see in C++17 and C++11) then only C++11 will essentially requires zeros via value-initialization.
And the rest (including C), requires only the first field to be initialized and the tail is undefined.

[hubert.reinterpretcast]

clang/test/CodeGen/init.c

197

That is my understanding. C++11 will require zeroes for U u = { }; and U u{}. The tail is undefined in other cases with automatic storage duration.

[jfb]

The entire point of this feature is to add guardrails to the language. What do people expect in the real world? Is there a cost to meeting these expectations? If we put the pattern (0x00 or 0xaa) in the technically undef space, what comes out?

[hubert.reinterpretcast]

In D68115#1686837, @jfb wrote:

The entire point of this feature is to add guardrails to the language.

I agree, and guardrails have a tendency to scratch paint if one drives against them.

What do people expect in the real world? Is there a cost to meeting these expectations?

The patch as-is moves past the scope of the -ftrivial-auto-var-init feature. The specific case I wrote the inline comment on is an instance where the initialization strategy appears deliberate and costs less space in the compiled binary than the case where the initialization strategy is hampered by trying to initialize bytes that are defined as holding indeterminate values. Paying for this extra space should require opting into (such as by using -ftrivial-auto-var-init).

If we put the pattern (0x00 or 0xaa) in the technically undef space, what comes out?

To extend the analogy, 0x00 seems to be the bumper car version in the context of the current discussion. Applications that have issues around uninitialized bytes in unions might be workable when using 0x00 as the pattern. With a non-bumper car pattern, it would become more clear to users when they are driving against the guardrails, so they aren't instead surprised when they fall off a cliff.

[vitalybuka]

In D68115#1686837, @jfb wrote:

The entire point of this feature is to add guardrails to the language. What do people expect in the real world? Is there a cost to meeting these expectations? If we put the pattern (0x00 or 0xaa) in the technically undef space, what comes out?

As a user I would prefer zeros there :)

[vitalybuka]

The patch as-is moves past the scope of the -ftrivial-auto-var-init feature.

That's because I had misunderstanding of the standard. I would be happy to update the patch to enable it only for -ftrivial-auto-var-init=pattern, if we want "bumper" version. For "non-bumper" we don't need a patch at all.
I don't have strong opinion which way to go.

[hubert.reinterpretcast]

In D68115#1686887, @vitalybuka wrote:

I would be happy to update the patch to enable it only for -ftrivial-auto-var-init=pattern, if we want "bumper" version.

It seems to be a separable feature (although it does interact with -ftrivial-auto-init=pattern). That option also provides guardrails for non-unions, and "bumper guardrails" for unions can be a useful feature without the non-union guardrails.

[jfb]

@vitalybuka could we move this patch forward?

[lebedev.ri]

Can patch description be made a bit more verbose?

However with -ftrivial-auto-var-init=pattern those undefs became 0xAA pattern and break some code.

Break how?

Does this have to be an unilateral change,
likely penalizing non--ftrivial-auto-var-init= cases,
i.e. [why] can't it be only done for when -ftrivial-auto-var-init= is enabled?

[hubert.reinterpretcast]

In D68115#1810891, @lebedev.ri wrote:

Does this have to be an unilateral change,
likely penalizing non--ftrivial-auto-var-init= cases,
i.e. [why] can't it be only done for when -ftrivial-auto-var-init= is enabled?

We left off near that conclusion (https://reviews.llvm.org/D68115#1686887); however, -ftrivial-auto-var-init= merely increases the chance that code expecting the zeroing to occur would break. A separate option to control zeroing for union padding would help in cases where the zeroing does not happen for reasons other than -ftrivial-auto-var-init.

[lebedev.ri]

In D68115#1811089, @hubert.reinterpretcast wrote:

In D68115#1810891, @lebedev.ri wrote:

Does this have to be an unilateral change,
likely penalizing non--ftrivial-auto-var-init= cases,
i.e. [why] can't it be only done for when -ftrivial-auto-var-init= is enabled?

We left off near that conclusion (https://reviews.llvm.org/D68115#1686887);

Would be great if @rsmith / @aaron.ballman could comment on that

however, -ftrivial-auto-var-init= merely increases the chance that code expecting the zeroing to occur would break. A separate option to control zeroing for union padding would help in cases where the zeroing does not happen for reasons other than -ftrivial-auto-var-init.

[aaron.ballman]

In D68115#1811091, @lebedev.ri wrote:

In D68115#1811089, @hubert.reinterpretcast wrote:

In D68115#1810891, @lebedev.ri wrote:

Does this have to be an unilateral change,
likely penalizing non--ftrivial-auto-var-init= cases,
i.e. [why] can't it be only done for when -ftrivial-auto-var-init= is enabled?

We left off near that conclusion (https://reviews.llvm.org/D68115#1686887);

Would be great if @rsmith / @aaron.ballman could comment on that

I don't have super strong opinions on it, but I think a separate feature for zeroing union padding is what gives users the most flexibility.

In D68115#1811089, @hubert.reinterpretcast wrote:

A separate option to control zeroing for union padding would help in cases where the zeroing does not happen for reasons other than -ftrivial-auto-var-init.

Agreed.

[vitalybuka]

In D68115#1819418, @aaron.ballman wrote:

In D68115#1811091, @lebedev.ri wrote:

In D68115#1811089, @hubert.reinterpretcast wrote:

In D68115#1810891, @lebedev.ri wrote:

Does this have to be an unilateral change,
likely penalizing non--ftrivial-auto-var-init= cases,
i.e. [why] can't it be only done for when -ftrivial-auto-var-init= is enabled?

We left off near that conclusion (https://reviews.llvm.org/D68115#1686887);

Would be great if @rsmith / @aaron.ballman could comment on that

I don't have super strong opinions on it, but I think a separate feature for zeroing union padding is what gives users the most flexibility.

In D68115#1811089, @hubert.reinterpretcast wrote:

A separate option to control zeroing for union padding would help in cases where the zeroing does not happen for reasons other than -ftrivial-auto-var-init.

Agreed.

I would be happy to finish this patch if we agree on something.

So if I understand this the proposal is to have something like -fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without -ftrivial-auto-var-init.
Is this correct?

[hubert.reinterpretcast]

In D68115#1820462, @vitalybuka wrote:

So if I understand this the proposal is to have something like -fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without -ftrivial-auto-var-init.
Is this correct?

That's my understanding and I would find such an option useful.

[aaron.ballman]

In D68115#1820462, @vitalybuka wrote:

I would be happy to finish this patch if we agree on something.

So if I understand this the proposal is to have something like -fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without -ftrivial-auto-var-init.
Is this correct?

In general, I believe so, yes. To be clear, it only sets zeros into union padding, not *all* padding. I do not have an opinion on whether we want it to be -fzero-union-padding as opposed to -finit-union-padding that honors the pattern from -ftrivial-auto-init=pattern and defaults to zero if no pattern is specified.

[vitalybuka]

In D68115#1820579, @aaron.ballman wrote:

In D68115#1820462, @vitalybuka wrote:

I would be happy to finish this patch if we agree on something.

So if I understand this the proposal is to have something like -fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without -ftrivial-auto-var-init.
Is this correct?

In general, I believe so, yes. To be clear, it only sets zeros into union padding, not *all* padding. I do not have an opinion on whether we want it to be -fzero-union-padding as opposed to -finit-union-padding that honors the pattern from -ftrivial-auto-init=pattern and defaults to zero if no pattern is specified.

They whole point of the patch was to avoid breaking code by -ftrivial-auto-init=pattern with "MyUnion my_union = {}". So to fix that only -fzero-union-padding behavior helpful.
-ftrivial-auto-init=pattern as-is already inits union padding with patterns.

[aaron.ballman]

In D68115#1820622, @vitalybuka wrote:

In D68115#1820579, @aaron.ballman wrote:

In D68115#1820462, @vitalybuka wrote:

I would be happy to finish this patch if we agree on something.

So if I understand this the proposal is to have something like -fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without -ftrivial-auto-var-init.
Is this correct?

In general, I believe so, yes. To be clear, it only sets zeros into union padding, not *all* padding. I do not have an opinion on whether we want it to be -fzero-union-padding as opposed to -finit-union-padding that honors the pattern from -ftrivial-auto-init=pattern and defaults to zero if no pattern is specified.

They whole point of the patch was to avoid breaking code by -ftrivial-auto-init=pattern with "MyUnion my_union = {}". So to fix that only -fzero-union-padding behavior helpful.
-ftrivial-auto-init=pattern as-is already inits union padding with patterns.

Ah, okay, good to know!

[jfb]

What's the verdict then?

[hubert.reinterpretcast]

In D68115#1946612, @jfb wrote:

What's the verdict then?

It sounds like we are looking for -fzero-union-padding. That's been where the discussion has left off twice for months.

[rsmith]

In D68115#1946668, @hubert.reinterpretcast wrote:

It sounds like we are looking for -fzero-union-padding. That's been where the discussion has left off twice for months.

I believe the state of Clang prior to this patch is actually wrong. We reach this code regardless of the kind of initialization used for the union, and some forms of initialization require zeroing of padding whereas some do not. If we want to model this precisely, we'll need to track on APValue whether the padding bits of the union constant are zeroed or not. For example, given:

union U { char c; int n; };
U u = U(); // value-initialization
U v = U{}; // aggregate initialization

Clang emits { i8 0, [3 x i8] undef } for both u and v. That's correct for v, but incorrect for u: it should emit { i8 0, [3 x i8] zeroinitializer } or perhaps simply zeroinitializer, because value-initialization invokes zero-initialization, which zeroes the padding.

Fixing this properly is likely not very hard, but it would require more changes than are present in this patch. (This patch is conservatively correct, but initializes more than we need to initialize.)

We also need to track in APValue whether padding bits are zeroed in order to correctly support bit_cast from structs with padding. Per discussion in committee, the intended behavior for bit_cast is:

A bit in the value representation of the result is indeterminate if does not correspond to a bit in the value representation of from or corresponds to a bit of an object that is not within its lifetime or has an indeterminate value ([basic.indet]). For each bit in the value representation of the result that is indeterminate, the smallest object containing that bit has an indeterminate value; the behavior is undefined unless that object is of unsigned ordinary character type or std::byte type. The result does not otherwise contain any indeterminate values.

So in particular:

struct A { char c; int n; };
constexpr long n = bit_cast<long>(A()); // ok, 0
constexpr long m = bit_cast<long>(A{}); // ill-formed, indeterminate value due to uninitialized padding between c and n

So I would propose we take the following path:

1. Extend Clang's constant evaluator and APValue to track, for a struct or union value, whether all padding bits are zeroed. (Should always be true for a value with no padding bits.)
2. Land this patch behind a flag to zero all padding bits for unions, ideally extended to cover struct padding as well as union padding.
3. After doing (1), extend __builtin_bit_cast support to properly handle padding bits.
4. After doing (1) and (2), extend constant aggregate emission to always zero padding when required by the language standard. (If you want, make the flag be three-way: never zero, zero as required by language standard, always zero, maybe: -fzero-padding=never / -fzero-padding=std, -fzero-padding=always.)

Note that (1) and (2) are independent, so I don't think we need to block this patch (2) on the implementation of (1), but we should be aware that we're not done here until we do steps (3) and (4).

[hubert.reinterpretcast]

In D68115#1946757, @rsmith wrote:

3. After doing (1), extend __builtin_bit_cast support to properly handle padding bits.
4. After doing (1) and (2), extend constant aggregate emission to always zero padding when required by the language standard. (If you want, make the flag be three-way: never zero, zero as required by language standard, always zero, maybe: -fzero-padding=never / -fzero-padding=std, -fzero-padding=always.)

Just to make sure I understand correctly. There is no proposal to consider non-standard zeroing behaviour in constant expression evaluation; right?

[jfb]

In D68115#1946757, @rsmith wrote:

In D68115#1946668, @hubert.reinterpretcast wrote:

It sounds like we are looking for -fzero-union-padding. That's been where the discussion has left off twice for months.

I believe the state of Clang prior to this patch is actually wrong.

That's my understanding as well. I'd like it if this patch (or a follow-up) got us back to standard behavior. In either case, I'd like the proposed behavior to bee on-by-default when doing initialization of stack variables.

[rsmith]

In D68115#1946990, @jfb wrote:

In D68115#1946757, @rsmith wrote:

In D68115#1946668, @hubert.reinterpretcast wrote:

It sounds like we are looking for -fzero-union-padding. That's been where the discussion has left off twice for months.

I believe the state of Clang prior to this patch is actually wrong.

That's my understanding as well. I'd like it if this patch (or a follow-up) got us back to standard behavior. In either case, I'd like the proposed behavior to bee on-by-default when doing initialization of stack variables.

Your preference is noted. However, 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.

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

[jfb]

In D68115#1962833, @rsmith wrote:

In D68115#1946990, @jfb wrote:

In D68115#1946757, @rsmith wrote:

In D68115#1946668, @hubert.reinterpretcast wrote:

It sounds like we are looking for -fzero-union-padding. That's been where the discussion has left off twice for months.

I believe the state of Clang prior to this patch is actually wrong.

That's my understanding as well. I'd like it if this patch (or a follow-up) got us back to standard behavior. In either case, I'd like the proposed behavior to bee on-by-default when doing initialization of stack variables.

Your preference is noted. However, 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).

[rsmith]

In D68115#1962863, @jfb wrote:

In 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?

[jfb]

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

That's exactly what I'd like, yes!

[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.]

Not guaranteeing a specific value for "pattern" remains my preferred choice. Where feasible, I'd rather we generate the most-repeated pattern so it's cheaper to synthesize.

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?

Yup!

[hubert.reinterpretcast]

In D68115#1962892, @rsmith wrote:

In D68115#1962863, @jfb wrote:

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

That's my view regarding the default behaviour with or without -ftrivial-auto-var-init=pattern, but I believe that there are cases where -ftrivial-auto-var-init=pattern is known to cause trouble for user code (due to the code having what is strictly uninitialized union padding).

[ ... ]

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

I have found that users are less convinced that uninitialized union padding is something to fix in user code than for cases where a variable is missing an initializer and nonetheless accessed without a prior assignment.

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?

There's a chance that "point in the future" is now (and a separate flag was proposed).

[jfb]

To get this unblocked a bit, I implemented a diagnostic: https://reviews.llvm.org/D80055

[tschuett]

As an outsider: In Swift, reading an uninitialized variable is a compile-time error. Clang is not powerful enough to do this analysis. Aren't you really looking for the Clang Intermediate Language (CIL) ?

[jfb]

In D68115#2040696, @tschuett wrote:

As an outsider: In Swift, reading an uninitialized variable is a compile-time error. Clang is not powerful enough to do this analysis. Aren't you really looking for the Clang Intermediate Language (CIL) ?

I have an entire talk about this: https://www.youtube.com/watch?v=I-XUHPimq3o

[tschuett]

I watched the talk, but I still prefer compile-time errors over runtime crashes.

clang/lib/CodeGen/CGExprConstant.cpp

struct ConstantAggregateBuilderUtils {
   llvm::Constant *getZeroes(CharUnits ZeroSize) const {
     llvm::Type *Ty = llvm::ArrayType::get(CGM.Int8Ty, ZeroSize.getQuantity());
     return llvm::ConstantAggregateZero::get(Ty);
   }
 };
 
 /// Incremental builder for an llvm::Constant* holding a struct or array
 /// constant.
-class ConstantAggregateBuilder : private ConstantAggregateBuilderUtils {
+class ConstantAggregateBuilder : public ConstantAggregateBuilderUtils {
   /// The elements of the constant. These two arrays must have the same size;
   /// Offsets[i] describes the offset of Elems[i] within the constant. The
   /// elements are kept in increasing offset order, and we ensure that there
   /// is no overlap: Offsets[i+1] >= Offsets[i] + getSize(Elemes[i]).
   ///
   /// This may contain explicit padding elements (in order to create a
   /// natural layout), but need not. Gaps between elements are implicitly
   /// considered to be filled with undef.

 
 bool ConstStructBuilder::AppendField(
     const FieldDecl *Field, uint64_t FieldOffset, llvm::Constant *InitCst,
     bool AllowOverwrite) {
   const ASTContext &Context = CGM.getContext();
 
   CharUnits FieldOffsetInChars = Context.toCharUnitsFromBits(FieldOffset);
 
-  return AppendBytes(FieldOffsetInChars, InitCst, AllowOverwrite);
+  if (!AppendBytes(FieldOffsetInChars, InitCst, AllowOverwrite))
+    return false;
+
+  if (!Field->getParent()->isUnion())
+    return true;
+
+  const ASTRecordLayout &Layout =
+      CGM.getContext().getASTRecordLayout(Field->getParent());
+  auto ZeroInit = Layout.getSize();
+  auto Z = Builder.getSize(InitCst);
+  if (ZeroInit <= Z)
+    return true;
+  return AppendBytes(FieldOffsetInChars + Z, Builder.getZeroes(ZeroInit - Z),
+                     AllowOverwrite);
 }
 
 bool ConstStructBuilder::AppendBytes(CharUnits FieldOffsetInChars,
                                      llvm::Constant *InitCst,
                                      bool AllowOverwrite) {
   return Builder.add(InitCst, StartOffset + FieldOffsetInChars, AllowOverwrite);
 }
 
bool ConstStructBuilder::AppendBitField(
   // width limits.
   if (FieldSize > FieldValue.getBitWidth())
     FieldValue = FieldValue.zext(FieldSize);
 
   // Truncate the size of FieldValue to the bit field size.
   if (FieldSize < FieldValue.getBitWidth())
     FieldValue = FieldValue.trunc(FieldSize);
 
+  if (Field->getParent()->isUnion()) {
+    const uint64_t CharWidth = CGM.getContext().getCharWidth();
+    assert(FieldOffset % CharWidth == 0);
+
+    const ASTRecordLayout &Layout =
+        CGM.getContext().getASTRecordLayout(Field->getParent());
+    uint64_t ZeroInit = CGM.getContext().toBits(Layout.getSize());
+    if (ZeroInit > FieldSize) {
+      uint64_t AddZeroes = ZeroInit - FieldSize;
+      FieldValue = FieldValue.zext(ZeroInit);
+      if (CGM.getDataLayout().isBigEndian())
+        FieldValue = FieldValue.shl(AddZeroes);
+    }
+  }
+
   return Builder.addBits(FieldValue,
                          CGM.getContext().toBits(StartOffset) + FieldOffset,
                          AllowOverwrite);
 }
 
 static bool EmitDesignatedInitUpdater(ConstantEmitter &Emitter,
                                       ConstantAggregateBuilder &Const,
                                       CharUnits Offset, QualType Type,

clang/test/CodeGen/2008-08-07-AlignPadding1.c

struct gc_generation {
   int threshold;
   int count;
 };
 
 #define GEN_HEAD(n) (&generations[n].head)
 
 // The idea is that there are 6 undefs in this structure initializer to cover
 // the padding between elements.
-// CHECK: @generations = global [3 x %struct.gc_generation] [%struct.gc_generation { %union._gc_head { %struct.anon { %union._gc_head* getelementptr inbounds ([3 x %struct.gc_generation], [3 x %struct.gc_generation]* @generations, i32 0, i32 0, i32 0), %union._gc_head* getelementptr inbounds ([3 x %struct.gc_generation], [3 x %struct.gc_generation]* @generations, i32 0, i32 0, i32 0), i64 0 }, [8 x i8] undef }, i32 700, i32 0, [8 x i8] undef }, %struct.gc_generation { %union._gc_head { %struct.anon { %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 48) to %union._gc_head*), %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 48) to %union._gc_head*), i64 0 }, [8 x i8] undef }, i32 10, i32 0, [8 x i8] undef }, %struct.gc_generation { %union._gc_head { %struct.anon { %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 96) to %union._gc_head*), %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 96) to %union._gc_head*), i64 0 }, [8 x i8] undef }, i32 10, i32 0, [8 x i8] undef }]
+// CHECK: @generations = global [3 x %struct.gc_generation] [%struct.gc_generation { %union._gc_head { %struct.anon { %union._gc_head* getelementptr inbounds ([3 x %struct.gc_generation], [3 x %struct.gc_generation]* @generations, i32 0, i32 0, i32 0), %union._gc_head* getelementptr inbounds ([3 x %struct.gc_generation], [3 x %struct.gc_generation]* @generations, i32 0, i32 0, i32 0), i64 0 }, [8 x i8] zeroinitializer }, i32 700, i32 0, [8 x i8] undef }, %struct.gc_generation { %union._gc_head { %struct.anon { %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 48) to %union._gc_head*), %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 48) to %union._gc_head*), i64 0 }, [8 x i8] zeroinitializer }, i32 10, i32 0, [8 x i8] undef }, %struct.gc_generation { %union._gc_head { %struct.anon { %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 96) to %union._gc_head*), %union._gc_head* bitcast (i8* getelementptr (i8, i8* bitcast ([3 x %struct.gc_generation]* @generations to i8*), i64 96) to %union._gc_head*), i64 0 }, [8 x i8] zeroinitializer }, i32 10, i32 0, [8 x i8] undef }]
 /* linked lists of container objects */
 struct gc_generation generations[3] = {
         /* PyGC_Head,                           threshold,      count */
         {{{GEN_HEAD(0), GEN_HEAD(0), 0}},       700,            0},
         {{{GEN_HEAD(1), GEN_HEAD(1), 0}},       10,             0},
         {{{GEN_HEAD(2), GEN_HEAD(2), 0}},       10,             0},
 };

clang/test/CodeGen/64bit-swiftcall.c

 typedef union {
   float f;
   double d;
 } union_het_fp;
 TEST(union_het_fp)
 // CHECK-LABEL: define swiftcc i64 @return_union_het_fp()
 // CHECK:  [[RET:%.*]] = alloca [[UNION:%.*]], align 8
 // CHECK:  [[CAST:%.*]] = bitcast [[UNION]]* [[RET]] to i8*
-// CHECK:  call void @llvm.memcpy{{.*}}(i8* align 8 [[CAST]]
+// CHECK:  call void @llvm.memset{{.*}}(i8* align 8 [[CAST]]
 // CHECK:  [[CAST:%.*]] = bitcast [[UNION]]* [[RET]] to { i64 }*
 // CHECK:  [[GEP:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[CAST]], i32 0, i32 0
 // CHECK:  [[R0:%.*]] = load i64, i64* [[GEP]], align 8
 // CHECK:  ret i64 [[R0]]
 // CHECK-LABEL: define swiftcc void @take_union_het_fp(i64 %0) {{.*}}{
 // CHECK:   [[V:%.*]] = alloca [[UNION:%.*]], align 8
 // CHECK:   [[CAST:%.*]] = bitcast [[UNION]]* [[V]] to { i64 }*
 // CHECK:   [[GEP:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[CAST]], i32 0, i32 0
 // CHECK:   store i64 %0, i64* [[GEP]], align 8
 // CHECK:   ret void
 // CHECK: }
 // CHECK-LABEL: define void @test_union_het_fp() {{.*}}{
 // CHECK:   [[AGG:%.*]] = alloca [[UNION:%.*]], align 8
 // CHECK:   [[CALL:%.*]] = call swiftcc i64 @return_union_het_fp()
 // CHECK:   [[T0:%.*]] = bitcast [[UNION]]* [[AGG]] to { i64 }*
 // CHECK:   [[T1:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[T0]], i32 0, i32 0
 // CHECK:   store i64 [[CALL]], i64* [[T1]], align 8
 // CHECK:   [[T0:%.*]] = bitcast [[UNION]]* [[AGG]] to { i64 }*
 // CHECK:   [[T1:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[T0]], i32 0, i32 0
 // CHECK:   [[V0:%.*]] = load i64, i64* [[T1]], align 8
 // CHECK:   call swiftcc void @take_union_het_fp(i64 [[V0]])
 // CHECK:   ret void
 // CHECK: }
 
-
 typedef union {
   float f1;
   float f2;
 } union_hom_fp;
 TEST(union_hom_fp)
 // CHECK-LABEL: define void @test_union_hom_fp()
 // CHECK:   [[TMP:%.*]] = alloca [[REC:%.*]], align 4
 // CHECK:   [[CALL:%.*]] = call [[SWIFTCC]] float @return_union_hom_fp()

clang/test/CodeGen/arm-swiftcall.c

 
 typedef union {
   float f;
   double d;
 } union_het_fp;
 TEST(union_het_fp)
 // CHECK-LABEL: define {{.*}} @return_union_het_fp()
 // CHECK:   [[RET:%.*]] = alloca [[REC:%.*]], align {{(4|8)}}
-// CHECK:   @llvm.memcpy
+// CHECK:   @llvm.memset
 // CHECK:   [[CAST_TMP:%.*]] = bitcast [[REC]]* [[RET]] to [[AGG:{ i32, i32 }]]*
 // CHECK:   [[T0:%.*]] = getelementptr inbounds [[AGG]], [[AGG]]* [[CAST_TMP]], i32 0, i32 0
 // CHECK:   [[FIRST:%.*]] = load i32, i32* [[T0]], align {{(4|8)}}
 // CHECK:   [[T0:%.*]] = getelementptr inbounds [[AGG]], [[AGG]]* [[CAST_TMP]], i32 0, i32 1
 // CHECK:   [[SECOND:%.*]] = load i32, i32* [[T0]], align {{(4|8)}}
 // CHECK:   [[T0:%.*]] = insertvalue [[UAGG:{ i32, i32 }]] undef, i32 [[FIRST]], 0
 // CHECK:   [[T1:%.*]] = insertvalue [[UAGG]] [[T0]], i32 [[SECOND]], 1
 // CHECK:   ret [[UAGG]] [[T1]]

 // CHECK:   [[CAST_TMP:%.*]] = bitcast [[REC]]* [[TMP]] to [[AGG]]*
 // CHECK:   [[T0:%.*]] = getelementptr inbounds [[AGG]], [[AGG]]* [[CAST_TMP]], i32 0, i32 0
 // CHECK:   [[FIRST:%.*]] = load i32, i32* [[T0]], align {{(4|8)}}
 // CHECK:   [[T0:%.*]] = getelementptr inbounds [[AGG]], [[AGG]]* [[CAST_TMP]], i32 0, i32 1
 // CHECK:   [[SECOND:%.*]] = load i32, i32* [[T0]], align {{(4|8)}}
 // CHECK:   call [[SWIFTCC]] void @take_union_het_fp(i32 [[FIRST]], i32 [[SECOND]])
 // CHECK:   ret void
 
-
 typedef union {
   float f1;
   float f2;
 } union_hom_fp;
 TEST(union_hom_fp)
 // CHECK-LABEL: define void @test_union_hom_fp()
 // CHECK:   [[TMP:%.*]] = alloca [[REC:%.*]], align 4
 // CHECK:   [[CALL:%.*]] = call [[SWIFTCC]] float @return_union_hom_fp()

clang/test/CodeGen/designated-initializers.c

 // RUN: %clang_cc1 -triple i386-unknown-unknown %s -emit-llvm -o - | FileCheck %s
 
 struct foo {
     void *a;
     int b;
 };
 
 // CHECK: @u = global %union.anon zeroinitializer
 union { int i; float f; } u = { };
 
-// CHECK: @u2 = global { i32, [4 x i8] } { i32 0, [4 x i8] undef }
+// CHECK: @u2 = global { i32, [4 x i8] } zeroinitializer, align 4
 union { int i; double f; } u2 = { };
 
 // CHECK: @u3 = global  %union.anon.1 zeroinitializer
 union { double f; int i; } u3 = { };
 
 // CHECK: @b = global [2 x i32] [i32 0, i32 22]
 int b[2] = {
   [1] = 22

clang/test/CodeGen/init.c

 // RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s
 
 struct I { int k[3]; };
 struct M { struct I o[2]; };
 struct M v1[1] = { [0].o[0 ... 1].k[0 ... 1] = 4, 5 };
 unsigned v2[2][3] = {[0 ... 1][0 ... 1] = 2222, 3333};
 
 // CHECK-DAG: %struct.M = type { [2 x %struct.I] }
 // CHECK-DAG: %struct.I = type { [3 x i32] }
 
 // CHECK-DAG: [1 x %struct.M] [%struct.M { [2 x %struct.I] [%struct.I { [3 x i32] [i32 4, i32 4, i32 0] }, %struct.I { [3 x i32] [i32 4, i32 4, i32 5] }] }],
 // CHECK-DAG: [2 x [3 x i32]] {{[[][[]}}3 x i32] [i32 2222, i32 2222, i32 0], [3 x i32] [i32 2222, i32 2222, i32 3333]],
 // CHECK-DAG: [[INIT14:.*]] = private global [16 x i32] [i32 0, i32 0, i32 0, i32 0, i32 0, i32 17, i32 17, i32 17, i32 17, i32 17, i32 17, i32 17, i32 0, i32 0, i32 0, i32 0], align 4
+// CHECK-DAG: [[INIT_PADDEDUNION:.*]] = private unnamed_addr constant [9 x { i8, [3 x i8] }] [{ i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }], align 4
+// CHECK-DAG: [[INIT_NESTEDUNION:.*]] = private unnamed_addr constant [5 x { { i8, [3 x i8] }, i16, [2 x i8] }] [{ { i8, [3 x i8] }, i16, [2 x i8] } { { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, i16 -3856, [2 x i8] undef }, { { i8, [3 x i8] }, i16, [2 x i8] } { { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, i16 -3856, [2 x i8] undef }, { { i8, [3 x i8] }, i16, [2 x i8] } { { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, i16 -3856, [2 x i8] undef }, { { i8, [3 x i8] }, i16, [2 x i8] } { { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, i16 -3856, [2 x i8] undef }, { { i8, [3 x i8] }, i16, [2 x i8] } { { i8, [3 x i8] } { i8 -16, [3 x i8] zeroinitializer }, i16 -3856, [2 x i8] undef }], align 4
 
 void f1() {
   // Scalars in braces.
   int a = { 1 };
 }
 
 void f2() {
   int a[2][2] = { { 1, 2 }, { 3, 4 } };
void nonzeroMemsetf64() {
   // CHECK-NOT: memcpy
   // CHECK: call void @llvm.memset.p0i8.i32(i8* {{.*}}, i8 68, i32 56, i1 false)
 }
 
 void nonzeroPaddedUnionMemset() {
   union U { char c; int i; };
   union U arr[9] = { 0xF0, 0xF0, 0xF0, 0xF0, 0xF0, 0xF0, 0xF0, 0xF0, 0xF0, };
   // CHECK-LABEL: @nonzeroPaddedUnionMemset(
-  // CHECK-NOT: store
-  // CHECK-NOT: memcpy
-  // CHECK: call void @llvm.memset.p0i8.i32(i8* {{.*}}, i8 -16, i32 36, i1 false)
+  // CHECK: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 {{.*}}, i8* align 4 {{.*}} [[INIT_PADDEDUNION]], {{.*}}, i32 36, i1 false)
 }
 
 void nonzeroNestedMemset() {
   union U { char c; int i; };
   struct S { union U u; short i; };
   struct S arr[5] = { { {0xF0}, 0xF0F0 }, { {0xF0}, 0xF0F0 }, { {0xF0}, 0xF0F0 }, { {0xF0}, 0xF0F0 }, { {0xF0}, 0xF0F0 }, };
   // CHECK-LABEL: @nonzeroNestedMemset(
-  // CHECK-NOT: store
-  // CHECK-NOT: memcpy
-  // CHECK: call void @llvm.memset.p0i8.i32(i8* {{.*}}, i8 -16, i32 40, i1 false)
+  // CHECK: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 {{.*}}, i8* align 4 {{.*}} [[INIT_NESTEDUNION]], {{.*}}, i32 40, i1 false)
 }
 
 // PR9257
 struct test11S {
   int A[10];
 };
 void test11(struct test11S *P) {
   *P = (struct test11S) { .A = { [0 ... 3] = 4 } };

clang/test/CodeGen/union-init2.c

-// RUN: %clang_cc1 -emit-llvm %s -o - -triple i686-pc-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm %s -o - -triple i686-pc-linux-gnu | FileCheck %s --check-prefixes=CHECK,CHECK-LE
+// RUN: %clang_cc1 -emit-llvm %s -o - -triple aarch64_be-none-linux-gnu | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 
 // Make sure we generate something sane instead of a ptrtoint
-// CHECK: bitcast ({ %union.x*, [4 x i8] }* @r to %union.x*), [4 x i8] undef
+// CHECK-LE: @r = global { %union.x*, [4 x i8] } { %union.x* bitcast ({ %union.x*, [4 x i8] }* @r to %union.x*), [4 x i8] zeroinitializer }, align [[ALIGN:4]]
+// CHECK-BE: @r = global { %union.x* } { %union.x* bitcast ({ %union.x* }* @r to %union.x*) }, align [[ALIGN:8]]
 union x {long long b;union x* a;} r = {.a = &r};
 
-
-// CHECK: global { [3 x i8], [5 x i8] } { [3 x i8] zeroinitializer, [5 x i8] undef }
 union z {
   char a[3];
   long long b;
 };
+// CHECK: @y = global { [3 x i8], [5 x i8] } zeroinitializer, align [[ALIGN]]
 union z y = {};
+
+// CHECK: @y2 = global { [3 x i8], [5 x i8] } { [3 x i8] c"\03\00\00", [5 x i8] zeroinitializer }, align [[ALIGN]]
+union z y2 = {3};
+
+union u {
+  int a : 13;
+  long long b;
+};
+
+// CHECK: @t = global { i8, i8, i8, i8, i8, i8, i8, i8 } zeroinitializer, align [[ALIGN]]
+union u t = {};
+
+// CHECK-LE: @t2 = global { i8, i8, i8, i8, i8, i8, i8, i8 } { i8 2, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0 }, align [[ALIGN]]
+// CHECK-BE: @t2 = global { i8, i8, i8, i8, i8, i8, i8, i8 } { i8 0, i8 16, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0 }, align [[ALIGN]]
+union u t2 = {2};

clang/test/CodeGen/windows-swiftcall.c

 typedef union {
   float f;
   double d;
 } union_het_fp;
 TEST(union_het_fp)
 // CHECK-LABEL: define dso_local swiftcc i64 @return_union_het_fp()
 // CHECK:  [[RET:%.*]] = alloca [[UNION:%.*]], align 8
 // CHECK:  [[CAST:%.*]] = bitcast [[UNION]]* [[RET]] to i8*
-// CHECK:  call void @llvm.memcpy{{.*}}(i8* align {{[0-9]+}} [[CAST]]
+// CHECK:  call void @llvm.memset{{.*}}(i8* align {{[0-9]+}} [[CAST]]
 // CHECK:  [[CAST:%.*]] = bitcast [[UNION]]* [[RET]] to { i64 }*
 // CHECK:  [[GEP:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[CAST]], i32 0, i32 0
 // CHECK:  [[R0:%.*]] = load i64, i64* [[GEP]], align 8
 // CHECK:  ret i64 [[R0]]
 // CHECK-LABEL: define dso_local swiftcc void @take_union_het_fp(i64 %0) {{.*}}{
 // CHECK:   [[V:%.*]] = alloca [[UNION:%.*]], align 8
 // CHECK:   [[CAST:%.*]] = bitcast [[UNION]]* [[V]] to { i64 }*
 // CHECK:   [[GEP:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[CAST]], i32 0, i32 0
 // CHECK:   store i64 %0, i64* [[GEP]], align 8
 // CHECK:   ret void
 // CHECK: }
 // CHECK-LABEL: define dso_local void @test_union_het_fp() {{.*}}{
 // CHECK:   [[AGG:%.*]] = alloca [[UNION:%.*]], align 8
 // CHECK:   [[CALL:%.*]] = call swiftcc i64 @return_union_het_fp()
 // CHECK:   [[T0:%.*]] = bitcast [[UNION]]* [[AGG]] to { i64 }*
 // CHECK:   [[T1:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[T0]], i32 0, i32 0
 // CHECK:   store i64 [[CALL]], i64* [[T1]], align 8
 // CHECK:   [[T0:%.*]] = bitcast [[UNION]]* [[AGG]] to { i64 }*
 // CHECK:   [[T1:%.*]] = getelementptr inbounds { i64 }, { i64 }* [[T0]], i32 0, i32 0
 // CHECK:   [[V0:%.*]] = load i64, i64* [[T1]], align 8
 // CHECK:   call swiftcc void @take_union_het_fp(i64 [[V0]])
 // CHECK:   ret void
 // CHECK: }
 
-
 typedef union {
   float f1;
   float f2;
 } union_hom_fp;
 TEST(union_hom_fp)
 // CHECK-LABEL: define dso_local void @test_union_hom_fp()
 // CHECK:   [[TMP:%.*]] = alloca [[REC:%.*]], align 4
 // CHECK:   [[CALL:%.*]] = call [[SWIFTCC]] float @return_union_hom_fp()

clang/test/CodeGenCXX/auto-var-init.cpp

 // PATTERN-O1-NOT: @__const.test_unmatched_uninit.uninit
 // PATTERN-O0: @__const.test_unmatched_custom.custom = private unnamed_addr constant %union.unmatched { i32 1001242351 }, align 4
 // PATTERN-O1-NOT: @__const.test_unmatched_custom.custom
 // ZERO-O0: @__const.test_unmatched_custom.custom = private unnamed_addr constant %union.unmatched { i32 1001242351 }, align 4
 // ZERO-O1-NOT: @__const.test_unmatched_custom.custom
 union unmatched { char c; int i; };
 // PATTERN-O0: @__const.test_unmatchedreverse_uninit.uninit = private unnamed_addr constant %union.unmatchedreverse { i32 [[I32]] }, align 4
 // PATTERN-O1-NOT: @__const.test_unmatchedreverse_uninit.uninit
-// PATTERN-O0: @__const.test_unmatchedreverse_custom.custom = private unnamed_addr constant { i8, [3 x i8] } { i8 42, [3 x i8] c"\[[IC]]\[[IC]]\[[IC]]" }, align 4
+// PATTERN-O0: @__const.test_unmatchedreverse_custom.custom = private unnamed_addr constant { i8, [3 x i8] } { i8 42, [3 x i8] zeroinitializer }, align 4
 // PATTERN-O1-NOT: @__const.test_unmatchedreverse_custom.custom
 // ZERO-O0: @__const.test_unmatchedreverse_custom.custom = private unnamed_addr constant { i8, [3 x i8] } { i8 42, [3 x i8] zeroinitializer }, align 4
 // ZERO-O1-NOT: @__const.test_unmatchedreverse_custom.custom
 union unmatchedreverse { int i; char c; };
 // PATTERN-O0: @__const.test_unmatchedfp_uninit.uninit = private unnamed_addr constant %union.unmatchedfp { double 0xFFFFFFFFFFFFFFFF }, align
 // PATTERN-O1-NOT: @__const.test_unmatchedfp_uninit.uninit
 // PATTERN-O0: @__const.test_unmatchedfp_custom.custom = private unnamed_addr constant %union.unmatchedfp { double 0x400921FB54442D18 }, align
 // PATTERN-O1-NOT: @__const.test_unmatchedfp_custom.custom

 // ZERO-LABEL: @test_unmatched_uninit()
 // ZERO-O0: call void @llvm.memset{{.*}}, i8 0,
 // ZERO-O1: store i32 0, {{.*}} align 4
 
 TEST_BRACES(unmatched, unmatched);
 // CHECK-LABEL: @test_unmatched_braces()
 // CHECK:       %braces = alloca %union.unmatched, align
 // CHECK-NEXT:  bitcast
-// CHECK-NEXT:  call void @llvm.memcpy
+// CHECK-NEXT:  call void @llvm.memset.p0i8.i64(i8* align 4 %0, i8 0, i64 4, i1 false
 // CHECK-NEXT:  call void @{{.*}}used{{.*}}%braces)
 
 TEST_CUSTOM(unmatched, unmatched, { .i = 0x3badbeef });
 // CHECK-LABEL: @test_unmatched_custom()
 // CHECK:       %custom = alloca %union.unmatched, align
 // CHECK-O0:    bitcast
 // CHECK-O0:    call void @llvm.memcpy
 // CHECK-O0:    call void @{{.*}}used{{.*}}%custom)

 // CHECK-NEXT:  call void @{{.*}}used{{.*}}%braces)
 
 TEST_CUSTOM(unmatchedreverse, unmatchedreverse, { .c = 42  });
 // CHECK-LABEL: @test_unmatchedreverse_custom()
 // CHECK:       %custom = alloca %union.unmatchedreverse, align
 // CHECK-O0:    bitcast
 // CHECK-O0:    call void @llvm.memcpy
 // CHECK-O0:    call void @{{.*}}used{{.*}}%custom)
-// PATTERN-O1:  store i32 -1431655894, i32* {{.*}}, align 4
+// PATTERN-O1:  store i32 -1431655766, i32* {{.*}}, align 4
 // ZERO-O1:     store i32 42, i32* {{.*}}, align 4
 
 TEST_UNINIT(unmatchedfp, unmatchedfp);
 // CHECK-LABEL: @test_unmatchedfp_uninit()
 // CHECK:       %uninit = alloca %union.unmatchedfp, align
 // CHECK-NEXT:  call void @{{.*}}used{{.*}}%uninit)
 // PATTERN-LABEL: @test_unmatchedfp_uninit()
 // PATTERN-O0: call void @llvm.memcpy{{.*}} @__const.test_unmatchedfp_uninit.uninit
 // ZERO-LABEL: @test_unmatchedfp_uninit()
 // ZERO-O0: call void @llvm.memset{{.*}}, i8 0,
 // ZERO-O1: store i64 0, {{.*}} align 8
 
 TEST_BRACES(unmatchedfp, unmatchedfp);
 // CHECK-LABEL: @test_unmatchedfp_braces()
 // CHECK:       %braces = alloca %union.unmatchedfp, align
 // CHECK-NEXT:  bitcast
-// CHECK-NEXT:  call void @llvm.memcpy
+// CHECK-NEXT:  call void @llvm.memset.p0i8.i64(i8* align 8 %0, i8 0, i64 8, i1 false
 // CHECK-NEXT:  call void @{{.*}}used{{.*}}%braces)
 
 TEST_CUSTOM(unmatchedfp, unmatchedfp, { .d = 3.1415926535897932384626433 });
 // CHECK-LABEL: @test_unmatchedfp_custom()
 // CHECK:       %custom = alloca %union.unmatchedfp, align
 // CHECK-O0:    bitcast
 // CHECK-O0:    call void @llvm.memcpy
 // CHECK-O0:    call void @{{.*}}used{{.*}}%custom)

clang/test/CodeGenCXX/const-init-cxx11.cpp

union U {
       int x;
       const char *y;
     } u;
 
     constexpr A(int n, double d, int x) : n(n), d(d), u(x) {}
     constexpr A(int n, double d, const char *y) : n(n), d(d), u(y) {}
   };
 
-  // CHECK: @_ZN11StructUnion1aE = constant {{.*}} { i32 1, double 2.000000e+00, {{.*}} { i32 3, [4 x i8] undef } }
+  // CHECK: @_ZN11StructUnion1aE = constant {{.*}} { i32 1, double 2.000000e+00, {{.*}} { i32 3, [4 x i8] zeroinitializer } }
   extern constexpr A a(1, 2.0, 3);
 
   // CHECK: @_ZN11StructUnion1bE = constant {{.*}} { i32 4, double 5.000000e+00, {{.*}} { i8* getelementptr inbounds ([6 x i8], [6 x i8]* @{{.*}}, i32 0, i32 0) } }
   extern constexpr A b(4, 5, "hello");
 
   struct B {
     int n;
   };

clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp

namespace NearlyZeroInit {
   struct B { int n; int arr[1024 * 1024 * 1024 * 2u]; } b = {1, {2}};
 }
 
 namespace PR37560 {
   union U {
     char x;
     int a;
   };
-  // FIXME: [dcl.init]p2, the padding bits of the union object should be
-  // initialized to 0, not undef, which would allow us to collapse the tail
-  // of these arrays to zeroinitializer.
-  // CHECK-DAG: @_ZN7PR375601cE = global <{ { i8, [3 x i8] } }> <{ { i8, [3 x i8] } { i8 0, [3 x i8] undef } }>
+  // CHECK-DAG: @_ZN7PR375601cE = global [1 x [[UU:%"[^"]*"]]] zeroinitializer
   U c[1] = {};
-  // CHECK-DAG: @_ZN7PR375601dE = global {{.*}} <{ { i8, [3 x i8] } { i8 97, [3 x i8] undef }, %"{{[^"]*}}" { i32 123 }, { i8, [3 x i8] } { i8 98, [3 x i8] undef }, { i8, [3 x i8] } { i8 0, [3 x i8] undef },
+  // CHECK-DAG: @_ZN7PR375601dE = global <{ { i8, [3 x i8] }, [[UU]], { i8, [3 x i8] }, [13 x [[UU]]] }> <{ { i8, [3 x i8] } { i8 97, [3 x i8] zeroinitializer }, [[UU]] { i32 123 }, { i8, [3 x i8] } { i8 98, [3 x i8] zeroinitializer }, [13 x [[UU]]] zeroinitializer }>
   U d[16] = {'a', {.a = 123}, 'b'};
-  // CHECK-DAG: @_ZN7PR375601eE = global {{.*}} <{ %"{{[^"]*}}" { i32 123 }, %"{{[^"]*}}" { i32 456 }, { i8, [3 x i8] } { i8 0, [3 x i8] undef },
+  // CHECK-DAG: @_ZN7PR375601eE = global <{ [[UU]], [[UU]], [14 x [[UU]]] }> <{ [[UU]] { i32 123 }, [[UU]] { i32 456 }, [14 x [[UU]]] zeroinitializer }>
   U e[16] = {{.a = 123}, {.a = 456}};
 
   union V {
     int a;
     char x;
   };
-  // CHECK-DAG: @_ZN7PR375601fE = global [1 x %"{{[^"]*}}"] zeroinitializer
+  // CHECK-DAG: @_ZN7PR375601fE = global [1 x [[UV:%"[^"]*"]]] zeroinitializer
   V f[1] = {};
-  // CHECK-DAG: @_ZN7PR375601gE = global {{.*}} <{ { i8, [3 x i8] } { i8 97, [3 x i8] undef }, %"{{[^"]*}}" { i32 123 }, { i8, [3 x i8] } { i8 98, [3 x i8] undef }, [13 x %"{{[^"]*}}"] zeroinitializer }>
+  // CHECK-DAG: @_ZN7PR375601gE = global <{ { i8, [3 x i8] }, [[UV]], { i8, [3 x i8] }, [13 x [[UV]]] }> <{ { i8, [3 x i8] } { i8 97, [3 x i8] zeroinitializer }, [[UV]] { i32 123 }, { i8, [3 x i8] } { i8 98, [3 x i8] zeroinitializer }, [13 x [[UV]]] zeroinitializer }>
   V g[16] = {{.x = 'a'}, {.a = 123}, {.x = 'b'}};
-  // CHECK-DAG: @_ZN7PR375601hE = global {{.*}} <{ %"{{[^"]*}}" { i32 123 }, %"{{[^"]*}}" { i32 456 }, [14 x %"{{[^"]*}}"] zeroinitializer }>
+  // CHECK-DAG: @_ZN7PR375601hE = global <{ [[UV]], [[UV]], [14 x [[UV]]] }> <{ [[UV]] { i32 123 }, [[UV]] { i32 456 }, [14 x [[UV]]] zeroinitializer }>
   V h[16] = {{.a = 123}, {.a = 456}};
-  // CHECK-DAG: @_ZN7PR375601iE = global [4 x %"{{[^"]*}}"] [%"{{[^"]*}}" { i32 123 }, %"{{[^"]*}}" { i32 456 }, %"{{[^"]*}}" zeroinitializer, %"{{[^"]*}}" zeroinitializer]
+  // CHECK-DAG: @_ZN7PR375601iE = global [4 x [[UV]]] {{\[}}[[UV]] { i32 123 }, [[UV]] { i32 456 }, [[UV]] zeroinitializer, [[UV]] zeroinitializer]
   V i[4] = {{.a = 123}, {.a = 456}};
 }
 
 // CHECK-LABEL: define {{.*}}@_Z3fn1i(
 int fn1(int x) {
   // CHECK: %[[INITLIST:.*]] = alloca %struct.A
   // CHECK: %[[A:.*]] = getelementptr inbounds %struct.A, %struct.A* %[[INITLIST]], i32 0, i32 0
   // CHECK: store i32 %{{.*}}, i32* %[[A]], align 4

clang/test/CodeGenCXX/designated-init.cpp

-// RUN: %clang_cc1 -std=c++98 -emit-llvm -o - %s -triple x86_64-linux-gnu | FileCheck %s
-// RUN: %clang_cc1 -std=c++11 -emit-llvm -o - %s -triple x86_64-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 -w -std=c++98 -emit-llvm -o - %s -triple x86_64-linux-gnu | FileCheck %s --check-prefixes=CHECK,CHECK-LE
+// RUN: %clang_cc1 -w -std=c++11 -emit-llvm -o - %s -triple x86_64-linux-gnu | FileCheck %s --check-prefixes=CHECK,CHECK-LE
+// RUN: %clang_cc1 -w -std=c++98 -emit-llvm -o - %s -triple aarch64_be-none-linux-gnu | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang_cc1 -w -std=c++11 -emit-llvm -o - %s -triple aarch64_be-none-linux-gnu | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 
 struct A { int x, y[3]; };
 struct B { A a; };
 
 // CHECK: @b = global %{{[^ ]*}} { %{{[^ ]*}} { i32 1, [3 x i32] [i32 2, i32 5, i32 4] } }
 B b = {(A){1, 2, 3, 4}, .a.y[1] = 5};
 
 union U {
struct Bitfield {
   int a : 3;
   int b : 4;
   int c : 5;
 };
 struct WithBitfield {
   int n;
   Bitfield b;
 };
-// CHECK: @bitfield = {{.*}} { i32 1, { i8, i8, [2 x i8] } { i8 42, i8 2, [2 x i8] undef } }
+// CHECK-LE: @bitfield = {{.*}} { i32 1, { i8, i8, [2 x i8] } { i8 42, i8 2, [2 x i8] undef } }
+// CHECK-BE: @bitfield = {{.*}} { i32 1, { i8, i8, [2 x i8] } { i8 74, i8 64, [2 x i8] undef } }
 WithBitfield bitfield = {1, (Bitfield){2, 3, 4}, .b.b = 5};
 
 struct String {
   const char buffer[12];
 };
 struct WithString {
   String str;
 };

 
 union OverwritePaddingWithBitfield {
   struct Padding { unsigned : 8; char c; } padding;
   char bitfield : 3;
 };
 struct WithOverwritePaddingWithBitfield {
   OverwritePaddingWithBitfield a;
 };
-// CHECK: @overwrite_padding = global { { i8, i8 } } { { i8, i8 } { i8 3, i8 1 } }
+// CHECK-LE: @overwrite_padding = global { { i8, i8 } } { { i8, i8 } { i8 3, i8 0 } }
+// CHECK-BE: @overwrite_padding = global { { i8, i8, i8, i8 } } { { i8, i8, i8, i8 } { i8 96, i8 0, i8 0, i8 0 } }
 WithOverwritePaddingWithBitfield overwrite_padding = {(OverwritePaddingWithBitfield){1}, .a.bitfield = 3};

clang/test/CodeGenCXX/static-init.cpp

 // RUN: %clang_cc1 %s -triple=x86_64-pc-linuxs -emit-llvm -std=c++98 -o - | FileCheck -check-prefix=CHECK -check-prefix=CHECK98 %s
 // RUN: %clang_cc1 %s -triple=x86_64-pc-linuxs -emit-llvm -std=c++11 -o - | FileCheck -check-prefix=CHECK -check-prefix=CHECK11 %s
 
 // CHECK: @_ZZ1hvE1i = internal global i32 0, align 4
 // CHECK: @base_req = global [4 x i8] c"foo\00", align 1
 // CHECK: @base_req_uchar = global [4 x i8] c"bar\00", align 1
 
-// CHECK: @_ZZN5test31BC1EvE1u = internal global { i8, [3 x i8] } { i8 97, [3 x i8] undef }, align 4
+// CHECK: @_ZZN5test31BC1EvE1u = internal global { i8, [3 x i8] } { i8 97, [3 x i8] zeroinitializer }, align 4
 
 // CHECK: @_ZZ2h2vE1i = linkonce_odr global i32 0, comdat, align 4
 // CHECK: @_ZGVZ2h2vE1i = linkonce_odr global i64 0, comdat, align 8{{$}}
 // CHECK: @_ZZN5test1L6getvarEiE3var = internal constant [4 x i32] [i32 1, i32 0, i32 2, i32 4], align 16
 // CHECK98: @_ZZN5test414useStaticLocalEvE3obj = linkonce_odr global %"struct.test4::HasVTable" zeroinitializer, comdat, align 8
 // CHECK11: @_ZZN5test414useStaticLocalEvE3obj = linkonce_odr global { i8** } { i8** getelementptr inbounds ({ [3 x i8*] }, { [3 x i8*] }* @_ZTVN5test49HasVTableE, i32 0, inrange i32 0, i32 2) }, comdat, align 8
 
 struct A {