- Mar 10, 2013
-
-
Jakub Staszak authored
llvm-svn: 176783
-
Jakub Staszak authored
llvm-svn: 176782
-
Richard Smith authored
llvm-svn: 176781
-
Richard Smith authored
6.4.4.4/1 and 6.4.5/1. llvm-svn: 176780
-
Richard Smith authored
handle raw string literals here. C++11 doesn't yet specify how they will behave, but discussion on core suggests that we should just strip off everything but the r-char-sequence. llvm-svn: 176779
-
Craig Topper authored
Remove an unused member variable from HelpPrinter. Move another member variable to be a local variable in the only method that uses it. llvm-svn: 176778
-
- Mar 09, 2013
-
-
Lang Hames authored
intrinsic - it can cause impossible-to-schedule subgraphs to be introduced. PR15053. llvm-svn: 176777
-
Jakub Staszak authored
llvm-svn: 176776
-
Benjamin Kramer authored
This made us emit runtime checks in a random order. Hopefully bootstrap miscompares will go away now. llvm-svn: 176775
-
Benjamin Kramer authored
llvm-svn: 176774
-
Benjamin Kramer authored
llvm-svn: 176773
-
Benjamin Kramer authored
llvm-svn: 176772
-
Jakub Staszak authored
llvm-svn: 176771
-
Jakub Staszak authored
llvm-svn: 176770
-
Arnold Schwaighofer authored
Ignore all DbgIntriniscInfo instructions instead of just DbgValueInst. llvm-svn: 176769
-
Arnold Schwaighofer authored
We want vectorization to happen at -g. Ignore calls to the dbg.value intrinsic and don't transfer them to the vectorized code. radar://13378964 llvm-svn: 176768
-
Benjamin Kramer authored
llvm-svn: 176767
-
Benjamin Kramer authored
The strlen+memcmp was hidden in a call to StringRef::operator==. We check if there are any null bytes in the string upfront so we can simplify the comparison Small speedup when compiling code with many function calls. llvm-svn: 176766
-
Jakub Staszak authored
llvm-svn: 176765
-
Nick Lewycky authored
r176751. Also, learn a lesson about applying patches by hand/eyeball. llvm-svn: 176764
-
Nick Lewycky authored
llvm-svn: 176763
-
Nick Lewycky authored
for choosing to emit a shndx was simply testing the wrong variable. llvm-svn: 176762
-
Jason Molenda authored
DNBArchImplARM. This framework is no longer around; all armv7 devices support using hardware breakpoints to instruction single step. llvm-svn: 176761
-
Jason Molenda authored
debugserver's build settings. llvm-svn: 176760
-
Jason Molenda authored
Also, don't build debugserver with -DUSE_ARM_DISASSEMBLER_FRAMEWORK - that framework isn't around at this point. llvm-svn: 176759
-
Edwin Vane authored
llvm-svn: 176758
-
Edwin Vane authored
Each transform belongs in its own sub-page now. Minor refactoring to reflect new heading levels. llvm-svn: 176757
-
Anna Zaks authored
[analyzer] Make Suppress IDC checker aware that it might not start from the same node it was registered at The visitor used to assume that the value it’s tracking is null in the first node it examines. This is not true. If we are registering the Suppress Inlined Defensive checks visitor while traversing in another visitor (such as FindlastStoreVisitor). When we restart with the IDC visitor, the invariance of the visitor does not hold since the symbol we are tracking no longer exists at that point. I had to pass the ErrorNode when creating the IDC visitor, because, in some cases, node N is neither the error node nor will be visible along the path (we had not finalized the path at that point and are dealing with ExplodedGraph.) We should revisit the other visitors which might not be aware that they might get nodes, which are later in path than the trigger point. This suppresses a number of inline defensive checks in JavaScriptCore. llvm-svn: 176756
-
Anna Zaks authored
llvm-svn: 176755
-
Anna Zaks authored
This tests that we track the original Expr if getDerefExpr fails. llvm-svn: 176754
-
Greg Clayton authored
llvm-svn: 176753
-
rdar://problem/13384282Greg Clayton authored
As much as I hate to leave this hacky code in that adds some d and q registers to ARM registers, I must leave it in. The code is now fixed to not just assume ANY arm target will have registers in a certain order. We now verify the common regs are the same name and byte size before adding the d and q regs. llvm-svn: 176752
-
Nick Lewycky authored
Count the subprograms, not the compile units. llvm-svn: 176751
-
Sean Callanan authored
an assertion due to non-implicit Objective-C methods without source locations. llvm-svn: 176750
-
Michael J. Spencer authored
llvm-svn: 176749
-
Michael J. Spencer authored
llvm-svn: 176748
-
Michael J. Spencer authored
This only happens when the section header count is > 1024. llvm-svn: 176747
-
Nick Lewycky authored
it. Fortunately, versions of gcov that predate the extra checksum also ignore any extra data, so this isn't a problem. This matches the API change made in r176745. llvm-svn: 176746
-
Nick Lewycky authored
it. Fortunately, versions of gcov that predate the extra checksum also ignore any extra data, so this isn't a problem. There will be a matching commit in compiler-rt. llvm-svn: 176745
-
Jordan Rose authored
Previously, MallocChecker's pointer escape check and its post-call state update for Objective-C method calls had a fair amount duplicated logic and not-entirely-consistent checks. This commit restructures all this to be more consistent and possibly allow us to be more aggressive in warning about double-frees. New policy (applies to system header methods only): (1) If this is a method we know about, model it as taking/holding ownership of the passed-in buffer. (1a) ...unless there's a "freeWhenDone:" parameter with a zero (NO) value. (2) If there's a "freeWhenDone:" parameter (but it's not a method we know about), treat the buffer as escaping if the value is non-zero (YES) and non-escaping if it's zero (NO). (3) If the first selector piece ends with "NoCopy" (but it's not a method we know about and there's no "freeWhenDone:" parameter), treat the buffer as escaping. The reason that (2) and (3) don't explicitly model the ownership transfer is because we can't be sure that they will actually free the memory using free(), and we wouldn't want to emit a spurious "mismatched allocator" warning (coming in Anton's upcoming patch). In the future, we may have an idea of a "generic deallocation", i.e. we assume that the deallocator is correct but still continue tracking the region so that we can warn about double-frees. Patch by Anton Yartsev, with modifications from me. llvm-svn: 176744
-