This is a simpler rule, broadly in line with previous Darwin (which chose
between "soft" and "softfp") but probably safer. In practice the only real
reason for "softfp" is ABI compatibility, not usually an issue on limited chips
like these, so anyone who wanted hard-float should already be saying so.
That's my story and I'm sticking to it.
rdar://problem/15887493
llvm-svn: 199896
Using backend-option like a few other debug codegen flags. I believe
Eric Christopher's working at porting those over to something nicer
such as an API level CodeGenOptions or the like, so this can be
improved along with that work.
llvm-svn: 199535
Previously we had bodged together some hacks mapping MachO embedded
targets (i.e. mainly ARM v6M and v7M) to the "*-*-darwin-eabi" triple.
This is incorrect in both details (they don't run Darwin and they're
not EABI in any real sense).
This commit appropriates the existing "MachO" environment for the
purpose instead.
llvm-svn: 199367
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
It controls everything that -flimit-debug-info used to, plus the
vtable type optimization. The old -fno-limit-debug-info option is now an
alias to -fstandalone-debug and vice versa.
Standalone is the default on Darwin until dtrace is updated to work with
non-standalone debug info (rdar://problem/15758808).
Note: I kept the LimitedDebugInfo name in CodeGenOptions::DebugInfoKind
because NoStandaloneDebugInfo sounded even more confusing.
llvm-svn: 198655
getARMCPU and getLLVMArchSuffixForARM existed as very similar functions
in both ToolChain.cpp and Tools.cpp. Create a single implementation of
each in Tools.cpp, eliminate the duplicate and share via Tools.h.
Creates an 'arm' namespace in Tools.h to be used by any ARM-targetting tools.
llvm-svn: 197153
Passing -mthumb with no explicit CPU on the command line
resulted in target CPU changing from the architecture
default to arm7tdmi. Now it does not.
llvm-svn: 197151
This refactors some of the Darwin toolchain classification to give a more solid
distinction between the three primary Darwin platforms (OS X, IOS and IOS
simulator) so that a 4th choice can be added temporarily: embedded MachO
targets.
Longer term, this support will be factored out into a separate class and no
longer classified as "darwin-eabi", but the refactoring should still be useful.
llvm-svn: 197148
- krait processor currently modeled with the same features as A9.
- Krait processor additionally has VFP4 (fused multiply add/sub)
and hardware division features enabled.
- krait has currently the same Schedule model as A9
- krait cpu flag is not recognized by the GNU assembler yet,
it is replaced with march=armv7-a to avoid a lower march
from being used.
llvm-svn: 196618
I happened to notice this while trying to write a test for an iOS simulator
target. I suspect we just missed this when we added separate "macosx" and "ios"
triples instead of the generic "darwin" OS.
llvm-svn: 196527
Clang still has support for running gcc for performing various stages
of a build. Right now it looks like this is used for
* Supporting Fortran in the clang driver
* Running an assembler or linker in systems we don't yet know how to
run them directly.
It looks like the gcc::Precompile is a vestige from the days when we
supported using clang for C and running gcc for c++. This patch removes it
(yes, we have no tests for it).
llvm-svn: 195586
Clang knows how to use the gnu assembler directly from doing so on linux and
hurd. The existing support worked out of the box on cygwin and mingw and I was
able to bootstrap clang with it in both systems (with pending patches for the
new mingw abi, but that is independent of the assembler).
llvm-svn: 195554
We are still using Dwarf Version 2 for Darwin systems, make it consistent
with -gline-tables-only.
This should fix an internal buildbot.
llvm-svn: 195267
should be isolated in the backend (r195123). From the frontend point
of view in case of "-mhard-float -mips16" combination of flags the float
ABI mode should remain unchanged.
The patch reviewed by Reed Kotler.
llvm-svn: 195124
the -Q flag to the as(1) assembler driver.
We will soon be switching the darwin as(1) assembler driver to call clang(1)
and use the intergated assembler by default. To do this and still support
clang(1)'s -no-integrated-as flag, when clang(1) runs the as(1) assembler
driver and -no-integrated-as is used it needs to pass the -Q flag to as(1)
so it uses its GNU based assembler, and not turn around and call clag(1)'s
integrated assembler.
rdar://15495921
llvm-svn: 195054
This adds -freroll-loops (and -fno-reroll-loops in the usual way) to enable
loop rerolling as part of the optimization pass manager. This transformation
can enable vectorization, reduce code size (or both).
Briefly, loop rerolling can transform a loop like this:
for (int i = 0; i < 3200; i += 5) {
a[i] += alpha * b[i];
a[i + 1] += alpha * b[i + 1];
a[i + 2] += alpha * b[i + 2];
a[i + 3] += alpha * b[i + 3];
a[i + 4] += alpha * b[i + 4];
}
into this:
for (int i = 0; i < 3200; ++i) {
a[i] += alpha * b[i];
}
Loop rerolling is currently disabled by default at all optimization levels.
llvm-svn: 194967
Teach the '-arch' command line option to enable the compiler-friendly
features of core-avx2 CPUs on Darwin. Pass the information along in the
target triple like Darwin+ARM does.
llvm-svn: 194907
Trying to fix test failures since earlier today.
One of the tests added in this commit is outputting test/Driver/clang_f_opts.s
which the builders that build in-tree (eg. clang-native-arm-cortex-a9) are
trying to run as a test case, causing failures.
clang_f_opts.c:
If -### doesn't emit the warning then this test probably shouldn't be in
here in the first place. Frontend maybe?
invalid-o-level.c:
Running %clang_cc1 in the Driver tests doesn't make sense because -cc1
bypasses the driver. (I'm not reverting the commit that introduced this but
please fix instead of keeping it this way.)
Reverting to fix the build failures and also so that the tests can be thought
out more thoroughly.
This reverts commit r194817.
llvm-svn: 194845
This options accepts a path to a directory, collects the filenames of the files
it contains, and the migrator will only modify files with the same filename.
llvm-svn: 194710
This adds a new option -fprofile-sample-use=filename to Clang. It
tells the driver to schedule the SampleProfileLoader pass and passes
on the name of the profile file to use.
llvm-svn: 194567
Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'
With the patch:
$ clang -O20 foo.c
warning: invalid value '20' in '-O20'. Fall back on value '3'
Reviewers: rengolin, hfinkel
Reviewed By: rengolin
CC: cfe-commits, hfinkel, rengolin
Differential Revision: http://llvm-reviews.chandlerc.com/D2125
llvm-svn: 194403
hack of passing -fconst-strings to -cc1, but at least the driver uses
the regular warning checking code path.
Since we don't support a warning that is DefaultIgnore in one language
but not in another, this patch creates a dummy C only warning in the same
group as the existing one to get the desired effect.
llvm-svn: 194097
The thread, memory, dataflow and function sanitizers are now diagnosed if
enabled explicitly on an unsupported platform. Unsupported sanitizers which
are enabled implicitly (as part of a larger group) are silently disabled. As a
side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus
essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain.
Differential Revision: http://llvm-reviews.chandlerc.com/D1990
llvm-svn: 193875
Enables the clang driver to begin targeting specific CPUs. Introduced a
"generic" CPU which will ensure that the optional FP feature is enabled
by default when it gets to LLVM, without needing any extra arguments.
Cortex-A53 and A-57 are also introduced with tests, although backend
handling of them does not yet exist.
llvm-svn: 193740
Although we wire up a bit for v8fp for macro setting
purposes, we don't set a macro yet. Need to ask list
about that.
Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0
llvm-svn: 193367
Adds some Cortex-A53 strings where they were missing before.
Cortex-A57 is entirely new to clang.
Doesn't touch code only used by Darwin, in consequence of which
one of the A53 lines has been removed.
Change-Id: I5edb58f6eae93947334787e26a8772c736de6483
llvm-svn: 193364
These options specify 64-bit FP registers and 32-bit FP registers respectively.
When using -mfp32, the FPU has 16x double-precision registers overlapping with
the 32x single-precision registers (each double-precision register overlaps
two single-precision registers).
When using -mfp64, the FPU has 32x double-precision registers overlapping with
the 32x single-precision registers (each double-precision register overlaps
with one single-precision register and has an additional 32-bits).
MSA requires -mfp64.
llvm-svn: 192899
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
Evgeniy Stepanov