(with -E), we turn the PCH include into an implicit include of the
file from which the PCH file was generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71534 91177308-0d34-0410-b5e6-96231b3b80d8
- Apologies for the extremely gross code duplication, I want to get
this working and then decide how to get this information out of the
back end.
- This replaces -m[no-]sse4[12] by -m[no-]sse4, it appears gcc
doesn't distinguish them?
- -msse, etc. now properly disable/enable related features.
- Don't always define __SSE3__...
- The main missing functionality bit here is that we don't initialize
the features based on the CPU for all -march options.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71117 91177308-0d34-0410-b5e6-96231b3b80d8
- This is a WIP...
- This adds -march= handling to the driver, and fixes the defaulting
of -mcpu on Darwin (which was using the wrong test).
Instead of handling -m{sse, ...} in the driver, pass them to clang-cc as
-target-feature [+-]name
In clang-cc, communicate with the (clang) target to discover the legal
features of a target, and the features which are enabled based on
-mcpu. This is currently hardcoded just enough to not be a feature
regression, we need to get this information from the backend's
TableGen information somehow.
This is used to construct the full list of features which are being
used, which is in turn used to initialize the predefines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71061 91177308-0d34-0410-b5e6-96231b3b80d8
- This implements gcc style Objective-C interface layout (I
think). Currently it is always off, there is no functionality
change unless this is passed.
For the curious, the deal is that gcc lays out the fields of a
subclass as if they were part of the superclass. That is, the
subclass fields immediately follow the super class fields instead
of being padded to the alignment of the superclass structure.
- Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
llvm-gcc uses it in 32-bit only, for reasons which aren't clear
yet. We probably want to switch to matching gcc, once this makes it
through testing... my hope is that we can also fix llvm-gcc in
order to maintain compatibility between the compilers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70827 91177308-0d34-0410-b5e6-96231b3b80d8
- This is somewhat cleaner and also fixes PR4063 for real, I had the
order wrong so we were just creating an empty dependency file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70687 91177308-0d34-0410-b5e6-96231b3b80d8
word-wrapping by default in Emacs; yay!). Thanks, Daniel.
Use LLVM's System layer rather than calling isatty() directly.
Fix a thinko in printing the indentation string that was causing some
weird output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70654 91177308-0d34-0410-b5e6-96231b3b80d8
Also, put a line of whitespace between the diagnostic and the source
code/caret line when the start of the actual source code text lines up
(or nearly lines up) with the most recent line of the diagnostic. For
example, here it's okay for the last line of the diagnostic to be
(vertically) next to the source line, because there is horizontal
whitespace to separate them:
decl-expr-ambiguity.cpp:12:16: error: function-style cast to a builtin
type can only take one argument
typeof(int)(a,5)<<a;
However, here is a case where we need the vertical separation (since
there is no horizontal separation):
message-length.c:10:46: warning: incompatible pointer types initializing 'void
(int, float, char, float)', expected 'int (*)(int, float, short,
float)'
int (*fp1)(int, float, short, float) = f;
This is part one of <rdar://problem/6711348>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70578 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70316 91177308-0d34-0410-b5e6-96231b3b80d8
processing to after PCH is loaded. -Eonly and -parse-noop are close to working
with PCH now but are not quite there yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70257 91177308-0d34-0410-b5e6-96231b3b80d8
essentially the same thing we do with pretokenized headers. stat()
caching improves performance of the Cocoa-prefixed "Hello, World" by
45%.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70223 91177308-0d34-0410-b5e6-96231b3b80d8
declaration rather than printing through the HandleTopLevelDecl
action. Using this, one can deserialize an entire PCH file and dump
it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70108 91177308-0d34-0410-b5e6-96231b3b80d8
DeclContext rather than in a separate list. This makes PCH
(de-)serialization trivial, so that ivars can be loaded lazily.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69857 91177308-0d34-0410-b5e6-96231b3b80d8
methods, class methods, and property implementations) and instead
place all of these entities into the DeclContext.
This eliminates more linear walks when looking for class or instance
methods and should make PCH (de-)serialization of ObjCDecls trivial
(and lazy).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69849 91177308-0d34-0410-b5e6-96231b3b80d8
PCH files now contain complete information about builtins, including
any declarations that have been synthesized as part of building the
PCH file. When using a PCH file, we do not initialize builtins at all;
when needed, they'll be found in the PCH file.
This optimization translations into a 9% speedup for "Hello, World!"
with Carbon.h as a prefix header and roughly a 5% speedup for 403.gcc
with its prefix header. We're also reading less of the PCH file for
"Hello, World!":
*** PCH Statistics:
286/20693 types read (1.382110%)
1630/59230 declarations read (2.751984%)
764/44914 identifiers read (1.701029%)
1/32954 statements read (0.003035%)
5/6187 macros read (0.080815%)
down from
*** PCH Statistics:
411/20693 types read (1.986179%)
2553/59230 declarations read (4.310316%)
1093/44646 identifiers read (2.448148%)
1/32954 statements read (0.003035%)
21/6187 macros read (0.339421%)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69815 91177308-0d34-0410-b5e6-96231b3b80d8
tentative definitions off to the ASTConsumer at the end of the
translation unit.
Eliminate CodeGen's internal tracking of tentative definitions, and
instead hook into ASTConsumer::CompleteTentativeDefinition. Also,
tweak the definition-deferal logic for C++, where there are no
tentative definitions.
Fixes <rdar://problem/6808352>, and will make it much easier for
precompiled headers to cope with tentative definitions in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69681 91177308-0d34-0410-b5e6-96231b3b80d8
Once selector support is in place, we should be able to take this for a spin (and add test cases).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69674 91177308-0d34-0410-b5e6-96231b3b80d8
also gets access to the Sema object performing semantic analysis. This
will be used by the PCH writer to serialize Sema state.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69595 91177308-0d34-0410-b5e6-96231b3b80d8