Use -no-struct-path-tbaa to turn it off.
This is the same as r191695, which was reverted because it depends on a
commit that has issues.
llvm-svn: 192497
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
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 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
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
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
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
* 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
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
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
clang already had a mstrict-align which mentiones "Force all memory
accesses to be aligned (ARM only)". On gcc arm this is controlled by
-munaligned-access / -mno-unaligned-access. Add the gcc versions to
the frontend and make -mstrict-align and alias to -mno-unaligned-access
and only show it in clang -cc1 -help.
Since the default value for unaligned accesses / strict alignment
depends on the tripple, both the enable and disable flags are added.
If both are set, the no-unaligned-access is used.
Patch by Jeroen Hofstee.
llvm-svn: 189175
This patch adds the -ffixed-r9 flag to clang to instruct llvm to
globally preserve the contents of r9. The flag is added to the newly
created ARM specific group.
While at it, also place marm / mno-thumb in that group.
Patch by Jeroen Hofstee.
llvm-svn: 189174
Joerg Sonnenberger