scrounging through SCEVUnknown contents and SCEVNAryExpr operands;
instead just do a simple deterministic comparison of the precomputed
hash data.

Also, since this is more precise, it eliminates the need for the slow
N^2 duplicate detection code.

llvm-svn: 105540

encapsulation to force the users of these classes to know about the internal
data structure of the Operands structure. It also can lead to errors, like in
the MSIL writer.

llvm-svn: 105539

llvm-svn: 105537

llvm-svn: 105534

created temporary. Use own initialized entity for copied in block
variables.

llvm-svn: 105533

TODO: add remainder of builtins to CGBuiltin, add code to SemaChecking to validate constants.

llvm-svn: 105532

llvm-svn: 105531

constructor into an extension warning into the error that C++98 requires.

llvm-svn: 105529

Partial specialization was not checking the callsite to make sure it was using the same constants as the specialization, leading to calls to the wrong specialization.  Patch by Takumi Nakamura\!

llvm-svn: 105528

llvm-svn: 105527

or block-pointer type by removing the qualifiers parameter.  Introduce a
method to perform semantic checking when adding qualifiers to a type.

llvm-svn: 105526

llvm-svn: 105525

In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type

llvm-svn: 105524

yet, only assembly encoding support.

llvm-svn: 105521

llvm-svn: 105519

a member template, and you try to call the member template with an explicit
template argument.  See PR7247 

For example, this downgrades the error to a warning in:

template<typename T> struct set{};
struct Value {
    template<typename T>
    void set(T value) {
    }
};
void foo() {
    Value v;
    v.set<double>(3.2);  // Warning here.
}

llvm-svn: 105518

should be calling it.

llvm-svn: 105517

llvm-gcc enabled this couple of weeks ago.

llvm-svn: 105516

unless using -arm-tail-calls.

llvm-svn: 105515

llvm-svn: 105514

llvm-svn: 105513

llvm-svn: 105511

there could be multiple subexpressions within a single expansion which
require insert point adjustment. This fixes PR7306.

llvm-svn: 105510

I don't think this ever resulted in problems on x86, but it
would on ARM.

llvm-svn: 105509

llvm-svn: 105508

Radar 8055687.

llvm-svn: 105505

This is never null, but the associated type might be.

llvm-svn: 105503

llvm-svn: 105502

register pressure.

llvm-svn: 105501

llvm-svn: 105500

llvm-svn: 105498

llvm-svn: 105496

llvm-svn: 105495

When deciding whether reinterpret_cast casts away constness we need to look at array qualifiers. Fixes rdar://problem/8018292.

llvm-svn: 105494

llvm-svn: 105492

I just implemented.

llvm-svn: 105491

Copy location info for current function argument from dbg.declare if respective store instruction does not have any location info.

llvm-svn: 105490

llvm-svn: 105489

llvm-svn: 105488

class object in blocks and carry it to IRGen.

llvm-svn: 105487