llvm-svn: 98862

No functional changes.

llvm-svn: 98860

llvm-svn: 98859

temporary workaround for matching inc/dec on x86_64 to the correct instruction.
 - This hack will eventually be replaced with a robust mechanism for handling
   matching instructions based on the available target features.

llvm-svn: 98858

to allow custom post-processing of matched instructions.

llvm-svn: 98857

llvm-svn: 98855

llvm-svn: 98854

llvm-svn: 98853

llvm-svn: 98852

llvm-svn: 98851

llvm-svn: 98850

a property which is not lvalue.

llvm-svn: 98848

RecyclingAllocator to allow client code to be simpler, and
simplify several clients.

llvm-svn: 98847

aligned storage, the capacity may be more than what is explicitly
requested.

llvm-svn: 98846

always create a new jump table.  The intention was to avoid merging jump
tables in SelectionDAGBuilder, and to wait for the branch folding pass to
merge tables.  Unfortunately, the same getJumpTableIndex() method is also
used to merge tables in branch folding, so as a result of this change
branch tables are never merged.  Worse, the branch folding code is expecting
getJumpTableIndex to always return the index of an existing table, but with
this change, it never does so.  In at least some cases, e.g., pr6543, this
creates references to non-existent tables.

I've fixed the problem by adding a new createJumpTableIndex function, which
will always create a new table, and I've changed getJumpTableIndex to only
look at existing tables.

llvm-svn: 98845

doesn't apply to the type, only to the variable, so subsequent uses
of U which expect it to be aligned weren't actually aligned.

llvm-svn: 98843

preprocessing record. Use that link with clang_getCursorReferenced()
and clang_getCursorDefinition() to match instantiations of a macro to
the definition of the macro.

llvm-svn: 98842

llvm-svn: 98840

files that produce special relocation types where the 
linker changes movq's into lea's.

llvm-svn: 98839

llvm-svn: 98838

generated by clang_annotateTokens().

llvm-svn: 98837

the macro definitions and macro instantiations that are found
during preprocessing. Preprocessing records are *not* generated by
default; rather, we provide a PPCallbacks subclass that hooks into the
existing callback mechanism to record this activity.

The only client of preprocessing records is CIndex, which keeps track
of macro definitions and instantations so that they can be exposed via
cursors. At present, only token annotation uses these facilities, and
only for macro instantiations; both will change in the near
future. However, with this change, token annotation properly annotates
macro instantiations that do not produce any tokens and instantiations
of macros that are later undef'd, improving our consistency.

Preprocessing directives that are not macro definitions are still
handled by clang_annotateTokens() via re-lexing, so that we don't have
to track every preprocessing directive in the preprocessing record.

Performance impact of preprocessing records is still TBD, although it
is limited to CIndex and therefore out of the path of the main compiler.

llvm-svn: 98836

llvm-svn: 98835

llvm-svn: 98833

intrinsics.  The intrinsic lookup code assumes that this check has been done
and assumes the names are at least 6 characters long.  Valgrind complained
about this.  pr6638.

llvm-svn: 98831

llvm-svn: 98830

BumpPtrAllocator-allocated region to allow it to be stored in a more
compact form and to avoid the need for a non-trivial destructor call.

Use this new mechanism in ScalarEvolution instead of
FastFoldingSetNode to avoid leaking memory in the case where a
FoldingSetNodeID uses heap storage, and to reduce overall memory
usage.

llvm-svn: 98829

llvm-svn: 98827

token sequence to detect macro instantiations (that produce at least
token). WIP.

llvm-svn: 98826

llvm-svn: 98825

llvm-svn: 98824

llvm-svn: 98823

llvm-svn: 98822

Patch by Victor Zverovich!

llvm-svn: 98821

llvm-svn: 98820

llvm-svn: 98819

non-placement news when selecting the corresponding operator delete;  this is
fixed.
Access and ambiguity control for calls to operator new and delete.  Also AFAICT

llvm-svn: 98818

llvm-svn: 98817

llvm-svn: 98816

under valgrind:

==19577== Invalid free() / delete / delete[]
==19577==    at 0x4C9C866: free (vg_replace_malloc.c:325)
==19577==    by 0x5121104: ??? (in /lib/libc-2.10.2.so)
==19577==    by 0x4C97412: _vgnU_freeres (vg_preloaded.c:62)
==19577==    by 0x5041486: __run_exit_handlers (exit.c:93)
==19577==    by 0x50414FE: exit (exit.c:100)
==19577==    by 0x5028B5C: (below main) (libc-start.c:254)
==19577==  Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
==19577== 

Apparently this happens under certain versions of glibc, so valgrind provides
the --run-libc-freeres=no option to avoid calling freeres().  This may increase
the number of "still reachable" blocks valgrind reports, but we don't care
about those, while this error breaks the buildbots.

There are upstream bugs about this at
http://sourceware.org/bugzilla/show_bug.cgi?id=10610 and
http://bugs.kde.org/show_bug.cgi?id=167483, but they don't look likely to be
fixed.

llvm-svn: 98813