| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
various .cpp files. This macro is inherently non-modular, and it wasn't
even needed in this header file.
llvm-svn: 206775
|
| |
|
|
|
|
| |
instruction
llvm-svn: 206774
|
| |
|
|
|
|
|
|
|
| |
Tentative revert for
http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/8305.
This reverts commit c2a58efff07294fca724f89500538f2ddbcd12ff.
llvm-svn: 206773
|
| |
|
|
| |
llvm-svn: 206772
|
| |
|
|
|
|
|
| |
Change `PositiveFloat` to `UnsignedFloat`, and fix some of the comments
to indicate that it's disappearing eventually.
llvm-svn: 206771
|
| |
|
|
| |
llvm-svn: 206770
|
| |
|
|
| |
llvm-svn: 206769
|
| |
|
|
| |
llvm-svn: 206768
|
| |
|
|
| |
llvm-svn: 206767
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r206707, reapplying r206704. The preceding commit
to CalcSpillWeights should have sorted out the failing buildbots.
<rdar://problem/14292693>
llvm-svn: 206766
|
| |
|
|
|
|
|
|
|
| |
This gross hack forces `hweight` into memory, preventing hidden
precision from making `1 > 1` occasionally equal `true`.
<rdar://problem/14292693>
llvm-svn: 206765
|
| |
|
|
| |
llvm-svn: 206764
|
| |
|
|
|
|
|
|
| |
Use volatile store to protect the generated PTX from DCE.
Patch by Jingyue Wu.
llvm-svn: 206763
|
| |
|
|
|
|
|
|
|
| |
Our build is still getting this test to fail with the presence of const in
'(Foo &const) y = 0x' and '(Foo &&const) z = 0x'. This change simply changes
the match substrings to ignore the portion after the final '&' and before the
closing ')'. This should cover the presence (or absence) of the const qualifier.
llvm-svn: 206762
|
| |
|
|
|
|
|
|
|
|
| |
The underlying issue was actually a Clang bug, now fixed. The test now
reports XPASS for me locally and on the buildbot.
llvm.org/pr17183 (LLDB)
llvm.org/pr18950 (Clang)
llvm-svn: 206761
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perhaps these should be @expectedFailureDarwin instead of
@unittest2.expectedFailure (applying to all hosts); I'm not aware of
the details in the rdars.
Just add a comment for now, for the benefit of anyone investigating
FreeBSD test issues in the future.
rdar://9980907
rdar://15367233
llvm-svn: 206760
|
| |
|
|
| |
llvm-svn: 206759
|
| |
|
|
|
|
| |
It can be reverted a few days later, after X86Disassembler.d is updated not to contain "X86Disassembler.c".
llvm-svn: 206758
|
| |
|
|
|
|
|
|
|
| |
I am not sure if this is due to an LLDB change, or the fact that FreeBSD
now has Clang 3.4.
llvm.org/pr19075
llvm-svn: 206757
|
| |
|
|
| |
llvm-svn: 206756
|
| |
|
|
| |
llvm-svn: 206755
|
| |
|
|
|
|
|
|
|
|
|
| |
ocasionally it fails with a slightly different report:
WARNING: ThreadSanitizer: signal handler spoils errno (pid=3674)
#0 MyHandler(int, siginfo*, void*)
...
#4 __tsan_free_hook
#5 main signal_errno.cc:40
llvm-svn: 206754
|
| |
|
|
| |
llvm-svn: 206753
|
| |
|
|
| |
llvm-svn: 206752
|
| |
|
|
|
|
|
|
|
|
| |
The additional "const" breaks the FreeBSD buildbot, and does not appear
to be due to a LLVM or Clang change. Revert the change while
investigating further.
This reverts revision 206619.
llvm-svn: 206751
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We normally don't drop functions from the C API's, but in this case I think we
can:
* The old implementation of getFileOffset was fairly broken
* The introduction of LLVMGetSymbolFileOffset was itself a C api breaking
change as it removed LLVMGetSymbolOffset.
* It is an incredibly specialized use case. The only reason MCJIT needs it is
because of its odd position of being a dynamic linker of .o files.
llvm-svn: 206750
|
| |
|
|
| |
llvm-svn: 206749
|
| |
|
|
| |
llvm-svn: 206748
|
| |
|
|
| |
llvm-svn: 206747
|
| |
|
|
|
|
| |
memset/memcpy/memmove, replace the intrinsic with __asan_memset/etc. This makes the memset/etc handling more complete and consistent with what we do in msan. It may slowdown some cases (when the intrinsic was actually inlined) and speedup other cases (when it was not inlined)
llvm-svn: 206746
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LazyCallGraph analysis framework. Wire it up all the way through the opt
driver and add some very basic testing that we can build pass pipelines
including these components. Still a lot more to do in terms of testing
that all of this works, but the basic pieces are here.
There is a *lot* of boiler plate here. It's something I'm going to
actively look at reducing, but I don't have any immediate ideas that
don't end up making the code terribly complex in order to fold away the
boilerplate. Until I figure out something to minimize the boilerplate,
almost all of this is based on the code for the existing pass managers,
copied and heavily adjusted to suit the needs of the CGSCC pass
management layer.
The actual CG management still has a bunch of FIXMEs in it. Notably, we
don't do *any* updating of the CG as it is potentially invalidated.
I wanted to get this in place to motivate the new analysis, and add
update APIs to the analysis and the pass management layers in concert to
make sure that the *right* APIs are present.
llvm-svn: 206745
|
| |
|
|
|
|
|
|
|
|
| |
became empty. This would manifest later as an assert failure due to
a non-empty list map but an empty result map. This doesn't easily
manifest with just the module pass manager and the function pass
manager, but the next commit will add the CGSCC pass manager that hits
this assert immediately.
llvm-svn: 206744
|
| |
|
|
| |
llvm-svn: 206743
|
| |
|
|
|
|
| |
-mllvm -asan-instrumentation-with-call-threshold=0. This is very unfortunate since it effectively doubles the number of gunit asan tests that need to be built and run, but as long as we need out-lined calls (PR17409) I see no other way to test this workaround
llvm-svn: 206742
|
| |
|
|
| |
llvm-svn: 206741
|
| |
|
|
|
|
|
|
| |
break the API.
No functionality change.
llvm-svn: 206740
|
| |
|
|
|
|
| |
teach the opt driver to use it rather than a manual list.
llvm-svn: 206739
|
| |
|
|
|
|
|
|
|
|
| |
Generating BZHI in the variable mask case, i.e. (and X, (sub (shl 1, N), 1)),
was already supported, but we were missing the constant-mask case. This patch
fixes that.
<rdar://problem/15480077>
llvm-svn: 206738
|
| |
|
|
|
|
|
|
| |
file. This will make it easy to scale up the number of passes supported.
Currently, it just supports the function and module transformation
passes that were already supported in the opt tool explicitly.
llvm-svn: 206737
|
| |
|
|
|
|
| |
some builder failures.
llvm-svn: 206736
|
| |
|
|
|
|
|
|
| |
Original commit message:
Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN,
safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64).
llvm-svn: 206735
|
| |
|
|
| |
llvm-svn: 206734
|
| |
|
|
| |
llvm-svn: 206733
|
| |
|
|
|
|
| |
safe.urem.iN (iN = i8, i16, i32, or i64).
llvm-svn: 206732
|
| |
|
|
|
|
| |
The lldb-gdbserver tests are skipped if the lldb-gdbserver exe cannot be found (currently only built for Linux and FreeBSD). The lldb-gdbserver exe is found by the LLDB_EXEC environment variable, using the same dir as the lldb exe, and then replacing lldb with lldb-gdbserver.
llvm-svn: 206731
|
| |
|
|
| |
llvm-svn: 206730
|
| |
|
|
|
|
|
|
|
|
|
| |
Unlike the standard AAPCS64 ABI, variadic arguments are always passed on the
stack with the Darwin ABI, and this was not being considered when deciding
whether to expand HFA/HVA arguments in a call. An HFA argument with a "float"
base type was being expanded into separate "float" arguments, each of which
was then extended to a double, resulting in a serious mismatch from what is
expected by the va_arg implementation. <rdar://problem/15777067>
llvm-svn: 206729
|
| |
|
|
| |
llvm-svn: 206728
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It could even be made non-virtual if it weren't for bad compiler
warnings.
This demonstrates that ArgList objects aren't destroyed polymorphically
and possibly that they aren't even used polymorphically. If that's the
case, it might be possible to refactor the two ArgList types more
separately and simplify the Arg ownership model. *continues
experimenting*
llvm-svn: 206727
|
| |
|
|
| |
llvm-svn: 206726
|