Linux and other (non-Darwin) platforms and have it use -fmath-errno by
default (for better or worse).
Darwin has seen the light here and uses -fno-math-errno by default, this
patch preserves that.
If any maintainers for a non-Linux platform would also like to opt-in to
-fno-math-errno by default, I'm happy to add folks, but we're currently
getting buts and misleading comparisons with GCC due to this difference
in behavior on Linux at least.
llvm-svn: 155607
requires the -plugin to come before any -plugin-opt options, we were passing
them the other way around. With this one can run (for example):
clang -o foo foo.c -O4 -Wl,-plugin-opt=generate-api-file
llvm-svn: 154357
First, this patch cleans up the parsing of the PIC and PIE family of
options in the driver. The existing logic failed to claim arguments all
over the place resulting in kludges that marked the options as unused.
Instead actually walk all of the arguments and claim them properly.
We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the
last one on the commandline. Previously there were lots of ordering bugs
that could creep in due to the nature of the parsing. Let me know if
folks would like weird things such as "-fPIE -fno-pic" to turn on PIE,
but disable full PIC. This doesn't make any sense to me, but we could in
theory support it.
Options that seem to have intentional "trump" status (-static, -mkernel,
etc) continue to do so and are commented as such.
Next, a -pie-level flag is threaded into the frontend, rigged to
a language option, and handled preprocessor, setting up the appropriate
defines. We'll now have the correct defines when compiling with -fpie.
The one place outside of the preprocessor that was inspecting the PIC
level (as opposed to the relocation model, which is set and handled
separately, yay!) is in the GNU ObjC runtime. I changed it to exactly
preserve existing behavior. If folks want to change its behavior in the
face of PIE, they can do that in a separate patch.
Essentially the only functionality changed here is the preprocessor
defines and bug-fixes to the argument management.
Tests have been updated and extended to test all of this a bit more
thoroughly.
llvm-svn: 154291
However, the '-x' option has special handling and wasn't following this
paradigm. Fix it to do so by claiming the arg as we parse the '-x' option.
rdar://11203340
llvm-svn: 154231
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.
The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.
Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.
This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.
llvm-svn: 154176
uses Neon instructions for single-precision FP.
-mfpmath=neon is analogous to passing llc -mattr=+neonfp.
-mfpmath=[vfp|vfp2|vfp3|vfp4] is analogous to passing llc -mattr=-neonfp.
rdar://11108618
llvm-svn: 154046
On msys bash, with %pathsep==os.pathsep==';', I can see lines like below in this script;
env DIR=X:/foo%{pathsep}X:/bar
Then it is expanded to;
env DIR=X:/foo;X:/bar
It should be with quote;
env "DIR=X:/foo;X:/bar"
llvm-svn: 153402
Previously, only diagnostics thrown by the cc1 process were
actually honoring the diagnostic options given on the command line,
like -Werror.
Reuse the existing code in Frontend currently used for cc1,
adjusting it to not interpret -Wl, linker flags as warnings.
Also fix a faulty test exposed by this change.
It wasn't actually testing anything, and was giving this warning:
clang-3: warning: argument unused during compilation: '-verify'
Which -Werror didn't turn into an error because it was output
by the driver, not the cc1 process, and diagnostic options
weren't parsed by the driver. And you couldn't see the warning
when running the test suite.
Fixes PR12181.
Patch by Dylan Noblesmith <nobled@dreamwidth.org>.
llvm-svn: 152660
The LIBRARY_PATH environment variable should be honored by clang. Have the
driver pass the directories to the linker.
<rdar://problem/9743567> and PR10296.
llvm-svn: 152578
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
This flag enables ThreadSanitizer instrumentation committed to llvm as r150423.
The patch includes one test for -fthread-sanitizer and one similar test for -faddress-sanitizer.
This patch does not modify the linker flags (as we do it for -faddress-sanitizer) because the run-time library is not yet
committed and it's structure in compiler-rt is not 100% clear.
The users manual wil be changed in a separate commit.
llvm-svn: 151846
Debian multiarch libraries, this should in theory add support for those
platform's header search rules. I don't have a system to check this
with, so review appreciated. I've added the corresponding tests
referring to the debian multiarch tree.
We are starting to have a relatively completely tested Linux platform
for header search and library search, with several interesting
peculiarities. We should point people at the debian_multiarch_tree when
suggesting new tests. Folks with Debian systems that can check this for
correctness, it would be much appreciated. The missing chunks I know of
are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and
64-bit variants of platforms, and the MIPS and ARM Debian toolchains.
llvm-svn: 151484
Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added
64-bit support. I just added one other place where powerpc64-linux-gnu
was missing (we only had powerpc64-unknown-linux-gnu).
I've also added a tree to test out the debian multiarch stuff. I don't
use debian regularly, so I'm not certain this is entirely accurate. If
anyone wants to check it against a debian system and fix any
inaccuracies, fire away. This way at least folks can see how this is
*supposed* to be tested.
It'd be particularly good to get the Debian MIPS toolchains tested in
this way.
llvm-svn: 151482
by -target and similar options. As discussed in PR 12026, the change
broke support for target-prefixed tools, i.e. calling x86_64--linux-ld
when compiling for x86_64--linux. Improve the test cases added
originally in r149083 to not require execution, just executable files.
Document the hack with appropiate FIXME comments.
llvm-svn: 151185
the linker toolchainness a bit more thoroughly. It used to work this
way, but hit buildbot issues. Hopefully subsequent fixes have addressed
those problems, but I'll be watching the bots.
llvm-svn: 151090
The Darwin toolchain constructor was assuming that all Darwin triples would
have an OS string starting with "darwin". Triples starting with "macosx"
would misinterpret the version number, and "ios" triples would completely
miss the version number (or worse) because the OS name is not 6 characters
long. We lose some sanity checking of triple strings here, since the
Triple.getOSVersion function doesn't do all the checking that the previous
code did, but this still seems like a step in the right direction.
llvm-svn: 149422
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
'-target'. The original flag was part of a flag group that marked it as
driver-only. The new flag didn't ever get equivalent treatment. This
caused the '-target' flag to get passed down to any raw GCC invocation.
Marking it as a driver option fixes this and PR11875.
llvm-svn: 149244
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
both actually tests what it wants to, doesn't have bogus and broken
assertions in it, and is also formatted much more cleanly and
consistently. Probably still some more that can be improved here, but
its much better.
Original commit message:
----
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.
Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.
llvm-svn: 149011
Original log:
Author: chandlerc <chandlerc@91177308-0d34-0410-b5e6-96231b3b80d8>
Date: Wed Jan 25 21:32:31 2012 +0000
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.
Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.
llvm-svn: 148993
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.
Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.
llvm-svn: 148981
freebsd test so that it's behavior isn't dependent on the filesystem of
the host running the tests. This should revive the build bots at least.
The tests and the trees still need a lot of love to make them as useful
and easy to maintain as linux-ld.c.
llvm-svn: 148949
- Support gcc-compatible vfpv3 name in addition to vfp3.
- Support vfpv3-d16.
- Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions
for those!).
llvm-svn: 147943
source file. Otherwise -g -save-temps will error out on the compile
of any .c file.
Fixes about 4000 of the errors in the clang-tests gdb test suite.
llvm-svn: 147819
Clang driver. This involves a bunch of silly option parsing code to try
to carefully emulate GCC's options. Currently, this takes a conservative
approach, and unless all of the unsafe optimizations are enabled, none
of them are. The fine grained control doesn't seem particularly useful.
If it ever becomes useful, we can add that to LLVM first, and then
expose it here.
This also fixes a few tiny bugs in the flag management around
-fhonor-infinities and -fhonor-nans; the flags now form proper sets both
for enabling and disabling, with the last flag winning.
I've also implemented a moderately terrifying GCC feature where
a language change is also provided by the '-ffast-math' flag by defining
the __FAST_MATH__ preprocessor macro. This feature is tracked and
serialized in the frontend but it isn't used yet. A subsequent patch
will add the preprocessor macro and tests for it.
I've manually tested that codegen appears to respect this, but I've not
dug in enough to see if there is an easy way to test codegen options w/o
relying on the particulars of LLVM's optimizations.
llvm-svn: 147434
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
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
edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.
A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.
I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.
llvm-svn: 143841
Former RUN line does not make sense on Win32 hosts.
Win32 hosts would not be expected to set appropriate $PWD.
Latter RUN line might be made valid if PathV2::is_absolute("/foo") would be true. Unfortunately, "/foo" should not be treated as absolute path on Win32.
FYI, on mingw32 with MSYS bash (it has 'shell' feature);
Former) $PWD is set as "X:/hogehoge/test/Driver"
Latter) PWD=/foo sets "X:/root/to/msys/foo" to $PWD.
llvm-svn: 142721
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
- This disables the system include directories, but not the compiler builtin
directories. Useful for projects that want to use things like the intrinsic
headers, but are otherwise freestanding.
- I'm willing to reconsider the option naming, I also considered providing an
explicit -builtinc (which would match -nobuiltininc), but this is more
consistent with existing options.
llvm-svn: 141692
this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.
Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.
llvm-svn: 141145
configuration, although the test still stubs out more directories than
are necessary or common in order to exercise all of the lookup paths
observed with upstream GCC.
This finishes testing the distribution-independent and
GCC-installation-independent parts of the library path search logic.
More testing is still needed for the triple detection, GCC-installation
detection, and handling distributions with unusual configurations.
llvm-svn: 141000
enabled for debian hosts, which is quite odd. I think all restriction on
when Clang attempts to use a multilib installation should go away. Clang
is fundamentally a cross compiler. It behaves more like GCC when built
as a cross compiler, and so it should just use multilib installs when
they are present on the system. However, there is a very specific
exemption for Exherbo, which I can't test on, so I'm leaving that in
place.
With this, check in a generic test tree for multilib on a 32-bit host.
This stubs out many directories that most distributions don't use but
that uptsream GCC supports. This is intended to be an agnostic test that
the driver behaves properly compared with the GCC driver it aims for
compatibility with.
Also, fix a bug in the driver that this testing exposed (see!) where it
was incorrectly testing the target architecture rather than the host
architecture.
If anyone is having trouble with the tree-structure stubs I'm creating
to test this, let me know and I can revisit the design. I chose this
over (for example) a tar-ball in order to make tests run faster at the
small, hopefully amortized VCS cost.
llvm-svn: 140999
include *any* path on crtbegin.o unless we actually find such a file via
one of the search paths. We still strictly check the search paths right
after this, so we'll catch any issues there.
The reason for this is that the driver does some normalization of the
path on the actual object file, and this changes the textual format of
the string on Windows. It no longer matches the textual format of the
sysroot flag.
llvm-svn: 140998
This requires fixing a latent bug -- if we used the default host triple
instead of an autodetected triple to locate GCC's installation, we
didn't go back and fix the GCC triple. Correct that with a pile of
hacks. This entire routine needs a major refactoring which I'm saving
for a subsequent commit. Essentially, the detection of the GCC triple
should be hoisted into the same routine as we locate the GCC
installation: the first is intrinsically tied to the latter. Then the
routine will just return the triple and base directory.
Also start to bring the rest of the library search path logic under
test, including locating crtbegin.o. Still need to test the multilib and
other behaviors, but there are also bugs in the way of that.
llvm-svn: 140995
This is still very much a WIP, but sysroot was completely broken before
this so we are moving closer to correctness.
The crux of this is that 'ld' (on Linux, the only place I'm touching
here) doesn't apply the sysroot to any flags given to it. Instead, the
driver must translate all the paths it adds to the link step with the
system root. This is easily observed by building a GCC that supports
sysroot, and checking its driver output.
This patch just fixes the non-multilib library search paths. We should
also use this in many other places, but first things first.
This also allows us to make the Linux 'ld' test independent of the host
system. This in turn will allow me to check in test tree configurations
based on various different distro's configuration. Again, WIP.
llvm-svn: 140990
precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.
This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.
There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.
If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.
No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.
llvm-svn: 140981
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
Make the suffixes optional everywhere, and just make sure they have the
right value. The suffixes aren't the interesting part of this test
anyways.
Sorry for the churn as I let the bots try out various patterns.
llvm-svn: 140927
This moves the existing code for CPATH into the driver and adds the environment lookup and path splitting there.
The paths are then passed down to cc1 with -I options (CPATH), added after the normal user-specified include dirs.
Language specific paths are passed via -LANG-isystem and the actual filtering is performed in the frontend.
I tried to match GCC's behavior as close as possible
Fixes PR8971.
llvm-svn: 140341
- wrong alignment for double (it was 4, but 8 is desired),
- added checks for _REENTRANT define,
- fixed the issue that defines were not tested (because the check for inside #ifdef).
llvm-svn: 138775
output on darwin so is hard coded there.
As a note this will need a little bit of refactoring in the class
hierarchy to separate it out for different verifiers based on input type.
Fixes rdar://8256258.
llvm-svn: 138343
automatically invoking llvm-gcc's cc1plus, which doesn't support all options
supported by Clang. Therefore, filter out unsupported options.
rdar://9964354
llvm-svn: 137842
Since -mkernel implies -fapple-kext, this just extends the current behavior
for -fapple-kext to apply for -mkernel as well. Radar 9933387.
llvm-svn: 137566
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
that the linker has a place to put the temporary object file and can leave it
around (for the driver to clean up). This is important so that the object file
references in the debug info are preserved for possible use by dsymutil.
- <rdar://problem/8294279> executable has no debug symbols when compiled with LTO
llvm-svn: 133543
an assembly file it worked correctly, while for a .c file it would given an
error about how --noexecstack is not a supported argument to -Wa.
llvm-svn: 133489
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
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
matches GCC behavior which libstdc++ uses to limit #warning-based
messages about deprecation.
The machinery involves threading this through a new '-fdeprecated-macro'
flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We
turn the flag off in the driver when the warning is turned off (modulo
matching some GCC bugs). We record this as a language option, and key
the preprocessor on the option when introducing the define.
A separate flag rather than a '-D' flag allows us to properly represent
the difference between C and C++ builds (only C++ receives the define),
and it allows the specific behavior of following -Wdeprecated without
potentially impacting the set of user-provided macro flags.
llvm-svn: 130055
-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.
Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.
This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.
llvm-svn: 130051
line options, instead of leveraging the blanket -mllvm option.
- This allows using the frontend itself without requiring the backend have
those options available (i.e., if the target wasn't built).
llvm-svn: 128087
MSYS substitutes path (that begins with "/") to de-mounted Windows path, even if it were nonexistent.
"/foo/bar" might be substituted to "C:/msysgit/foo/bar".
llvm-svn: 127861
MSYS substitutes path (that begins with "/") to de-mounted Windows path.
"/tmp" might be substituted as "C:/DOCUME~1/chapuni/LOCALS~1/Temp".
llvm-svn: 127860
*) 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
- We actually pretend that we have two separate types for LLVM assembly/bitcode because we need to use the standard suffixes with LTO ('clang -O4 -c t.c' should generate 't.o').
It is now possible to do something like:
$ clang -emit-llvm -S t.c -o t.ll ... assorted other compile flags ...
$ clang -c t.ll -o t.o ... assorted other compile flags ...
and expect that the output will be almost* identical to:
$ clang -c t.c -o t.o ... assorted other compile flags ...
because all the target settings (default CPU, target features, etc.) will all be initialized properly by the driver/frontend.
*: This isn't perfect yet, because in practice we will end up running the optimization passes twice. It's possible to get something equivalent out with a well placed -mllvm -disable-llvm-optzns, but I'm still thinking about the cleanest way to solve this problem more generally.
llvm-svn: 105584
added as the last output step, instead of just hacking it into the link step.
- Among other things, this fixes dSYM generation when using multiple -arch options.
llvm-svn: 105475
'-fasm' and explicitly map from that flag to -fgnu-keywords in the driver. Turn
off the driver in the lexer test for this madness and add a test to the driver
that the translation actually works.
llvm-svn: 104428
means it isn't really possible to write the test case for this code, but this is
the kind of thing that really requires testing against the installed compiler
anyway.
llvm-svn: 100935
Clang is installed. This is designed to match gcc, and is important when
installed in a non-standard location.
- This is gross, but no worse than ever. It will die when we finally move to
the compiler-rt based toolchain, any day now.
llvm-svn: 100915
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
- We still need support for detecting the target features, since the name
doesn't actually do a good job of decribing what the CPU supports (for LLVM).
llvm-svn: 88819
regardless of the architecture).
- This is a good default for development & testing; for example without this
any tests using 'clang' in the test suite will fail on PowerPC, since the
driver will avoid using clang.
- We don't want to actually ship something built this way, but that should be
handled via some sort of configuration file.
llvm-svn: 76886
- Default to yonah on Darwin (to get SSE3).
- Default to Pentium4 (32-bit) and x86-64 (64-bit) on
non-Darwin. Welcome to the 21st century.
llvm-svn: 71069
- This is a WIP...
- This adds -march= handling to the driver, and fixes the defaulting
of -mcpu on Darwin (which was using the wrong test).
Instead of handling -m{sse, ...} in the driver, pass them to clang-cc as
-target-feature [+-]name
In clang-cc, communicate with the (clang) target to discover the legal
features of a target, and the features which are enabled based on
-mcpu. This is currently hardcoded just enough to not be a feature
regression, we need to get this information from the backend's
TableGen information somehow.
This is used to construct the full list of features which are being
used, which is in turn used to initialize the predefines.
llvm-svn: 71061
- Otherwise, we will end up with stray .dSYM files which don't get
lipo'ed or removed.
- Ideally we would run dsymutil on the result, but we don't have the
infrastructure for that yet. Note that gcc doesn't handle this case
either.
- <rdar://problem/6809621> [driver] clang leaves .dSYM files lying
around in tmp.
llvm-svn: 69951
- Cover your eyes...
- This is a simple but effective way to allow developers to build a
project with clang while manipulating the command line, without
having to edit the project itself.
llvm-svn: 69342
up adding them twice when running with -no-integrated-cpp or
-save-temps.
- <rdar://problem/6766636> -save-temps falls over with prefix headers
llvm-svn: 68660
incorrectly. I'm blanking on the smartest way to write this search,
but we should just do the right thing when we move to TableGen.
- <rdar://problem/6761194> [driver] -Wextra-tokens isn't parsed
correctly
llvm-svn: 68525
preceeded by a linker input flag.
- <rdar://problem/6757236> clang should make a dSYM when going
straight from source to binary
- This still matches gcc, but the right way to solve this would be to
detect the situation we care about (we are compiling from source
and linking in one step), instead of looking at the suffix of the
input file. The Tool doesn't quite have enough information to do
this yet, however.
- Also, find the suffix correctly.
llvm-svn: 68417
- <rdar://problem/6741594> [pth] don't abuse -x to drive pth
generation
- Simpler, and fixes PR3915.
Cleanup test cases for PTH:
- Update to use -emit-pth
- Removed PTH test of carbon.c and cocoa.mm; these didn't actually
verify anything, and since PTH is token based the extra coverage
(over cocoa.m) isn't particularly helpful.
- Split PTH tests in cocoa.m to cocoa-pth.m, solely to increase
available parallelism when running tests.
Ted, could you update the PTH test cases (include-pth.c and
cocoa-pth.m) to have some sort of positive check that the PTH is
getting used? "# of PTH cache hits" or "tokens read from PTH cache"
statistics would work great. :)
llvm-svn: 68189
- -emit-llvm no longer changes what compilation steps are done.
- -emit-llvm and -emit-llvm -S write output files with .o and .s
suffixes, respectively.
- <rdar://problem/6714125> clang-driver should support -O4 and -flto,
like llvm-gcc
llvm-svn: 67645
- Don't default to using clang for C++ (use -ccc-clang-cxx to
override).
- Default to only using clang on i386 and x86_64 (use
-ccc-clang-archs "" to override).
- <rdar://problem/6712350> [driver] clang should not be used on
powerpc by default
- <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx
I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.
This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.
llvm-svn: 67640
- <rdar://problem/6669441> ccc doesn't handle assembler-with-cpp
semantics correctly (but clang supports it)
- This is sad, because it requires a fairly useless target
hook. C'est la vie.
llvm-svn: 67418
with a raw lexer instead of a PP lexer. This means that -verify doesn't scan
#include'd headers for expected-error/warning strings, and it also means that it
doesn't ignore them in #if 0.
llvm-svn: 59774
- env-include-paths.c is XFAIL as it exposed a bug.
Add test/Coverage.
- For tests which achieve code coverage but don't validate anything.
llvm-svn: 57070
Chandler Carruth