Add a hook in the C API of LTO so that clients of the code generator can set
their own handler for the LLVM diagnostics.
The handler is defined like this:
typedef void (*lto_diagnostic_handler_t)(lto_codegen_diagnostic_severity_t
severity, const char *diag, void *ctxt)
- severity says how bad this is.
- diag is a string that contains the diagnostic message.
- ctxt is the registered context for this handler.

This hook is more general than the lto_get_error_message, since this function
keeps only the latest message and can only be queried when something went wrong
(no warning for instance).

<rdar://problem/15517596>

llvm-svn: 199338

This was never used for anything so we should just get rid of it.

llvm-svn: 199337

This was never used for anything so we should just get rid of it.

llvm-svn: 199336

Set NaCl OSTargetInfo to have LongLongAlign = 64. Otherwise, it will
pick up the setting of 32 from X86_32TargetInfo.

llvm-svn: 199335

which catch buggy versions of libstdc++. While libc++ would pass them,
we don't actually update the state in the configure script to use libc++
when we pass --enable-libcpp, the logic for that is in the
Makefiles. So just completely skip the library test when that configure
flag is passed.

Hopefully this will be enough to fix the darwin bots at last, and thanks
to Duncan Smith for getting things set up so I can watch the bots myself
on lab.llvm.org and see any failures!

llvm-svn: 199334

This was never used for anything so we should just get rid of it.

llvm-svn: 199333

precise in the length accounting and use memcpy instead of
strcpy/strcat.

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

llvm-svn: 199332

Redirect the output of llc to /dev/null.

llvm-svn: 199329

This fixes a regression intruced by r199135.

Revision 199135 tried to simplify part of the logic in method
DAGCombiner::SimplifyVBinOp introducing calls to method BuildVectorSDNode::isConstant().

However, that revision wrongly changed the check performed by method
SimplifyVBinOp to identify dag nodes that can be folded.
Before revision 199135, that method only tried to simplify vector binary operations
if both operands were build_vector of Constant/ConstantFP/Undef only.

After revision 199135, method SimplifyVBinop tried to
simplify also vector binary operations with only one constant operand.

This fixes the problem restoring the old behavior of SimplifyVBinOp.

llvm-svn: 199328

llvm-svn: 199327

I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too
cumbersome to use without std::move. I will keep the patch locally and submit
when we switch to c++11.

llvm-svn: 199326

enable flag that selects the C++ standard library to use with the host
toolchain. Otherwise we end up testing the wrong config.

I'm not really happy about this placement, but its pragmatic and should
unblock the Apple builders.

llvm-svn: 199325

marked as AlwaysInline or ForceInline.

This moves us to what gcc does with -fno-inline. The attribute approach
was discussed to be better than switching to InlineAlways inliner in presence
of LTO.

llvm-svn: 199324

the | and & bitwise operators.

rdar://15570412

llvm-svn: 199323

Per discussion with Anna a /long/ time ago, it was way too easy to misuse
BlockCall: because it inherited from AnyFunctionCall (through SimpleCall),
getDecl() was constrained to return a FunctionDecl, and you had to call
getBlockDecl() instead. This goes against the whole point of CallEvent
(to abstract over different ways to invoke bodies of code).

Now, BlockCall just inherits directly from CallEvent. There's a bit of
duplication in getting things out of the origin expression (which is still
known to be a CallExpr), but nothing significant.

llvm-svn: 199321

This allows us to use CHECK-LABEL to ensure that we're checking the right CFG.

Debugging change only.

llvm-svn: 199320

llvm-svn: 199319

llvm-svn: 199318

Before:
  var arr = [ 1, 2, 3 ];
  var obj = {a : 1, b : 2, c : 3};

After:
  var arr = [1, 2, 3];
  var obj = {a: 1, b: 2, c: 3};

llvm-svn: 199317

llvm-svn: 199316

llvm-svn: 199315

*quite* ready to just slam C++11 on by default.

llvm-svn: 199314

libstdc++v4.6. This is quite hard to test directly, so we test for it by
checking a known missing feature in that version that was added in v4.7.

This should prevent users from upgrading Clang but not GCC and hosting
with a too-old GCC's libstdc++ and getting strange and hard to debug
errors when we switch to C++11 by default.

Also, switch several of the macros I introduced to use AC_LANG_SOURCE
rather than AC_LANG_PROGRAM as we don't need configure's help writing
our main function (and we don't need such a function at all for most of
the tests).

llvm-svn: 199313

MSVC on x64 requires that we create image relative symbol
references to refer to RTTI data. Seeing as how there is no way to
explicitly make reference to a given relocation type in LLVM IR, pattern
match expressions of the form &foo - &__ImageBase.

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

llvm-svn: 199312

llvm-svn: 199311

Disabling remote MCJIT tests on ARM again, as they're still failing when
self-hosting on ARM, despite all my tests. At least now we have more info
on what message it's breaking and what is going on. Investigating.

llvm-svn: 199310

llvm-svn: 199309

a subprocess invocation which is pretty significant on Windows. It also
likely saves a bunch of thrashing the host machine needlessly. Finally
it makes the tests much more predictable and less dependent on the host.
For example 'header_lookup1.c' was passing '-fno-ms-extensions' just to
thwart the host detection adding it into the compilation. By runnig CC1
directly we don't have to deal with such oddities.

llvm-svn: 199308

test the CC1 layer.

This actually uncovered that the test semes to no longer be passing for
the reasons intended. =[ The name of the test would lead me to believe
that it should be testing the semantics of noreturn in the static
analyzer.... but there are in fact no -verify assertions about noreturn
that i can find. And the noreturn checker is no longer in 'alpha.core'.
It is in 'core.builtins'. The test *does* have one assertion for a null
dereference warning. This *also* isn't in 'alpha.core', but the driver
inserts a pile of other checker packages, including 'core' which has
this warning.

So I have switch the RUN line to actually do the minimal thing that this
test currently exercises, but someone who works on the static analyzer
should probably look at this and either nuke it or move it to actually
check the noreturn behavior.

llvm-svn: 199307

llvm-svn: 199306

llvm-svn: 199305

[lsan] remove LeakSanitizerIsTurnedOffForTheCurrentProcess (this was a bad idea), leave __lsan_is_turned_off

llvm-svn: 199304

replace LeakSanitizerIsTurnedOffForTheCurrentProcess with __lsan_is_turned_off, but this time hide it under __has_feature(address_sanitizer); also include <sanitizer/lsan_interface.h>

llvm-svn: 199303

Way back in r129652 we tried to avoid emitting an empty block at -O0
for switch cases that did nothing but break. This led to a poor
debugging experience as reported in PR9796, so we disabled the
optimization for -O0 but left it in for higher optimization levels in
r154420.

Since the whole point of this was to improve -O0, it's silly to keep
the complexity at all.

llvm-svn: 199302

llvm-svn: 199301

llvm-svn: 199300

llvm-svn: 199299

Fix the attribute enable_if example in the docs to be 100% real-world, instead of merely being close to the real world to mislead people. This now matches the test.

llvm-svn: 199298

Add OpSize16 to the two byte forms of INC/DEC that we only use in 64-bit mode and a 64-bit only LEA. Even though we'll not be in 16-bit mode when we use them it makes their tables consistent with their 32-bit counterparts.

llvm-svn: 199297

llvm-svn: 199296