calling gcc in generic configurations.

llvm-svn: 68260

 - PR3922

 - I have a clean solution for this in flight, but it may take a while
   to come to fruition so we'll take a quick fix for now.

llvm-svn: 68241

 - PR3875.
 - <rdar://problem/6615249> [driver] ccc should support some form of
   --help

llvm-svn: 68148

 - Patch by Ed Schouten!

llvm-svn: 68061

 - Not particularly elegant, but my hand is forced by gcc.

Also, tweak -ccc-print-bindings output.

llvm-svn: 68027

warnings.

llvm-svn: 68018

llvm-svn: 67837

llvm-svn: 67806

separate, or vice versa).

Also, fix initialization of LinkingOutput variable.

llvm-svn: 67757

llvm-svn: 67756

llvm-svn: 67754

llvm-svn: 67741

 - Lift ArgList to a base class for InputArgList and DerivedArgList.
 
 - This is not a great decomposition, but it does embed the
   translation into the type system, and keep things efficient for
   tool chains that don't want to do any translation.

 - No intended functionality change.

Eventually I hope to get rid of tool chain specific translation and
have each tool do the right thing, but for now this is the easiest way
to match gcc precisely (which is good for testing).

llvm-svn: 67676

 - -emit-llvm no longer changes what compilation steps are done.

 - -emit-llvm and -emit-llvm -S write output files with .o and .s
    suffixes, respectively.

 - <rdar://problem/6714125> clang-driver should support -O4 and -flto,
   like llvm-gcc

llvm-svn: 67645

conceivably handle, but are defaulting to not using clang for.

llvm-svn: 67641

 - Don't default to using clang for C++ (use -ccc-clang-cxx to
   override).

 - Default to only using clang on i386 and x86_64 (use
   -ccc-clang-archs "" to override).

 - <rdar://problem/6712350> [driver] clang should not be used on
   powerpc by default
 - <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx

I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.

This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.

llvm-svn: 67640

Driver::ShouldUseClangCompiler.
 - No functionality change.

llvm-svn: 67639

llvm-svn: 67529

llvm-svn: 67490

 - <rdar://problem/6669441> ccc doesn't handle assembler-with-cpp
   semantics correctly (but clang supports it)

 - This is sad, because it requires a fairly useless target
   hook. C'est la vie.

llvm-svn: 67418

diagnostics.
 - This ensures that the whole argument and values are printed,
   instead of just the option name.

llvm-svn: 67366

llvm-svn: 67362

testing) even with -pipe on.

llvm-svn: 67348

diagnostic (to suppress more generic unused warning).

llvm-svn: 67294

are forwarded to GCC.
 - The later is unfortunate, as it prevents us from generally warning
   about anything interesting on platforms that use a generic
   toolchain. However, we can't do much better without significantly
   complicating things, and generally we should have proper tool chain
   definitions.

llvm-svn: 67293

 - Make InputInfo a variant of filename, pipe, input argument,
   nothing.

 - Leave a FIXME in InputInfo that this should be revisited.

llvm-svn: 67292

driver is functional without them.

llvm-svn: 67254

sometimes leaves around.

llvm-svn: 67253

llvm-svn: 67248

if our usual methods fail. This isn't necessary for running the tool,
but improves the accuracy of logging output.

Also, have GCC tools lookup gcc program path.

llvm-svn: 67243

llvm-svn: 67241

programs.

llvm-svn: 67229

 - This is still suboptimal, but should at least be workable.

llvm-svn: 67223

llvm-svn: 67220

(brings code in line with diagnostic.

llvm-svn: 67217

llvm-svn: 67206

llvm-svn: 67204

llvm-svn: 67192

(e.g., -filelist) are currently broken.

llvm-svn: 67183

its commands).

llvm-svn: 67179