to return an owning pointer.

llvm-svn: 66934

add a fixme note on how to remove code duplication.

llvm-svn: 66932

llvm-svn: 66931

llvm-svn: 66930

llvm-svn: 66927

llvm-svn: 66926

llvm-svn: 66924

instantiation for binary operators. This change moves most of the
operator-overloading code from the parser action ActOnBinOp to a new,
parser-independent semantic checking routine CreateOverloadedBinOp. 

Of particular importance is the fact that CreateOverloadedBinOp does
*not* perform any name lookup based on the current parsing context (it
doesn't take a Scope*), since it has to be usable during template
instantiation, when there is no scope information. Rather, it takes a
pre-computed set of functions that are visible from the context or via
argument-dependent lookup, and adds to that set any member operators
and built-in operator candidates. The set of functions is computed in
the parser action ActOnBinOp based on the current context (both
operator name lookup and argument-dependent lookup). Within a
template, the set computed by ActOnBinOp is saved within the
type-dependent AST node and is augmented with the results of
argument-dependent name lookup at instantiation time (see
TemplateExprInstantiator::VisitCXXOperatorCallExpr).

Sadly, we can't fully test this yet. I'll follow up with template
instantiation for sizeof so that the real fun can begin.

llvm-svn: 66923

llvm-svn: 66922

changes.

For InvokeInst now all arguments begin at op_begin().
The Callee, Cont and Fail are now faster to get by
access relative to op_end().

This patch introduces some temporary uglyness in CallSite.
Next I'll bring CallInst up to a similar scheme and then
the uglyness will magically vanish.

This patch also exposes all the reliance of the libraries
on InvokeInst's operand ordering. I am thinking of taking
care of that too.

llvm-svn: 66920

llvm-svn: 66918

llvm-svn: 66915

 - Enough stuff works now we can test argument parsing & pipelining.

llvm-svn: 66913

llvm-svn: 66912

 - language recognition was recognizing prefixes incorrectly.
 - -x none wasn't working.
 - test for "can lipo" was backwords.
 - missed a '"' in -ccc-print-phases

llvm-svn: 66911

really horrible extensions that are disabled by default but that can
be accepted by -fheinous-gnu-extensions (but which always emit a 
warning when enabled).

As our first instance of this, implement PR3788/PR3794, which allows
non-lvalues in inline asms in contexts where lvalues are required. bleh.

llvm-svn: 66910

llvm-svn: 66909

llvm-svn: 66908

-ccc-print-options.

llvm-svn: 66907

llvm-svn: 66906

llvm-svn: 66905

Also changed BlockDecl API to be more consistent (wrt FunctionDecl).

llvm-svn: 66904

codegen to the same thing as integer truncates to i8 (the top bits are 
just undefined).  This implements rdar://6667338

llvm-svn: 66902

conditions. Currently the analyzer does not reason well about
promotions/truncations of symbolic values, so at branch conditions when we see:

  if (condition)
  
and condition is something like a 'short' or 'char', essentially ignore the
promotion to 'int' so that we track constraints on the original symbolic value.
We only ignore the casts if the underlying type has the same or fewer bits as
the converted type.

This fixes:

<rdar://problem/6619921>

llvm-svn: 66899

errors when thrown.  This gets us nice errors like this from tblgen:

CMOVL32rr: 	(set GR32:i32:$dst, (X86cmov GR32:$src1, GR32:$src2))
/Users/sabre/llvm/Debug/bin/tblgen: error:
Included from X86.td:116:
Parsing X86InstrInfo.td:922: In CMOVL32rr: X86cmov node requires exactly 4 operands!
def CMOVL32rr : I<0x4C, MRMSrcReg,       // if <s, GR32 = GR32
^

instead of just:

CMOVL32rr: 	(set GR32:i32:$dst, (X86cmov GR32:$src1, GR32:$src2))
/Users/sabre/llvm/Debug/bin/tblgen: In CMOVL32rr: X86cmov node requires exactly 4 operands!

This is all I plan to do with this, but it should be easy enough to improve if anyone 
cares (e.g. keeping more loc info in "dag" expr records in tblgen.

llvm-svn: 66898

llvm-svn: 66897

This solution is much simpler (and doesn't add any per-scope overhead, which concerned Chris). 

The only downside is the LabelMap is now declared in two places (Sema and BlockSemaInfo). My original fix tried to unify the LabelMap in "Scope" (which would support nested functions in general). In any event, this fixes the bug given the current language definition. If/when we decide to support GCC style nested functions, this will need to be tweaked.

llvm-svn: 66896

llvm-svn: 66895

llvm-svn: 66894

Remove ActiveScope (revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).

Will replace with something better today...

llvm-svn: 66893

is 64-bit. I used his suggestion of doing a direct bitwidth/signedness
conversion of the 'offset' instead of just changing the sign. For more
information, see:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-March/004587.html

llvm-svn: 66892

llvm-svn: 66891

llvm-svn: 66890

llvm-svn: 66889

llvm-svn: 66888

llvm-svn: 66887

llvm-svn: 66886

to perform). Still doesn't do anything interesting.
 - This code came out much cleaner than in ccc with the reworked
   phases & mapping of types to lists of compilation steps (phases) to
   perform.

llvm-svn: 66885

llvm-svn: 66884

llvm-svn: 66883