Commit Graph

158 Commits

Author SHA1 Message Date
Rafael Espindola 7cf32219a7 Remove the Tools DensMap from the toolchain.
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
2013-03-20 03:05:54 +00:00
Rafael Espindola d15a8918fb Finish refactoring the tool selection logic.
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
2013-03-19 00:36:57 +00:00
Rafael Espindola 260e28d65a Centralize the recording of which tools have been constructed.
llvm-svn: 177319
2013-03-18 20:48:54 +00:00
Rafael Espindola c8e3a0162b Use early returns when checking if we already constructed a tool and when
delegating to Generic_GCC::SelectTool (it already updates the tool map).

llvm-svn: 177305
2013-03-18 18:50:01 +00:00
Rafael Espindola 30212ab363 Remove unused argument.
llvm-svn: 177303
2013-03-18 18:19:46 +00:00
Rafael Espindola 84b588b25c Pass an ArgList to every toolchain constructor. Remove the useIntegratedAs
argument.

llvm-svn: 177301
2013-03-18 18:10:27 +00:00
Rafael Espindola 88b55ead59 Remove unused argument.
llvm-svn: 177293
2013-03-18 17:25:58 +00:00
Dmitri Gribenko 15225aee17 Driver: add support for new style multiarch in Ubuntu 13.04
Patch by Sanne Wouda.

llvm-svn: 176557
2013-03-06 17:14:05 +00:00
David Chisnall e0a5c0d914 Default to enabling default-synthesized ivars on all platforms
llvm-svn: 176419
2013-03-03 15:36:10 +00:00
Tim Northover 9bb857a4f1 Add support for AArch64 target.
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
2013-01-31 12:13:10 +00:00
Rafael Espindola 0f207edaa5 Initial support for FreeBSD on ARM.
Patch by Andrew Turner.

llvm-svn: 170096
2012-12-13 04:17:14 +00:00
Matthew Curtis e689b0570c Hexagon TC: Reimplement Link::ConstructJob to call
linker directly

Rather than calling gcc.

llvm-svn: 169512
2012-12-06 15:46:07 +00:00
Matthew Curtis f10a595eac Hexagon TC: Move getHexagonTargetCPU from Tools.cpp to
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
2012-12-06 14:16:43 +00:00
Matthew Curtis 22dd8da6cd Hexagon TC: Update toolchain to add appropriate include
paths

- Inherit from Linux rather than ToolChain
- Override AddClangSystemIncludeArgs and AddClangCXXStdlibIncludeArgs
  to properly set include paths.

llvm-svn: 169495
2012-12-06 12:43:18 +00:00
Chandler Carruth 3a02247dc9 Sort all of Clang's files under 'lib', and fix up the broken headers
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
2012-12-04 09:13:33 +00:00
Chad Rosier 546c261e7e Remove an extra semicolon.
llvm-svn: 168707
2012-11-27 17:31:26 +00:00
Chandler Carruth 05fb585a36 Fix the '-fuse-init-array' option to actually be an option.
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
2012-11-21 23:40:23 +00:00
Alexey Samsonov 8368b376ad [Sanitizer] force linking with static sanitizer runtimes on Darwin even if they are not found in resource directory. Add test checking sanitizer linker flags on Darwin.
llvm-svn: 168428
2012-11-21 14:17:42 +00:00
Chandler Carruth 76a943be7b Completely re-work how the Clang driver interprets PIC and PIE options.
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
2012-11-19 03:52:03 +00:00
Fariborz Jahanian 0e3043b2ed block extended signatur option. Change previous option
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
2012-11-15 19:02:45 +00:00
Bob Wilson 5ad5a9511c Remove old driver code to grab the iOS simulator version from the -D option.
We can now rely on the -mios-simulator-version-min command line option
and remove the awful hack. <rdar://problem/10304510>

llvm-svn: 167603
2012-11-09 01:59:30 +00:00
Bob Wilson a2d228b570 Remove more code related to invoking llvm-gcc. <rdar://problem/11991320>
llvm-svn: 167598
2012-11-08 23:21:22 +00:00
Simon Atanasyan 2d1b1ad831 Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option.
The patch reviewed by Rafael Espindola.

