| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
ARM: enable the integrated assembler by default for Darwin.
llvm-svn: 151454
|
| |
|
|
| |
llvm-svn: 151288
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
are likely many other OPT_xxxx_EQ options that could/should be added here.
rdar://10704648
llvm-svn: 151174
|
| |
|
|
|
|
|
| |
crash. This can speedup the process of generating a delta reduced test case.
rdar://10905465
llvm-svn: 151109
|
| |
|
|
| |
llvm-svn: 150960
|
| |
|
|
|
|
|
| |
configure's --with-gcc-toolchain. The configure option is now just a default
value for the command line one.
llvm-svn: 150898
|
| |
|
|
| |
llvm-svn: 150883
|
| |
|
|
| |
llvm-svn: 150696
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
llvm-svn: 150612
|
| |
|
|
|
|
| |
-lgcc_s.
llvm-svn: 150602
|
| |
|
|
| |
llvm-svn: 150587
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too.
Reverts r149571/restores r149504, now that config.h is generated
correctly by LLVM's configure in all build configurations.
llvm-svn: 150487
|
| |
|
|
|
|
|
|
|
| |
-arch options if the're all the same.
Patch by Jeremy Huddleston.
rdar://10849701
llvm-svn: 150403
|
| |
|
|
|
|
| |
this functionality.
llvm-svn: 150358
|
| |
|
|
|
|
|
| |
simplicity. Also addresses a FIXME, although not one that could be
observed.
llvm-svn: 150294
|
| |
|
|
|
|
|
|
|
|
| |
When creating the MCSubtargetInfo, the assembler driver uses the CPU and
feature string to construct a more accurate model of what instructions
are and are not legal.
rdar://10840476
llvm-svn: 150273
|
| |
|
|
|
|
|
|
|
|
| |
This was from way-back-when (r82583) when Clang's C++ support wasn't prime-time
yet. Production quality C++ was tested experimentally from r100119 and turned
on by default in r141063.
Patch by Justin Bogner.
llvm-svn: 150148
|
| |
|
|
|
|
|
| |
These are new options that gcc doesn't recognize so the clang driver needs
to remove them when it falls back to invoking gcc.
llvm-svn: 149951
|
| |
|
|
|
|
|
| |
Add a quiet option for dwarfdump and move it out of NDEBUG only.
Still requires an option as we don't want this on by default.
llvm-svn: 149894
|
| |
|
|
|
|
| |
to leave this as a debug only option for now.
llvm-svn: 149890
|
| |
|
|
|
|
|
| |
- Turn openSUSE version parsing into a StringSwitch
- Add an entry for Fedora release 16 (Verne)
llvm-svn: 149872
|
| |
|
|
|
|
| |
aka precise pangolin.
llvm-svn: 149869
|
| |
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
| |
|
|
| |
llvm-svn: 149798
|
| |
|
|
|
|
|
|
|
| |
That llvm change removed the -trap-func backend option, so that using
-ftrap-function with clang would cause the backend to complain. Fix it
by adding the trap function name to the CodeGenOptions and passing it through
to the TargetOptions.
llvm-svn: 149679
|
| |
|
|
|
|
|
|
|
| |
--with-gcc-toolchain
that just uses the new toolchain probing logic. This fixes linking with -m32 on
64 bit systems (the /32 dir was not being added to the search).
llvm-svn: 149652
|
| |
|
|
|
|
| |
Too many weird build failures.
llvm-svn: 149571
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too. (clang r149497 / llvm r149498)
Also include the config.h header after all other headers, per
the LLVM coding standards.
It also turns out WindowsToolChain.cpp wasn't using the config
header at all, so that include's just deleted now.
llvm-svn: 149504
|
| |
|
|
| |
llvm-svn: 149439
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
from the driver.
llvm-svn: 149276
|
| |
|
|
|
|
|
|
| |
the recent refactoring. All interesting NetBSD release have a GNU as
version on i386 that supports --32, so don't bother with the conditional
setting of it.
llvm-svn: 149087
|
| |
|
|
| |
llvm-svn: 149084
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
target triple correctly."
There were some problems with this, so I'm backing it out for now.
llvm-svn: 149040
|
| |
|
|
| |
llvm-svn: 149016
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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. ;]
llvm-svn: 148977
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 148953
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
continue until cleanliness improves.
llvm-svn: 148951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 148950
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 148942
|