the preferred alignment.  Thus, revert r135934, r135935, and r135940.

llvm-svn: 136062

refer to 'expansion' instead of 'instantiation'.

llvm-svn: 136060

llvm-svn: 136059

'expansion' rather than 'instantiation' for macro source locations.

llvm-svn: 136058

etc. With this I think essentially all of the SourceManager APIs are
converted. Comments and random other bits of cleanup should be all thats
left.

llvm-svn: 136057

and various other 'expansion' based terms. I've tried to reformat where
appropriate and catch as many references in comments but I'm going to do
several more passes. Also I've tried to expand parameter names to be
more clear where appropriate.

llvm-svn: 136056

the pid of the process currently being debugged by debugserer in
hex, or 0 if unavailable.

This is effectively the same as the qC packet but that packet is
not clear in either its documentation or implementation (in gdb et al)
as to whether it is intended to return a pid or a thread id.  qGetPid
is unambiguous.

If qGetPid is unimplemented in the remote debugserver, the debugger may
try qC and see what kind of value is returned..

llvm-svn: 136055

llvm-svn: 136054

to isMacroArgExpansion.

llvm-svn: 136053

Indent the frames in the "thread.GetStatus" frame listing.  Also put the same space after each thread listing for "thread backtrace all" as "thread backtrace 1 3 5"

llvm-svn: 136052

llvm-svn: 136051

support for 256-bit versions (but no instruction selection yet, coming next).

llvm-svn: 136050

llvm-svn: 136049

llvm-svn: 136048

27 insertions(+), 62 deletions(-)

llvm-svn: 136047

and to work with pointer arithmetic in addition to array indexing.

The new pointer arithmetic porition of the array bounds checking can be
turned on by -Warray-bounds-pointer-arithmetic (and is off by default).

llvm-svn: 136046

llvm-svn: 136045

llvm-svn: 136044

llvm-svn: 136043

llvm-svn: 136041

optimization from the test.

llvm-svn: 136039

Use the driver instead of just clang -cc1.

llvm-svn: 136037

llvm-svn: 136036

2003-09-18-BitfieldTests.c 2007-04-11-PR1321.c 2003-11-13-TypeSafety.c 2003-08-29-StructLayoutBug.c 2010-05-14-Optimized-VarType.c 2003-10-06-NegateExprType.c 2007-06-05-NoInlineAttribute.c 2011-03-31-ArrayRefFolding.c 2010-07-14-ref-off-end.c Atomics-no64bit.c 2007-05-11-str-const.c 2004-11-27-InvalidConstantExpr.c 2007-04-05-UnPackedStruct.c 2004-03-15-SimpleIndirectGoto.c 2004-01-08-ExternInlineRedefine.c sret2.c 2007-02-07-AddrLabel.c 2002-09-19-StarInLabel.c 2003-11-16-StaticArrayInit.c 2003-08-18-SigSetJmp.c 2007-04-24-VolatileStructCopy.c 2002-07-29-Casts.c 2005-06-15-ExpandGotoInternalProblem.c 2007-09-17-WeakRef.c 2007-04-24-str-const.c 2003-08-30-LargeIntegerBitfieldMember.c inline-asm-mrv.c

from llvm/test/FrontendC.

llvm-svn: 136035

When dead code elimination deletes a PHI value, the virtual register may
split into multiple connected components. In that case, revert each
component to the RS_Assign stage.

The new components are guaranteed to be smaller (the original value
numbers are distributed among the components), so this will always be
making progress. The components are now allowed to evict other live
ranges or be split again.

llvm-svn: 136034

2009-03-09-WeakDeclarations-1.c, and 2010-05-31-palignr.c from
llvm/test/FrontendC.

llvm-svn: 136033

llvm-svn: 136032

llvm-svn: 136031

llvm-svn: 136030

llvm-svn: 136029

llvm-svn: 136028

Rename TargetAsmParser to MCTargetAsmParser and TargetAsmLexer to MCTargetAsmLexer; rename createAsmLexer to createMCAsmLexer and createAsmParser to createMCAsmParser.

llvm-svn: 136027

llvm-svn: 136026

dependence on CodeGen layers and backends from the MC layers.

llvm-svn: 136024

The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.

These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.

To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.

This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.

Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.

llvm-svn: 136023

llvm-svn: 136016

    for child in value:
        # do something with the child value

and SBValue.linked_list_iter():

    for task in task_head.linked_list_iter('next', eol_test):
        # visit each item in the linked list

llvm-svn: 136015

llvm-svn: 136013

llvm-svn: 136012

llvm-svn: 136011