| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149011 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148993 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148981 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Linux toolchain selection -- sorry folks. =] This should fix the Hexagon
toolchain.
However, I would point out that I see why my testing didn't catch this
-- we have no tests for Hexagon. ;]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148977 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to suit the FreeBSD folks. Take them back to something closer to the old
behavior. We test whether the /usr/lib32 directory exists (within the
SysRoot), and use it if so, otherwise use /usr/lib.
FreeBSD folks, let me know if this causes any problems, or if you have
further tweaks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148953 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148952 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
continue until cleanliness improves.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148951 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
- Neither of these have anything to do with the host, or its info.
- The HostInfo class was setup as a full blown class *hierarchy* with
a separate implementation for each "host" OS. This required
dispatching just to create the objects in the first place.
- The hierarchy claimed to represent the host, when in fact it was
based on the target OS.
- Each leaf in the hierarchy was responsible for implementing the flag
processing and caching, resulting in a *lot* of copy-paste code and
quite a few bugs.
- The caching was consistently done based on architecture alone, even
though *any* aspect of the targeted triple might change the behavior
of the configured toolchain.
- Flag processing was already being done in the Driver proper,
separating the flag handling even more than it already is.
Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.
The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.
This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148950 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148945 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
helped stage the refactoring of things a bit, but really isn't the right
place for it. The driver may be responsible for compilations with many
different targets. In those cases, having a target triple in the driver
is actively misleading because for many of those compilations that is
not actually the triple being targeted.
This moves the last remaining users of the Driver's target triple to
instead use the ToolChain's target triple. The toolchain has a single,
concrete target it operates over, making this a more stable and natural
home for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148942 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
adding search paths. Add them only when they exist, and prefix the paths
with the sysroot. This will allow targeting a FreeBSD sysroot on
a non-FreeBSD host machine, and perhaps more importantly should allow
testing the FreeBSD driver's behavior similarly to the Linux tests with
a fake tree of files in the regression test suite.
I don't have FreeBSD systems handy to build up the list of files that
should be used here, but this is the basic functionality and I'm hoping
Roman or someone from the community can contribute the actual test
cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148940 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
search paths for 32-bit targets. This avoids having to detect which is
expected for the target system, and the linker should DTRT, and take the
32-bit libraries from the first one when applicable. Thanks to Roman
Divacky for sanity checking this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148939 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the GCC installation's multiarch suffix now that it is exposed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148938 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148935 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the target triple to stand in for the "host" triple.
Thanks to a great conversation with Richard Smith, I'm now much more
confident in how this is proceeding. In all of the places where we
currently reason about the "host" architecture or triple, what we really
want to reason about in the detected GCC installation architecture or
triple, and the ways in which that differs from the target. When we find
a GCC installation with a different triple from our target *but capable
of targeting our target* through an option such as '-m64', we want to
detect *that* case and change the paths within the GCC installation (and
libstdc++ installation) to reflect this difference.
This patch makes one function do this correctly. Subsequent commits will
hoist the logic used here into the GCCInstallation utility, and then
reuse it through the rest of the toolchains to fix the remaining places
where this is currently happening.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I can't read Java-style 'Gcc' acronyms. ;]
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
It's bugs all the way down today it seems...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
inside the innards of the Driver implementation, and only ever
implemented to return 'true' for the Darwin OSes. Instead use a more
direct query on the target triple and a comment to document why the
target matters here.
If anyone is worried about this predicate getting wider use or improper
use, I can make it a local or private predicate in the driver.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The Driver has a fixed target, whether we like it or not, the
DefaultTargetTriple is not a default. This at least makes things more
honest. I'll eventually get rid of most (if not all) of
DefaultTargetTriple with this proper triple object. Bit of a WIP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148796 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
X86 backend in LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148636 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148582 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
IdempotentOperationsChecker to the 'experimental' category. Fixes <rdar://problem/10146347>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148533 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
also needs -fcxx-modules to enable modules for C++/Objective-C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148393 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows -Wswitch-enum to find switches that need updating when these enums are modified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148281 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly. Getting the target triple wrong mostly appears to work, but messes up in subtle cases; for example, we incorrectly conclude that fwrite is actually named fwrite$UNIX2003. Also shuffles around the auto-detection code a bit to try and make it a bit more reliable. Fixes <rdar://problem/10664848>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148249 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148162 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch from Jyotsna Verma:
I have made the changes to remove assertions in the Hexagon backend
specific clang driver. Instead of asserting on invalid arch name, it has
been modified to use the default value.
I have changed the implementation of the CPU flag validation for the
Hexagon backend. Earlier, the clang driver performed the check and
asserted on invalid inputs. In the new implementation, the driver passes
the last CPU flag (or sets to "v4" if not specified) to the compiler (and
also to the assembler and linker which perform their own check) instead of
asserting on incorrect values. This patch changes the setCPU function for
the Hexagon backend in clang/lib/Basic/Targets.cpp which causes the
compiler to error out on incorrect CPU flag values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148139 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148138 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148137 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Gnu hash is not supported by the Android loader.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148113 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148055 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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!).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147920 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
shared between lambda expressions and block literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for the arm-linux-androideabi triple in particular.
Also use this to do a better job of selecting soft FP settings.
Patch by Evgeniy Stepanov.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147872 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147818 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147664 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147552 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147489 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
default anyway).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#import
mapping is a crucial part of the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147434 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Sylvestre Ledru. Fixes PR11673.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147277 91177308-0d34-0410-b5e6-96231b3b80d8
|
