Clang when linking and using a GCC installation from a GCC
cross-compiler.

This was desired already by two special case platforms (Android and
Mips), and turns out to be generally (if frustratingly) true. I've added
a substantial comment to the code clarifying the underlying assumptions
of doing actual cross compiles with Clang (or GCC for that matter!) and
help avoid further confusion here.

The end result is to realize that fully general form of PR12478 cannot
be resolved while we support existing cross-compiling GCC toolchains,
and linking with them (namely, linking against their libgcc and
libstdc++ installs). GCC installs these target libraries under
a target-specific prefix but one that may not be available within the
actual sysroot in use. When linking in this world, GCC works and Clang
should as well, but caveat emptor: DSOs from this tree must be
replicated and rpath-fixed to be found at runtime within the sysroot.

I've extended the cross compile test cases to cover these issues by
pointing them at a sysroot and actually checking the library search
paths.

llvm-svn: 187466

clang/test/Driver/qa_override.c: Resurrect a part of r187376. It still requires the feature 'clang-driver' for cygming.

llvm-svn: 187405

output rather than just part of it.

Also, remove the frighteningly ancient comment about not working with
the gcc-driver. (!!!)

llvm-svn: 187376

The quotes (from r187330) didn't really help here, the trick was to disable
the test on MSYS builds. This removes those quotes, changes back the comment
to explain why /? has to be quoted specifically, and moves the REQUIRES
line to the top of the file because that's important.

llvm-svn: 187366

llvm-svn: 187337

It was still failing with double quotes:

http://bb.pgr.jp/builders/clang-i686-msys/builds/698/steps/test_clang/logs/Clang%20%3A%3A%20Driver__cl.c

llvm-svn: 187330

This test would fail in weird ways on systems with a one-letter filename
in the root directory, because the shell would helpfully expand /? to e.g. /n.

Make sure this doesn't happen by adding quotes.

llvm-svn: 187295

This establishes a new Flag in Options.td, which can be assigned to
options that should be made available in clang's cl.exe compatible
mode, and updates the Driver to make use of the flag.

(The whitespace change to CMakeLists forces the build to re-run CMake
 and pick up the include dependency on the new .td file. This makes the
 build work if someone moves backwards in commit history after this change.)

Differential Revision: http://llvm-reviews.chandlerc.com/D1215

llvm-svn: 187280

llvm-svn: 187203

llvm-svn: 187194

llvm-svn: 187192

This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code.  Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing.  Code generation will otherwise be the same as
powerpc64 (big-endian), for now.

The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.

The new test case variant ensures that correct built-in defines for
little-endian code are generated.

llvm-svn: 187180

Just more craziness to find crtbegin.o etc.

Patch by Stephen Kelly.

llvm-svn: 187175

Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)

I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.

llvm-svn: 187156

llvm-svn: 187061

llvm-svn: 186983

llvm-svn: 186970

It was fixed by r186603.

llvm-svn: 186962

llvm-svn: 186949

Sorry about forgetting to include this in the previous patch.

llvm-svn: 186946

This is still a fairly odd test. Clang wants to run gcc for assembling. At
least with -### it only prints that instead of actually trying to run it with
-ccc-echo.

llvm-svn: 186945

The mode doesn't actually do anything yet, but this provides a
way to get into it.

llvm-svn: 186720

-mcheck-zero-division.

llvm-svn: 186710

llvm-svn: 186701

llvm-svn: 186694

Copies the x86 behavior.

llvm-svn: 186674

and add a new option --driver-mode= to control it explicitly.

The CCCIsCXX and CCCIsCPP flags were non-overlapping, i.e. there
are currently really three modes that Clang can run in: gcc, g++
or cpp, so it makes sense to represent them as an enum.

Having a command line flag to control it helps testing.

llvm-svn: 186605

MSBuild writes response files as UTF-16 little endian with a byte order
mark.  With this change, clang will be able to read them, although we
still can't parse any of their flags.

Adds a UTF-16-LE response file with a BOM for testing.

Differential Revision: http://llvm-reviews.chandlerc.com/D1137

llvm-svn: 186603

llvm-svn: 186438

Some versions of python will expand the glob used in the test, others wont,
causing the test to fail when run with LIT_USE_INTERNAL_SHELL=1.

llvm-svn: 185653

This is at least good documentation, but also opens the possibility of
using pipefail.

llvm-svn: 185652

This avoids depending on pipefail not being used.

llvm-svn: 185648

llvm-svn: 185577

Verify that assembling an empty file does not auto-include altivec.h.

llvm-svn: 185563

Darwin systems currently do not support dwarf version 3 or above. When we are
ready, we can bump the default to gdwarf-4 for Darwin.

For other systems, the default is dwarf version 3, if everything goes smoothly,
we can bump the version to 4.

rdar://13591116

llvm-svn: 185483

llvm-svn: 185075

llvm-svn: 184970

clang/test/Driver/pth.c: Fix r184942, a regexp like "\\\\" is redundant here. Should be matched to single \ with '\\'.

llvm-svn: 184952

llvm-svn: 184942

llvm-svn: 184902