Functions with an explicit exception specification have their behavior
dictated by the specification. The additional /EHc behavior only comes
into play if no exception specification is given.
llvm-svn: 262198
Like cl.exe, clang-cl allows adding system include directories via the
INCLUDE env var. Having a driver flag for this functionality is useful,
so add this too.
(In the future, we probably also want to have a flag alternative to
VCINSTALLDIR as used in MSVCToolChain::getVisualStudioBinaries(), and
a way to override the registry accesses in MSVCToolChain::getWindowsSDKDir()
-- maybe -ivcroot= and -iwinsdkroot=?).
llvm-svn: 260990
Previously LLVM could not process any debug info we produced, so it
didn't make sense to spend time generating it. Now that it has primitive
support for local variable info, it does make sense to generate normal
debug info.
llvm-svn: 260435
Microsoft's documentation states that specifying
/Oy- after the /O[12x] options disables frame-pointer omission.
What it does *not* state is that it also disables frame-pointer omission
if /Oy- is specified before /O[12x].
llvm-svn: 258447
The /Brepro flag controls whether or not the compiler should embed
timestamps into the object file. Object files which do not embed
timestamps are not suitable for incremental linking but are suitable for
hermetic build systems and staged self-hosts of clang.
A normal clang spelling of this flag has been added,
-mincremental-linker-compatible.
llvm-svn: 256204
The documentation suggests /Wall should really turn on -Wextra and any
other warnings that are not enabled by default. That would correspond
to Clang's -Weverything, but is probably not what users want.
llvm-svn: 255524
There's no way to make a flag alias to two flags, so add a /WCL4 flag that
maps to the All, Extra diag groups. Fixes PR25563.
http://reviews.llvm.org/D15350
llvm-svn: 255382
These are enabled by default in clang-cl, because the whole idea is that
it should work like cl.exe, but I suppose it can make sense to disable
them if someone wants to compile code in a more strict mode.
llvm-svn: 249775
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
The default target is ARM on the ARM self host bots. This is problematic since
the behaviour on x86, x64 is different from ARM. Explicitly pass the target.
This should hopefully fix the ARM bots.
llvm-svn: 249229
LLVM r217812 made it so that clang-cl implicitly creates bigobj files when
needed, independent of this flag. It looks like cl has this flag to produce obj
flags compatible with MSVS 2003's linker by default, something we don't care
about. Since clang-cl always has /bigobj behavior, don't warn that the flag is
unused, just ignore it silently.
llvm-svn: 248034
cl uses 'CL' and '_CL_' to prepend and append command line options to
the given argument vector. There is an additional quirk whereby '#' is
transformed into '='.
Differential Revision: http://reviews.llvm.org/D11896
llvm-svn: 244473
Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
llvm-svn: 244097
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
This hooks up the /fp options as aliases for -f[no-]fast-math and
-f[no]-trapping-math. It probably doesn't match cl.exe's behaviour
completely (e.g. LLVM is currently never as precise as /fp:precise),
but it's close enough.
Differential revision: http://reviews.llvm.org/D8909
llvm-svn: 234449
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
N.B. CodeGen support is still ongoing.
llvm-svn: 232906
While it's true that we don't create the PDB as requested on the command
line, this is a well-documented limitation. Warning about it doesn't
help people using legacy build systems with clang-cl, and it makes the
clang-cl self-host very noisy.
llvm-svn: 230527
This is typically used to suppress warnings about calling snprintf and
other "deprecated" POSIX functions. Accepting this flag helps avoid tons
of useless warnings when trying out clang-cl on a new project.
Patch by Scott Graham!
llvm-svn: 229583
The /volatile:ms semantics turn volatile loads and stores into atomic
acquire and release operations. This distinction is important because
volatile memory operations do not form a happens-before relationship
with non-atomic memory. This means that a volatile store is not
sufficient for implementing a mutex unlock routine.
Differential Revision: http://reviews.llvm.org/D7580
llvm-svn: 229082
* /Zc:trigraphs and /Zc:trigraphs- are now honored
* /Zc:strictStrings is now honored
* /Zc:auto is now honored/ignored (clang does the Right Thing for this already)
Also add a dedicated test for the various /Zc: flags.
clang-cl doesn't always agree with cl.exe on the default values for /Zc flags.
For example, I think clang always behaves as if /Zc:inline is passed, and
warns if the user explicitly passes /Zc:inline-
Fixes PR21974.
llvm-svn: 224791
CL's /Zp flag is analogous to GCC's -fpack-struct, it controls the
default maximum alignment of records.
Differential Revision: http://reviews.llvm.org/D4671
llvm-svn: 213958
David Majnemer