which add another wrinkle to the installation of the libstdc++ headers.
Add at least some basic testing of the weirdnesses of Gentoo's layout.
llvm-svn: 189212
Summary:
This change turns SanitizerArgs into high-level options
stored in the Driver, which are parsed lazily. This fixes an issue of multiple copies of the same diagnostic message produced by sanitizer arguments parser.
Reviewers: rsmith
Reviewed By: rsmith
CC: chandlerc, eugenis, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1341
llvm-svn: 188660
Otherwise it lists all files (e.g. shared libraries) that happen to be in the
same paths the GCC installations usually reside in.
On a x86_64 Debian 7 system with i386 multilibs.
before: clang -v 2>&1|wc -l
3059
after: clang -v 2>&1|wc -l
10
llvm-svn: 188400
on the system, and report it when running the driver in verbose mode.
Without this it is essentially impossible to understand why a particular
GCC toolchain is used by Clang for libstdc++, libgcc, etc.
This also required threading a hook through the toolchain layers for
a specific toolchain implementation to print custom information under
'clang -v'. The naming here isn't spectacular. Suggestions welcome.
llvm-svn: 187427
There are fundamentally two different things that were getting conflated
here.
1) A bi-arch GCC toolchain install. This is not a full blown cross
compiler, but it supports targetting both 32-bit and 64-bit variants
of the same architecture using multilib OS installs and runtimes.
2) A "multiarch" Debian OS/runtime layout that lays out the libraries,
headers, etc as-if there were going to be a full blown cross compiler
even when in reality it is just a bi-arch GCC targeting two variants.
Also, these tend to use oddly "canonicalized" triples without the
vendor in them unlike the typical cross compiler runtime library
search that vanilla GCC cross compilers perform.
Now, when we mean the bi-arch nature of GCC accomplished with just
a suffix or tweak to the GCC paths, we say 'Biarch' or something
related. When we mean the Debian layout of includes and libraries, we
say multiarch or reference the multiarch triple.
In the process of reading and often renaming stuff in all these places,
also reformat with clang-format. No functionality change should be going
on here, this is just tidying up.
llvm-svn: 184632
This adds a bunch of llvm::opt name specifiers to all the uses of types
from that namespace.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D983
llvm-svn: 184079
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
Each toolchain has a set of tools, but they are all of known types. It can
have a linker, an assembler, a "clang" (compile, analyze, ...) a non-clang
compiler, etc.
Instead of keeping a map, just have member variable for each type of tool.
llvm-svn: 177479
The general pattern now is that Foobar::constructTool only creates tools
defined in the tools::foobar namespace and then delegates to the parent.
The remaining duplicated code is now in the tools themselves.
llvm-svn: 177368
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
ToolChains.cpp
This is in anticipation of forthcoming library path changes.
Also ...
- Fixes some inconsistencies in how the arch is passed to tools.
- Add test cases for various forms of arch flags
llvm-svn: 169505
paths
- Inherit from Linux rather than ToolChain
- Override AddClangSystemIncludeArgs and AddClangCXXStdlibIncludeArgs
to properly set include paths.
llvm-svn: 169495
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
Previously, this flag to CC1 was never exposed at the clang driver
layer, and if you happened to enable it (by being on Android or GCC 4.7
platform), you couldn't *disable* it, because there was no 'no' variant.
The whole thing was confusingly implemented.
Now, the target-specific flag processing gets the driver arg list, and
we use standard hasFlag with a default based on the GCC version and/or
Android platform. The user can still pass the 'no-' variant to forcibly
disable the flag, or pass the positive variant to clang itself to enable
the flag.
The test has also been substantially cleaned up and extended to cover
these use cases.
llvm-svn: 168473
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
llvm-svn: 162252
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.
llvm-svn: 158694
For now -fno-math-errno is the default on BSD-derived platforms (Darwin,
DragonFlyBSD, FreeBSD, NetBSD, OpenBSD). If the default is not right for
your platform, please yell. I only verified the result with the default
compilers on Darwin and FreeBSD.
llvm-svn: 155990
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
world on Solaris 11 for both x86 and x86-64 using the built-in assembler and
Solaris (not GNU) ld, however it currently relies on a hard-coded GCC location
to find crtbegin.o and crtend.o, as well as libgcc and libgcc_eh.
llvm-svn: 150580
driver based on discussions with Doug Gregor. There are several issues:
1) The patch was not reviewed prior to commit and there were review comments.
2) The design of the functionality (triple-prefixed tool invocation)
isn't the design we want for Clang going forward: it focuses on the
"user triple" rather than on the "toolchain triple", and forces that
bit of state into the API of every single toolchain instead of
handling it automatically in the common base classes.
3) The tests provided are not stable. They fail on a few Linux variants
(Gentoo among them) and on mingw32 and some other environments.
I *am* interested in the Clang driver being able to invoke
triple-prefixed tools, but we need to design that feature the right way.
This patch just extends the previous hack without fixing the underlying
problems with it. I'm working on a new design for this that I will mail
for review by tomorrow.
I am aware that this removes functionality that NetBSD relies on, but
this is ToT, not a release. This functionality hasn't been properly
designed, implemented, and tested yet. We can't "regress" until we get
something that really works, both with the immediate use cases and with
long term maintenance of the Clang driver.
For reference, the original commit log:
Keep track of the original target the user specified before
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
llvm-svn: 149337
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
llvm-svn: 149083
gross hack to provide it from my previous patch removing HostInfo. This
was enshrining (and hiding from my searches) the concept of storing and
diff-ing the host and target triples. We don't have the host triple
reliably available, so we need to merely inspect the target system. I've
changed the logic in selecting library search paths for NetBSD to match
what I provided for FreeBSD -- we include both search paths, but put the
32-bit-on-64-bit-host path first so it trumps.
NetBSD maintainers, you may want to tweak this, or feel free to ask me
to tweak it. I've left a FIXME here about the challeng I see in fixing
this properly.
llvm-svn: 148952
a HostInfo reference. Nothing about the HostInfo was used by any
toolchain except digging out the driver from it. This just makes that
a lot more direct. The change was accomplished entirely mechanically.
It's one step closer to removing the shim full of buggy copy/paste code
that is HostInfo.
llvm-svn: 148945
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
inside of GCCInstallation to be a proper llvm::Triple. This is still
a touch ugly because we have to use it as a string in so many places,
but I think on the whole the more structured representation is better.
Comments of course welcome if this tradeoff isn't working for folks.
llvm-svn: 148843
especially nice as the Windows toolchain needs the windows header files,
and has lots of platform specific hooks in it.
To facilitate the split, hoist a bunch of file-level static helpers into
class-level static helpers. Spiff up their doxygen comments while there
as they're now more likely to be looked up via docs.
Hopefully, this will be followed by further breaking apart of the
toolchain definitions. Most of the large and complex ones should likely
live on their own. I'm looking at you Darwin. ;]
llvm-svn: 146840
. 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
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
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
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
variable to begin with... As I'm planning to add include root
information to this object, this would have caused confusion. It didn't
even *actually* hold the include root by the time we were done with it.
llvm-svn: 143840
toolchain instead of merely using it in the constructor. This will allow
us to query it when building include paths as well as the file search
paths built in the constructor. I've lifted as little of it as I could
into the header file.
Eventually this will likely sink down into some of the Generic
toolchains and be used on more platforms, but I'm starting on Linux so
I can work out all the APIs needed there, where it is easiest to test
and we have the most pressing need.
llvm-svn: 143838
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
llvm-svn: 143822
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
llvm-svn: 143752
Check whether the libc++ library is available when using -stdlib=libc++,
and also adjust the check for whether to link with -lgcc_s.1.
Patch by Ted Kremenek and Daniel Dunbar.
llvm-svn: 141374
This replaces the hack to read UNAME_RELEASE from the environment when
identifying the OS version on Darwin, and it's more flexible. It's also
horribly ugly, but at least this consolidates the ugliness to touch less of
the code so that it will be easier to rip out later.
llvm-svn: 140187
feature akin to the ARC runtime checks. Removes a terrible hack where
IR gen needed to find the declarations of those symbols in the translation
unit.
llvm-svn: 139404
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
Preserve the original triple in the NetBSD toolchain when using -m32 or
-m64 and the resulting effective target is different from the triple it
started with. This allows -m32 to use the same assembler/linking in
cross-compiling mode and avoids confusion about passing down target
specific flags in that case like --32.
llvm-svn: 131404
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
llvm-svn: 122519
*) Try to detect as much as possible from the system itself, not the distro.
This should make it easier to port to a new distro and more likely to
work on a unknown one.
*) The distro enum now doesn't include the arch. Just use the existing
host detection support in LLVM.
*) Correctly handle --sysroot.
A small regression is that now clang will pass bitcode file to the linker.
This is necessary for the gold plugin support to work.
It might be better to detect this at configure/cmake time, but doing it in
c++ first is a lot easier.
llvm-svn: 118382
distros listed by running
gcc main.o -o main
g++ main.o -o main
gcc main.o -o main -static
g++ main.o -o main -static
gcc f.o -o f.so -shared
g++ f.o -o f.so -shared
and comparing the ld line with the one created by clang. I also added
-m32/m64 in distros that support it.
While I tested many distros, there will always be more. If you are hit by this
it should be somewhat easy to add your distro. If you are in a hurry, do
revert this, but please inform how to detect you distro and the ld command
lines produced by the above gcc invocations. Most distros have some patches
on gcc :-(
llvm-svn: 118149
the GCC dir. Unfortunately, this breaks -lstdc++ on SnowLeopard, etc. because
the libstdc++ dylib was hiding there. Workaround this by providing the path to
the right -lstdc++.6 (the only version used in recent memory) if we can't see an
obvious -lstdc++, but can find = -lstdc++.6.
llvm-svn: 114146
ToolChain. This fixes a potenial bad cast when running Clang on PPC code, since
the tool chain in effect is not a subclass of the Darwin one, but we were
treating it like it was.
- This introduces some gross code duplication, but the right fix for it is to
just move the Driver to start depending on the targets in libBasic, so I am
not planning on fixing it immediately.
llvm-svn: 111856
- Replace -cc1 level -fobjc-legacy-dispatch with -fobjc-dispatch-method={legacy,non-legacy,mixed}.
- Lift "mixed" vs "non-mixed" policy choice up to driver level, instead of being buried in CGObjCMac.cpp.
- No intended functionality change.
llvm-svn: 102255
to compile a translation unit into the debug info for that file.
- Used by parts of Darwin build process to check compiler flags, etc.
- <rdar://problem/7256886> clang does not emit AT_APPLE_flags
llvm-svn: 91661
- This commit has some messy stuff in it to extend string lifetimes, but that
will go away once we switch to using the enum'd Triple interfaces.
llvm-svn: 72243
- This is really gross, but its the easiest way to match gcc. Once we
are confident in the driver, we can try and push these translations
down into tools.
- No test cases for this yet, it's hard to see the effects of these
translations before the gcc tool argument translation is pulled
over.
- Interaction with "unused argument" warning hasn't been worked out
yet.
- <rdar://problem/6717359> [driver] implement toolchain specific
argument translation.
"It's horrible in here."
llvm-svn: 67683
- Lift ArgList to a base class for InputArgList and DerivedArgList.
- This is not a great decomposition, but it does embed the
translation into the type system, and keep things efficient for
tool chains that don't want to do any translation.
- No intended functionality change.
Eventually I hope to get rid of tool chain specific translation and
have each tool do the right thing, but for now this is the easiest way
to match gcc precisely (which is good for testing).
llvm-svn: 67676
Chandler Carruth