| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on
indirect function calls, using either the check mechanism (X86, ARM, AArch64) or
or the dispatch mechanism (X86-64). The check mechanism requires a new calling
convention for the supported targets. The dispatch mechanism adds the target as
an operand bundle, which is processed by SelectionDAG. Another pass
(CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as
required by /guard:cf. This feature is enabled using the `cfguard` CC1 option.
Reviewers: thakis, rnk, theraven, pcc
Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65761
|
|
|
|
| |
llvm-svn: 286324
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is adding command-line support for the MSVC buffer security check.
The buffer security check is turned on with the '/GS' compiler switch.
https://msdn.microsoft.com/en-us/library/8dbf701c.aspx
The MSVC buffer security check in implemented here:
http://reviews.llvm.org/D20346
Reviewers: hans, rnk
Subscribers: chrisha, cfe-commits, rnk, hans, thakis
Differential Revision: http://reviews.llvm.org/D20347
llvm-svn: 272832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC's driver accepts all unknown arguments but warns about them. clang
by default rejects all unknown arguments. This causes issues
specifically with build systems such as autoconf which liberally pass
things such as $LDFLAGS to the compiler and expect everything to work.
This patch teaches clang-cl to ignore unknown driver arguments.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16511
llvm-svn: 258720
|
|
|
|
|
|
|
| |
The /Oy- flag should have no effect for 64-bit X86, it has reliable
unwind tables.
llvm-svn: 245913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had multiple bugs here:
- We didn't support multiple optimization options in one argument.
e.g. -O2y-
- We didn't correctly expand -O[12dx] to their respective options.
- We treated -O1 as clang -O1 instead of clang -Os.
- We treated -Ox as clang -O3 instead of clang -O2. In fact, cl's -Ox
option is *less* powerful than cl's -O2 option despite -Ox described
as "Full Optimization".
This fixes PR24003.
llvm-svn: 243261
|
|
|
|
| |
llvm-svn: 243207
|
|
|
|
| |
llvm-svn: 242321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are slight differences between /GR- and -fno-rtti which made
mapping one to the other inappropriate.
-fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
information for the v-table.
/GR- does not generate complete object locators and thus will not
reference them in vftables. However, constructs like dynamic_cast and
typeid are permitted.
This should bring our implementation of RTTI up to semantic parity with
MSVC modulo bugs.
llvm-svn: 212138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't 100% compatible with MSVC, but it's close enough. MSVC's /EH
flag doesn't really control exceptions so much as how to clean up after
an exception is thrown. The upshot is that cl.exe /EHs- will compile
try, throw, and catch statements with a warning, but clang-cl will
reject such constructs with a hard error. We can't compile such EH
constructs anyway, but this may matter to consumers of the AST.
Reviewers: hans
Differential Revision: http://reviews.llvm.org/D4317
llvm-svn: 211909
|
|
|
|
|
|
|
| |
None of our tests use /fallback, so this lets us gradually add RTTI
support without breaking projects using /fallback.
llvm-svn: 208787
|
|
|
|
|
|
| |
We would previously hit an assert if using /fallback with an .ll file.
llvm-svn: 207234
|
|
|
|
|
|
| |
Note that /Gy no longer implies -fdata-sections.
llvm-svn: 205716
|
|
|
|
| |
llvm-svn: 204723
|
|
|
|
|
|
|
| |
Clang itself only emits CodeView line tables, so it seems more
consistent to ask cl.exe for the same format.
llvm-svn: 201721
|
|
|
|
| |
llvm-svn: 201626
|
|
|
|
|
|
| |
On machines that have cl.exe on PATH, the note will print the full path.
llvm-svn: 201613
|
|
|
|
|
|
| |
This makes it a lot easier to see what's going on from the output.
llvm-svn: 201604
|
|
|
|
|
|
| |
For example, don't fall back in /P (preprocess) mode.
llvm-svn: 199153
|
|
|
|
|
|
|
| |
We started parsing /FI in r191442, and now we can pass it on to the
fallback too.
llvm-svn: 191537
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 191316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
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
|