| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
continue until cleanliness improves.
llvm-svn: 148951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
- Neither of these have anything to do with the host, or its info.
- The HostInfo class was setup as a full blown class *hierarchy* with
a separate implementation for each "host" OS. This required
dispatching just to create the objects in the first place.
- The hierarchy claimed to represent the host, when in fact it was
based on the target OS.
- Each leaf in the hierarchy was responsible for implementing the flag
processing and caching, resulting in a *lot* of copy-paste code and
quite a few bugs.
- The caching was consistently done based on architecture alone, even
though *any* aspect of the targeted triple might change the behavior
of the configured toolchain.
- Flag processing was already being done in the Driver proper,
separating the flag handling even more than it already is.
Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.
The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.
This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!
llvm-svn: 148950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
helped stage the refactoring of things a bit, but really isn't the right
place for it. The driver may be responsible for compilations with many
different targets. In those cases, having a target triple in the driver
is actively misleading because for many of those compilations that is
not actually the triple being targeted.
This moves the last remaining users of the Driver's target triple to
instead use the ToolChain's target triple. The toolchain has a single,
concrete target it operates over, making this a more stable and natural
home for it.
llvm-svn: 148942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
It's bugs all the way down today it seems...
llvm-svn: 148839
|
|
|
|
|
|
|
|
|
|
|
|
| |
inside the innards of the Driver implementation, and only ever
implemented to return 'true' for the Darwin OSes. Instead use a more
direct query on the target triple and a comment to document why the
target matters here.
If anyone is worried about this predicate getting wider use or improper
use, I can make it a local or private predicate in the driver.
llvm-svn: 148797
|
|
|
|
|
|
|
|
|
| |
The Driver has a fixed target, whether we like it or not, the
DefaultTargetTriple is not a default. This at least makes things more
honest. I'll eventually get rid of most (if not all) of
DefaultTargetTriple with this proper triple object. Bit of a WIP.
llvm-svn: 148796
|
|
|
|
| |
llvm-svn: 148582
|
|
|
|
| |
llvm-svn: 148162
|
|
|
|
| |
llvm-svn: 148141
|
|
|
|
| |
llvm-svn: 148138
|
|
|
|
| |
llvm-svn: 148137
|
|
|
|
|
|
|
|
|
|
|
|
| |
the driver.
clang/lib/Driver/Driver.cpp: Don't pass through negative exit status, or parent would be confused.
llvm::sys::Program::Wait(): Suppose 0x8000XXXX and 0xC000XXXX as abnormal exit code and pass it as negative value.
Win32 Exception Handler: Exit with ExceptionCode on an unhandle exception.
llvm-svn: 145389
|
|
|
|
|
|
|
|
| |
output files that are valid regardless of whether the compilation
succeeded or failed (but not if we crash). Add depfiles to the
failure result file list.
llvm-svn: 145018
|
|
|
|
|
|
|
| |
- With the current implementation of sys::Program this always printed "2".
- The command execution code will output the right number anyway (including the signal name).
llvm-svn: 144993
|
|
|
|
|
|
|
| |
obviously only used during compilation.
rdar://10386708
llvm-svn: 143813
|
|
|
|
|
|
|
| |
arguments that caused clang to crash.
rdar://8314451
llvm-svn: 143573
|
|
|
|
|
|
|
| |
The integrated assembler seems to be working pretty well for -static code
now, so remove the hacks to disable it.
llvm-svn: 143304
|
|
|
|
|
|
|
|
|
| |
There are now separate Triple::MacOSX and Triple::IOS values for the OS
so comparing against Triple::Darwin will fail to match those. Note that
I changed the expected output for the Driver/rewrite-objc.m test, which had
previously not been passing Darwin-specific options with the macosx triple.
llvm-svn: 141944
|
|
|
|
|
|
|
| |
This is old leftover cruft from the days when C++ was not yet ready
for prime time.
llvm-svn: 141063
|
|
|
|
| |
llvm-svn: 140889
|
|
|
|
| |
llvm-svn: 140682
|
|
|
|
|
|
| |
for a lot of cross-compile toolchains. Also add some slightly better support for -B.
llvm-svn: 140645
|
|
|
|
| |
llvm-svn: 140478
|
|
|
|
| |
llvm-svn: 140434
|
|
|
|
|
|
|
|
| |
doesn't.
Also, on windows, chdir seems to live in <direct.h>.
llvm-svn: 140414
|
|
|
|
|
|
|
|
|
|
| |
to operate "as if" in a certain working directory.
- For now, we just implement this by changing the actual working directory, but
eventually we would want to handle this transparently. This is useful to
avoid an extra exec() pair in some situations, and will be something we would
want to support for more flexibility in using the Clang libraries.
llvm-svn: 140409
|
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140369
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
|
| |
specified path(s) to the list of prefix directories.
rdar://10097714
llvm-svn: 139677
|
|
|
|
|
|
| |
preprocessor output) with multiple -arch options.
llvm-svn: 139207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as well as the search path printed by -print-search-dirs.
The main purpose of this change is to cause -print-file-name=include
to print the path to the include directory under Clang's resource
directory, instead of the system compiler's include directory, whose
header files Clang may not be able to parse. Some build scripts will
do something like:
$(CC) -nostdinc -I`$(CC) -print-file-name=include`
to exclude all header paths except the compiler's.
llvm-svn: 139127
|
|
|
|
| |
llvm-svn: 138670
|
|
|
|
|
|
| |
for catching this.
llvm-svn: 138666
|
|
|
|
|
|
|
|
| |
cases we want the prefix to be the original file name less the suffix. For an
input such as test.c to named temporary would be something like test-3O4Clq.o
Part of <rdar://problem/8314451>
llvm-svn: 138662
|
|
|
|
|
|
|
| |
-fapple-kext.
Fixes <rdar://problem/10013310>. Reverts <rdar://problem/7809940>.
llvm-svn: 138564
|
|
|
|
|
|
|
|
|
|
|
| |
output on darwin so is hard coded there.
As a note this will need a little bit of refactoring in the class
hierarchy to separate it out for different verifiers based on input type.
Fixes rdar://8256258.
llvm-svn: 138343
|
|
|
|
|
|
|
| |
from stdin. This allows Eli and the like to continue with their debugging
trickery without loss of limb (or car) on my part. :)
llvm-svn: 137906
|
|
|
|
| |
llvm-svn: 137896
|
|
|
|
| |
llvm-svn: 137893
|
|
|
|
|
|
| |
inputs that aren't preprocessable.
llvm-svn: 137532
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 137524
|
|
|
|
|
|
|
| |
enough to offer to investigate the underlying issue. Thanks to Doug for his
assistance as well.
llvm-svn: 136719
|
|
|
|
|
|
| |
Someone with more cmake experience want to throw me a bone? :)
llvm-svn: 136709
|
|
|
|
|
|
|
|
|
| |
information including the fully preprocessed source file(s) and command line
arguments. The developer is asked to attach this diagnostic information to a
bug report.
rdar://9575623
llvm-svn: 136702
|
|
|
|
|
|
|
|
|
|
|
| |
use in KEXTs. However, users/Xcode still need to tweak the linker flags to do
the right thing, and end up using -Xlinker, for example. Instead, have the
driver "do the right thing" when linking when -fapple-kext is present on the
command line, and we should have Xcode use -fapple-kext instead of setting other
flags like -Xlinker -kext or -nodefaultlibs.
rdar://7809940
llvm-svn: 136294
|
|
|
|
|
|
| |
Mulder!
llvm-svn: 135855
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
| |
llvm-svn: 135621
|
|
|
|
|
|
|
|
|
| |
information
including the fully preprocessed source file(s) and command line arguments. The
developer is asked to attach this diagnostic information to a bug report.
llvm-svn: 135614
|