| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
|
|
|
|
| |
This reverts commit r178497 since the backend has been fixed.
Also add a test to ensure that we're emitting template information for unions.
llvm-svn: 178587
|
|
|
|
|
|
| |
Also add a test for PR15637.
llvm-svn: 178497
|
|
|
|
|
|
|
|
|
| |
* Store the .block_descriptor (instead of self) in the alloca so we
can guarantee that all captured variables are available at -O0.
* Add the missing OpDeref for the alloca.
rdar://problem/12767564
llvm-svn: 178361
|
|
|
|
|
|
|
|
| |
* Let DIType for block-captured self to point to the completed cached
interface type.
rdar://problem/12767564
llvm-svn: 178360
|
|
|
|
|
|
| |
DICompositeType::setContainingType
llvm-svn: 178092
|
|
|
|
|
|
| |
metadata fields
llvm-svn: 178079
|
|
|
|
|
|
|
| |
is enabled. Also add a new -test-coverage cc1 flag which makes testing coverage
possible and add our first clang-side coverage test.
llvm-svn: 177470
|
|
|
|
|
|
| |
Un-breaks gdb's invoke-block behavior.
llvm-svn: 177118
|
|
|
|
|
|
|
|
|
| |
This way the register allocator will not optimize away the debug info
for captured variables.
Fixes rdar://problem/12767564
llvm-svn: 177086
|
|
|
|
|
|
|
|
|
| |
differentiate multiple inlined call sites on the same line
in the debug info.
Fixes rdar://problem/13036237
llvm-svn: 176895
|
|
|
|
|
|
|
|
| |
Generate forward declarations that are RAUW'd by finalize().
We thus avoid outputting the same type several times in multiple
stages of completion.
llvm-svn: 176820
|
|
|
|
|
|
|
|
|
|
| |
that adds ivars to an interface.
Fixes rdar://13175234
This is an update to r176116 that performs a smart caching of interfaces.
llvm-svn: 176584
|
|
|
|
|
|
| |
This reverts commit ea95e4587fd13606fbf63b10a07a7d02026aa39c.
llvm-svn: 176151
|
|
|
|
|
|
| |
adds ivars to an interface. Fixes rdar://13175234
llvm-svn: 176116
|
|
|
|
| |
llvm-svn: 176003
|
|
|
|
|
|
|
|
|
| |
and through to the debug info in the module. In order to make the
testcase a bit more efficient allow the filename to go through
compilation for compile and not assemble jobs and turn off the
extract for cases where we don't create an object.
llvm-svn: 175935
|
|
|
|
|
|
| |
PrintTemplateArgumentList.
llvm-svn: 175894
|
|
|
|
| |
llvm-svn: 175815
|
|
|
|
|
|
| |
By Adrian Pranti.
llvm-svn: 175793
|
|
|
|
|
|
| |
restrictions.
llvm-svn: 174601
|
|
|
|
|
|
| |
This reverts commit 1513eb9284c23acfd19cf742b95996fbb11ca741.
llvm-svn: 174249
|
|
|
|
| |
llvm-svn: 174246
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r173593 made us a little too eager to associate all code at the end of a
function with the user-written 'return' line. This caused problems with
breakpoints as they'd be set in exception handling code preceeding the
actual non-exception return handling code, leading to the breakpoint never
being hit in non-exceptional execution.
This change restores the pre-r173593 exception handling line information where
the cleanup code is associated with the '}' not the return line.
llvm-svn: 174206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the gotchas (see changes to CodeGenFunction) was due to the fix in
r139416 (for PR10829). This only worked previously because the top level
lexical block would set the location to the end of the function, the debug
location would be updated (as per r139416), the location would be set to
the end of the function again (but that would no-op, since it was the same
as the previous location), then the return instruction would be emitted using
the debug location.
Once the top level lexical block was no longer emitted, the end-of-function
location change was causing the debug loc to be updated, regressing that bug.
llvm-svn: 173593
|
|
|
|
| |
llvm-svn: 173022
|
|
|
|
|
|
|
|
|
|
| |
Looks like r161368 fixed this for one case but not all. This change generalizes
the solution over all the unwrapping cases. Now that preserving the qualifiers
is done independent of the particular type being unwrapped I won't bother
adding test cases for each one but at least demonstrate that this change was
necessary & sufficient to fix the bug.
llvm-svn: 173002
|
|
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
|
|
|
|
|
| |
float static members
llvm-svn: 172942
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions.
Adding the pseudo first parameter to a member function pointer's function type
and mark it as artificial.
Combined with a fix to GDB ( http://sourceware.org/bugzilla/show_bug.cgi?id=14998 )
this fixes gdb.cp/member-ptr.exp with Clang.
llvm-svn: 172911
|
|
|
|
|
|
|
|
|
|
| |
order. Describe static data members to metadata using new interfaces.
Part of PR14471.
Patch by Paul Robinson!
llvm-svn: 172591
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for using this to construct the function type for
pointers to member functions to include the implicit/artificial 'this'
parameter in that case as well. (feedback from GDB indicates that this might be
all that's necessary to get it to behave well with Clang's pointer-to-member
function debug output)
llvm-svn: 171809
|
|
|
|
|
|
| |
No (intended) functional change.
llvm-svn: 171800
|
|
|
|
|
|
|
|
|
|
| |
Using added LLVM functionality in r171698. This works in GDB for member
variable pointers but not member function pointers. See the LLVM commit and
GDB bug 14998 for details.
Un-xfailing cases in the GDB 7.5 test suite will follow.
llvm-svn: 171699
|
|
|
|
|
|
|
|
| |
Catch some cases I'd missed in r171605 related to unnamed parameters of record
type. This resolves all remaining cases of PR14573 suppression in the GDB 7.5
test suite. Fix to the test suite to follow.
llvm-svn: 171633
|
|
|
|
|
|
| |
LLVM ignores this data for now - patch for that to follow.
llvm-svn: 171605
|
|
|
|
|
|
| |
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
|