Fix up three tests - one that was relying on abbreviation number,
another relying on a location list in this case (& testing raw asm,
changed that to use dwarfdump on the debug_info now that that's where
the location is), and another which was added in r184368 - exposing a
bug in that fix that is exposed when we emit the location inline rather
than through a location list. Fix that bug while I'm here.

llvm-svn: 184387

llvm-svn: 184386

[clang-lit] Added the run_long_tests param option/long_tests feature to toggle execution of long running FileCheck tests.

This will allow for longer running FileCheck based tests to be committed to
clang for use on buildbots, preventing the normal make-check cycle from
increasing in time significantly.

This is a necessary change in order to commit the end-to-end arm neon intrinsic
tests since FileCheck takes ~20 seconds to run said test due to the large amount
of neon intrinsics.

To force a test to run only when --param run_long_tests=true is passed in use
the following requires statement:

// REQUIRES: long_tests

llvm-svn: 184385

Revert r184205 and associated patches while investigating issue with broken buildbot (possible interaction with LTO)

<rdar://problem/14209661>

llvm-svn: 184384

[libclang] Make sure crash-recovery for module-building does not interfere with libclang crash-recovery.

This tests llvm commit r184380.
rdar://14204560

llvm-svn: 184383

llvm-svn: 184382

llvm-svn: 184381

[Support/CrashRecoveryContext] Make sure CrashRecoveryContext does not clear the thread-local "CurrentContext"
in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread.

When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable
for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread.

The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up
crash-recovery for its parent.

A test for this will be added in the clang repository.
rdar://14204560

llvm-svn: 184380

llvm-svn: 184379

llvm-svn: 184378

showing "(null)".

llvm-svn: 184377

llvm-svn: 184376

llvm-svn: 184375

llvm-svn: 184374

llvm-svn: 184373

llvm-svn: 184372

llvm-svn: 184371

llvm-svn: 184370

llvm-svn: 184369

We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.

Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).

llvm-svn: 184368

Debug Info: PR14763/r183329 - specify that non-trivial pass-by-value parameters are stored indirectly

This is to fix the location information for such parameters to refer to
the object accessible through the pointer rather than to the pointer
parameter itself.

llvm-svn: 184367

I forgot to to do this in r184356. The only references were in APFloatTest.cpp.

llvm-svn: 184366

This is a precursor to fix a regression caused by PR14763/r183329 where
the location of a non-trivial pass-by-value parameter ends up
incorrectly referring directly to the parameter (a pointer) rather than
the object pointed to by the pointer.

llvm-svn: 184365

The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.

llvm-svn: 184364

This ensures that we won't try to do cleanups of test cases that we are skipping
e.g. this brings down the time required to run the cmdline category on my machine from ~70s to ~30s

llvm-svn: 184363

llvm-svn: 184362

This is a basic implementation - we still don't have any support (that I
know of) for dumping DWARF expressions in a meaningful way, so the
location information itself is just printed as a sequence of bytes as we
do elsewhere.

llvm-svn: 184361

Access the TargetLoweringInfo from the TargetMachine object instead of caching it. The TLI may change between functions. No functionality change.

llvm-svn: 184360

llvm-svn: 184359

Implement full support for non-pointer types in custom allocators.  This is for the associative containers only.  This work still needs to be done on the unordered and sequence containers.  Fixes http://llvm.org/bugs/show_bug.cgi?id=15978

llvm-svn: 184358

[MC/DWARF] Generate multiple .debug_line entries for adjacent .loc directives

The compiler occasionally generates multiple .loc directives in a row
(at the same instruction address).  These need to be transformed into
multple actual .debug_line table entries, since they are used to signal
certain information to the debugger (e.g. if the opening brace of a
function body is on the same line as the declaration).

The MCAsmStreamer version of EmitDwarfLocDirective handles this
correctly by emitting a .loc directive every time it is called.
However, the MCObjectStream version simply defaults to recording
the information and emitting only a single table entry later,
e.g. when EmitInstruction is called.

This patch introduces a MCAsmStreamer::EmitDwarfLocDirective
version that emits a line table entry for a .loc directive
that may already be pending before recording the new directive.
(This is similar to how this is handled in GNU as.)

With this patch (and the code alignment factor patch) applied,
I'm now getting identical DWARF .debug sections for all test-suite
object files on PowerPC for the internal and the external assembler.

llvm-svn: 184357

Turns out all the references were in llvm and not in clang.

llvm-svn: 184356

llvm-svn: 184355

llvm-svn: 184354

Store the individual fields we need instead of a sys::FileStatus.

llvm-svn: 184353

Access the TargetLoweringInfo from the TargetMachine object instead of caching it. The TLI may change between functions. No functionality change.

llvm-svn: 184352

Modified the implementation of fs::GetUniqueID on Windows such that it actually finds a unique identifier for a file.  Also adds unit tests for GetUniqueID.

llvm-svn: 184351

This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:

1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.

llvm-svn: 184350

Access the TargetLoweringInfo from the TargetMachine object instead of caching it. The TLI may change between functions. No functionality change.

llvm-svn: 184349

llvm-svn: 184348