| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
final assembly
llvm-svn: 168198
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before, the parser would assert on the following code:
@a2 = global i8 addrspace(1)* @a
@a = addrspace(1) global i8 0
because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
the initializer for @a2.
llvm-svn: 168197
|
| |
|
|
| |
llvm-svn: 168196
|
| |
|
|
| |
llvm-svn: 168195
|
| |
|
|
| |
llvm-svn: 168191
|
| |
|
|
|
|
| |
Removed an assert that was for debug only.
llvm-svn: 168190
|
| |
|
|
| |
llvm-svn: 168189
|
| |
|
|
|
|
| |
but wasn't due to the same logic bug that caused PR14361.
llvm-svn: 168186
|
| |
|
|
|
|
| |
A PR is being filed to address some code issues here.
llvm-svn: 168185
|
| |
|
|
|
|
| |
made in upstream llvm (r168114)
llvm-svn: 168184
|
| |
|
|
|
|
| |
visitLog* functions.
llvm-svn: 168183
|
| |
|
|
| |
llvm-svn: 168182
|
| |
|
|
|
|
|
|
|
| |
replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was. There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.
llvm-svn: 168181
|
| |
|
|
| |
llvm-svn: 168180
|
| |
|
|
| |
llvm-svn: 168178
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that a partial match of an (explicit or implicit) allOf matcher
binds results, i.e.
recordDecl(decl().bind("x"), hasName("A"))
can very well bind a record that is not named "A". With this fix, the common
cases of stumbling over this bug are fixed by the BoundNodesMap overwriting the
results of a partial match. An error can still be created with a weird
combination of anyOf and allOf (see inactive test). We need to decide whether
this is worth fixing, as the fix will have performance impact.
Review: http://llvm-reviews.chandlerc.com/D124
llvm-svn: 168177
|
| |
|
|
|
|
| |
Patch by Pekka Jääskeläinen!
llvm-svn: 168176
|
| |
|
|
|
|
|
|
| |
This has been broken for a while, but the branch was never being taken.
(We were trying to do 'str + floatVal'; now we do 'str % intVal' and use
the '%d' format.)
llvm-svn: 168174
|
| |
|
|
|
|
|
| |
Technically this is still a layering violation but it's header-only which makes
it less harmful. No functionality change.
llvm-svn: 168173
|
| |
|
|
|
|
|
|
| |
libRewriteCore.
LLVM_USED_LIBS does nothing here.
llvm-svn: 168172
|
| |
|
|
|
|
| |
to pass on Atom.
llvm-svn: 168171
|
| |
|
|
| |
llvm-svn: 168170
|
| |
|
|
|
|
| |
test which produces linker errors on Darwin.
llvm-svn: 168169
|
| |
|
|
|
|
| |
ubsan on OS X in 'make' build system. Patch by Jean-Daniel Dupas.
llvm-svn: 168168
|
| |
|
|
| |
llvm-svn: 168167
|
| |
|
|
| |
llvm-svn: 168166
|
| |
|
|
|
|
| |
email address for completeness.
llvm-svn: 168165
|
| |
|
|
|
|
|
|
|
|
|
| |
Notably, I'm reviewing this stuff already, and this makes it clear I'm
on the hook for it.
I'm relying on Eric Christopher and Michael Spencer to help with Support
when there are platform specific issues, but Chris wants a single point
of contact, and I'm happy with that.
llvm-svn: 168164
|
| |
|
|
| |
llvm-svn: 168151
|
| |
|
|
| |
llvm-svn: 168150
|
| |
|
|
| |
llvm-svn: 168149
|
| |
|
|
|
|
|
|
|
| |
all symbols during object loading, not just global ones.
This fixes JIT execution of code using llvm.global_ctors with internal
linkage constructors.
llvm-svn: 168148
|
| |
|
|
|
|
|
|
|
|
|
| |
It turns out that the operands of a Constant are not always themselves
Constant. For example, one of the operands of BlockAddress is
BasicBlock, which is not a Constant.
This should fix the dragonegg-x86_64-linux-gcc-4.6-test build which
broke in r168037.
llvm-svn: 168147
|
| |
|
|
| |
llvm-svn: 168146
|
| |
|
|
| |
llvm-svn: 168145
|
| |
|
|
|
|
| |
is present: it is often the case that .debug_aranges section contains ranges only for a small subset of compile units. Test cases will be added in separate commits.
llvm-svn: 168144
|
| |
|
|
| |
llvm-svn: 168143
|
| |
|
|
|
|
|
|
| |
of the code that deals with divs.
Thanks to Paul Redmond for catching this while reviewing the code.
llvm-svn: 168142
|
| |
|
|
|
|
| |
vector types.
llvm-svn: 168141
|
| |
|
|
|
|
|
| |
finally was able to restore a register, instead of just reporting the
frames that couldn't supply the reg.
llvm-svn: 168139
|
| |
|
|
| |
llvm-svn: 168138
|
| |
|
|
| |
llvm-svn: 168137
|
| |
|
|
|
|
| |
it as a pointer.
llvm-svn: 168136
|
| |
|
|
| |
llvm-svn: 168135
|
| |
|
|
|
|
| |
now." I missed Daniel's r168095 by my accident.
llvm-svn: 168134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CachedCompletionAllocator
to the CodeCompletionTUInfo that is going to be used to get the results.
Previously we would use ASTUnit's CodeCompletionTUInfo which has its own allocator
that will go away when we reparse. That could result in a use-after-free bug when
getting the parent context name from a CodeCompletionString.
Addresses rdar://12568377.
llvm-svn: 168133
|
| |
|
|
|
|
| |
None of my buildhost (centos6 x86-64 and cygwin) is passing. Investigating.
llvm-svn: 168132
|
| |
|
|
|
|
| |
allowed in branch delay slot.
llvm-svn: 168131
|
| |
|
|
|
|
|
|
| |
- This diverges from gcc, and confuses tools (like dtrace) which track # line
markers as a way to determine which content is in the context of the main
file.
llvm-svn: 168128
|
| |
|
|
|
|
|
| |
width of an enum with negative values in IntRange. Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.
llvm-svn: 168126
|