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
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
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
"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
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
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
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
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
Bill Wendling