llvm-svn: 58896

Rename isString -> isExternalSymbol; getString -> getExternalSymbol since these work on externsym machine relocations.

llvm-svn: 58895

llvm-svn: 58894

llvm-svn: 58893

llvm-svn: 58892

 - Size/align are not effected by CVR qualifiers.

Support getCanonicalType: const Type* -> const Type*.

llvm-svn: 58891

theframe size is 0; the prologue and epilogue should be emitted in this case.

llvm-svn: 58890

generate the type of a member.

llvm-svn: 58889

llvm-svn: 58888

promotion.
 - Eliminate uses after free and simplify tests.

Devang: Please check that this is still doing what you intended.
llvm-svn: 58887

llvm-svn: 58886

llvm-svn: 58885

llvm-svn: 58884

llvm-svn: 58883

llvm-svn: 58882

llvm-svn: 58881

Previously:

class C {
  int C;  // Declarator::SetConstructor was called here.
};

llvm-svn: 58880

llvm-svn: 58879

llvm-svn: 58878

llvm-svn: 58877

is noticeably worse than previous PPC-specific code.
Since the latter was also wrong in some cases and
correctness is more important than efficiency, I'm
disabling this test temporarily while I fix it.

llvm-svn: 58876

llvm-svn: 58875

llvm-svn: 58874

llvm-svn: 58873

llvm-svn: 58872

This is Chris' patch from the PR, modified to realize that
SETUGT/SETULT occur legitimately with integers, plus
two fixes in LegalizeDAG to pass a valid result type into
LegalizeSetCC.  The argument of TLI.getSetCCResultType is
ignored on PPC, but I think I'm following usage elsewhere.

llvm-svn: 58871

llvm-svn: 58870

llvm-svn: 58869

llvm-svn: 58868

llvm-svn: 58867

-When parsing declarators, don't depend on "CurScope->isCXXClassScope() == true" for constructors/destructors
-For C++ member declarations, don't depend on "Declarator.getContext() == Declarator::MemberContext"

llvm-svn: 58866

exception, like it does for a std::string exception.

llvm-svn: 58865

llvm-svn: 58864

llvm-svn: 58863

llvm-svn: 58862

the condition for a BRCOND, according to what is
returned by getSetCCResultContents.  Since all
targets return the same thing (ZeroOrOneSetCCResult),
this should be harmless!  The point is that all over
the place the result of SETCC is fed directly into
BRCOND.  On machines for which getSetCCResultContents
returns ZeroOrNegativeOneSetCCResult, this is a
sign-extended boolean.  So it seems dangerous to
also feed BRCOND zero-extended booleans in some
circumstances - for example, when promoting the
condition.

llvm-svn: 58861

functions in C++, e.g.,

  struct X {
    operator bool() const;
  };

Note that these conversions don't actually do anything, since we don't
yet have the ability to use them for implicit or explicit conversions.

llvm-svn: 58860

This is a temporary fix for the -print-emitted-asm option, where
errs() is used as the stream, in the case where other code is
using stderr without using errs()' buffer. Hopefully soon we'll
fix errs() to be non-buffered instead. Patch by Preston Gurd.

llvm-svn: 58859

llvm-svn: 58856

Assert that Parser::MaybeParseOperatorFunctionId is called when token is kw_operator, and replace ExpectAndConsume for the 'operator' token with a ConsumeToken.

llvm-svn: 58855