support it.  I don't know what evaluation method we use for complex
arithmetic, so I don't know whether/if we should warn about use of
CX_LIMITED_RANGE.

This concludes my planned hacking on STDC pragmas, flame away :)

llvm-svn: 69556

llvm-svn: 69554

llvm-svn: 69551

llvm-svn: 69550

llvm-svn: 69547

for a token is set, this makes the diagnostic "expanded from stack" work
for this diagnostic.  Add a testcase for PR3918.

llvm-svn: 69544

llvm-svn: 69540

llvm-svn: 69539

llvm-svn: 69538

llvm-svn: 69537

llvm-svn: 69532

in a function-like macro body.  This has the added bonus of moving some
function-like macro specific code out of the object-like macro codepath.

llvm-svn: 69530

with assembler-with-cpp mode.

llvm-svn: 69520

llvm-svn: 69518

llvm-svn: 69485

as decimal, even if it starts with 0.  Also, since things like 0x1 are
completely illegal, don't even bother using numericliteralparser for them.

llvm-svn: 69454

llvm-svn: 69423

llvm-svn: 69422

llvm-svn: 69416

llvm-svn: 69415

llvm-svn: 69413

llvm-svn: 69412

Highlights: PP::isNextPPTokenLParen() no longer eats the ( 
when present.  We now simplify slightly the logic parsing
macro arguments.  We now handle PR3937 and other related cases
correctly.

llvm-svn: 69411

on the code.

llvm-svn: 69404

llvm-svn: 69403

llvm-svn: 69401

1. We had logic in sema to decide whether or not to emit the error
   based on manually checking whether in a system header file.
2. we were allowing redefinitions of typedefs in class scope in C++
   if in header file.
3. there was no way to force typedef redefinitions to be accepted
   by the C compiler, which annoys me when stripping linemarkers out
   of .i files.

The fix is to split the C++ class typedef redefinition path from the
C path, and change the C path to be a warning that normally maps to
error.  This causes it to properly be ignored in system headers, 
etc. and gives us a way to control it.  Passing 
-Wtypedef-redefinition now turns the error into a warning.

One behavior change is that we now diagnose cases where you redefine
a typedef in your .c file that was defined in a header file.  This
seems like reasonable behavior, and the diagnostic now indicates that
it can be controlled with -Wtypedef-redefinition.

llvm-svn: 69391

macro definitions.

llvm-svn: 68884

llvm-svn: 68788

llvm-svn: 68651

llvm-svn: 68640

 - Add -static-define option driver can use when __STATIC__ should be
   defined (instead of __DYNAMIC__).

 - Don't set __OPTIMIZE_SIZE__ on Os, __OPTIMIZE_SIZE__ is tied to Oz.

 - Set __NO_INLINE__ following GCC 4.2.

 - Set __GNU_GNU_INLINE__ or __GNU_STDC_INLINE__ following GCC 4.2.

 - Set __EXCEPTIONS for Objective-C NonFragile ABI.

 - Set __STRICT_ANSI__ for standard conforming modes.

 - I added a clang style test case in utils for this, but its not
   particularly portable and I don't think it belongs in the test
   suite.

llvm-svn: 68621

 - Add -pic-level clang-cc option to specify the value for the define,
   updated driver to pass this.

 - Added __pic__

 - Added OBJC_ZEROCOST_EXCEPTIONS define while I was here (to match gcc).

llvm-svn: 68584

llvm-svn: 68526

llvm-svn: 68521

GCC ignores macro definitions after \n's or that real code depends
on this.

llvm-svn: 68511

llvm-svn: 68450

 - <rdar://problem/6741594> [pth] don't abuse -x to drive pth
   generation

 - Simpler, and fixes PR3915.

Cleanup test cases for PTH:
 - Update to use -emit-pth

 - Removed PTH test of carbon.c and cocoa.mm; these didn't actually
   verify anything, and since PTH is token based the extra coverage
   (over cocoa.m) isn't particularly helpful.

 - Split PTH tests in cocoa.m to cocoa-pth.m, solely to increase
   available parallelism when running tests.

Ted, could you update the PTH test cases (include-pth.c and
cocoa-pth.m) to have some sort of positive check that the PTH is
getting used? "# of PTH cache hits" or "tokens read from PTH cache"
statistics would work great. :)

llvm-svn: 68189

... arguments.

llvm-svn: 67706

Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602