the ClusterManager. Also switched to using Mutex::Locker where we can.

llvm-svn: 149132

map that tracks all live Module classes. We must leak our mutex for our
collection class as it might be destroyed in an order we can't control.

llvm-svn: 149131

Patch by Timur Iskhodzhanov (timurrrr@google.com)

To test:
$ cl /c *.c*
in the asan directory.

The code fails to link if you omit the "/c" part but that's one of the
next steps,
as well as a few TODO's I've put into the Windows-specific code.

llvm-svn: 149130

Patch by Timur Iskhodzhanov (timurrrr@google.com)

The double-extern thing is
http://llvm.org/bugs/show_bug.cgi?id=11869

And the #include <string[s].h> are only needed on Mac (see comments in
the original code)
and also including them might make strchr/index conflict with the g++
system headers (which don't follow the man pages, ouch!)

llvm-svn: 149129

llvm-svn: 149127

llvm-svn: 149125

llvm-svn: 149124

llvm-svn: 149123

Move some patterns back near their instructions and use AddedComplexity to fix priority. Merge some patterns into their instruction definition.

llvm-svn: 149122

-Wno-everything remap all warnings to ignored.

We can now use "-Wno-everything -W<warning>" to ignore all warnings except
specific ones.

llvm-svn: 149121

the original action.

llvm-svn: 149120

llvm-svn: 149118

llvm-svn: 149117

we should (theoretically optimize and codegen ConstantDataVector as well
as ConstantVector.

llvm-svn: 149116

llvm-svn: 149115

GEP instructions are there for the compiler and shouldn't really output much
code (if any at all). When a GEP is stored in the entry block, Fast ISel (for
one) will not know that it could fold it into further uses. For instance, inside
of the EH handling code. This results in a lot of unnecessary spills and loads
which bloat code and slows down pretty much everything.
<rdar://problem/10694814>

llvm-svn: 149114

llvm-svn: 149113

the direct serialization of the linked-list structure. Instead, use a
scheme similar to how we handle redeclarations, with redeclaration
lists on the side. This addresses several issues:
  - In cases involving mixing and matching of many categories across
  many modules, the linked-list structure would not be consistent
  across different modules, and categories would get lost.
  - If a module is loaded after the class definition and its other
  categories have already been loaded, we wouldn't see any categories
  in the newly-loaded module.

llvm-svn: 149112

mid-level constant folding APIs instead of doing its own analysis.
This makes it more general (e.g. can now share a <2 x i64> with a
<4 x i32>) and avoid duplicating a bunch of logic.

llvm-svn: 149111

ConstantVector's to integer type.

llvm-svn: 149110

of a for-range variable.  Fixes PR11793.

llvm-svn: 149109

function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.

llvm-svn: 149108

llvm-svn: 149107

llvm-svn: 149106

llvm-svn: 149105

llvm-svn: 149104

Fixed another double file descriptor close issue that could occur when destroying a ProcessGDBRemote() object. There was a race which was detected by our fd_interposing library:

error: /Applications/Xcode.app/Contents/MacOS/Xcode (pid=55222): close (fd=60) resulted in EBADF:
0   libFDInterposing.dylib              0x00000001082be8ca close$__interposed__ + 666
1   LLDB                                0x00000001194fde91 lldb_private::ConnectionFileDescriptor::Close(int&, lldb_private::Error*) + 97
2   LLDB                                0x00000001194fddcd lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Error*) + 143
3   LLDB                                0x00000001194fe249 lldb_private::ConnectionFileDescriptor::Read(void*, unsigned long, unsigned int, lldb::ConnectionStatus&, lldb_private::Error*) + 835
4   LLDB                                0x00000001194fc320 lldb_private::Communication::Read(void*, unsigned long, unsigned int, lldb::ConnectionStatus&, lldb_private::Error*) + 634
5   LLDB                                0x000000011959c7f4 GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote&, unsigned int) + 228
6   LLDB                                0x000000011959c6b5 GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSeconds(StringExtractorGDBRemote&, unsigned int) + 49
7   LLDB                                0x0000000119629a71 GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse(ProcessGDBRemote*, char const*, unsigned long, StringExtractorGDBRemote&) + 509
8   LLDB                                0x00000001195a4076 ProcessGDBRemote::AsyncThread(void*) + 514
9   LLDB                                0x0000000119568094 ThreadCreateTrampoline(void*) + 91
10  libsystem_c.dylib                   0x00007fff8ca028bf _pthread_start + 335
11  libsystem_c.dylib                   0x00007fff8ca05b75 thread_start + 13

fd=60 was previously closed with this event:
pid=55222: close (fd=60) => 0
0   libFDInterposing.dylib              0x00000001082be870 close$__interposed__ + 576
1   LLDB                                0x00000001194fde91 lldb_private::ConnectionFileDescriptor::Close(int&, lldb_private::Error*) + 97
2   LLDB                                0x00000001194fddcd lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Error*) + 143
3   LLDB                                0x00000001194fbf00 lldb_private::Communication::Disconnect(lldb_private::Error*) + 92
4   LLDB                                0x00000001195a2a77 ProcessGDBRemote::StopAsyncThread() + 89
5   LLDB                                0x00000001195a2bf6 ProcessGDBRemote::DoDestroy() + 310
6   LLDB                                0x00000001195f938d lldb_private::Process::Destroy() + 85
7   LLDB                                0x0000000118819b48 lldb::SBProcess::Kill() + 72
8   DebuggerLLDB                        0x0000000117264358 DBGLLDBSessionThread(void*) + 4450
9   LLDB                                0x0000000119568094 ThreadCreateTrampoline(void*) + 91
10  libsystem_c.dylib                   0x00007fff8ca028bf _pthread_start + 335
11  libsystem_c.dylib                   0x00007fff8ca05b75 thread_start + 13

fd=60 was created with this event:
pid=55222: socket (domain = 2, type = 1, protocol = 6) => fd=60
0   libFDInterposing.dylib              0x00000001082bc968 socket$__interposed__ + 600
1   LLDB                                0x00000001194fd75f lldb_private::ConnectionFileDescriptor::ConnectTCP(char const*, lldb_private::Error*) + 179
.....

llvm-svn: 149103

llvm-svn: 149102

Provide source line number information.

llvm-svn: 149101

It had failed on Win32 due to inability of executing shell scripts.
Still it fails even with mingw MSYS bash.

llvm-svn: 149100

llvm-svn: 149099

Remove a pseudo terminal master open and slave file descriptor that was being
used for pythong stdin. It was not hooked up correctly and was causing file
descriptor leaks.

llvm-svn: 149098

llvm-svn: 149097

llvm-svn: 149096

Turn off implicit truncation warning for compound assignment to bitfields; it might be reasonable in some cases, but it clearly doesn't make sense in some cases, like the included testcase.

<rdar://problem/10238797>, part 2.

llvm-svn: 149095

llvm-svn: 149094

Adjust an example MachObjectWriter diagnostic to use the information
to issue a better message.

Before:
LLVM ERROR: unknown ARM fixup kind!

After:
x.s:6:5: error: unsupported relocation on symbol
    beq bar
    ^

rdar://9800182

llvm-svn: 149093

Can be used to issue more user friendly diagnostics for faulty
relocation constructs and such.

llvm-svn: 149092

llvm-svn: 149091

llvm-svn: 149090