It makes no sense to try and compile for arm7tdmi when we're targeting
something like gnueabihf. Although not strictly the most basic hardware
conceivable, I believe arm1176jzf-s is a reasonable compromise (that can always
be overridden explicitly if needed) since it's still in reasonably common use
unlike earlier cores.
Patch by Stephen Kelly.
llvm-svn: 188796
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
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
llvm-svn: 187180
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere
As discussed in the review, this change includes using directives in
header files. I'll make follow up changes to remove those in favor of
name specifiers.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D975
llvm-svn: 183989
When choosing a default CPU, clang used to pick ARM7TDMI (which has Thumb) even
when the more restrictive armv4 triple was specified. This should fix that.
Patch by Jeroen Hofstee.
llvm-svn: 183905
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
svn 170909 added support for cortex-r5 but in this case it was done
incorrectly. The last argument to StringSwitch.Cases() is the replacement
value, so by adding "cortex-r5" it changed the default cpu for armv7r to
cortex-r5 instead of cortex-r4.
llvm-svn: 176456
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
crtfastmath.o contains routines to set the floating point flags to a faster,
unsafe mode. Linking it in speeds up code dealing with denormals significantly
(PR14024).
For now this is only enabled on linux where I can test it and crtfastmath.o is
widely available. We may want to provide a similar file with compiler-rt
eventually and/or enable it on other platforms too.
llvm-svn: 165240
This parameter is useless because nowhere used explicitly and always
gets its default value - "false".
The patch reviewed by Rafael Espindola.
llvm-svn: 165149
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
The getARMTargetCPU and getLLVMArchSuffixForARM functions exist in both
Toolchain.cpp and Tools.cpp. This stuff needs a thorough overhaul. In the
meantime, this patch at least makes them consistent. One version had been
converted to use StringSwitch, and the other version had new Cortex M-series
processors added.
llvm-svn: 153202
On Darwin the architecture and the corresponding Mach-O slice is typically
specified with -arch. If not, it defaults to the current host architecture.
Do not use -mcpu to override the -arch value. This is only an issue when
people need to use specialized code for a non-default CPU (hopefully guarded
by run-time checks to detect the current processor). The -mcpu option is
still used for the -target-cpu option to clang, but this patch causes it to
not be used to set the architecture in the target triple.
llvm-svn: 153197
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
llvm-svn: 152141
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
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
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
handling logic of the generic ToolChain. This flag, despite its name,
has *nothing* to do with the GCC flag '-nostdlib' that relates
(exclusively) to the linking behavior. It is a most unfortunate name in
that regard...
It is used to tell InitHeaderSearch.cpp *which* set of C++ standard
library header search paths to use -- those for libstdc++ from GCC's
installation, or those from a libc++ installation. As this logic is
hoisted out of the Frontend, and into the Driver as part of this
ToolChain, the generic method will be overridden for the platform, where
it can implement this logic directly. As such, hiding the CC1 option
passing in the generic space is a natural fit despite the odd naming.
Also, expand on the comments to clarify whats going on, and tidy up the
Tools.cpp code now that its simpler.
llvm-svn: 143687
implementation in the driver. This cleans up the signature and semantics
of the include flag adding component of the toolchain. Another step to
ready it for holding all the InitHeaderSearch logic.
llvm-svn: 143686
and the C++ include management routine from the proper place when
forming preprocessor options in the driver. This is the first step to
teaching the driver to manage all of the header search paths. Currently,
these methods remain just stubs in the abstract toolchain. Subsequent
patches will flesh them out with implementations for various toolchains
based on the current code in InitHeaderSearch.cpp.
llvm-svn: 143684
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
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
Tim Northover