We forgot a conversion step when initializing an atomic type with an
rvalue of the same type.
This fixes PR22043.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224902 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r220169 which reverted r220153. However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct. This
occurs when the aligned next field offset is greater than the new
field's offset. When this occurs, we make the struct packed.
*However*, once packed the next field offset might be less than the
new feild's offset. It is in this case that we might further pad the
struct.
- We would pad structs which were perfectly sized! This behavior is
immensely old. This behavior came from blindly subtracting
NextFieldOffsetInChars from RecordSize. This doesn't take into
account the fact that the struct might have a greater overall
alignment than the last field.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220175 91177308-0d34-0410-b5e6-96231b3b80d8
or a class derived from T. We already supported this when initializing
_Atomic(T) from T for most (and maybe all) other reasonable values of T.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214390 91177308-0d34-0410-b5e6-96231b3b80d8
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.
On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154612 91177308-0d34-0410-b5e6-96231b3b80d8
David Majnemer