| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
field number was 0 anyhow.
llvm-svn: 171472
|
| |
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
| |
|
|
|
|
| |
Add OpenCL images as clang builtin types.
llvm-svn: 170432
|
| |
|
|
|
|
| |
these files to Windows style.
llvm-svn: 170431
|
| |
|
|
| |
llvm-svn: 170428
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I wasn't sure where to put the test case for this, but this seemed like as good
a place as any. I had to reorder the tests here to make them legible while
still matching the order of metadata output in the IR file (for some reason
making it virtual changed the ordering).
Relevant commit to fix up LLVM to actually respect 'artificial' member
variables is coming once I write up a test case for it.
llvm-svn: 170154
|
| |
|
|
|
|
|
|
|
| |
The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.
llvm-svn: 169311
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
|
|
|
| |
The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.
llvm-svn: 169219
|
| |
|
|
|
|
|
|
|
|
| |
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
llvm-svn: 168825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
|
| |
|
|
| |
llvm-svn: 168041
|
| |
|
|
| |
llvm-svn: 167932
|
| |
|
|
|
|
| |
variables captured in a block. // rdar://12184410
llvm-svn: 167931
|
| |
|
|
|
|
|
|
| |
temporarily since it breaks the gdb bots.
This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7.
llvm-svn: 167887
|
| |
|
|
|
|
|
|
|
| |
If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>
llvm-svn: 167807
|
| |
|
|
|
|
|
|
|
| |
This is useful because unnamed bitfields can have effects on the
offsets which are not otherwise reflected in the DWARF information.
<rdar://problem/12629719>
llvm-svn: 167503
|
| |
|
|
|
|
| |
of class_type).
llvm-svn: 167336
|
| |
|
|
| |
llvm-svn: 167308
|
| |
|
|
| |
llvm-svn: 167261
|
| |
|
|
|
|
| |
and are generated by Clang (global initializers/destructors, thunks) . Fixes PR13942.
llvm-svn: 166676
|
| |
|
|
| |
llvm-svn: 166497
|
| |
|
|
| |
llvm-svn: 166240
|
| |
|
|
|
|
|
|
|
|
| |
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
llvm-svn: 166236
|
| |
|
|
|
|
| |
debug info.
llvm-svn: 166109
|
| |
|
|
|
|
| |
Patch by Jeremiah Zanin.
llvm-svn: 165849
|
| |
|
|
|
|
| |
per address space pointer sizes to be optimized correctly.
llvm-svn: 165726
|
| |
|
|
| |
llvm-svn: 165395
|
| |
|
|
|
|
| |
PR14029, clang part.
llvm-svn: 165289
|
| |
|
|
|
|
|
|
|
| |
that the backend can mark it as the representative pointer for
the block.
rdar://12001329
llvm-svn: 164418
|
| |
|
|
| |
llvm-svn: 164260
|
| |
|
|
| |
llvm-svn: 164254
|
| |
|
|
| |
llvm-svn: 164253
|
| |
|
|
| |
llvm-svn: 164252
|
| |
|
|
|
|
|
|
|
|
|
| |
Make clang emit a flag for DW_AT_object_pointer for the artificial
args where it should (implicit first arguments). FileCheck-ize a
test as well and update tests to take into account the object
pointer flag.
rdar://9797999
llvm-svn: 163755
|
| |
|
|
|
|
| |
this should be done on the subprogram, not the variable.
llvm-svn: 163733
|
| |
|
|
|
|
|
|
|
|
| |
args where it should (implicit first arguments). FileCheck-ize a
test as well and update tests to take into account the object
pointer flag.
rdar://9797999
llvm-svn: 163668
|
| |
|
|
| |
llvm-svn: 163586
|
| |
|
|
|
|
|
|
|
| |
that the types aren't artificial the args are, but this is currently
represented by an artificial type.)
Found by inspection.
llvm-svn: 163585
|
| |
|
|
| |
llvm-svn: 163325
|
| |
|
|
| |
llvm-svn: 163032
|
| |
|
|
|
|
| |
instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins.
llvm-svn: 163013
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Author: Eric Christopher <echristo@apple.com>
Date: Thu Aug 16 23:50:46 2012 +0000
Add some caching here for the builtin types.
rdar://12117935
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162066 91177308-0d34-0410-b5e6-96231b3b80d8
after fixing a thinko.
llvm-svn: 162243
|
| |
|
|
|
|
|
|
| |
Make isa part of objc_object at metadata generation time.
Noticed on inspection.
llvm-svn: 162145
|
| |
|
|
|
|
| |
bots back.
llvm-svn: 162080
|
| |
|
|
|
|
|
|
| |
reference, so &* on an empty WeakVH binds a reference to a dereferenced null
pointer. So don't do that; we have a perfectly good implicit conversion to
Value*.
llvm-svn: 162079
|
| |
|
|
|
|
| |
rdar://12117935
llvm-svn: 162066
|
| |
|
|
|
|
| |
Noticed on inspection.
llvm-svn: 162062
|
| |
|
|
| |
llvm-svn: 161744
|
| |
|
|
|
|
|
|
| |
just let the alignment be zero.
PR13531
llvm-svn: 161379
|