filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.

This change errs on the side of value, making op-> return T* and op* return
T&.

(reviewed by Richard Smith)

llvm-svn: 155808

This ought to fix PR11926, a crash when when running Clang built with GCC 4.7

llvm-svn: 155805

g++4.7, which reuses stack space allocated for temporaries. CFGElement::getAs
returns a suitably-cast version of 'this'. Patch by Markus Trippelsdorf!

No test: this code has the same observable behavior as the old code when built
with most compilers, and the tests were already failing when built with a
compiler for which this produced a broken binary.

llvm-svn: 155803

llvm-svn: 155800

llvm-svn: 155799

llvm-svn: 155798

llvm-svn: 155797

llvm-svn: 155795

llvm-svn: 155793

if !ForceInterpreteri). It has no effect (apart from a memory leak...)

llvm-svn: 155792

llvm-svn: 155791

llvm-svn: 155790

type. But a glvalue can be reinterpret_cast to either flavor of reference.

llvm-svn: 155789

victim. Don't crash if we have a delay-parsed exception specification for a
class member which is invalid in a way which precludes building a FunctionDecl.

llvm-svn: 155788

llvm-svn: 155787

llvm-svn: 155786

Mark the default cases of MVT::getVectorElementType and MVT:getVectorNumElements as unreachable to reduce code size.

llvm-svn: 155785

diagnostic, add a test for this paragraph, and tighten up the diagnostic wording
a little.

llvm-svn: 155784

We don't compute spill weights until after coalescing anyway.

llvm-svn: 155766

llvm-svn: 155765

        i32 __builtin_annotation(i32, string);

Applying it to i64 (e.g., long long) generates the following IR.

        trunc i64 {{.*}} to i32
        call i32 @llvm.annotation.i32
        zext i32 {{.*}} to i64

The redundant truncation and extension make the result difficult to use.

This patch makes __builtin_annotation() generic.

        type __builtin_annotation(type, string);

For the i64 example, it simplifies the generated IR to:

        call i64 @llvm.annotation.i64

Patch by Xi Wang!

llvm-svn: 155764

llvm-svn: 155763

t.c:3:9: error: expected expression
  if (x)) {
        ^

.. which isn't even true - a statement or expression is fine.  After:

t.c:3:9: error: extraneous ')' after condition, expected a statement
  if (x)) {
        ^

This is the second part of PR12595

llvm-svn: 155762

This way we can enable the POD-like class optimization for a lot more classes,
saving ~120k of code in clang/i386/Release+Asserts when selfhosting.

llvm-svn: 155761

llvm-svn: 155760

us to improve this diagnostic (telling us to insert another ")":

t.c:2:19: error: expected ';' at end of declaration
  int x = 4+(5-12));
                  ^
                  ;
to:
t.c:2:19: error: extraneous ')' before ';'
  int x = 4+(5-12));
                  ^

...telling us to remove the ")".  This is PR12595.  There are more uses of ExpectAndConsumeSemi
that could be switched over, but I don't hit them on a daily basis :)

llvm-svn: 155759

llvm-svn: 155758

llvm-svn: 155757

Rename isPODType (using the C++98 rules) into isCXX98PODType and make isPODType decide which one to use based on LangOptions.

- -Wc++98-compat depends on the c++98 definition
- Now __is_pod returns the right thing in c++11 and c++98 mode
- All changes to the type traits test are validated against g++ 4.7

llvm-svn: 155756

This is just papering over a major bug in isPODType, real fix coming up soon.

llvm-svn: 155755

Keep the old definition for C++98 so we don't break tr1::is_pod.

llvm-svn: 155754

The code could search past the end of the basic block when there was
already a constant pool entry after the block.

Test case with giant basic block in SingleSource/UnitTests/Vector/constpool.c

llvm-svn: 155753

[analyzer] Remove references to idx::TranslationUnit. Index is dead, cross-TU inlining never panned out.

llvm-svn: 155751

disallowing reads over 1KiB in total size
unless the user explicitly allows them.

llvm-svn: 155750

This time, also fix the caller of AddGlue to properly handle
incomplete chains. AddGlue had failure modes, but shamefully hid them
from its caller. It's luck ran out.

Fixes rdar://11314175: BuildSchedUnits assert.

llvm-svn: 155749

Make sure when parsing the Thumb1 sp+register ADD instruction that
the source and destination operands match. In thumb2, just use the
wide encoding if they don't. In Thumb1, issue a diagnostic.

rdar://11219154

llvm-svn: 155748

Make the operand order of the instruction match that of the asm syntax.

llvm-svn: 155747

llvm-svn: 155746

On x86-32, structure return via sret lets the callee pop the hidden
pointer argument off the stack, which the caller then re-pushes.
However if the calling convention is fastcc, then a register is used
instead, and the caller should not adjust the stack. This is
implemented with a check of IsTailCallConvention
X86TargetLowering::LowerCall but is now checked properly in
X86FastISel::DoSelectCall.

llvm-svn: 155745

Previously, ARMConstantIslandPass would conservatively compute the
address of an aligned basic block as:

  RoundUpToAlignment(Offset + UnknownPadding)

This worked fine for the layout algorithm itself, but it could fool the
verify() function because it accounts for alignment padding twice: Once
when adding the worst case UnknownPadding, and again by rounding up the
fictional block offset. This meant that when optimizeThumb2Instructions
would shrink an instruction, the conservative distance estimate could
grow. That shouldn't be possible since the woorst case alignment padding
wss already included.

This patch drops the use of RoundUpToAlignment, and depends only on
worst case padding to compute conservative block offsets. This has the
weird effect that the computed offset for an aligned block may not be
aligned.

The important difference is that shrinking an instruction can never
cause the estimated distance between two instructions to grow. The
estimated distance is always larger than the real distance that only the
assembler knows.

<rdar://problem/11339352>

llvm-svn: 155744