The patch suggested by Logan Chien.

llvm-svn: 162840

For invalid pointers passed to free_common check whether they are actually skewed to hold an additional CFAllocatorRef.
If so, fix the pointer and pass it to asan_free.

See http://code.google.com/p/address-sanitizer/issues/detail?id=70 for more background.

llvm-svn: 162839

Reversing the logic since C99 mode is actually not an extension.  Also, changing the group to the singular to match the diagnostic better.

llvm-svn: 162838

VisitVarDecl should return Error(E), and we should test that the address
of a TLS var can't be used as a constexpr.

llvm-svn: 162837

Can't use __thread in init.c because it doesn't have a triple.

llvm-svn: 162836

This makes Clang produce an error for code such as:

  __thread int x;
  int *p = &x;

The lvalue of a thread-local variable cannot be evaluated at compile
time.

llvm-svn: 162835

[asan/tsan] use InternalScopedBuffer instead of stack arrays. Use mmap inseted of InternalAlloc in InternalScopedBuffer

llvm-svn: 162834

[super dealloc].  rdar://problem/11141872

llvm-svn: 162833

[tsan] fix tsan's Makefile.old -- our build bot still uses it (hopefully, will soon migrate to cmake completely)

llvm-svn: 162832

[asan] fix asan's Makefile.old -- our build bot still uses it (hopefully, will soon migrate to cmake completely)

llvm-svn: 162831

llvm-svn: 162830

llvm-svn: 162829

llvm-svn: 162828

a comma separated collection of key:value pairs (which are strings).  This
allows a general way to provide analyzer configuration data from the command line.

No clients yet.

llvm-svn: 162827

llvm-svn: 162826

llvm-svn: 162825

Adding arbitrary records to ARM.td would break
basic-arm-instructions.s because selection of nop vs mov r0,r0 was
ambiguous (this will be tested by a subsequent addition to ARM.td).
An imperfect but sensible fix is to give precedence to match rules
that have more constraints.

llvm-svn: 162824

llvm-svn: 162823

library.

These headers are intended to be available to user code when built with
AddressSanitizer (or one of the other sanitizer's in the future) to
interface with the runtime library. As such, they form stable external
C interfaces, and the headers shouldn't be located within the
implementation.

I've pulled them out into what seem like fairly obvious locations and
names, but I'm wide open to further bikeshedding of these names and
locations.

I've updated the code and the build system to cope with the new
locations, both CMake and Makefile. Please let me know if this breaks
anyone's build.

The eventual goal is to install these headers along side the Clang
builtin headers when we build the ASan runtime and install it. My
current thinking is to locate them at:

  <prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h
  <prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h
  <prefix>/lib/clang/X.Y/include/sanitizer/...

But maybe others have different suggestions?

Fixing the style of the #include between these headers at least unblocks
experimentation with installing them as they now should work when
installed in these locations.

llvm-svn: 162822

I have tested the fix, but have not been successfull in generating
a robust unit test. This can only be exposed through particular
register assignments.

llvm-svn: 162821

llvm-svn: 162820

llvm-svn: 162819

In C++, objects being returned on the stack are actually copy-constructed into
the return value. That means that when a temporary is returned, it still has
to be destroyed, i.e. the returned expression will be wrapped in an
ExprWithCleanups node. Our "returning stack memory" checker needs to look
through this node to see if we really are returning an object by value.

PR13722

llvm-svn: 162817

WHen running with -verify-machineinstrs, check that tied operands come
in matching use/def pairs, and that they are consistent with MCInstrDesc
when it applies.

llvm-svn: 162816

This only fires if using a recent enough CMake -- compiler-rt uses a few
of the more advanced features that not everyone needs.

Please let me know if anyone sees issues with this. I'll be updating
documentation and other stuff to tell people about this.

Many thanks to Alexey for doing a ton of work to get ASan's CMake build
into a really fantastic shape. =]

llvm-svn: 162815

The isTied bit is set automatically when a tied use is added and
MCInstrDesc indicates a tied operand. The tie is broken when one of the
tied operands is removed.

llvm-svn: 162814

llvm-svn: 162813

libprofile: [CMake] Let libprofile_rt be not loadable_module but shared library. Autoconf's one does so.

llvm-svn: 162812

FIXME: profile_rt.dll could be built on win32.
llvm-svn: 162811

Summary:
Summary: Keep history of macro definitions and #undefs with corresponding source locations, so that we can later find out all macros active in a specified source location. We don't save the history in PCH (no need currently). Memory overhead is about sizeof(void*)*3*<number of macro definitions and #undefs>+<in-memory size of all #undef'd macros>

I've run a test on a file composed of 109 .h files from boost 1.49 on x86-64 linux.
Stats before this patch:
*** Preprocessor Stats:
73222 directives found:
  19171 #define.
  4345 #undef.
  #include/#include_next/#import:
    5233 source files entered.
    27 max include stack depth
  19210 #if/#ifndef/#ifdef.
  2384 #else/#elif.
  6891 #endif.
  408 #pragma.
14466 #if/#ifndef#ifdef regions skipped
80023/451669/1270 obj/fn/builtin macros expanded, 85724 on the fast path.
127145 token paste (##) operations performed, 11008 on the fast path.

Preprocessor Memory: 5874615B total
  BumpPtr: 4399104
  Macro Expanded Tokens: 417768
  Predefines Buffer: 8135
  Macros: 1048576
  #pragma push_macro Info: 0
  Poison Reasons: 1024
  Comment Handlers: 8

Stats with this patch:
...
Preprocessor Memory: 7541687B total
  BumpPtr: 6066176
  Macro Expanded Tokens: 417768
  Predefines Buffer: 8135
  Macros: 1048576
  #pragma push_macro Info: 0
  Poison Reasons: 1024
  Comment Handlers: 8

In my test increase in memory usage is about 1.7Mb, which is ~28% of initial preprocessor's memory usage and about 0.8% of clang's total VMM allocation.

As for CPU overhead, it should only be noticeable when iterating over all macros, and should mostly consist of couple extra dereferences and one comparison per macro + skipping of #undef'd macros. It's less trivial to measure, though, as the preprocessor consumes a very small fraction of compilation time.


Reviewers: doug.gregor, klimek, rsmith, djasper

Reviewed By: doug.gregor

CC: cfe-commits, chandlerc

Differential Revision: http://llvm-reviews.chandlerc.com/D28

llvm-svn: 162810

This hoists most of the CFLAGS into a common variable. It also adds
detection for -Wno-c99-extensions and uses it to silence a pile of
warnings.

Finally, it switches to the proper flag -rdynamic.

With this, the cmake build is warning free on my bootstrap Linux build.

llvm-svn: 162809

llvm-svn: 162808

llvm-svn: 162807

use re.findall and specify the regexp of regname: regvalue that we're interested in.
<rdar://problem/12188752> 

llvm-svn: 162806

llvm-svn: 162805

into the correct types when pulling them out in the result
callback in a type safe way.

This is also the base change for multiple things that will
allow handling things more generally and thus supporting more
of the AST, especially handling Type nodes.

Patch contributed by Michael Diamond.

llvm-svn: 162804

Invalidate the instruction cache right before we start actually executing code, otherwise
we can miss some that came later. This is still not quite right for a truly lazilly
compiled environment, but it's closer.

llvm-svn: 162803

Fix a subtle ArchSpec::cores_match() logic issue which prevents the add-dsym command
to add a debug symbol file to one of the target's current modules.

llvm-svn: 162802

and when used in property type declaration, is handled as type
attribute. Do not issue the warning when declaraing the property. 
// rdar://12173491

llvm-svn: 162801

llvm-svn: 162800