when specifying --coverage (or related) flags.
The system for doing this was based on the old LLVM-hosted profile_rt
library, and hadn't been updated for Linux to use the new compiler-rt
library. Also, it couldn't possibly work on multiarch or biarch systems
in many cases. The whole thing now works much the same as the sanitizer
libraries that are built and used out of the compiler-rt repo.
Note that other target OSes haven't been updated because I don't know if
they're doing anything special with the installation path of profile_rt.
I suspect however that *all* of these are wrong and would encourage
maintainers of each target to take a hard look at how compiler-rt
runtime libraries are linked on their platforms.
llvm-svn: 184666
verifies that we run the assembler and linker in the correct mode, and
that we can successfully use a bi-arch variant of a GCC installation in
a generic cross compilation invocation of Clang.
llvm-svn: 184662
directory for programs used by the driver is actually the standard
behavior we want to be compatible with GCC cross compilers -- it isn't
specific to SUSE or any other distro.
Also start fleshing out testing of the different cross compilation
patterns, both with a new very bare-bones tree of cross compilers and by
extending the multilib trees. Currently, we don't correctly model doing
a cross compile using the non-triple target of a bi-arch GCC install,
but I'll add support for that (and tests) next.
llvm-svn: 184499
-gcc-toolchain foo -> --gcc-toolchain=foo
-target foo -> --target=foo
I've added legacy aliases for the original spellings. I've updated the
canonical tests to check both spellings, and switched all of the
-gcc-toolchain usages elsewhere in the test suite to use the new one.
I've updated some of the usages of -target to the new syntax, but will
finish that in a separate entirely mechanical change once I'm sure this
won't get rolled back for some reason (It touches a *huge* number of RUN
lines in the test suite unsurprisingly).
A nice result is that the three most common flags I end up using when
doing cross compiles are all now consistent: --target=, --sysroot=, and
--gcc-toolchain=.
llvm-svn: 184408
gcc's inputs are already added by the InputInfoList passed to
Action::ConstructJob.
Fixes a regression from r183989. This was manifesting when targetting
mingw as an extra input argument to gcc when assembling. It presumably
affects other situations where clang calls gcc.
Prior to r183989, forwardToGCC() was returning false because the INPUT
option defined in OptParser.td had the DriverOption flag set on it.
LLVM's Option library does not set this flag for INPUT.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D999
llvm-svn: 184308
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
llvm-svn: 184276
integrated assembler then go ahead and still split the dwarf anyhow.
Add two tests, one to exercise existing behavior of not splitting
when we're just emitting assembly files and the other to test
that we split when we're not in integrated as mode.
llvm-svn: 183355
This option is used to select a dynamic loader prefix to be used
at runtime. Currently this is implemented for the Linux toolchain.
Differential Revision: http://llvm-reviews.chandlerc.com/D851
llvm-svn: 182744
If -fsanitize=leak is specified, link the program with the
LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified,
because AddressSanitizer has this functionality built in.
llvm-svn: 182729
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
llvm-svn: 182645
imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.
I've fixed this to follow the logic:
1) If the last dominating flag is -fno-math-errno, -ffast-math, or
-Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
math-errno.
3) Otherwise, use the toolchain default.
This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.
I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.
llvm-svn: 182203
We've added the RS880 variant in the LLVM backend to represent an R600
GPU with no vertex cache, so we need to update the GPU mappings for
-mcpu.
llvm-svn: 181202
Specifically, allow the flags that fall under this umbrella (i.e., -O3,
-ffast-math, and -fstrict-aliasing) to be overridden/disabled with the
individual -O[0|1|2|s|z]/-fno- flags.
This also fixes the handling of various floating point optimization
flags that are modified by -ffast-math (and thus -Ofast as well).
Part of rdar://13622687
llvm-svn: 180204
Sourcery CodeBench and modern FSF Mips toolchains require a bit more
complicated algorithm to calculate headers, libraries and sysroot paths
than implemented by Clang driver now. The main problem is that all these
paths depend on a set of command line arguments additionally to a target
triple value. For example, let $TC is a toolchain installation directory.
If we compile big-endian 32-bit mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2 folder and the toolchain's linker requires
--sysroot=$TC/mips-linux-gnu/libc argument. If we compile little-endian
32-bit soft-float mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2/soft-float/el folder and the toolchain's
linker requires --sysroot=$TC/mips-linux-gnu/libc/soft-float/el argument.
1. Calculate MultiarchSuffix using all necessary command line options and
use this MultiarchSuffix to detect crtbegin.o location in the
GCCInstallationDetector::ScanLibDirForGCCTriple() routine.
2. If a user does not provide --sysroot argument to the driver explicitly,
calculate new sysroot value based on command line options. Then use this
calculated sysroot path:
a. To populate a file search paths list in the Linux::Linux() constructor.
b. To find Mips toolchain specific include headers directories
in the Linux::AddClangSystemIncludeArgs() routine.
c. To provide -–sysroot argument for a linker.
Note:
- The FSF's tree slightly differs (folder names) and is not supported
yet.
- New addExternCSystemIncludeIfExits() routine is a temporary solution.
I plan to move path existence check to the addExternCSystemInclude()
routine by a separate commit.
The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D644
llvm-svn: 179934
- There is no reason to have a modules specific flag for disabling
autolinking. Instead, convert the existing flag into -fno-autolink (which
should cover other autolinking code generation paths like #pragmas if and
when we support them).
llvm-svn: 179612
two new options –msingle-float and –mdouble-float. These options can be
used simultaneously with float ABI selection options (-mfloat-abi,
-mhard-float, -msoft-float). They mark whether a floating-point
coprocessor supports double-precision operations.
llvm-svn: 179481
Joey Gouly