llvm-svn: 202919

llvm-svn: 202918

llvm-svn: 202917

I did not intend to cast a pointer to ulittle32_t there because the return
type is const void*.

llvm-svn: 202916

Looks like llvm-readobj is the only customer of this code, and apparently
there's no test to cover this function. I'll write it after finishing
plumbing from llvm-objdump to there.

llvm-svn: 202915

llvm-svn: 202914

llvm-svn: 202913

Some unreachable code is only "sometimes unreachable" because it
is guarded by a configuration value that is determined at compile
time and is always constant.  Sometimes those represent real bugs,
but often they do not.  This patch causes the reachability analysis
to cover such branches even if they are technically unreachable
in the CFG itself.  There are some conservative heuristics at
play here to determine a "configuration value"; these are intended
to be refined over time.

llvm-svn: 202912

Summary:
Our usual definition of max_align_t wouldn't match up with MSVC if it
was used in a template argument.

Reviewers: chandlerc, rsmith, rnk

Reviewed By: chandlerc

CC: cfe-commits

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

llvm-svn: 202911

This change addresses the following bug:
http://www.llvm.org/bugs/show_bug.cgi?id=18814

llvm-svn: 202910

llvm-svn: 202909

Currently this code is duplicated across visitSHL, visitSRA and visitSRL.  The
plan is to add rotates as clients to this new function.

There is no functional change intended here.

llvm-svn: 202908

ProcessGDBRemote::GetAuxvData obtains the auxv from a remote gdbserver (via a binary-data packet), and returns the data as a DataBufferSP.

The patch includes a small fix to GDBRemoteCommunicationClient::SendPacketsAndConcatenateResponses() to support binary file format packet returns (by not assuming each binary packet is a null-terminated string when concatenating them).

llvm-svn: 202907

This simplifies my last patch a bit. No change in
functionality.

llvm-svn: 202906

llvm-svn: 202905

LWG Issue #2271: regex_traits::lookup_classname specification unclear. libc++ already does the right thing; just update the tests.

llvm-svn: 202904

Use llvm::sys::fs::make_absolute to get an absolute path before
matching. Also, allow "." directories to enable testing.  ".." is still
not supported, and will require crossing file system boundaries to
implement correctly.

llvm-svn: 202903

llvm-svn: 202902

Summary:
This is needed to allow MSVC's <atomic> header to properly parse.
It uses _Atomic as a class-id.

Reviewers: rnk

Reviewed By: rnk

CC: cfe-commits

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

llvm-svn: 202901

DebugInfo: Refix r202888 (a fix to r202769) in a different way, ensuring types aren't needlessly built during -gmlt

llvm-svn: 202900

exceed the bounds of the backing memory.

<rdar://problem/16088322>

llvm-svn: 202899

llvm-svn: 202898

llvm-svn: 202897

Looks like libstdc++ 4.7 still needs it.

llvm-svn: 202896

llvm-svn: 202895

llvm-svn: 202894

llvm-svn: 202893

Fies PR19040.

llvm-svn: 202892

clang-cl defaults to -gline-tables-only, because that's the only
CodeView debug info that LLVM knows how to emit.

llvm-svn: 202891

Fixed SBDebugger.CreateTarget("filename") and also make sure remote targets don't pickup bogus locally cached files.

<rdar://problem/16217254>
<rdar://problem/16078651>

llvm-svn: 202890

llvm-svn: 202889

This fails an "isa<> used with null pointer" assert during a clang-cl
self-host on Windows.  This was caused by r202769, and I'm currently
reducing a test case.

Reviewers: dblaikie

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

llvm-svn: 202888

This change uses a fixed known offset for the Linux i386 DR0 register.
This change also undoes the 32-bit wordsize change from r169645 that
revolved around being 32-bit/64-bit friendly in
WriteRegOperation::Execute within the Linux ProcessMonitor.cpp. I ran
all the tests on x86_64 Linux with no failures. I also ran some simple
tests with 32-bit Linux exe on x86_64 host and 32-bit linux exe on
i686 32-bit host and these worked fine.

Note (from Todd): the UserData struct in the Linux i386 register
context (only used by Linux i386 host running Linux 32-bit inferior)
is out of sync with what shows up in the sys/user.h for an 32-bit
Linux build (per an earlier change of mine to make it look more like
x86_64 host running x86 exe). I think we should (1) make i386 Linux
targets run using the same register context (and correct ones) on i386
and x86_64 linux hosts if that is possible, and (2) we could use some
tests around the register handling, particularly to verify things like
DR0 registers are in the right spots on host/target combos that we can
verify vs. known correct values.

Change by Matthew Gardiner.

llvm-svn: 202887

llvm-svn: 202886

llvm-svn: 202885

llvm-svn: 202884

llvm-svn: 202883

llvm-svn: 202882

llvm-svn: 202881

Copying isn't cheap as it contains a std::string.

llvm-svn: 202880