We were previously mostly passing it through, but -O0 and -O3 are not valid
options to cl.exe.
We should translate -O0 to /Od and -O3 to /Ox. -O{1,2,s} get passed through.
llvm-svn: 191323
This patch turns the -mv* hexagon options into aliases. We should really produce
errors for invalid versions in the driver, but this patch preserves the old
behavior for now.
llvm-svn: 191298
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
llvm-svn: 191283
gcc doesn't support "gcc -m sse" and this was not tested in clang and only
used for link argument on darwin, so this was very likely just a bug.
llvm-svn: 191251
This solves two problems:
1) MSBuild will not flag the build as unsuccessful just because we print
an error in the output, since "error(clang):" doesn't seem to match
the regex it's using.
2) It becomes more clear that the diagnostic is coming from clang as
supposed to cl.exe.
Differential Revision: http://llvm-reviews.chandlerc.com/D1735
llvm-svn: 191250
This doesn't change a lot since clang still thinks it knows all of the
-f*, -m* and -W* options for example.
Other than the options clang explicitly claims to know, this fixes pr9701.
llvm-svn: 191249
Summary:
We enable ASAN's use-after-return instrumentation at compile-time,
but still keep it disabled at run-time.
This enables the users to flip the flag at run-time using environment variable
ASAN_OPTIONS=detect_stack_use_after_return=1 instead of using a separate build.
If UAR detection is disabled at run-time, this extra compile-time instrumentation
costs very small slowdown. On SPEC 2006 14 tests are not affected at all,
4 tests get ~ 1% slowdown and 453.povray gets 4%.
Reviewers: samsonov
Reviewed By: samsonov
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1741
llvm-svn: 191186
This solves the problem of fallback onto ourselves if clang-cl
has been renamed to cl.exe and put on the PATH, as happens with
the VS integration.
Differential Revision: http://llvm-reviews.chandlerc.com/D1731
llvm-svn: 191099
Instead add the ASan runtime to the linker command line so that only the ASan API functions can be undefined in the target library.
Fixes http://llvm.org/bugs/show_bug.cgi?id=17275
llvm-svn: 191076
When this flag is enabled, clang-cl falls back to cl.exe if it
cannot compile the code itself for some reason.
The idea is to use this to help build projects that almost compile
with clang-cl, except for some files that can then be built with
the fallback mechanism.
Differential Revision: http://llvm-reviews.chandlerc.com/D1711
llvm-svn: 191034
I put in the warnings because MSVC has them, but I don't think they're very
useful.
Clang does not warn about overriding flags in general, e.g. it's perfectly
fine to have -fomit-frame-pointer followed by -fno-omit-frame-pointer.
We should focus on warning where things get confusing, such as with the
/TP and /TC options. In "clang-cl /TC a.c /TP b.cc", the user might not
realize that the /TP flag will apply to both files, and we warn about that.
Differential Revision: http://llvm-reviews.chandlerc.com/D1718
llvm-svn: 190964
as suggested by Jordan on IRC. Also, use the unqualified name
in Job.cpp.
And while we're here, refer to StringRef with the unqualified
name, because we have a using directive for that too.
llvm-svn: 190909
This will define _MSC_VER to 1700 by default and avoid linker errors
from /failifmismatch linker directives in the C++ standard headers.
Most people trying out the Visual Studio integration are using 2012,
since that's the only version that clang-format works with. This way
they don't have to pass funky -Xclang -fmsc-version=1700 flags just to
link against the standard C++ runtime.
llvm-svn: 190908
Seems like it was intentional to export ArgStringList as
driver::ArgStringList, and e.g. examples/clang-interpreter/main.cpp
uses it this way.
However, exporting it with a typedef seems like a more common way to do it.
llvm-svn: 190906
Previously we would warn about unused arguments such as /MD when linking.
Clang already has logic to ignore compile-only options, e.g. for -D and -U.
This patch extends that to include clang-cl's compile-only options too.
Also, some clang-cl options should always be ignored. Doing this earlier
means they get ignored both for compilation and link-only invocations.
llvm-svn: 190825
I think it makes sense that a Command knows how to execute itself.
There's no functionality change but i rewrote the code to avoid the manual
memory management of Argv.
My motivation for this is that I plan to subclass Command to build fall-back
functionality into clang-cl.
Differential Revision: http://llvm-reviews.chandlerc.com/D1654
llvm-svn: 190621
This moves the code to Job.cpp, which seems like a more natural fit,
and replaces the "is this a JobList? is this a Command?" logic with
a virtual function call.
It also removes the code duplication between PrintJob and
PrintDiagnosticJob and simplifies the code a little.
There's no functionality change here, except that the Executable is
now always printed within quotes, whereas it would previously not be
quoted in crash reports, which I think was a bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D1653
llvm-svn: 190620
Some build systems use pipes for stdin/stderr. On nix-ish platforms colored
output can be forced by -fcolor-diagnostics. On Windows this option has
no effect in these cases because LLVM uses the console API (which only
operates on the console buffer) even if a console wrapper capable of
interpreting ANSI escape codes is used.
The -fansi-escape-codes option allows switching from the console API to
ANSI escape codes. It has no effect on other platforms.
llvm-svn: 190464
This adds driver support for building DLLs (the /LD and /LDd flags).
It basically does two things: runtime selection and passing -dll and
-implib to the linker.
llvm-svn: 190428
I was going to update the comment referring to PipedJob, which was removed
some time ago, but then it turned out that this method is not actually used
at all.
llvm-svn: 190171
We already use .obj as extension when the user provides a stem file
name (via /Fo), but were failing in the most basic case when the file
name is based on the input file.
llvm-svn: 190071
* In C, as before, if the "warning flag" is enabled, warnings are produced by
forcing string literals to have const-qualified types (the produced warnings
are *not* -Wwrite-strings warnings). However, more recent GCCs (at least 4.4
onwards) now take -w into account here, so we now do the same.
* In C++, this flag is entirely sane: it behaves just like any other warning
flag. Stop triggering -fconst-strings here. This is a bit cleaner, but there's
no real functionality change except in the case where -Xclang -fno-const-strings
is also specified.
llvm-svn: 190006
* It was redundant with -flto.
* It was confusing since -uAnythingElse is a different option.
* GCC uses -fuse-linker-plugin, so it was not even a compatibility option.
llvm-svn: 189976
This never really worked. Even if we find and execute link.exe in the VS bin dir
this way, link.exe wouldn't find the DLLs it needs, libraries, etc.
It also causes trouble when the user has multiple versions of VS installed,
one of them is in the path, but this code finds the other one (PR17041).
Revert until we can fix this properly.
> Windows ToolChain: add VS bin dir to PogramPaths
>
> We have a lot of fancy logic to find Visual Studio, which is currently used
> to set the system header include paths.
>
> Use the same code to set the ProgramPaths, which is used for finding programs
> such as link.exe. Previously, Clang would just search PATH for link.exe,
> but now it should find it if it's able to find Visual Studio.
llvm-svn: 189661
Passing inconsistent munaligned-access / mno-unaligned-access
flags, intentionally resulted in a warning and the flag
no-unaligned-access being used.
Gcc does, at least in practice, use the last flag in such a
case. This patch updates clang behaviour accordingly; use the
last flag or base alignment behaviour on the target (which
llvm will do if no flag is explicitly passed)
Patch by Jeroen Hofstee.
llvm-svn: 189542
When sysroot is not set, look for libstdc++ first on the clang install
directory. Before this change if clang was installed alongside a gcc with
the same version as the system one we would select the system libstdc++.
Unfortunately this is hard to test as only the non-sysroot case is changed.
llvm-svn: 189536
As Chandler pointed out, we should not be using -backend-option because this
will cause crashes for users of the tooling interface, etc. A better way to fix
this will be to provide the unrolling pass-manager flag to the loop vectorizer
directly.
Original commit message:
Disable loop vectorizer unrolling when no unrolling requested
In addition to the regular loop unrolling transformation, the loop vectorizer
can also unroll loops. If no unrolling has specifically been requested (by
-fno-unroll-loops), and the loop vectorizer will be used, then add the backend
option to (also) prevent the loop vectorizer from unrolling loops.
I confirmed with Nadav (off list) that disabling vectorizer loop unrolling when
-fno-unroll-loops is provided is the desired behavior.
llvm-svn: 189441
In addition to the regular loop unrolling transformation, the loop vectorizer
can also unroll loops. If no unrolling has specifically been requested (by
-fno-unroll-loops), and the loop vectorizer will be used, then add the backend
option to (also) prevent the loop vectorizer from unrolling loops.
I confirmed with Nadav (off list) that disabling vectorizer loop unrolling when
-fno-unroll-loops is provided is the desired behavior.
llvm-svn: 189440
This exposes the -fsanitize=address option and adds the runtime library
to the link command.
Differential Revision: http://llvm-reviews.chandlerc.com/D1526
llvm-svn: 189389
We error on -O5 and higher. While it is tempting to do the same for -O4, I
agree with Jordan Rose: we should warn for a release at least first.
llvm-svn: 189369
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
Hans Wennborg