Age | Commit message (Collapse) | Author |
|
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
|
|
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
|
|
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
|
|
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
|
|
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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. ;]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146552 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
. move compiler-rt to a separate directory so the -L argument only includes compiler-rt (thanks joerg)
. build all clang subdirs
. switches the Minix platform to ELF
. normalizes toolchain invocation
Patch by Ben Gras.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146206 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dual support for compiler-rt on Linux, during bringup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144165 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
routines on the base toolchain class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143900 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
toolchain. The logic is mostly generic already, and where possible
should be made more generic. Also, it has no impact other than to expose
a set of methods which each toolchain can then query to setup their
desired configuration. These should be available to toolchains beyond
just Linux.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
aren't guaranteed to live long enough otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the detected GCC installation. This allows us to expose another aspect
of what we detected: the GCC version. This will be used shortly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143871 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will facilitate further use and recombinations of them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variable to begin with... As I'm planning to add include root
information to this object, this would have caused confusion. It didn't
even *actually* hold the include root by the time we were done with it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
toolchain instead of merely using it in the constructor. This will allow
us to query it when building include paths as well as the file search
paths built in the constructor. I've lifted as little of it as I could
into the header file.
Eventually this will likely sink down into some of the Generic
toolchains and be used on more platforms, but I'm starting on Linux so
I can work out all the APIs needed there, where it is easiest to test
and we have the most pressing need.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143752 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Check whether the libc++ library is available when using -stdlib=libc++,
and also adjust the check for whether to link with -lgcc_s.1.
Patch by Ted Kremenek and Daniel Dunbar.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141374 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This replaces the hack to read UNAME_RELEASE from the environment when
identifying the OS version on Darwin, and it's more flexible. It's also
horribly ugly, but at least this consolidates the ugliness to touch less of
the code so that it will be easier to rip out later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://10125227
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140179 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
feature akin to the ARC runtime checks. Removes a terrible hack where
IR gen needed to find the declarations of those symbols in the translation
unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139404 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This concludes //rdar://8843851
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138947 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This matches gcc's behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138324 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
some common llvm types: stringref and smallvector. This cleans up the codebase
quite a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135576 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Jean-Daniel Dupas!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Preserve the original triple in the NetBSD toolchain when using -m32 or
-m64 and the resulting effective target is different from the triple it
started with. This allows -m32 to use the same assembler/linking in
cross-compiling mode and avoids confusion about passing down target
specific flags in that case like --32.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131404 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
update -mios-simulator-version-min to set it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130592 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Luis Felipe Strano Moraes!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129559 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126767 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125708 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
might expect.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124848 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122519 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
*) 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118382 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
distros listed by running
gcc main.o -o main
g++ main.o -o main
gcc main.o -o main -static
g++ main.o -o main -static
gcc f.o -o f.so -shared
g++ f.o -o f.so -shared
and comparing the ld line with the one created by clang. I also added
-m32/m64 in distros that support it.
While I tested many distros, there will always be more. If you are hit by this
it should be somewhat easy to add your distro. If you are in a hurry, do
revert this, but please inform how to detect you distro and the ld command
lines produced by the above gcc invocations. Most distros have some patches
on gcc :-(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118149 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
systems.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117697 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rewrite linker arguments to use libclang_rt.cc_kext.a
instead of gcc-specific libcc_kext.a
Resolves Radar 7808495
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114193 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114147 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the GCC dir. Unfortunately, this breaks -lstdc++ on SnowLeopard, etc. because
the libstdc++ dylib was hiding there. Workaround this by providing the path to
the right -lstdc++.6 (the only version used in recent memory) if we can't see an
obvious -lstdc++, but can find = -lstdc++.6.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114146 91177308-0d34-0410-b5e6-96231b3b80d8
|