The MSP430X architecture is an extension of the 16 bit MSP430 architecture to a 20 bit address space. This is done by expanding the processor's registers to 20 bit, keeping the least addressable unit at one octet (CHAR_BIT equals 8).
On this architecture, one could think of an implementation of the C programming language that provides a 20 bit integer type for int, using an 8 bit char, a 16 bit short and an emulated 32 bit long. Since 20 is not a multiple of CHAR_BIT, some padding bits are required when storing a variable of type int. For instance, one could store an int in four bytes, leaving one byte and four bits of another byte as padding.
After reading what the standard says about padding bits in integer types, I'm unsure of how they are supposed to behave. Since in this case the padding only exists for storage, their value can neither be set nor observed except by type punning. And even then, copying an object of this 20 bit type does not copy any padding bits. Is such a kind of padding bits allowed by ISO 9899:2011?
The C standard does not require padding bits to be copied by assignment. Assignment is specified in terms of values, not representations.
N1570 6.2.6.2p5 says:
The values of any padding bits are unspecified.
That's an unqualified statement, implying that they're unspecified in all circumstances, even after an assignment from an object that has some padding bits set.
By itself, that statement might be considered vague enough that it doesn't firmly establish that padding bits aren't necessarily copied.
Padding bits do not contribute to the representation of an integer object. A footnote on the quoted sentence says:
All other combinations of padding bits are alternative object representations of the value specified by the value bits.
(The "other" refers to trap representations.)
6.5.16.1p2, describing simple assignment, says:
In simple assignment (
=), the value of the right operand is converted to the type of the assignment expression and replaces the value stored in the object designated by the left operand.
The description is in terms of values not representations; there is no implication that the representation of the RHS must be maintained in the LHS object. And of course the RHS in an assignment can be an arbitrary expression, not just an object reference. Even if it is just the name of an object, it undergoes lvalue conversion, described in 6.3.2.1p2; this conversion refers only to the value of the object, not to its representation.
(Elsewhere, the standard says that parameter passing, function argument passing, and returning a value from a function behave like simple assignment.)