Commit Graph

11 Commits

Author SHA1 Message Date
Peter Collingbourne bcf909d737 Update clang for D20348
Differential Revision: http://reviews.llvm.org/D20339

llvm-svn: 272710
2016-06-14 21:02:05 +00:00
Philip Reames c758ca3c5c Adjust clang side tests effected by 239795 before reapplying said change
llvm-svn: 239848
2015-06-16 20:24:06 +00:00
David Blaikie bdf40a62a7 Test case updates for explicit type parameter to the gep operator
llvm-svn: 232187
2015-03-13 18:21:46 +00:00
David Majnemer 3087a2b949 Sema: Permit an atomic type to be initialized by the same atomic type
We forgot a conversion step when initializing an atomic type with an
rvalue of the same type.

This fixes PR22043.

llvm-svn: 224902
2014-12-28 21:47:31 +00:00
David Majnemer 8e133965c8 CodeGen: ConstStructBuilder must verify packed constraints after padding
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.

llvm-svn: 220175
2014-10-19 23:40:06 +00:00
Richard Smith 77be48ac47 PR18097: Support initializing an _Atomic(T) from an object of C++ class type T
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.

llvm-svn: 214390
2014-07-31 06:31:19 +00:00
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Douglas Gregor 298f43df14 Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both
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.

llvm-svn: 154612
2012-04-12 20:42:30 +00:00
Richard Smith be646db000 Update recently-added test to use new __c11_ form of atomic builtins.
llvm-svn: 154514
2012-04-11 18:00:46 +00:00
David Chisnall eb9496efc7 Make __atomic_init() (soon to be __c11_atomic_init()) work with non-scalar types.
llvm-svn: 154507
2012-04-11 17:24:05 +00:00
David Chisnall 28397be059 Allow c++ initialisers to initialise _Atomic fields.
llvm-svn: 154499
2012-04-11 15:29:15 +00:00