findOrEmitSection).

Vaidas Gasiunas's patch, r201259, fixed one instance where we were always
allocating sections as text. This patch fixes the remaining buggy call sites.

No test case: This isn't breaking anything that I know of, it's just
inconsistent.

<rdar://problem/15943542>

llvm-svn: 201605

This makes it a lot easier to see what's going on from the output.

llvm-svn: 201604

pexpect had a hack to work around some old buggy platforms, and as a
result of the hack running the tests on FreeBSD produced a stream of
kernel warnings in the system log:

  Feb 5 17:19:11 feynman kernel: WARNING pid 11323 (python2.7):
    ioctl sign-extension ioctl ffffffff80087467

The hack has now been removed upstream, so remove it here too.

llvm.org/pr18749

llvm-svn: 201603

No functional change intended.

llvm-svn: 201602

llvm-svn: 201601

Make sure we don't try to print the SystemExit exception, or we will cause the containing process to exit() from under us

llvm-svn: 201600

While at it, have cmake build and test the tool if libedit is not installed,
as this dependency is now optional.

llvm-svn: 201599

llvm-svn: 201598

It doesn't conflict with any cl.exe options and it's useful for debugging.

llvm-svn: 201597

llvm-svn: 201596

llvm-svn: 201595

In rare cases the modification of one scop can effect the validity of other
scops, as code generation of an earlier scop may make the scalar evolution
functions derived for later scops less precise. The example that triggered this
patch was a scop that contained an 'or' expression as follows:

  %add13710 = or i32 %j.19, 1
    -->  {(1 + (4 * %l)),+,2}<nsw><%for.body81>

Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This
information was not available after the first scop was code generated (or
independent-blocks was run on it) and SCEV could not derive a precise SCEV
expression any more. This means we could not any more code generate this SCoP.
My current understanding is that there is always the risk that an earlier code
generation change invalidates later scops.  As the example we have seen here is
difficult to avoid, we use this occasion to guard us against all such
invalidations.

This patch "solves" this issue by verifying right before we start working on
a detected scop, if this scop is in fact still valid. This adds a certain
overhead. However the verification we run is anyways very fast and secondly
it is only run on detected scops. So the overhead should not be very large. As
a later optimization we could detect scops only on demand, such that we need
to run scop-detections always only a single time.

This should fix the single last failure in the LLVM test-suite for the new
scev-based code generation.

llvm-svn: 201593

llvm-svn: 201592

llvm-svn: 201591

llvm-svn: 201590

This is an undocumented, but reportedly widely used flag.
We don't support it, but should be able to parse it.

llvm-svn: 201588

Missed updating this test case with r201585 -- the lockable attribute is now internally represented by CapabilityAttr.

llvm-svn: 201587

Extend the test (like it is done in scan-build) to check also if the variable 
is empty or not.

llvm-svn: 201586

DeLesley Hutchins (who wrote the original thread-safety attribute functionality) and I have agreed to start migrating from lock-specific terminology to "capability"-specific terminology. This opens the door for future threading-related analysis passes so that a common nomenclature can be used.

The following attributes have been (silently) deprecated, with their replacements listed:

lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability

There are no functional changes intended.

llvm-svn: 201585

llvm-svn: 201584

...as well as fake flexible array members: structs that end in arrays with
length 0 or 1.

Patch by Daniel Fahlgren!

llvm-svn: 201583

Summary:
This fixes several test failures when building LLVM on a MIPS host.

The failures were:
    LLVM :: DebugInfo/enum.ll
    LLVM :: DebugInfo/inlined-arguments.ll
    LLVM :: DebugInfo/member-order.ll
    LLVM :: DebugInfo/namespace.ll
    LLVM :: DebugInfo/template-recursive-void.ll
    LLVM :: DebugInfo/tu-composite.ll
    LLVM :: DebugInfo/two-cus-from-same-file.ll
    LLVM :: Linker/type-unique-simple-a.ll
    LLVM :: Linker/type-unique-simple2.ll

Reviewers: jacksprat, matheusalmeida

Reviewed By: matheusalmeida

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

llvm-svn: 201582

TargetData was renamed DataLayout back in r165242.

llvm-svn: 201581

llvm-svn: 201580

llvm-svn: 201579

Recommit r201346, reverted in r201373.

llvm-svn: 201578

This way the same RegisterContext class can support i386 and
amd64/x86_64 core files.

With some further refinement we should be able to merge all of the
processor-specific RegisterContextPOSIX_* classes into a single shared
one.

llvm-svn: 201577

llvm-svn: 201576

llvm-svn: 201575

Extended qualifiers can appear in many places, refactor the code so it's
more reusable.  Add tests in areas where we've increased compatibility.

llvm-svn: 201574

llvm-svn: 201573

llvm-svn: 201572

llvm-svn: 201571

llvm-svn: 201570

Pointer types in the MSVC ABI are a bit awkward, the width of the
pointer is considered a kind of CVR qualifier.

Restrict is handled similarly to const and volatile but is mangled after
the pointer width qualifier.

This fixes PR18880.

llvm-svn: 201569

[tsan] in deadlock detector do not register locks on their creation and unregister them on destruction; added a relevant test

llvm-svn: 201568

Failing on some bots.

llvm-svn: 201567

llvm-svn: 201566

Report segmentation faults near or below stack bottom as stack-overflow
(not stack-buffer-overflow!).

llvm-svn: 201565

llvm-svn: 201564