| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 112864
|
| |
|
|
|
|
|
|
|
|
| |
method where they belong. Also fixed a logic error in maintaining the command
interface flag (runStarted) indicating whether the lldb "run"/"process launch"
command has been issued. It was erroneously cleared.
Modified the test cases to take advantage of the refactoring.
llvm-svn: 112863
|
| |
|
|
| |
llvm-svn: 112862
|
| |
|
|
|
|
|
|
|
|
| |
there are clearly no stores between the load and the store. This fixes
this miscompile reported as PR7833.
This breaks the test/CodeGen/X86/narrow_op-2.ll optimization, which is
safe, but awkward to prove safe. Move it to X86's README.txt.
llvm-svn: 112861
|
| |
|
|
|
|
| |
template arguments of a MemberExpr.
llvm-svn: 112860
|
| |
|
|
| |
llvm-svn: 112858
|
| |
|
|
| |
llvm-svn: 112857
|
| |
|
|
|
|
| |
arguments of a DeclRefExpr.
llvm-svn: 112854
|
| |
|
|
| |
llvm-svn: 112853
|
| |
|
|
| |
llvm-svn: 112852
|
| |
|
|
| |
llvm-svn: 112851
|
| |
|
|
| |
llvm-svn: 112850
|
| |
|
|
| |
llvm-svn: 112849
|
| |
|
|
|
|
| |
Based on a patch by Francois Pichet!
llvm-svn: 112848
|
| |
|
|
| |
llvm-svn: 112847
|
| |
|
|
|
|
| |
to be used elsewhere. Also trim trailing whitespaces
llvm-svn: 112846
|
| |
|
|
|
|
| |
locally.
llvm-svn: 112845
|
| |
|
|
|
|
|
| |
Minix apparently doesn't like double-slash separators, and there's
no apparent need for them here.
llvm-svn: 112844
|
| |
|
|
|
|
|
|
| |
LVI lattice, undef and the full set ConstantRange should not
be treated as equivalent.
llvm-svn: 112843
|
| |
|
|
| |
llvm-svn: 112842
|
| |
|
|
|
|
| |
ARM register class allocation order functions to take advantage of that.
llvm-svn: 112841
|
| |
|
|
| |
llvm-svn: 112840
|
| |
|
|
|
|
|
|
|
| |
- SourceRange highlighting is only given for the relevant side of the operator (assignments give both)
- Added PostVisitBinaryOperator hook to retrieve the ExplodedNode for an operator
- Added a BugReporterVisitor to display the last store to every VarDecl in a Stmt
- Changed bug reporting to use the new BugReporterVisitor
llvm-svn: 112839
|
| |
|
|
|
|
|
| |
based on ConvertTypeForMem. Thanks to John for pointing out the right
solution.
llvm-svn: 112838
|
| |
|
|
|
|
|
|
| |
cursors. Sadly, this visitation is a hack, because we don't have
proper source-location information for nested-name-specifiers in the
AST. It does improve on the status quo, however.
llvm-svn: 112837
|
| |
|
|
| |
llvm-svn: 112836
|
| |
|
|
|
|
| |
a 'bool' byref variable in memory. Fixes radar 8382559.
llvm-svn: 112835
|
| |
|
|
| |
llvm-svn: 112834
|
| |
|
|
|
|
| |
should have no effect with the Mac runtime where clang (unlike GCC) uses the display name symbol name.
llvm-svn: 112833
|
| |
|
|
| |
llvm-svn: 112832
|
| |
|
|
| |
llvm-svn: 112830
|
| |
|
|
| |
llvm-svn: 112828
|
| |
|
|
| |
llvm-svn: 112826
|
| |
|
|
|
|
| |
after regalloc.
llvm-svn: 112825
|
| |
|
|
| |
llvm-svn: 112824
|
| |
|
|
|
|
|
|
|
|
|
|
| |
complains when the element type of a C++ "delete" expression is
different from what we would expect from the pointer type. When
deleting a bool*, we end up with an i1 on one side (where we compute
the LLVM type from the Clang bool type) and i8 on the other (where we
grab the LLVM type from the LLVM pointer type). I've weakened the
assertion appropriately, and the Boost Parallel Graph Library now
passes its regression tests.
llvm-svn: 112821
|
| |
|
|
| |
llvm-svn: 112820
|
| |
|
|
|
|
|
|
|
|
|
|
| |
constructing an LLVM PointerType directly from the "bool"'s LLVM type
(i1), which resulted in unfortunate pointer type i1*. The fix is to
build the LLVM PointerType from the corresponding Clang PointerType,
so that we get i8* in the case of a bool.
John, please review. I also left a FIXME there because we seem to be
dropping "volatile", which would be rather unfortunate.
llvm-svn: 112819
|
| |
|
|
| |
llvm-svn: 112818
|
| |
|
|
| |
llvm-svn: 112816
|
| |
|
|
| |
llvm-svn: 112815
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
implement ARM array cookies. Also fix a few unfortunate bugs:
- throwing dtors in deletes prevented the allocation from being deleted
- adding the cookie to the new[] size was not being considered for
overflow (and, more seriously, was screwing up the earlier checks)
- deleting an array via a pointer to array of class type was not
causing any destructors to be run and was passing the unadjusted
pointer to the deallocator
- lots of address-space problems, in case anyone wants to support
free store in a variant address space :)
llvm-svn: 112814
|
| |
|
|
|
|
| |
in a comment.
llvm-svn: 112813
|
| |
|
|
|
|
| |
and there seems to be no reason not to.
llvm-svn: 112812
|
| |
|
|
|
|
|
|
| |
intervals, and where the uses and defs of the original intervals were in the original code.
Spill intervals can be hidden using the "-rmf-intervals=virt-nospills*" option.
llvm-svn: 112811
|
| |
|
|
|
|
|
|
|
| |
I'm sure it is harmless. Original commit message:
If PrototypeValue is erased in the middle of using the SSAUpdator
then the SSAUpdator may access freed memory. Instead, simply pass
in the type and name explicitly, which is all that was used anyway.
llvm-svn: 112810
|
| |
|
|
| |
llvm-svn: 112809
|
| |
|
|
| |
llvm-svn: 112808
|
| |
|
|
| |
llvm-svn: 112807
|
| |
|
|
| |
llvm-svn: 112806
|