llvm-svn: 70330

and apparently not part of -Wall

llvm-svn: 70329

This should fix PR3379 and PR4064.
Patch inspired by Edwin Török!

llvm-svn: 70328

llvm-svn: 70327

now gotten back about 180k of the 500k we lost.

llvm-svn: 70326

which eliminates the storage for IdentifierInfo in the "uninteresting
identifier" cases. Sadly, this only brought back 7k of the 500k we
lost :(

llvm-svn: 70325

llvm-svn: 70323

llvm-svn: 70322

line when using a PCH that were not provided when building the PCH
file. If those names were used as identifiers somewhere in the PCH
file, reject the PCH file.

llvm-svn: 70321

for identifiers to separate "interesting" from "uninteresting"
identifiers. However, to cope with compiler invocations where the
predefines buffers mismatch, we need to be able to search the complete
identifier table. Cocoa.h.pch is now about 500k larger that it used to
be :(

llvm-svn: 70320

llvm-svn: 70319

regardless of extension.
 - Otherwise we can't expect that just plugging in -ccc-pch-is-pch
   will work.

llvm-svn: 70318

llvm-svn: 70317

PCH file and the predefines buffer used when including the PCH
file. We (explicitly) detect conflicting macro definitions (rejecting
the PCH file) and about missing macro definitions (they'll be
automatically pulled from the PCH file anyway).

We're missing some checking to make sure that new macro definitions
won't have any impact on the PCH file itself (e.g., #define'ing an
identifier that the PCH file used).

llvm-svn: 70316

llvm-svn: 70315

support in clang.

llvm-svn: 70314

llvm-svn: 70313

llvm-svn: 70310

llvm-svn: 70309

"function designator".

(This causes a minor glitch in the 
diagnostics for C++ member pointers, but we weren't printing the 
right diagnostic there anyway.)

llvm-svn: 70307

llvm-svn: 70305

frontend is far enough along that most discrepancies between Clang and GCC are
(at least for C and Objective-C) are intentional. We also now have codegen to
test the frontend.

llvm-svn: 70303

llvm-svn: 70302

llvm-svn: 70300

Fix choice of version of Windows callback to use to consider not only the Visual Studio version, but also the Windows SDK version.

Patch by Tareq Siraj.

llvm-svn: 70299

If the physical register does not belong to the virtual register's regclass,
don't coalesce. The physical register could be an invalid operand for an
instruction using the vreg.

The regclass matching is done after determining the actual subregisters being copied.

llvm-svn: 70298

llvm-svn: 70297

Also make the method non-asserting. It will return NULL when given an invalid subreg index.

The method is needed by an upcoming patch.

llvm-svn: 70296

llvm-svn: 70295

llvm-svn: 70294

llvm-svn: 70293

mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.

As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.

llvm-svn: 70292

llvm-svn: 70291

llvm-svn: 70290

llvm-svn: 70286

add "Looping back to the head of the loop" diagnostic for loops.

llvm-svn: 70285

llvm-svn: 70284

llvm-svn: 70283

llvm-svn: 70282

scheme to be more useful.

The new scheme introduces a set of categories that should be more 
readable, and also reflects what we want to consider as an extension 
more accurately.  Specifically, it makes the "what is a keyword" 
determination accurately reflect whether the keyword is a GNU or 
Microsoft extension.

I also introduced separate flags for keyword aliases; this is useful 
because the classification of the aliases is mostly unrelated to the 
classification of the original keyword.

This patch treats anything that's in the implementation 
namespace (prefixed with "__", or "_X" where "X" is any upper-case 
letter) as a keyword without marking it as an extension.  This is 
consistent with the standards in that an implementation is allowed to define 
arbitrary extensions in the implementation namespace without violating 
the standard. This gets rid of all the nasty "extension used" warnings 
for stuff like __attribute__ in -pedantic mode.  We still warn for 
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we 
could add additional information to the keyword table.

This also removes processing for the unused "Boolean" language option; 
such an extension isn't supported on any other C implementation, so I 
don't see any point to adding it.

The changes to test/CodeGen/inline.c are required because previously, we 
weren't actually disabling the "inline" keyword in -std=c89 mode.

I'll remove Boolean and NoExtensions from LangOptions in a follow-up 
commit.

llvm-svn: 70281