llvm-svn: 230454

llvm-svn: 230453

It is possible for the atomic routines to be provided by the compiler without
requiring any additional libraries.  Check if that is the case before checking
for a library.

Patch by Matt Glazar!

llvm-svn: 230452

and llvm::sys::fs::make_absolute prepends the current
working directory to that path, leave the original
bare file name unchanged if $cwd/ls doesn't exist.

http://reviews.llvm.org/D7477
<rdar://problem/18775190>

llvm-svn: 230451

Why do we need a registered target for this?

llvm-svn: 230450

Also add some general test/Parser coverage for SEH blocks.

llvm-svn: 230449

This reverts the revert from commit r230406.

The changes in r230445 and r230446 make the test pass on Windows now.

llvm-svn: 230448

llvm-svn: 230447

Covered by existing tests in test/CodeGen/override-layout.c and
test/CodeGenCXX/override-layout.cpp. Seriously, they found real bugs in
my code. :)

llvm-svn: 230446

llvm-svn: 230445

llvm-svn: 230432

llvm-svn: 230430

llvm-svn: 230429

of writing out an AST file.

llvm-svn: 230428

llvm-svn: 230427

ParseCXXTryBlockCommon() makes sense because it has two callers due to
function try blocks.  There are no SEH function try blocks.

llvm-svn: 230426

llvm-svn: 230425

- add clangCodeGen.a to the tools that need it
- tweak pp-trace command line handling to not conflict with clang's.

llvm-svn: 230424

This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.

This reapplies r230044 with a fixed configure+make build and updated
dependencies and testcase requirements. Over the last iteration this
version adds
- missing target requirements for testcases that specify an x86 triple,
- a missing clangCodeGen.a dependency to libClang.a in the make build.

rdar://problem/19104245

llvm-svn: 230423

llvm-svn: 230422

Some of these tests fail on Darwin systems because of a lack of a triple;
fix that.

llvm-svn: 230421

llvm-svn: 230420

llvm-svn: 230419

llvm-svn: 230418

constructor.

llvm-svn: 230417

Since r199356, we've printed a warning when dropping debug info.
r225562 started crashing on that, since it registered a diagnostic
handler that only expected errors.  This fixes the handler to expect
other severities.  As a side effect, it now prints "error: " at the
start of error messages, similar to `llvm-as`.

There was a testcase for r199356, but it only really checked the
assembler.  Move `test/Bitcode/drop-debug-info.ll` to `test/Assembler`,
and introduce `test/Bitcode/drop-debug-info.3.5.ll` (and companion
`.bc`) to test the bitcode reader.

Note: tools/gold/gold-plugin.cpp has an equivalent bug, but I'm not sure
what the best fix is there.  I'll file a PR.

llvm-svn: 230416

Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

Differential Revision: http://reviews.llvm.org/D7736

llvm-svn: 230415

Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections would be great.

This seems to pass all the tests (check-all, covering clang and llvm) so I
believe that pretty well exercises both the backwards compatibility and common
(same version) compatibility given the number of checked in bitcode files we
already have. Is that a reasonable approach to testing here? Would some more
explicit tests be desired?

1) is this the right way to do back-compat in this case (looking at the number
  of entries in the bitcode record to disambiguate between the old schema and
  the new?)

2) I don't quite understand the logarithm logic to choose the encoding type of
  the type parameter in the abbreviation description, but I found another
  instruction doing the same thing & it seems to work. Is that the right
  approach?

Reviewers: dexonsmith

Differential Revision: http://reviews.llvm.org/D7655

llvm-svn: 230414

This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially  { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).

I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).

The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.

llvm-svn: 230413

graph with M modules to take O(P) time, not just O(M) time, when using explicit
module builds.

llvm-svn: 230412

This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions from the non-comdat side.

In ELF there is no one true section for "4 byte mergeable" constants.
We are better off computing the required properties of the section
and asking the context for it.

llvm-svn: 230411

Suggested by Duncan. Happy to bikeshed the name, cache the result, etc.

llvm-svn: 230410

llvm-svn: 230409

If you try to auto-complete "target symbols<TAB>" you get "target symbolsadd" instead of "target symbols ".

Fix this by returning the fact that the "symbols" word is complete if there is nothing else to complete after the "symbols" word.

<rdar://problem/19164599>

llvm-svn: 230408

I'd been using '' where I should have been using ``.

llvm-svn: 230407

It crashes for targeting (i686|x86_64)-win32.

  clang: clang/lib/AST/VTableBuilder.cpp:142: {anonymous}::FinalOverriders::OverriderInfo {anonymous}::FinalOverriders::getOverrider(const clang::CXXMethodDecl*, clang::CharUnits) const: Assertion `OverridersMap.count(std::make_pair(MD, BaseOffset)) && "Did not find overrider!"' failed.

llvm-svn: 230406

Also, fix confusing bit of the gcroot documentation that bit me personally.

llvm-svn: 230405

llvm-svn: 230404

Fixing an issue pointed out by Sean Silva.  Thanks!

llvm-svn: 230403

llvm-svn: 230402