This GCC flag is useful when you want to control whether implicit
template instantiation occurs at the commandline level. Clang doesn't
currently support such controls, but technically *always* implicitly
instantiating (what Clang does, and what every other compiler still in
use does by default) is valid behavior even under
-fno-implicit-templates, it just may be slow and very wasteful. If
people really want this, we can try to implement it, but I don't have an
actual use.
This should help fix the build of libstdc++ with Clang, its build system
uses this flag.
llvm-svn: 193319
flag. We should probably wire at least some variants of this up to our
actual diagnostics engine, but I'm leaving that for someone else. This
fixes the builds of packages which hard code something here, at least
including libstdc++ itself.
llvm-svn: 193318
It is possible that we should say some of these are unsupported, but this is
not any worse than the old behavior of ignoring all unknown -f options.
llvm-svn: 191429
* 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
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
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
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
'-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
This was GCC's option to turn on UCN support, which we always have on now
in C99 and C++ modes.
Additionally, mark the -fno-extended-identifiers option as unsupported,
since we don't support disabling UCNs in C99 and C++ modes.
PR11538
llvm-svn: 174530
Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility)
to provide a way to enable the basic-block vectorization pass. This uses the same
acronym as gcc, superword-level parallelism (SLP), also common in the literature,
to refer to basic-block vectorization.
Nadav suggested this as a follow-up to the adding of -fvectorize.
llvm-svn: 169909
assembly.
By default, we don't emit IR for MS-style inline assembly (see r158833 as to
why). This is strictly for testing purposes and should not be enabled with the
expectation that things will work. This is a temporary flag and will be removed
once MS-style inline assembly is fully supported.
llvm-svn: 160573
This flag sets the 'fp-contract' mode, which controls the formation of fused
floating point operations. Available modes are:
- Fast: Form fused operations anywhere.
- On: Form fused operations where allowed by FP_CONTRACT. This is the default
mode.
- Off: Don't form fused operations (in future this may be relaxed to forming
fused operations where it can be proved that the result won't be
affected).
Currently clang doesn't support the FP_CONTRACT pragma, so the 'On' and 'Off'
modes are equivalent.
llvm-svn: 159794
matches GCC behavior which libstdc++ uses to limit #warning-based
messages about deprecation.
The machinery involves threading this through a new '-fdeprecated-macro'
flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We
turn the flag off in the driver when the warning is turned off (modulo
matching some GCC bugs). We record this as a language option, and key
the preprocessor on the option when introducing the define.
A separate flag rather than a '-D' flag allows us to properly represent
the difference between C and C++ builds (only C++ receives the define),
and it allows the specific behavior of following -Wdeprecated without
potentially impacting the set of user-provided macro flags.
llvm-svn: 130055
-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.
Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.
This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.
llvm-svn: 130051
'-fasm' and explicitly map from that flag to -fgnu-keywords in the driver. Turn
off the driver in the lexer test for this madness and add a test to the driver
that the translation actually works.
llvm-svn: 104428
Chandler Carruth