llvm-svn: 166389
2012-10-21 11:44:57 +00:00
Rafael Espindola 151a957fb0 Implement ToolChain::IsUnwindTablesDefault to reduce code duplication a bit.
llvm-svn: 164473
2012-09-23 03:05:41 +00:00
John McCall 3deb1ad40c Screw around with ObjCRuntime some more, changing the
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
2012-08-21 02:47:43 +00:00
Eli Friedman 9fa2885522 clang support for Bitrig (an OpenBSD fork); patch by David Hill.
llvm-svn: 161546
2012-08-08 23:57:20 +00:00
Fariborz Jahanian c934daba9b Make property synthesis the default on Windows.
llvm-svn: 161266
2012-08-03 21:51:38 +00:00
David Chisnall da22535573 Hoist the logic for selecting the Objective-C dispatch method into the runtime
class, from the target.  No functionality change, just less duplicated logic.

llvm-svn: 159710
2012-07-04 11:52:24 +00:00
John McCall 5fb5df9c83 Restructure how the driver communicates information about the
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
2012-06-20 06:18:46 +00:00
Rafael Espindola 66aa045fd9 Add a -fuse-init-array option to cc1 and map to the UseInitArray target
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
2012-06-19 01:26:10 +00:00
Chad Rosier 6037c6bae0 Move the iOSVersionMin string to a header so as to avoid a dangling pointer.
llvm-svn: 156497
2012-05-09 18:37:26 +00:00
Bob Wilson f9fbc6a84a Rip out old code for finding libraries in GCC's directories.
llvm-svn: 156058
2012-05-03 05:23:52 +00:00
Benjamin Kramer c242ef245c Driver: Turn the default value for -fmath-errno into a proper target hook and disable it by default on more platforms.
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
2012-05-02 14:55:48 +00:00
David Chisnall a27cf0e6e1 Make a modern Objective-C runtime the default target for *BSD. Don't yet change this on GNU/Linux, where the GCC runtime still tends to be used.
llvm-svn: 154315
2012-04-09 12:33:41 +00:00
Benjamin Kramer ddefa6d925 Use VersionTuple to manage macosx versions in the driver. No functionality change.
llvm-svn: 152504
2012-03-10 20:55:36 +00:00
Ted Kremenek d151dde0e6 Enable default @synthesize by default.
llvm-svn: 152140
2012-03-06 20:06:15 +00:00
Ted Kremenek e65b086e07 Add clang support for new Objective-C literal syntax for NSDictionary, NSArray,
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
2012-03-06 20:05:56 +00:00
Argyrios Kyrtzidis 3dbeb55874 [driver] Emit an error when trying to use ARC on macosx earlier than 10.6
rdar://10459258

llvm-svn: 151706
2012-02-29 03:43:52 +00:00
Jim Grosbach 2e16624291 Re-enable the Darwin ARM integrated assembler.
All known nightly-test failures are fixed.

llvm-svn: 151595
2012-02-27 23:55:25 +00:00
Chad Rosier 4c5c8ccf40 Temporarily revert r151288:
ARM: enable the integrated assembler by default for Darwin. 

llvm-svn: 151454
2012-02-25 20:32:43 +00:00
Jim Grosbach 1d43ca99e2 ARM: enable the integrated assembler by default for Darwin.
llvm-svn: 151288
2012-02-23 21:55:04 +00:00
Rafael Espindola 1af7c219c7 Implement a -gcc-toolchain command line option that does the same as
configure's --with-gcc-toolchain. The configure option is now just a default
value for the command line one.

llvm-svn: 150898
2012-02-19 01:38:32 +00:00
David Chisnall f571cde869 First pass at Solaris toolchain support. This version compiles and links hello
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
2012-02-15 13:39:01 +00:00
Chandler Carruth 9b5f8ddcf8 Begin refactoring to use the newly added triple predicates for
simplicity. Also addresses a FIXME, although not one that could be
observed.

llvm-svn: 150294
2012-02-11 03:31:12 +00:00
Chandler Carruth d7fa2e04f6 Revert r149083 which is not the direction we're going in the Clang
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
2012-01-31 02:21:20 +00:00
Joerg Sonnenberger 91960f4abb 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: 149083
2012-01-26 21:56:28 +00:00
Chandler Carruth 1ccbed88fc Remove the 'ToolTriple' concept from the NetBSD toolchain along with my
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
2012-01-25 11:18:20 +00:00
Chandler Carruth b65b111d24 Switch the ToolChain types to all store a Driver reference rather than
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
2012-01-25 09:12:06 +00:00
Chandler Carruth 866faab4db Make a major refactoring to how the GCC installation detection works.
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
2012-01-25 07:21:38 +00:00
Chandler Carruth 4d9d76839a Address one part of the FIXME I introduced my switching the triple
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
2012-01-24 19:28:29 +00:00