It passes all tests, produces better results than the old code but uses the
wrong pass, LoopDependenceAnalysis, which is old and unmaintained. "Why is it
still in tree?", you might ask. The answer is obviously: "To confuse developers."

Just swapping in the new dependency pass sends the pass manager into an infinte
loop, I'll try to figure out why tomorrow.

llvm-svn: 166399

Reported by Vincent Lejeune using an out-of-tree target.

llvm-svn: 166398

llvm-svn: 166397

Reported by:  Jack Howarth  <howarth@bromo.med.uc.edu>

llvm-svn: 166396

llvm-svn: 166395

Contributed by:  Sameer Sahasrabuddhe <sameer.sahasrabuddhe@amd.com>

llvm-svn: 166394

llvm-svn: 166393

llvm-svn: 166392

llvm-svn: 166391

Requires a lot less code and complexity on loop-idiom's side and the more
precise analysis can catch more cases, like the one I included as a test case.
This also fixes the edge-case miscompilation from PR9481. I'm not entirely
sure that all cases are handled that the old checks handled but LDA will
certainly become smarter in the future.

llvm-svn: 166390

Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option.

The patch reviewed by Rafael Espindola.

llvm-svn: 166389

We used a SCEV to detect that A[X] is consecutive. We assumed that X was
the induction variable. But X can be any expression that uses the induction
for example: X = i + 2;

llvm-svn: 166388

This is important for nested-loop reductions such as :

In the innermost loop, the induction variable does not start with zero:

for (i = 0 .. n)
 for (j = 0 .. m)
  sum += ...

llvm-svn: 166387

llvm-svn: 166386

found: if an overloaded operator& is present before a template definition,
the expression &T::foo is represented as a CXXOperatorCallExpr, not as a
UnaryOperator, so we didn't notice that it's permitted to reference a non-static
data member of an unrelated class.

While investigating this, I discovered another problem in this area: we are
treating template default arguments as unevaluated contexts during substitution,
resulting in performing incorrect checks for uses of non-static data members in
C++11. That is not fixed by this patch (I'll look into this soon; it's related
to the failure to correctly instantiate constexpr function templates), but was
resulting in this bug not firing in C++11 mode (except with -Wc++98-compat).

Original message:

PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.

llvm-svn: 166385

llvm-svn: 166384

declarations and statements. Emit an error if the FP_CONTRACT is used
later in a compound statement.

llvm-svn: 166383

rather than "$src = $dst").

llvm-svn: 166382

users new to lldb are at the top.

llvm-svn: 166381

Remove 'Customization', 'Documentation', and 'FAQ' pages from the sidebar's "USE AND EXTENSION"
section.  These pages have no content.  If someone ever wants to add content to them, we can
re-add them to the sidebar.

llvm-svn: 166380

PR14134.

llvm-svn: 166379

obvious stuff and most new code being committed conforms to that.  Some old
code does not; this might cause confusion and this is the motivation to
document the correct guidelines.

llvm-svn: 166378

llvm-svn: 166377

llvm-svn: 166376

llvm-svn: 166375

InstCombine: Fix an edge case where constant icmps could sneak into ConstantFoldInstOperands and crash.

Have to refactor the ConstantFolder interface one day to define bugs like this away. Fixes PR14131.

llvm-svn: 166374

literal-operator-id.

llvm-svn: 166373

since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.

llvm-svn: 166372

If the pointer is consecutive then it is safe to read and write. If the pointer is non-loop-consecutive then
it is unsafe to vectorize it because we may hit an ordering issue.

llvm-svn: 166371

Xcode 4.5 passes -Wno-arc-abi to clang, which makes a clang newer than
r163917 warn that it doesn't understand -Wno-arc-abi. I asked if adding
this is ok at
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121015/066433.html
and nobody objected.

Adding this makes life a bit easier for the chromium project. If you think
this is a burden on for clang, shout, and I'll revert this.

llvm-svn: 166370

llvm-svn: 166369

to be printed truncated.

<rdar://problem/12389615>

llvm-svn: 166368

llvm-svn: 166367

llvm-svn: 166366

the header file.
(followup patch to Sean's commit of r166355 earlier today.)

llvm-svn: 166365

llvm-svn: 166364

This is actually required by the C++ standard in
[basic.stc.dynamic.allocation]p3:

  If an allocation function declared with a non-throwing
  exception-specification fails to allocate storage, it shall return a
  null pointer. Any other allocation function that fails to allocate
  storage shall indicate failure only by throwing an exception of a type
  that would match a handler of type std::bad_alloc.

We don't bother checking for the specific exception type, but just go off
the operator new prototype. This should help with a certain class of lazy
initalization false positives.

<rdar://problem/12115221>

llvm-svn: 166363

llvm-svn: 166362

initialized by a reference constant expression.

Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.

llvm-svn: 166361

[ms-inline asm] Rename AsmOpRewrite to just AsmRewrite to be more generic. No functional change intended.

llvm-svn: 166360