disambiguate it.
 - No functionality change.

llvm-svn: 69034

llvm-svn: 69033

not in c89 mode).

llvm-svn: 69032

inlined for some reason, then we don't want a strong or even weak
definition.

llvm-svn: 69031

llvm-svn: 69030

llvm-svn: 69029

llvm-svn: 69028

llvm-svn: 69027

llvm-svn: 69026

llvm-svn: 69025

t.c:3:8: warning: extra tokens at end of #endif directive
#endif foo
       ^
       //

Don't do this in strict-C89 mode because bcpl comments aren't 
valid there, and it is too much trouble to analyze whether
C block comments are safe.

llvm-svn: 69024

Warning to properly report that it is an import/include_next instead of
claiming it is a #include.

llvm-svn: 69023

llvm-svn: 69022

llvm-svn: 69021

 - Exposed quite a few Sema issues and a CodeGen crash.

 - See FIXMEs in test case, and in SemaDecl.cpp (PR3983).

I'm skeptical that __private_extern__ should actually be a storage
class value. I think that __private_extern__ basically amounts to
  extern A __attribute__((visibility("hidden")))
and would be better off handled (a) as that, or (b) with an extra bit
in the VarDecl.

llvm-svn: 69020

 - No functionality change.

llvm-svn: 69019

delete it.

llvm-svn: 69018

deleting, not just the basic block.

llvm-svn: 69011

llvm-svn: 69010

llvm-svn: 69009

memory and aren't volatile.  This was interfering with
good scheduling.

llvm-svn: 69008

llvm-svn: 69007

Fix PR3934 part 2. findOnlyInterestingUse() was not setting IsCopy and IsDstPhys which are returned by value and used by callee. This happened to work on the earlier test cases because of a logic error in the caller side.

llvm-svn: 69006

non-inline external definitions (and tentative definitions) that are
found at the top level. The corresponding declarations are stored in a
record in the PCH file, so that they can be provided to the
ASTConsumer (via HandleTopLevelDecl) when the PCH file is read.

llvm-svn: 69005

This was exposed as a result of something else that was recently fixed.

llvm-svn: 69004

expression or statement serialization before we can test them.

llvm-svn: 69002

llvm-svn: 68998

llvm-svn: 68997

promoted to legal types without changing the type of the vector.  This is
following a suggestion from Duncan
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019923.html).
The transformation that used to be done during type legalization is now
postponed to DAG legalization.  This allows the BUILD_VECTORs to be optimized
and potentially handled specially by target-specific code.

It turns out that this is also consistent with an optimization done by the
DAG combiner: a BUILD_VECTOR and INSERT_VECTOR_ELT may be combined by
replacing one of the BUILD_VECTOR operands with the newly inserted element;
but INSERT_VECTOR_ELT allows its scalar operand to be larger than the
element type, with any extra high bits being implicitly truncated.  The
result is a BUILD_VECTOR where one of the operands has a type larger the
the vector element type.

Any code that operates on BUILD_VECTORs may now need to be aware of the
potential type discrepancy between the vector element type and the
BUILD_VECTOR operands.  This patch updates all of the places that I could
find to handle that case.

llvm-svn: 68996

implies an all-zero bit pattern.

llvm-svn: 68994

llvm-svn: 68992

Northover.

llvm-svn: 68991

llvm-svn: 68990

llvm-svn: 68989

handle the definition of __builtin_va_list on x86-64, eliminate the
forced -triple in PCH tests to get better coverage.

llvm-svn: 68988

 - No functionality change.

llvm-svn: 68987

it accordingly. Thanks to Jakob Stoklund Olesen for pointing
out how this might be useful.

llvm-svn: 68986

llvm-svn: 68985

Objective-C types and record types for the moment.

llvm-svn: 68984

codegenerator bug.

llvm-svn: 68983