llvm-svn: 188711

Re-add the inboundsless tests I didn't add originally

llvm-svn: 188710

llvm-svn: 188709

Until gdb supports the new accelerator tables we should add the
pubnames section so that gdb_index can be generated from gold
at link time. On darwin we already emit the accelerator tables
and so don't need to worry about pubnames.

llvm-svn: 188708

Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to
the IRGen ASTConsumer.

llvm-svn: 188707

instead of pointing to a page with two links on it.

llvm-svn: 188706

changing Parameter of Sema::ActOnCompoundStmt from MutableArrayRef to
ArrayRef.
No functionality change intended.

llvm-svn: 188705

llvm-svn: 188704

llvm-svn: 188703

Warning was:
  Argument not separated from preceding token by whitespace.

llvm-svn: 188701

The previous value was set to match some ancient version of Apple's GCC.
The value should be higher than anything used by Apple's GCC, but we don't
intend for this value to be updated in the future. We have other macros to
identify compiler versions. <rdar://problem/14749599>

llvm-svn: 188700

- split WidenVecRes_Binary into WidenVecRes_Binary and WidenVecRes_BinaryCanTrap
  - WidenVecRes_BinaryCanTrap preserves the original behaviour for operations
    that can trap
  - WidenVecRes_Binary simply widens the operation and improves codegen for
    3-element vectors by allowing widening and promotion on x86 (matches the
    behaviour of unary and ternary operation widening)
- use WidenVecRes_Binary for operations on integers.

Reviewed by: nrotem

llvm-svn: 188699

This means that "register read stmm0 --format f" actually works now.

This is a little messy but LLDB assumes 'long double' is portable, when it is not.

llvm-svn: 188698

llvm-svn: 188697

for possible use of CF_IMPLICIT_BRIDGING_ENABLE
pragma.

llvm-svn: 188691

llvm-svn: 188690

futher commits.

llvm-svn: 188689

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

llvm-svn: 188688

Revert "Revert "Revert "DebugInfo: Omit debug info for dynamic classes in TUs that do not have the vtable for that class"""

This reverts commit r188642.

This change is causing LTO builds to cause our 16 GB machines to swap and OOM
all weekend. I am going to work with Dave Blaikie to resolve the issue.

Sorry Dave =(.

llvm-svn: 188687

Originally committed in r188651, improved/fixed to be assert-neutral by
Takumi in r188661.

llvm-svn: 188686

llvm-svn: 188685

Everything except long/ulong is handled by just casting to the next larger type,
doing the math and then shifting/casting the result.

For 64-bit types, we break the high/low parts of each operand apart, and do
a FOIL-based multiplication.

v2:
  Discard the stack-overflow implementation due to copyright concerns.
  - The implementation is still FOIL-based, but discards the previous code.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188684

llvm-svn: 188683

This is still an alpha checker, but we use it in certain tests to make sure
something is not being executed.

This should fix the buildbots.

llvm-svn: 188682

This is PR16890.

llvm-svn: 188681

This keeps the analyzer from making silly assumptions, like thinking
strlen(foo)+1 could wrap around to 0. This fixes PR16558.

Patch by Karthik Bhat!

llvm-svn: 188680

This builtin does not actually evaluate its arguments for side effects,
so we shouldn't include them in the CFG. In the analyzer, rely on the
constant expression evaluator to get the proper semantics, at least for
now. (In the future, we could get ambitious and try to provide path-
sensitive size values.)

In theory, this does pose a problem for liveness analysis: a variable can
be used within the __builtin_object_size argument expression but not show
up as live. However, it is very unlikely that such a value would be used
to compute the object size and not used to access the object in some way.

<rdar://problem/14760817>

llvm-svn: 188679

llvm-svn: 188678

Summary:
ScanReachableSymbols uses a "visited" set to avoid scanning the same object
twice. However, it did not use the optimization for LazyCompoundVal objects,
which resulted in exponential complexity for long chains of temporary objects.
Adding this resulted in a decrease of analysis time from >3h to 3 seconds for
some files.

Reviewers: jordan_rose

CC: cfe-commits

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

llvm-svn: 188677

The Thumb2 add immediate is in fact defined for SP. The manual is misleading as it points to a different section for add immediate with SP, however the encoding is the same as for add immediate with register only with the SP operand hard coded. As such add immediate with SP and add immediate with register can safely be treated as the same instruction.

All the patch does is adjust a register constraint on an instruction alias.

llvm-svn: 188676

llvm-svn: 188675

llvm-svn: 188674

ADD, SUB, MUL integer and FP types. OR, AND, XOR.
Added embeded broadcast form for these instructions.

llvm-svn: 188673

llvm-svn: 188672

For now this matches the equivalent of (neg (abs ...)), which did hit a few
times in projects/test-suite.  We should probably also match cases where
absolute-like selects are used with reversed arguments.

llvm-svn: 188671

llvm-svn: 188670

This first cut is pretty conservative.  The final argument register (R6)
is call-saved, so we would need to make sure that the R6 argument to a
sibling call is the same as the R6 argument to the calling function,
which seems worth keeping as a separate patch.

Saying that integer truncations are free means that we no longer
use the extending instructions LGF and LLGF for spills in int-conv-09.ll
and int-conv-10.ll.  Instead we treat the registers as 64 bits wide and
truncate them to 32-bits where necessary.  I think it's unlikely we'd
use LGF and LLGF for spills in other situations for the same reason,
so I'm removing the tests rather than replacing them.  The associated
code is generic and applies to many more instructions than just
LGF and LLGF, so there is no corresponding code removal.

llvm-svn: 188669

AFAIK, there are no -W options for gcc-as and gcc-ld.
It caused failure to build clang with gcc-4.7 on cygwin.

FIXME: Could we recategorize Options for gcc-as and gcc-ld?
llvm-svn: 188668

llvm-svn: 188667

llvm-svn: 188666