| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
management.
It is better practice and, also, it is not clear whether std::auto_ptr<> is smart enough to know about delete[] vs. delete
llvm-svn: 174236
|
| |
|
|
|
|
|
|
| |
Testing case is reduced from MultiSource/BenchMarks/Prolangs-C++/deriv1.
rdar://problem/13071590
llvm-svn: 174235
|
| |
|
|
|
|
|
|
|
| |
Different modules may have different views of the various "special"
types in the AST, such as the redefinition type for "id". Merge those
types rather than only considering the redefinition types for the
first AST file loaded.
llvm-svn: 174234
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added a regular expression command called "_regexp-list" which mimics the GDB "line" command in the following forms:
LINENUM, to list around that line in current file,
FILE:LINENUM, to list around that line in that file,
FUNCTION, to list around beginning of that function,
*ADDRESS, to list around the line containing that address.
ADDRESS, same as above, but don't require a '*' as long as ADDRESS is hex
llvm-svn: 174233
|
| |
|
|
| |
llvm-svn: 174232
|
| |
|
|
|
|
| |
Added the ability to send monitor command to the remote GDB server with "process plugin packet monitor".
llvm-svn: 174231
|
| |
|
|
| |
llvm-svn: 174230
|
| |
|
|
| |
llvm-svn: 174229
|
| |
|
|
|
|
| |
This Constant could be an aggregate to represent multiple values.
llvm-svn: 174228
|
| |
|
|
|
|
| |
Class global variables were not being linked correctly when debugging with DWARF in .o files.
llvm-svn: 174227
|
| |
|
|
|
|
|
|
|
|
| |
Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD.
Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match.
Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid.
llvm-svn: 174222
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the SCEV vector size in LoopStrengthReduce. It is observed that
the BaseRegs vector size is 4 in most cases,
and elements are frequently copied when it is initialized as
SmallVector<const SCEV *, 2> BaseRegs.
Our benchmark results show that the compilation time performance
improved by ~0.5%.
Patch by Wan Xiaofei.
llvm-svn: 174219
|
| |
|
|
| |
llvm-svn: 174218
|
| |
|
|
| |
llvm-svn: 174217
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces a 'kind' attribute for the <Para> tag, that captures the
kind of the parent block command.
For example:
\todo Meow.
used to be just <Para>Meow.</Para>, but now it is
<Para kind="todo">Meow.</Para>
llvm-svn: 174216
|
| |
|
|
| |
llvm-svn: 174215
|
| |
|
|
|
|
| |
nsstringis are compared without. // rdar://12716301
llvm-svn: 174214
|
| |
|
|
|
|
| |
Suggested by Csaba. Text based on an e-mail of mine on cfe-dev.
llvm-svn: 174213
|
| |
|
|
|
|
|
|
| |
With the optimization in the previous commit, this should be safe again.
Originally applied in r173951, then reverted in r174069.
llvm-svn: 174212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;
Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.
This is a pure optimization; the test changes are to guard against possible
future regressions.
llvm-svn: 174211
|
| |
|
|
| |
llvm-svn: 174210
|
| |
|
|
|
|
|
|
|
|
| |
It's supposed to
be "signed char" not "int".
<rdar://problem/13131126>
llvm-svn: 174209
|
| |
|
|
|
|
|
|
|
| |
1) allows the use of RIP-relative addressing in 32-bit LEA instructions under
x86-64 (ILP32 and LP64)
2) separates the size of address registers in 64-bit LEA instructions from
control by ILP32/LP64.
llvm-svn: 174208
|
| |
|
|
|
|
| |
Found by Alexander Kornienko.
llvm-svn: 174207
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r173593 made us a little too eager to associate all code at the end of a
function with the user-written 'return' line. This caused problems with
breakpoints as they'd be set in exception handling code preceeding the
actual non-exception return handling code, leading to the breakpoint never
being hit in non-exceptional execution.
This change restores the pre-r173593 exception handling line information where
the cleanup code is associated with the '}' not the return line.
llvm-svn: 174206
|
| |
|
|
| |
llvm-svn: 174205
|
| |
|
|
|
|
|
|
| |
instruction set
I've renamed the altivec test to ppc-features (because now there is more than one feature to test).
llvm-svn: 174204
|
| |
|
|
|
|
| |
Part of rdar://13134273
llvm-svn: 174203
|
| |
|
|
|
|
| |
-Wimplicit-fallthrough)
llvm-svn: 174202
|
| |
|
|
| |
llvm-svn: 174201
|
| |
|
|
| |
llvm-svn: 174200
|
| |
|
|
| |
llvm-svn: 174199
|
| |
|
|
| |
llvm-svn: 174198
|
| |
|
|
| |
llvm-svn: 174197
|
| |
|
|
| |
llvm-svn: 174196
|
| |
|
|
| |
llvm-svn: 174195
|
| |
|
|
| |
llvm-svn: 174194
|
| |
|
|
| |
llvm-svn: 174193
|
| |
|
|
|
|
| |
where the module was explicitly or implicitly imported in the local translation unit.
llvm-svn: 174192
|
| |
|
|
|
|
| |
module import occurred.
llvm-svn: 174191
|
| |
|
|
|
|
| |
a source location came from the predefines buffer.
llvm-svn: 174190
|
| |
|
|
| |
llvm-svn: 174189
|
| |
|
|
| |
llvm-svn: 174188
|
| |
|
|
| |
llvm-svn: 174187
|
| |
|
|
| |
llvm-svn: 174186
|
| |
|
|
| |
llvm-svn: 174185
|
| |
|
|
| |
llvm-svn: 174184
|
| |
|
|
| |
llvm-svn: 174183
|
| |
|
|
| |
llvm-svn: 174182
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to the patch, Clang does not properly promote types when a complex
integer operand is combined with an integer via a binary operator, or when
one is assigned to the other in either order. This patch detects when
promotion is needed (and permissible) and generates the necessary code.
The test assmes no target has the same size operands for "char" and
"long long," and that no target performs arithmetic on char operands without
extending them to a larger format first. If there are any targets for
which this is not the case, they should be XFAILed.
llvm-svn: 174181
|