| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 252514
|
| |
|
|
|
|
|
|
|
|
|
| |
Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9
layout for sparc (32bit), sparc (32bit) with lib64 multilib, and
sparc64.
The test cases added here also cover r239047, which fixed the linker
paths.
llvm-svn: 239154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch, this test was accidentally testing that
CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING
were set to a particular set of values.
The test was also getting pretty hairy since it was attempting to craft
a regular expression that covered "all" possible combinations of
settings for these configure-time constants.
Clean it up by directly capturing the resource directory in a FileCheck
variable.
llvm-svn: 227310
|
| |
|
|
|
|
| |
For some regression tests the path to the right toolchain is specified using the -sysroot switch. However, if clang was configured with a custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the equivalent configure command), the path to the custom gcc toolchain path takes precedence to the one specified by sysroot. This causes several regression tests to fail as they will be using an unexpected path. This patch fixes this issue by adding --gcc-toolchain='' to all tests that rely on that. The empty string causes the driver to pick the path from sysroot instead.
llvm-svn: 225182
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modern Debian-based distributions) due to on-going multiarch madness.
It appears that when the multiarch heeader search support went into the
clang driver, it went in in a quite bad state. The order of includes
completely failed to match the order exhibited by GCC, and in a specific
case -- when the GCC triple and the multiarch triple don't match as with
i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find
the libstdc++ target-specific header files.
I assume that folks who have been using Clang on Ubuntu 32-bit systems
have been applying weird patches to hack around this. I can't imagine
how else it could have worked. This was originally reported by a 64-bit
operating system user who had a 32-bit crosscompiler installed. We tried
to use that rather than the bi-arch support of the 64-bit compiler, but
failed due to the triple differences.
I've corrected all the wrong orderings in the existing tests and added
a specific test for the multiarch triple strings that are different in
a significant way. This should significantly improve the usability of
Clang when checked out vanilla from upstream onto Ubuntu machines with
an i686 GCC installation for whatever reason.
llvm-svn: 216531
|
| |
|
|
|
|
|
|
|
|
| |
TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin).
The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed.
Differential Revision: http://reviews.llvm.org/D4180
llvm-svn: 212725
|
| |
|
|
|
|
|
|
|
| |
target triples.
The patch fixes the bug #19869.
http://llvm.org/bugs/show_bug.cgi?id=19869
llvm-svn: 211619
|
| |
|
|
|
|
|
|
|
|
| |
There was already partial support for multi-arch on powerpc64le,
but the MultiarchIncludeDirs setting was missing. This patch
adds the appropriate definition, and also extends the
linux-header-search.cpp test case to verify an Ubuntu 14.04
powerpc64le tree.
llvm-svn: 211359
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iterating over different library path suffixes and different library versions.
To find the most appropriate library for the given command line flags we
iterate over a set of disk paths. Before probe each path the already
detected set of multilibs are cleared. If the set of paths contains
existing paths which do not satisfy command line flags or do not contain
necessary libraries and object files at all we might lose found multilibs.
The patch updates variables which hold detected multilibs if we really find
a new multilib matches command line flags.
The patch reviewed by Jon Roelofs.
llvm-svn: 208523
|
| |
|
|
| |
llvm-svn: 202721
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now instead of just looking in the system root for it, we also look
relative to the clang binary's directory. This should "just work" in
almost all cases. I've added test cases accordingly.
This is probably *very* worthwhile to backport to the 3.4 branch so that
folks can check it out, build it, and use that as their host compiler
going forward.
llvm-svn: 199632
|
| |
|
|
|
|
|
|
| |
which add another wrinkle to the installation of the libstdc++ headers.
Add at least some basic testing of the weirdnesses of Gentoo's layout.
llvm-svn: 189212
|
| |
|
|
|
|
| |
can be removed.
llvm-svn: 187194
|
| |
|
|
|
|
| |
them later.
llvm-svn: 187192
|
| |
|
|
|
|
|
|
| |
Just more craziness to find crtbegin.o etc.
Patch by Stephen Kelly.
llvm-svn: 187175
|
| |
|
|
| |
llvm-svn: 184902
|
| |
|
|
|
|
| |
Patch by Sanne Wouda.
llvm-svn: 176557
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
|
| |
|
|
|
|
|
| |
--- log message follows this test ---
[tests] Fixup some tests to work in "CLANG_IS_PRODUCTION" mode.
llvm-svn: 154342
|
| |
|
|
| |
llvm-svn: 151491
|
| |
|
|
|
|
| |
Turns out this can be .exe or .EXE, depending on the build system.
llvm-svn: 151490
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 148582
|
| |
|
|
| |
llvm-svn: 148141
|
| |
|
|
| |
llvm-svn: 148138
|
| |
|
|
|
|
| |
path is actually a multilib.
llvm-svn: 144177
|
|
|
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
|
