Also add some documentation.

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

llvm-svn: 188403

Otherwise it lists all files (e.g. shared libraries) that happen to be in the
same paths the GCC installations usually reside in.

On a x86_64 Debian 7 system with i386 multilibs.
before: clang -v 2>&1|wc -l
        3059
after:  clang -v 2>&1|wc -l
        10

llvm-svn: 188400

llvm-svn: 188353

The rationale for this change is to differentiate following two situations:
  1) clang -c -emit-llvm a.c
  2) clang -c -flto a.c 

Reviewed by Eric Christopher. Thanks a lot!

llvm-svn: 188352

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

llvm-svn: 188346

This adds support for the /link option, which forwards
subsequent arguments to the linker.

The test for this will only work when targetting win32.
Since that's the only target where clang-cl makes sense,
use that target by default.

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

llvm-svn: 188331

llvm-svn: 188325

Anything that comes after -- is treated as an input file. This
used to be handled automagically by the option parsing library,
but after LLVM r188314, we should handle it ourselves.

No functionality change.

llvm-svn: 188316

We used to decide whether to really vectorize depending on the optimization
level in PassManagerBuilder.

This patch moves this decision to the clang driver. We look at the optimization
level and whether the f(no-)vectorize is set and decide whether to vectorize.

This allows us to simplify the logic in PassManagerBuilder to just a check for
whether the vectorizer should run or not.

We now do the right thing for:
$ clang -O1 -fvectorize
$ clang -fno-vectorize -O3

llvm-svn: 188280

llvm-svn: 188258

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

llvm-svn: 188226

This is used to name the linked output file.

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

llvm-svn: 188210

llvm-svn: 188190

This patch adds -mmsa and -mno-msa to the options supported by 
clang to enable and disable support for MSA.

When MSA is enabled, a predefined macro '__mips_msa' is defined to 1.

Patch by Daniel Sanders

llvm-svn: 188184

llvm-svn: 188128

Since r187945, clang-cl will add the runtime library dependency to
the .obj file.

llvm-svn: 188086

No functionality change.

llvm-svn: 188084

llvm-svn: 188068

llvm-svn: 188058

This option prints information about #included files to stderr. Clang could
already do it, this patch just teaches the existing code about the /showIncludes
style and adds the flag.

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

llvm-svn: 188037

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

llvm-svn: 188000

This reverts commit r187991 and adjusts the comment.  /Za is much more
involved, and we don't want to give anyone the impression we actually
support it.

llvm-svn: 187998

The /Za flag should probably do more, but let's start with this.

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

llvm-svn: 187991

llvm-svn: 187977

llvm-svn: 187972

'-fno-unroll-loops'. The option to the backend is even called
'DisableUnrollLoops'. This is precisely the form that Clang *didn't*
support. We didn't recognize the flag, we didn't pass it to the CC1
layer, and even if we did we wouldn't use it. Clang only inspected the
positive form of the flag, and only did so to enable loop unrolling when
the optimization level wasn't high enough. This only occurs for an
optimization level that even has a chance of running the loop unroller
when optimizing for size.

This commit wires up the 'no' variant, and switches the code to actually
follow the standard flag pattern of using the last flag and allowing
a flag in either direction to override the default.

I think this is still wrong. I don't know why we disable the loop
unroller entirely *from Clang* when optimizing for size, as the loop
unrolling pass *already has special logic* for the case where the
function is attributed as optimized for size! We should really be
trusting that. Maybe in a follow-up patch, I don't really want to change
behavior here.

llvm-svn: 187969

These flags set some preprocessor macros and injects a dependency
on the runtime library into the object file, which later is picked up
by the linker.

This also adds a new CC1 flag for adding a dependent library.

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

llvm-svn: 187945

DataFlowSanitizer is a generalised dynamic data flow analysis.

Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own.  Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.

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

llvm-svn: 187925

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

llvm-svn: 187840

This implements support for the /Fo option, which is used
to set the filename or output dir for object files.

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

llvm-svn: 187820

These are used to specify source files, and whether to treat source
files as C or C++.

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

llvm-svn: 187760

This patch was created by Lawrence Crowl and reviewed in:
http://llvm-reviews.chandlerc.com/D963

llvm-svn: 187738

Related to <rdar://problem/14578094>.

llvm-svn: 187680

> This adds a bunch of options to clang-cl. Notably, this includes
> all the options that get passed when doing a default build of a
> command-line project with msbuild.exe in Debug and Release modes,
> and I believe all flags from Reid's original patch.

The original commit was reverted in r187640 after it broke the Mac build.

This should now be fixed, by Clang r187668, LLVM r187675, and putting
a -- before %s in the test.

llvm-svn: 187679

llvm-svn: 187654

It broke the "phase1 - sanity" buildbot. Reverting until
we can figure out what's going on.

And Eric says it broke all current Mac builds actually.

llvm-svn: 187640

This adds a bunch of options to clang-cl. Notably, this includes
all the options that get passed when doing a default build of a
command-line project with msbuild.exe in Debug and Release modes,
and I believe all flags from Reid's original patch.

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

llvm-svn: 187637

Revert "If -fslp-vectorize or -fno-slp-vectorize are given, honor this selection. If no flag is given, enable it for -O3."

This reverts commit r187630.

Looks like it is breaking the bots.

llvm-svn: 187633

If -fslp-vectorize or -fno-slp-vectorize are given, honor this selection. If no flag is given, enable it for -O3.

llvm-svn: 187630

llvm-svn: 187596