. move compiler-rt to a separate directory so the -L argument only includes compiler-rt (thanks joerg)
. build all clang subdirs
. switches the Minix platform to ELF
. normalizes toolchain invocation
Patch by Ben Gras.
llvm-svn: 146206
it to GNU assembler. In addition, change function getMipsArchFromCPU() so that
it can be reused in ConstructJob().
Patch by Simon Atanasyan.
llvm-svn: 145509
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
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.
Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.
The -ftemplate-depth=N part of this fixes PR9890.
llvm-svn: 145045
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
This is a partial revert of r143846. While cleaning up after a crash is
probably a good idea, we were also deleting .d files if the compilation failed
due to invalid input, which is not the desired behavior. The test is XFAIL'd
until the cleanup code can be reworked to do the right thing.
llvm-svn: 144590
version of Ubuntu. It has a very broken multiarch configuration, and so
we need special logic to handle it correctly. Fixing and testing this
uncovered a few other trivial issues with the logic that are fixed as
well.
I added tests to cover this as it is hard to notice if you install
recent versions of the OS.
llvm-svn: 144165
useful when using Clang as a system-compiler, but its harmless. When
using Clang as a cross-compiler, this can be very handy as quite a few
toolchains ship their libc headers here rather than under
'/usr/include'.
For reference, this is the beginning of my work to also make the Clang
driver more suitable as a cross-compiler.
llvm-svn: 144089
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
llvm-svn: 143917
toolchain. The logic is mostly generic already, and where possible
should be made more generic. Also, it has no impact other than to expose
a set of methods which each toolchain can then query to setup their
desired configuration. These should be available to toolchains beyond
just Linux.
llvm-svn: 143899
detection system that is providing the library paths and crt object
files.
This, modulo any bugs that need to be shaken out, resolves numerous bugs
with how we handle header paths. Here are a few that I know of:
- We no longer need to enumerate all GCC versions searched.
- OpenSUSE searched GCC versions in the wrong order.
- There were typos when selecting various patterns, etc.
- We aren't stating quite some many directories now.
- SysRoot didn't always work in a reasonable way.
I'm working on tests for this, but the tests are making me and Lit sad.
The real testing for this type of driver change is to try it out on
various distributions. I'll hit the common ones right away, and start
more thorough testing tomorrow after some sleep.
llvm-svn: 143874
the detected GCC installation. This allows us to expose another aspect
of what we detected: the GCC version. This will be used shortly.
llvm-svn: 143871
directories. This way we stop at the first multiarch directory found on
the system. This achieves the real intended result of pruning
non-existent directories.
llvm-svn: 143866
a better way. The more I think about it the more worried I am that this
hammer is simply too large. We should only be reaching out to the
filesystem when doing interesting "detection" things, not gratuitously.
Original commit message:
Start pruning down the set of flags passed to CC1 for header search.
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
llvm-svn: 143865