| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 132193
|
| |
|
|
|
|
| |
These should be DW_OP_bit_piece of CR (64).
llvm-svn: 132192
|
| |
|
|
|
|
|
|
| |
so that it looks at the initializer of a local variable of class type
(or array thereof) to determine whether it's just an implicit
invocation of the trivial default constructor. Fixes PR10034.
llvm-svn: 132191
|
| |
|
|
| |
llvm-svn: 132190
|
| |
|
|
|
|
|
|
|
|
| |
- Flip order of bitfields. This gets our output matching GAS.
- Handle case where the end of the prolog wasn't specified.
- If the resulting unwind info struct is less than 8 bytes, pad to 8 bytes.
Add a test for the latter two.
llvm-svn: 132188
|
| |
|
|
|
|
|
|
| |
refer to them.
I tested this with both check-all and the gdb testsuite.
llvm-svn: 132187
|
| |
|
|
|
|
| |
noexcept workarounds.
llvm-svn: 132186
|
| |
|
|
|
|
|
|
| |
trying instsimplify on the arm where we know the compared value.
Stuff like "x == y ? y : x&y" now folds into "x&y".
llvm-svn: 132185
|
| |
|
|
| |
llvm-svn: 132181
|
| |
|
|
| |
llvm-svn: 132180
|
| |
|
|
|
|
| |
followed by a conditional and imm8.
llvm-svn: 132179
|
| |
|
|
| |
llvm-svn: 132178
|
| |
|
|
|
|
|
| |
Use them to calculate the offset inside the prolog. Emit this value when
emitting the unwind codes.
llvm-svn: 132177
|
| |
|
|
|
|
|
|
| |
to 4 bytes.
I'm surprised no one caught the missing break statements.
llvm-svn: 132176
|
| |
|
|
| |
llvm-svn: 132175
|
| |
|
|
|
|
|
|
| |
still report leaks, but they're spurious now. Valgrind cannot peer into
std::vector objects--or any dynamic array, for that matter--because it doesn't
know how big the array is.
llvm-svn: 132174
|
| |
|
|
|
|
|
| |
already defined, and err when the PushMachFrame operation isn't the first
operation (if specified at all).
llvm-svn: 132173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter types to be ill-formed. However, it relies on the
completeness of method parameter types when producing metadata, e.g.,
for a protocol, leading IR generating to crash in such cases.
Since there's no real way to tighten down the semantics of Objective-C
here without breaking existing code, do something safe but lame:
suppress the generation of metadata when this happens.
Fixes <rdar://problem/9123036>.
llvm-svn: 132171
|
| |
|
|
|
|
| |
question isn't actually in instcombine).
llvm-svn: 132170
|
| |
|
|
| |
llvm-svn: 132168
|
| |
|
|
|
|
| |
InsertNewInstWith, and use setDebugLoc for the cases which can't be easily handled by the automated mechanisms.
llvm-svn: 132167
|
| |
|
|
|
|
|
|
| |
This looks like it flagged an actual bug. Devang, please review. I added
the parentheses that change behavior, but make the behavior more closely
match commit log's intent.
llvm-svn: 132165
|
| |
|
|
| |
llvm-svn: 132164
|
| |
|
|
|
|
|
| |
crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and
crc64.[8|16|32] have been renamed to .crc32.64.[8|64].
llvm-svn: 132163
|
| |
|
|
| |
llvm-svn: 132162
|
| |
|
|
| |
llvm-svn: 132161
|
| |
|
|
| |
llvm-svn: 132160
|
| |
|
|
| |
llvm-svn: 132152
|
| |
|
|
|
|
| |
iSel may not be able to find corresponding Node for llvm.dbg.value during DAG construction. Make iSel's life easier by removing this distance between llvm.dbg.value and its value instruction.
llvm-svn: 132151
|
| |
|
|
| |
llvm-svn: 132150
|
| |
|
|
| |
llvm-svn: 132149
|
| |
|
|
| |
llvm-svn: 132148
|
| |
|
|
| |
llvm-svn: 132147
|
| |
|
|
| |
llvm-svn: 132146
|
| |
|
|
|
|
| |
control of f/fno-diagnostics-show-note-include-stack flags. This should help with reducing diagnostic spew from macros instantiations.
llvm-svn: 132143
|
| |
|
|
| |
llvm-svn: 132141
|
| |
|
|
|
|
| |
a function has any function calls.
llvm-svn: 132140
|
| |
|
|
|
|
| |
This will give a better error message for cases such as "namespace foo::bar::baz {}" and a suggested fix-it of "namespace foo { namespace bar { namespace baz {} } }"
llvm-svn: 132138
|
| |
|
|
| |
llvm-svn: 132137
|
| |
|
|
| |
llvm-svn: 132136
|
| |
|
|
|
|
| |
broken for ARM, please remove the following XFAIL when it will be fixed.
llvm-svn: 132135
|
| |
|
|
| |
llvm-svn: 132134
|
| |
|
|
| |
llvm-svn: 132132
|
| |
|
|
| |
llvm-svn: 132131
|
| |
|
|
| |
llvm-svn: 132130
|
| |
|
|
| |
llvm-svn: 132129
|
| |
|
|
| |
llvm-svn: 132128
|
| |
|
|
| |
llvm-svn: 132127
|
| |
|
|
| |
llvm-svn: 132126
|