llvm-svn: 72311

PPC double double.

(No testcase because no normal target uses the format at the moment.)

llvm-svn: 72310

llvm-svn: 72308

llvm-svn: 72304

expressions. We are now missing template instantiation logic for only
three classes of expressions:
  - Blocks-related expressions (BlockExpr, BlockDeclRefExpr)
  - C++ default argument expressions
  - Objective-C expressions

Additionally, our handling of DeclRefExpr is still quite poor, since
it cannot handle references to many kinds of declarations.

As part of this change, converted the TemplateExprInstantiator to use
iteration through all of the expressions via clang/AST/StmtNodes.def,
ensuring that we don't forget to add template instantiation logic for
any new expression node kinds.

llvm-svn: 72303

llvm-svn: 72301

Fix bug in FoldFCmp_IntToFP_Cst. If inttofp is a uintofp, use unsigned instead of signed integer constant.

llvm-svn: 72300

llvm-svn: 72299

llvm-svn: 72298

llvm-svn: 72293

llvm::SmallVector, using data() instead of &[0]. The PCH testsuite now
runs cleanly (again).

llvm-svn: 72292

ProtoRefs.data() instead of &ProtoRefs[0] to access the raw buffer.

llvm-svn: 72291

is true. Because of recent changes to llvm::SmallVector, using these iterators
when Exprs was empty would cause an assertion failure.

This fixes: PR 4245.

llvm-svn: 72286

must be dominated by the normal label.

llvm-svn: 72285

llvm-svn: 72284

non-argument names, pass the tokens through.

llvm-svn: 72283

call other member functions of class templates, including after
template instantiation. No functionality change.

llvm-svn: 72282

expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.

Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.

llvm-svn: 72281

llvm-svn: 72280

  (T(*)(int[x+y]));

is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id,
so unnecessary Action calls are made for an unused (and possibly leaked) "x+y".

Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached,
the context that follows is determined (possibly by parsing a cast-expression),
and then we re-introduce the cached tokens into the token stream and parse them appropriately.

llvm-svn: 72279

The TokenLexer may encounter annotations if the parser enters them using Preprocessor::EnterTokenStream.
So check for annotation before using the Token's IdentifierInfo.

llvm-svn: 72278

files for PIC16 target.

llvm-svn: 72277

code in preparation for code generation.  The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads.  Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about.  However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds.  Consider the following case:
In function @f:
...
  invoke @g to label %normal unwind label %unwinds
...
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

In function @g:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  "rethrow exception"

Now inline @g into @f.  Currently this is turned into:
In function @f:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label.  Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.

(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
  invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
  unwind

This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering).  But that means
you are using eh.exception again far from a landing pad.

(3) Bugpoint simplifications.  When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.

Note that it is currently rare for this pass to actually do
anything.  And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc!  But it does fire
a few times in the testsuite.  As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block.  This other
block contains an eh.exception call.  So probably by tweaking
LoopStrengthReduce a bit this can be avoided.

llvm-svn: 72276

compiled with -fobjc-sender-dependent-dispatch.  This is used in AOP, COP, implementing object 
planes, and a few other things.
Patch by David Chisnall.

llvm-svn: 72275

llvm-svn: 72274

improve codegen in some cases.

llvm-svn: 72273

 - We could just warn about -fno-unit-at-a-time, but in practice people using it
   probably aren't going to get what they want out of clang.

Also, use "clang" specified error for unsupported things instead of driver
unsupported error.

llvm-svn: 72272

for ARM.  This fixes rdar://6908807.

llvm-svn: 72269

 - PR4242.

llvm-svn: 72268

and objects of this class are derived from 'NSProxy'.
Under such conditions, which means that every method possible is 
implemented in the class, we should not issue "Method definition not found" 
warnings.

llvm-svn: 72267

assuming that the use of the value is in a block dominated by the
"normal" destination. LangRef.html and other documentation sources
don't explicitly guarantee this, but it seems to be assumed in
other places in LLVM at least.

This fixes an assertion failure on the included testcase, which
is derived from the Ada testsuite.

FixUsesBeforeDefs is a temporary measure which I'm looking to
replace with a more capable solution.

llvm-svn: 72266

There are no unnecessary action calls period (courtesy of the annotation scheme) and too many 'this means'..

llvm-svn: 72263

Emit debug information for globals (which include automatic variables as well because on PIC16 they are emitted as globals by the frontend).

llvm-svn: 72262

Targets like PIC16 generate Static decls for automatic variables, emit the appropriate debug descriptor as well in that case.

llvm-svn: 72261

Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and
a paren expression without considering the context past the parentheses.

Behold:
  (T())x;  - type-id
  (T())*x; - type-id
  (T())/x; - expression
  (T());   - expression

llvm-svn: 72260

Factor the compound literal parsing out from ParseParenExpression and into a new ParseCompoundLiteralExpression.
No functionality change.

llvm-svn: 72259

Now it parses the cast expression unless 'stopIfCastExpr' is true.

llvm-svn: 72258

Embed its functionality into it's only user, ParseCXXCasts.
CXXCasts now get the "actual" expression directly, they no longer always receive a ParenExpr. This is better since the
parentheses are always part of the C++ casts syntax.

llvm-svn: 72257

'ParseExprAfterTypeofSizeofAlignof' method.

llvm-svn: 72256

-Makes typeof consistent with sizeof/alignof
-Fixes a bug when '>' is in a typeof expression, inside a template type param:
  A<typeof(x>1)> a;

llvm-svn: 72255