as Eli noticed.

llvm-svn: 154641

__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.

Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.

Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.

Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.

With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.

llvm-svn: 154640

llvm-svn: 154638

Added more complete error checking for mutexes only for "Debug" builds where we always check if a mutex is valid prior to doing stuff with it. We also track when mutexes are initialized and destroyed and keep these in sets that can very subsequent pthread_mutex_XXX API calls.

llvm-svn: 154637

llvm-svn: 154636

Fix some test suite errors.  TestForwardDecl.py errors were due to bad Makefile.rules, while TestHiddenIvars.py errors due to features only available in modern objc runtime.

llvm-svn: 154635

the debug information individual Decls came from.

We've had a metadata infrastructure for a while,
which was intended to solve a problem we've since
dealt with in a different way.  (It was meant to
keep track of which definition of an Objective-C
class was the "true" definition, but we now find
it by searching the symbols for the class symbol.)
The metadata is attached to the ExternalASTSource,
which means it has a one-to-one correspondence with
AST contexts.

I've repurposed the metadata infrastructure to
hold the object file and DIE offset for the DWARF
information corresponding to a Decl.  There are
methods in ClangASTContext that get and set this
metadata, and the ClangASTImporter is capable of
tracking down the metadata for Decls that have been
copied out of the debug information into the
parser's AST context without using any additional
memory.

To see the metadata, you just have to enable the
expression log:
-
(lldb) log enable lldb expr
-
and watch the import messages.  The high 32 bits
of the metadata indicate the index of the object
file in its containing DWARFDebugMap; I have also
added a log which you can use to track that mapping:
-
(lldb) log enable dwarf map
-

This adds 64 bits per Decl, which in my testing
hasn't turned out to be very much (debugging Clang
produces around 6500 Decls in my tests).  To track
how much data is being consumed, I've also added a
global variable g_TotalSizeOfMetadata which tracks
the total number of Decls that have metadata in all
active AST contexts.

Right now this metadata is enormously useful for
tracking down bugs in the debug info parser.  In the
future I also want to use this information to provide
more intelligent error messages instead of printing
empty source lines wherever Clang refers to the
location where something is defined.

llvm-svn: 154634

Expose GetAddressClass() from both the SBAddress and SBInstruction so clients can tell the difference between ARM/Thumb opcodes when disassembling ARM.

llvm-svn: 154633

struct __rw_objc_super; no functionality change.

llvm-svn: 154632

directly instead of a user Instruction. This allows them to test
whether a def dominates a particular operand if the user instruction
is a PHI.

llvm-svn: 154631

llvm-svn: 154630

symbolic operands added when using the C disassembler API.

llvm-svn: 154628

FunctionDecls into classes if it looked up a
method in a different DWARF context than the
one where it found the parent class's definition.

The symptom of this was, for a method A::B(),

1) LLDB finds A in context 1, creating a
   CXXRecordDecl for A and marking it as needing
   completion

2) LLDB looks up B in context 2, finds that its
   parent A already has a CXXRecordDecl, but can't
   find a CXXMethodDecl for B

3) Not finding a CXXMethodDecl for B, LLDB doesn't
   set the flag indicating that B was resolved

4) Because the flag wasn't set, LLDB's fallthrough
   code creates a FunctionDecl for B and sticks it
   in the DeclContext -- in this case, A.

5) Clang crashes on finding a FunctionDecl inside a
   CXXRecordDecl.

llvm-svn: 154627

The codepath already only works for source bits > target bits, it's just that
it was testing for the source expr bits to be exactly 64. This meant simple
cases (int i = x_long / 2) were missed & ended up under the general
-Wconversion warning, which a user might not have enabled.

llvm-svn: 154626

We should not deserialize unused declarations from the PCH file. Achieve
this by storing the top level declarations during parsing
(HandleTopLevelDecl ASTConsumer callback) and analyzing/building a call
graph only for those.

Tested the patch on a sample ObjC file that uses PCH. With the patch, 
 the analyzes is 17.5% faster and clang consumes 40% less memory.
Got about 10% overall build/analyzes time decrease on a large Objective
C project.

A bit of CallGraph refactoring/cleanup as well..

llvm-svn: 154625

llvm-svn: 154624

llvm-svn: 154622

llvm-svn: 154620

when BOOL is not of an intergal type when
boolean literals are used. // rdar://11231426

llvm-svn: 154619

There is an assert at line 558 in ScheduleDAGInstrs::buildSchedGraph(AliasAnalysis *AA).
This assert needs to addressed for post RA scheduler. Until that assert is addressed,
any passes that uses post ra scheduler will fail. So, I am temporarily disabling the
hexagon tests until that fix is in.

The assert is as follows:
    assert(!MI->isTerminator() && !MI->isLabel() &&
               "Cannot schedule terminators or labels!");

llvm-svn: 154617

llvm-svn: 154616

llvm-svn: 154615

Fixed an issue that happens in LLDB versions after SBFrame switched to using a lldb::ExecutionContextRefSP where we might segfault due to using a shared pointer with NULL in it. The SBFrame object should always have a valid lldb::ExecutionContextRefSP in it. The SBFrame::Clear() method was doing the wrong thing and is now fixed.

llvm-svn: 154614

llvm-svn: 154613

in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.

On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.

llvm-svn: 154612

llvm-svn: 154611

of zero-initialized sections, virtual sections and common symbols
and preventing the loading of sections which are not required for
execution such as debug information.

Patch by Andy Kaylor!

llvm-svn: 154610

llvm-svn: 154608

llvm-svn: 154607

Otherwise MipsTargetInfoBase::getDefaultFeatures() might return an invalid
features set with an empty feature name.

llvm-svn: 154606

Generalize r153635 to deal with TokenFactor chains; also clean up the logic and fix the tests. rdar://11069732, rdar://11236106

llvm-svn: 154604

Also fixed the ProcessLinux, ProcessPOSIX and ProcessFreeBSD to have the correct UpdateThreadList() prototype.

llvm-svn: 154603

(lldb) command script import heap.py

Find all malloc blocks that contains a pointer value of 0x1234000:
(lldb) ptr_refs 0x1234000

Find all malloc blocks that contain a C string:
(lldb) cstr_refs "hello"

Get info on a malloc block that starts at or contains 0x12340000
(lldb) malloc_info 0x12340000

llvm-svn: 154602

for packet confirmation.  
Also added a bit more logging.
Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state
thread so that the Process can shut down cleanly.

<rdar://problem/11228538>

llvm-svn: 154601

llvm-svn: 154600

llvm-svn: 154597

types. The second and third conversions in the sequence are based on
the conversion for the underlying type, so that we get sensible
overloading behavior for, e.g., _Atomic(int) vs. _Atomic(float).

As part of this, actually implement the lvalue-to-rvalue conversion
for atomic types. There is probably a pile of code in SemaExpr that
can now be deleted, but I haven't tracked it down yet.

llvm-svn: 154596

that of typedef BOOL if found.
// rdar://11231426

llvm-svn: 154595

is non-NULL before asking for its name.

llvm-svn: 154593

__weak and __block when rewriting.
// rdar://11236342

llvm-svn: 154592