[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists

llvm-svn: 199638

coding standards, and instead fix the existing section.

Thanks to Daniel Jasper for pointing out we already had a section
devoted to this topic. Instead of adding sections, just hack on this
section some. Also fix the example in the anonymous namespace section
below it to agree with the new advice.

As a re-cap, this switches the LLVM preferred style to never indent
namespaces. Having two approaches just led to endless (and utterly
pointless) debates about what was "small enough". This wasn't helping
anyone. The no-indent rule is easy to understand and doesn't really make
anything harder to read. Moreover, with tools like clang-format it is
considerably nicer to have simple consistent rules.

llvm-svn: 199637

llvm-svn: 199633

Now instead of just looking in the system root for it, we also look
relative to the clang binary's directory. This should "just work" in
almost all cases. I've added test cases accordingly.

This is probably *very* worthwhile to backport to the 3.4 branch so that
folks can check it out, build it, and use that as their host compiler
going forward.

llvm-svn: 199632

This test fails the newly added regression tests.

llvm-svn: 199631

type units were enabled. The crux of the issue is that the
addDwarfTypeUnitType routine can end up being indirectly recursive. In
this case, the reference into the dense map (TU) became invalid by the
time we popped all the way back and used it to add the DIE type
signature.

Instead, use early return in the case where we can bypass the recursive
step and creating a type unit. Then use the pointer to the new type unit
to set up the DIE type signature in the case where we have to.

I tried really hard to reduce a testcase for this, but it's really
annoying. You have to get this to be mid-recursion when the densemap
grows. Even if we got a test case for this today, it'd be very unlikely
to continue exercising this pattern.

llvm-svn: 199630

Fix all the remaining lost-fast-math-flags bugs I've been able to find.  The most important of these are cases in the generic logic for combining BinaryOperators.
This logic hadn't been updated to handle FastMathFlags, and it took me a while to detect it because it doesn't show up in a simple search for CreateFAdd.

llvm-svn: 199629

llvm-svn: 199628

llvm-svn: 199627

This attribute is supported by GCC.  More generally it should
probably be a type attribute, but this behavior matches 'nonnull'.

This patch does not include warning logic for checking if a null
value is returned from a function annotated with this attribute.
That will come in subsequent patches.

llvm-svn: 199626

llvm-svn: 199625

Remove hard tabs in favour of spaces.  NFC.

llvm-svn: 199624

The alias test "exprf x 1234" expands to "expr -f x 1234" and is
expected to fail: it ends up trying to evaluate the invalid expression

    void
    $__lldb_expr(void *$__lldb_arg)
    {
        -f x 1234;
    }

On FreeBSD LLDB ends up finding a static function f() in a math library,
and thus the error produced does not include "use of undeclared
identifier 'f'".

We will report failure to parse the expression in any case, so require
only that error message.

llvm-svn: 199623

Have I mentioned that functions returning true on error and false on
success are confusing? They're more confusing when their name is
"verify". Anyways...

llvm-svn: 199622

For FCMEQ, FCMGE, FCMGT, FCMLE and FCMLT, floating point zero will be
printed as #0.0 instead of #0. To support the history codes using #0,
we consider to let asm parser accept both #0.0 and #0.

llvm-svn: 199621

(and to mention namespace ending comments). This is based on a quick
discussion on the developer mailing list where there was essentially no
objections to a simple and consistent rule. This should avoid future
debates about whether or not a namespace is "big enough" to indent. It
also matches clang-format's current behavior with LLVM source code which
hasn't really seen any opposition in code reviews that I spot checked.

llvm-svn: 199620

Implement type trait primitives used in the latest edition of the Microsoft
standard C++ library type_traits header.

With this change we can parse much of the Visual Studio 2013 standard headers,
particularly anything that includes <type_traits>.

Fully implemented, available in all language modes:

 * __is_constructible()
 * __is_nothrow_constructible()
 * __is_nothrow_assignable()

Partially implemented, semantic analysis WIP, available as MS extensions:

 * __is_destructible()
 * __is_nothrow_destructible()

llvm-svn: 199619

Check all default ctors, not just the first one we see. This brings
__has_nothrow_constructor() in line with the other unary type traits.

A C++ class can have multiple default constructors but clang was only checking
the first one written, presumably due to ambiguity in the GNU specification.

MSVC has the same bug, while g++ has the correct implementation which we now
match.

llvm-svn: 199618

such an assert will fail in invalid code that does so!

llvm-svn: 199617

Move the retrieval of VT after all of the early exits from PerformOrCombine that do not use VT. NFC.

llvm-svn: 199612

[APInt] Fix nearestLogBase2 to return correct answers for very large APInt and APInt with a bitwidth of 1.

I also improved the comments, added some more tests, etc.

llvm-svn: 199610

This was due to arithmetic overflow in the getNumBits() computation. Now we
cast BitWidth to a uint64_t so that does not occur during the computation. After
the computation is complete, the uint64_t is truncated when the function
returns.

I know that this is not something that is likely to happen, but it *IS* a valid
input and we should not blow up.

llvm-svn: 199609

Also make them vector-aware.

llvm-svn: 199608

llvm-svn: 199605

llvm-svn: 199604

llvm-svn: 199602

llvm-svn: 199598

LLVM_*_OUTPUT_INTDIR should be available everywhere. It was my mistake when I introduced INTDIR stuff.

llvm-svn: 199597

[CMake][Standalone] Redefine LLVM_RUNTIME_OUTPUT_INTDIR and LLVM_LIBRARY_OUTPUT_INTDIR to point appropriate target directories.

llvm-svn: 199596

  In LLVM build tree, they points corresponding INTDIR.

  In Clang standalone tree, they points external dir (llvm-config's --bindir and --libdir).

llvm-svn: 199595

llvm-svn: 199594

llvm-svn: 199593

llvm-svn: 199592

[CMake] Prune LLVM_TOOLS_DIR and LLVM_LIBS_DIR in clang/test/CMakeLists.txt. They are overridden in configure_lit_site_cfg().

llvm-svn: 199591

intrinsics.

Reported on the list by Evan with a couple of attempts to fix, but it
took a while to dig down to the root cause. There are two overlapping
bugs here, both centering around the circumstance of discovering
a memcpy operand which is known to be completely outside the bounds of
the alloca.

First, we need to kill the *other* side of the memcpy if it was added to
this alloca. Otherwise we'll factor it into our slicing and try to
rewrite it even though we know for a fact that it is dead. This is made
more tricky because we can visit the sides in either order. So we have
to both kill the other side and skip instructions marked as dead. The
latter really should be goodness in every case, but here is a matter of
correctness.

Second, we need to actually remove the *uses* of the alloca by the
memcpy when queuing it for later deletion. Otherwise it may still be
using the alloca when we go to promote it (if the rewrite re-uses the
existing alloca instruction). Do this by factoring out the
use-clobbering used when for nixing a Phi argument and re-using it
across the operands of a to-be-deleted instruction.

llvm-svn: 199590

  - Forgot to tweak autoconf's Makefile.
  - Apply lit's param to config.clang_tools_dir.

llvm-svn: 199589

llvm-svn: 199587

The newer isl version broke backward compatibility. For some reason, I did not
find this in my own tests.

llvm-svn: 199586

This removes the last isl_int dependency in the default build. There are
still some in OpenScop and Scoplib. For those isl-0.12.2 still needs to be used.

llvm-svn: 199585

llvm-svn: 199583