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
Summary:
-iframework option is used to specified System framework path so the
path specified should be passed to linker as -F option
rdar://problem/18234544
Reviewers: bob.wilson
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7106
llvm-svn: 228413
After r228258, Clang started emitting C++ EH IR that LLVM wasn't ready
to deal with, even when exceptions were disabled with /EHs-. This time,
make /EHs- turn off -fexceptions while still emitting exceptional
constructs in functions using __try. Since Sema rejects C++ exception
handling constructs before CodeGen, landingpads should only appear in
such functions as the result of a __try.
llvm-svn: 228329
In r227480, Ulrich Weigand introduced a workaround for a linker
optimization bug that can create mis-optimized code for accesses to
general-dynamic or local-dynamic TLS variables. The linker
optimization bug only occurred for Clang/LLVM because of some
inefficient code being generated for these TLS accesses. I have
recently corrected LLVM to produce the efficient code sequence
expected by the linkers, so this workaround is no longer needed.
Therefore this patch reverts r227480.
I've tested that the previous bootstrap failure no longer occurs with
the workaround reverted.
llvm-svn: 228253
Previously, we would use a frame pointer by default on non-Linux OSs. On
Linux, any optimization flags imply -fomit-frame-pointer. XCore always
defaulted to -fomit-frame-pointer.
Now x86 Windows matches our behavior on Linux. All other ISAs supported
by Windows (ARM, x64) use xdata information, and frame pointers aren't
useful. Frame pointers are now off by default for such targets, but can
be forced via -fno-omit-frame-pointer and code using alloca().
In fact, on Win64 our frame-pointer prologue is not describable with
UNWIND_INFO. This change is a workaround to avoid using the broken FP
using prologue for most functions. This is PR22467.
llvm-svn: 228236
Appends the username to the first component (after the temp dir) of the
module cache path. If the username contains a character that shouldn't
go into a path (for now conservatively allow [a-zA-Z0-9_]), we fallback
to the user id.
llvm-svn: 228013
-save-temps=cwd is equivalent to -save-temps
-save-temps=obj saves temporary file in the same directory as output
This helps to avoid clobbering of temp files in case of parallel
compilation with -save-temps of the files that have the same name
but located in different directories.
Patch by Artem Belevich
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D7304
llvm-svn: 227886
Summary:
The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling
exceptions.
This commit makes clang add the -fno-rtti by default on the PS4, unless
-frtti was passed in.
It also diagnoses misuses for the PS4:
- Exceptions need rtti. Warn and enable rtti if no rtti flag was passed,
error if -fno-rtti was passed.
I also added a more general warning for when -fno-rtti is the default
(currently it's only on the PS4) and the vptr sanitizer is on.
Fixed a few tests, due to different flag order when passing cc1 arguments.
Reviewers: chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7250
llvm-svn: 227518
Work around a bug in GNU ld (and gold) linker versions up to 2.25
that may mis-optimize code generated by this version of clang/LLVM
to access general-dynamic or local-dynamic TLS variables.
Bug is fixed here:
https://sourceware.org/ml/binutils/2015-01/msg00318.html
llvm-svn: 227480
Those used the old Big Endian support on ARM and don't need flags.
Refactor the logic in a separate common function, which also looks at
-march. Add corresponding logic for the Linux toolchain.
llvm-svn: 227393
Summary:
This was already done for the sanitizers, but it needs to be done for
the profile and builtin libs as well.
Reviewers: srhines, timmurray, eugenis, samsonov
Reviewed By: samsonov
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D7187
llvm-svn: 227392
This patch allows clang to have llvm reserve the x18
platform register on AArch64. FreeBSD will use this in the kernel for
per-cpu data but has no need to reserve this register in userland so
will need this flag to reserve it.
This uses llvm r226664 to allow this register to be reserved.
Patch by Andrew Turner.
llvm-svn: 227062
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.
Command line options:
-noop-insertion // Enable noop insertion.
-noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
-max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.
In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
-fdiversify
This is the clang part of the patch.
llvm part: D3392
http://reviews.llvm.org/D3393
Patch by Stephen Crane (@rinon)
llvm-svn: 225910
Allow blessed access to the symbol rewriter from the driver. Although the
symbol rewriter could be invoked through tools like opt and llc, it would not
accessible from the frontend. This allows us to read the rewrite map files in
the frontend rather than the backend and enable symbol rewriting for actually
performing the symbol interpositioning.
llvm-svn: 225504
It is somewhat common for CFLAGS to be used with .s files. We were
already ignoring -flto. This patch just does the same for -fno-lto.
llvm-svn: 225093
Unfortunately, MSVC does not indicate to the driver what target is being used.
This means that we cannot correctly select the target architecture for the
clang_rt component. This breaks down when targeting windows with the clang
driver as opposed to the clang-cl driver. This should fix the native ARM
buildbot tests.
llvm-svn: 225089
The logic for addSanitizerRTWindows was performing the same logical operation as
getCompilerRT, which was previously fully generalised for Linux and Windows.
This avoids having a duplication of the logic for building up the name of a
clang_rt component. This change does move the current limitation for Windows
into getArchNameForCompilerRTLib, where it is assumed that the architecture for
Windows is always i386.
llvm-svn: 225087
Unify the component handling for compiler-rt. The components are regularly
named, built up from:
${LIBRARY_PREFIX}clang_rt.${component}-${arch}[-${environment}]${LIBRARY_SUFFIX}
Unify the handling for all the various components, into a single path to link
against the various components in a number of places. This reduces duplication
of the clang_rt library name construction logic.
llvm-svn: 225013
Unlike Unices, Windows does not use a library prefix. Use the traditional
naming scheme even for Windows itanium environments. This makes the builtins
behave more like the sanitisers as well.
llvm-svn: 224996
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
llvm-svn: 224790
This reapplies r224503 along with a fix for compiling Fortran by having the
clang driver invoke gcc (see r224546, where it was reverted). I have added
a testcase for that as well.
Original commit message:
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
llvm-svn: 224688
This reverts commit r224503.
It broke compilation of fortran through the Clang driver. Previously
`clang -c t.f` would invoke `gcc t.f` and `clang -cc1as`, but now it
tries to call `clang -cc1 t.f` which fails for obvious reasons.
llvm-svn: 224546
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
llvm-svn: 224503
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
llvm-svn: 224375
can change the backend to be the same default. Leave the
modified/new testcases with the exception of the default behavior
since it increases our testing footprint.
llvm-svn: 223976
This reverts commit r223455. It's been succesfully argued that
-fexceptions (at the driver level) is a misnomer and has little to do
with -fobjc-exceptions.
llvm-svn: 223723
Clang attempted to replicate a GCC bug: -fobjc-exceptions forces
-fexceptions to be enabled. However, this has unintended effects and
other awkard side effects that Clang doesn't "correctly" ape (e.g. it's
impossible to turn off C++ exceptions in ObjC++ mode).
Instead, -f[no]objc-exceptions and -f[no]cxx-exceptions now have an
identical relationship with -f[no]exceptions.
llvm-svn: 223455
No functionality change is intended, just a cleanup of the logic clang
uses to determine what -fexceptions/-fno-exceptions ends up doing.
llvm-svn: 223453
I added this check a while back but then made a note to myself that it
should be completely unnecessary since iOS always uses PIC code-gen for
aarch64. Since I could never come up with any reason why it would be
necessary, I'm just going to remove it and we'll see if anything breaks.
rdar://problem/13627985
llvm-svn: 223097
Using lld on Windows requires calling link-lld.exe instead of
lld.exe. This patch puts this knowledge into clang so that when
using the GCC style clang driver, it can properly delegate to
lld.
Differential Revision: http://reviews.llvm.org/D6428
Reviewed by: Reid Kleckner, Rui Ueyama
llvm-svn: 223086
Add neon-vfpv3 to allow specifying both at the same time. This is not an
option that GCC supports, but follows the same track and should be
non-controversial.
Change-Id: Id9ec157c835937d7d11ad0f49dbe5171fac17658
llvm-svn: 222933
In particular, make SanitizerArgs responsible for parsing
and passing down to frontend -fsanitize-recover and
-fsanitize-undefined-trap-on-error flags.
Simplify parsing -f(no-)sanitize= flags parsing: get rid of
too complex filterUnsupportedKinds function.
No functionality change.
llvm-svn: 222105
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
This change removes libclang_rt.profile-pic-<arch>.a version of
profile runtime. Instead, it's sufficient to always build
libclang_rt.profile-<arch>.a with -fPIC, as it can be linked into
both executables and shared objects.
llvm-svn: 221952
Darwin's "-arch arm64" option implies full Cyclone CPU, for both architectural
and tuning purposes. So if neither of the explicit options have been given,
forward that on to the proper invocation.
rdar://problem/18906227
llvm-svn: 221631
If clang was configured with a custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the equivalent configure command), the path to the custom gcc toolchain path takes precedence to the one specified by -ccc-install-dir. This causes several regression tests to fail as they will be using an unexpected path. Adding the switch --gcc-toolchain="" in each test command is not enough as the hexagon toolchain implementation in the driver is not evaluating this argument. This commit modifies the hexagon toolchain to take the --gcc-toolchain="" argument into account when deciding the toolchain path, similarly to what is already done for other targets toolchains. Additionally, the faulty regression tests are modified in order to --gcc-toolchain="" be passed to the commands.
llvm-svn: 221535
This CPU definition is redundant. The Cortex-A9 is defined as
supporting multiprocessing extensions. Remove references to this CPU.
This CPU was recently removed from LLVM. See http://reviews.llvm.org/D6057
Change-Id: I62ae7cc656fcae54fbaefc4b6976e77e694a8678
llvm-svn: 221458
The command line options are specified in a space-separated list that is an
argument to -dwarf-debug-flags, so that breaks if there are spaces in the
options. This feature came from Apple's internal version of GCC, so I went back
to check how llvm-gcc handled this and matched that behavior.
rdar://problem/18775420
llvm-svn: 221309
'char' is unsigned on all ARM and Thumb architectures. Clang gets this
right for ARM, and for thumb when using and arm triple and the -mthumb
option, but gets it wrong for thumb triples. This fixes that.
llvm-svn: 220555
This is a very basic toolchain. It supports cross-compiling Windows (primarily
inspired by the WoA target). It is meant to use clang with the LLVM IAS and a
binutils ld-compatible interface for the linker (eventually to be lld). It does
not perform any "standard" GCC lookup, nor does it perform any special
adjustments given that it is expected to be used in an environment where the
user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK.
The primary runtime library is expected to be compiler-rt and the C++
implementation to be libc++.
It also expects that a sysroot has been setup given the usual Unix semantics
(standard C headers in /usr/include, all the import libraries available in
/usr/lib). It also expects that an entry point stub is present in /usr/lib
(crtbegin.obj for executables, crtbeginS.obj for shared libraries).
The entry point stub is responsible for running any GNU constructors.
llvm-svn: 220546
This is a sad thing to do, but all the alternatives look ugly.
Looks like there are legitimate cases when users may want to link
with sanitizer runtimes *and* -nodefaultlibs (and ensure they provide
replacements for system libraries). For example, this happens in libc++
test suite.
"-nodefaultlibs" is told to link only the libraries explicitly provided
by the user, and providing "-fsanitize=address" is a clear indication of
intention to link with ASan runtime.
We can't easily introduce analogue of "-print-libgcc-name": linking with
sanitizers runtimes is not trivial: some runtimes are split into several
archive libraries, which are required to be wrapped in
-whole-archive/-no-whole-archive.
If "-fsanitize=whatever" and "-nodefaultlibs" are provided, system library
dependencies of sanitizer runtimes (-lc/-ldl/-lpthread/-lrt) will *not* be
linked, and user would have to link them in manually. Note that this can
cause problems, as failing to provide "-lrt" might lead to crashes in runtime
during ASan initialization. But looks like we should bite this bullet.
See r218541 review thread for the discussion.
llvm-svn: 220455
When a user has not configured a standard Visual Studio environment
by running vcvarsall, clang tries its best to find Visual Studio
include files and executables anyway. This patch makes clang also
try to find system and Windows SDK libraries for linking against,
as well.
Reviewed by: Hans Wennborg
Differential Revision: http://reviews.llvm.org/D5873
llvm-svn: 220425
This resubmits change r220226. That change broke the chromium
build bots because chromium it ships an hermetic MSVC toolchain
that it expects clang to fallback to by finding it on the path.
This patch fixes the issue by bumping up the prioritization of PATH
when looking for MSVC binaries.
Reviewed by: Hans Wennborg, Reid Kleckner
Differential Revision: http://reviews.llvm.org/D5892
llvm-svn: 220424
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
-g1 on gcc (and also IBM's xlc) are documented to be very similar to
-gline-tables-only. Our -gline-tables-only might still be more verbose than -g1
on other compilers, but currently we treat -g1 as -g, and so we're producing
much more debug info at -g1 than everybody else. Treating -g1 as
-gline-tables-only brings us much closer to what everyone else is doing.
For more information, see the discussion on
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039649.html
llvm-svn: 220311
In environments where PATH was set to point to the VS installation, Clang would
override that by looking in the registry and finding the latest VS installation.
If the environment is set up to point to a VS installation, that should take
precedence.
Reverting this until we can fix it.
llvm-svn: 220243
List the module cache we use for crashdumps as a tempfile. This
simplifies how we pick up this directory when generating the actual
crash diagnostic and removes some duplicate logic.
llvm-svn: 220241
Typically clang finds Visual Studio by the user explicitly setting
up a Visual Studio environment via vcvarsall. But we still try to
behave intelligently and fallback to different methods of finding
Visual Studio when this is not done. This patch improves various
fallback codepaths to make Visual Studio locating more robust.
Specifically, this patch:
* Adds support for searching environment variables for VS 12.0
* Correctly locates include folders for Windows SDK 8.x (this was
previously broken, and would cause clang to error)
* Prefers locating link.exe in the same location as cl.exe. This
is helpful in case another link.exe is in the path earlier than
Visual Studio (e.g. GnuWin32)
* Minor cleanup in the registry reading code to make it more
robust in the presence of long pathnames.
llvm-svn: 220226
Some early revisions of the Cortex-A53 have an erratum (835769) whereby it is
possible for a 64-bit multiply-accumulate instruction in AArch64 state to
generate an incorrect result. The details are quite complex and hard to
determine statically, since branches in the code may exist in some
circumstances, but all cases end with a memory (load, store, or prefetch)
instruction followed immediately by the multiply-accumulate operation.
The safest work-around for this issue is to make the compiler avoid emitting
multiply-accumulate instructions immediately after memory instructions and the
simplest way to do this is to insert a NOP.
This patch implements clang options to enable this workaround in the backend.
The work-around code generation is not enabled by default.
llvm-svn: 219604
Looks like llvm::sys::path::filename() was canonicalizing my paths
before emitting them for FileCheck to stumble over.
Fix a style nit with r219460 while I'm at it.
llvm-svn: 219464
When building with coverage, -no-integrated-as, and -c, the driver was
emitting -cc1 -coverage-file pointing at a file in /tmp. Ensure the
coverage file is emitted in the same directory as the output file.
llvm-svn: 219460
Summary: The changes introduced in the above two commits are giving
a rough time to one of the build bots. Reverting the changes for the
moment so that the bot can go green again.
Change-Id: Id19f6cb2a8bc292631fac2262268927563d820c2
llvm-svn: 218970
The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.
llvm-svn: 218748
being on by default. -fno-cxx-modules can still be used to enable C modules but
not C++ modules, but C++ modules is not significantly less stable than C
modules any more.
Also remove some of the scare words from the modules documentation. We're
certainly not going to remove modules support (though we might change the
interface), and it works well enough to bootstrap and build lots of
non-trivial code.
Note that this does not represent a commitment to the current interface nor
implementation, and we still intend to follow whatever direction the C and C++
committees take regarding modules support.
llvm-svn: 218717
It makes no sense to link in sanitizer runtimes in this case: the user
probably doesn't want to see any system/toolchain libs in his link if he
provides these flags, and the link will most likely fail anyway - as sanitizer
runtimes depend on libpthread, libdl, libc etc.
Also, see discussion in https://code.google.com/p/address-sanitizer/issues/detail?id=344
llvm-svn: 218541
Translate -lfoo to -lfoo.lib while making sure that -lfoo.lib stays as
-lfoo.lib. Also, these arguments were being passed twice: once
explicitly via AddAllArgs, and again implicitly as linker inputs. Now
they are passed once.
Fixes PR20868.
llvm-svn: 217895
Change 1: we used to add static sanitizer runtimes at the
very beginning of the linker invocation, even before crtbegin.o, which
is gross and not correct in general. Fix this: now addSanitizerRuntimes()
adds all sanitizer-related link flags to the end of the linker invocation
being constructed. It means, that we should call this function in the
correct place, namely, before AddLinkerInputs() to make sure sanitizer
versions of library functions will be preferred.
Change 2: Put system libraries sanitizer libraries depend on at the
end of the linker invocation, where all the rest system libraries are
located. Respect --nodefaultlibs and --nostdlib flags. This is another way
to fix PR15823. Original fix landed in r215940 put "-lpthread" and friends
immediately after static ASan runtime, before the user linker inputs.
This caused significant slowdown in dynamic linker for large binaries
linked against thousands of shared objects. Instead, to mark system
libraries as DT_NEEDED we prepend them with "--no-as-needed" flag,
discarding the "-Wl,--as-needed" flag that could be provided by the user.
Otherwise, this change is a code cleanup. Instead of having a special method
for each sanitizer, we introduce a function collectSanitizerRuntimes() that
analyzes -fsanitize= flags and returns the set of static and shared
libraries that needs to be linked.
llvm-svn: 217817
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.
Patch by Martell Malone!
Reviewed By: asl, rnk
Differential Revision: http://reviews.llvm.org/D3419
llvm-svn: 217790
It turned out that we have to bridge more stuff between the executable
and the ASan RTL DLL than just __asan_option_detect_stack_use_after_return.
See PR20918 for more details.
llvm-svn: 217673
r216662 changed the default ABI for 32-bit ARM targets to be "aapcs"
when no environment is given in the triple, however NetBSD requires it
to be "apcs-gnu".
llvm-svn: 217141
With this patch we call external tools for powerpc-darwin with "-arch ppc"
instead of "-arch powerpc", so as to be compatible with the cctools assembler
and ld64 linker.
Patch by Stephen Drake!
llvm-svn: 216687
The current default abi when no environment is given is "apcs-gnu",
which is obsolete. This patch changes the default to "aapcs". "aapcs" has both
hard- and soft-float variants, so the -mhard-float, -msoft-float and
-mfloat-abi= options now all behave as expected when no environment is
specified in the triple.
While writing this I also noticed that a preprocessor test claims to be
checking darwin, but is actually checking the defaults, which are
different for darwin.
llvm-svn: 216662
ACLE 2.0 allows __fp16 to be used as a function argument or return
type. This enables this for AArch64.
This also fixes an existing bug that causes clang to not allow
homogeneous floating-point aggregates with a base type of __fp16. This
is valid for AAPCS64, but not for AAPCS-VFP.
llvm-svn: 216558
There is no reason to have different library names for shared and static
cases on linux. It also breaks Android where we install the shared asan-rt
library into the system and should keep the old name.
This change reverts most of r216380 limiting it to win32 targets only.
llvm-svn: 216533
With this patch, "check-asan" passes all the tests with both MT and MD ASan RTL if you set COMPILER_RT_BUILD_SHARED_ASAN to ON
(PR20214)
llvm-svn: 216447
1. Always put static sanitizer runtimes to the front of the linker
invocation line. This was already done for all sanitizers except UBSan:
in case user provides static libstdc++ we need to make sure that new/delete
operator definitions are picked from sanitizer runtimes instead of libstdc++.
We have to put UBSan runtime first for similar reasons: it depends on some
libstdc++ parts (e.g. __dynamic_cast function), and has to go first in
link line to ensure these functions will be picked up from libstdc++.
2. Put sanitizer libraries system dependencies (-ldl, -lpthread etc.) right
after sanitizer runtimes. This will ensure these libraries participate in
the link even if user provided -Wl,-as-needed flag. This should fix PR15823.
3. In case we link in several sanitizer runtimes (e.g. "ubsan", "ubsan_cxx"
and "san"), add system dependencies (-ldl, -lpthread, ...) only once.
llvm-svn: 215940
of MIPS toolchains.
The uCLibc implemented for multiple architectures. A couple of MIPS toolchains
contains both uCLibc and glibc implementation so these options allow to select
used C library.
Initially -muclibc / -mglibc (as well as -mbionic) have been implemented in gcc
for various architectures so they are not MIPS specific.
llvm-svn: 215552
Rather than silently disabling unaligned accesses for v6m targets as
in the previous patch to llvm, instead produce a warning saying that
this architecture doesn't support unaligned accesses.
Patch by Ben Foster
llvm-svn: 215531
Summary:
Just like with -finput-charset=UTF-8 in review http://reviews.llvm.org/D4347, I think we should just ignore it when UTF-8 is provided.
Reviewers: rnk, rafael
Reviewed By: rafael
Subscribers: rafael, cfe-commits
Differential Revision: http://reviews.llvm.org/D4841
llvm-svn: 215368
Summary:
This flag can be used to force linking of CXX-specific parts
of sanitizer runtimes into the final executable. It gives more precise
control than --driver-mode=g++ and comes handy when user links several
object files with sanitized C++ code into an executable, but wants
to provide libstdc++ himself, instead of relying on Clang dirver's
behavior.
Test Plan: clang regression test suite
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4824
llvm-svn: 215252
It wasn't actually a bug that -mabicalls/-mno-abicalls wasn't being passed to
GAS. The only reason we pass it to the integrated assembler is because it shares
the same framework with CodeGen.
llvm-svn: 215236
Also added the testcase that should have been in r215194.
This behaviour has surprised me a few times now. The problem is that the
generated MipsSubtarget::ParseSubtargetFeatures() contains code like this:
if ((Bits & Mips::FeatureABICalls) != 0) IsABICalls = true;
so '-abicalls' means 'leave it at the default' and '+abicalls' means 'set it to
true'. In this case, (and the similar -modd-spreg case) I'd like the code to be
IsABICalls = (Bits & Mips::FeatureABICalls) != 0;
or possibly:
if ((Bits & Mips::FeatureABICalls) != 0)
IsABICalls = true;
else
IsABICalls = false;
and preferably arrange for 'Bits & Mips::FeatureABICalls' to be true by default
(on some triples).
llvm-svn: 215211
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
llvm-svn: 215046
to instruct the code generator to not enforce a higher alignment
than the given number (of bytes) when accessing memory via an opaque
pointer or reference. Patch reviewed by John McCall (with post-commit
review pending). rdar://16254558
llvm-svn: 214911
This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).
llvm-svn: 214752
That reduces a number of `if` operators and prevent a combinatorics explosion
if/when more dynamic linker path variants added.
No functional changes.
llvm-svn: 214712
Build systems tend to traffic in files and modification times, so having
them touch a file at the beginning of the build can be easier than
having them update the compile command they use every time they build.
llvm-svn: 214577
The -mstrict-align option was originally added in r167619 as a target-
independent option. It was then changed in r167623 to be implemented with an
ARM-specific backend option, even though the code remained in the
target-independent Clang::ConstructJob function. This means that if you used
the -mstrict-align option with a non-ARM target, you would still get the
-arm-strict-align option getting passed to the backend, which was harmless
but gross. The driver option was then replaced by the GCC-compatible
-m[no-]unaligned-access option (r189175) and modified to work with AArch64
(r208075). However, in the process, the help text for -mstrict-align was
incorrectly changed to show it as only being supported for AArch64. Even worse,
the logic for handling these options together with -mkernel was wrong for
AArch64, where -mkernel does not currently imply strict alignment.
This patch fixes up all of those things. Besides the obvious change to the
option help text, it moves the logic into the ARM and AArch64-specific parts
of the driver, so that the option will be correctly ignored for non-ARM
targets. <rdar://problem/17823697>
llvm-svn: 214148
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
llvm-svn: 214074
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
Both /showIncludes and /E write to stdout. Allowing both results
in interleaved output and an error when double-closing the file
descriptor, intended to catch issues like this.
llvm-svn: 213589
1. Revert "Add default feature for CPUs on AArch64 target in Clang"
at r210625. Then, all enabled feature will by passed explicitly by
-target-feature in -cc1 option.
2. Get "-mfpu" deprecated.
3. Implement support of "-march". Usage is:
-march=armv8-a+[no]feature
For instance, "-march=armv8-a+neon+crc+nocrypto". Here "armv8-a" is
necessary, and CPU names are not acceptable. Candidate features are
fp, neon, crc and crypto. Where conflicting feature modifiers are
specified, the right-most feature is used.
4. Implement support of "-mtune". Usage is:
-march=CPU_NAME
For instance, "-march=cortex-a57". This option will ONLY get
micro-architectural feature enabled specifying to target CPU,
like "+zcm" and "+zcz" for cyclone. Any architectural features
WON'T be modified.
5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is
an alias to "-march={feature of CPU_NAME}+[no]feature" and
"-mtune=CPU_NAME" together. Where this option is used in conjunction
with -march or -mtune, those options take precedence over the
appropriate part of this option.
llvm-svn: 213353
Summary:
With this patch (and a corresponding LLVM patch), assembling an empty file with
GCC and Clang -fintegrated-as produce near identical objects. The remaining
differences are:
* GCC/GAS produce objects have a .pdr section
* GCC/GAS produce objects have a .gnu.attributes section
Other differences are insignificant such as precise file offsets and the order
of strings in the string table.
Differential Revision: http://reviews.llvm.org/D4531
llvm-svn: 213241
however certain sloppy Makefiles pass -z options directly to
the compiler. This patch enables clang to recognize these
options (because -z is not used by clang itself).
llvm-svn: 213198
Summary:
As a result of this patch, assembling an empty file with GCC and Clang (using
GAS as the assembler) now produces identical objects.
-mfp32/-mfpxx/-mfp64 now form a trinity of options. -mfpxx is the default
when the triple vendor is 'img' or 'mti', the ABI is O32, and the CPU is
between mips2 and mips32r2/mips64r2 (inclusive).
-mno-shared is always given to the assembler to match the effect of
-mabicalls (currently unimplemented but Clang acts as if it is given).
Similarly, -call_nonpic is always given to match the effect of -mplt (also
unimplemented and acts as if given) except when the ABI is 64 in which case
-mplt has no effect so -KPIC is given instead.
-mhard-float/-msoft-float are now passed on.
-modd-spreg/-mno-odd-spreg are now passed on.
-mno-mips16 is correctly passed on. The assembler option is -no-mips16 not
-mno-mips16
Differential Revision: http://reviews.llvm.org/D4515
llvm-svn: 213138
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
llvm-svn: 213119
Summary:
This implements the -arch flag for both x86 and x86-64 by letting
them affect the default target features we pass to cc1. -m machine
flags will override the features set by -arch.
Reviewers: hansw
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4519
llvm-svn: 213083
Returns a warning when using an unknown optimization flag.
This patch includes -finline-limit as one of those ignored flags.
More options will be moved in this group
Patch by Arthur Marble <arthur@info9.net> in the context of
Debian Google Summer of code 2014.
Reviewers: rnk, Sylvestre
llvm-svn: 212805
This patch flips the default value for -gcolumn-info to be on by
default. I discussed the rationale and provided compile/size data
in:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/074290.html
This also updates the documentation and some tests that relied on
the lack of column information. Some tests had column information
in the expected output, but it was wrong (the tsan tests). Others
were using the driver to execute.
llvm-svn: 212781
Summary:
* Support the multilib layout used by the mips-img-linux-gnu
* Recognize mips{,64}{,el}-img-linux-gnu as being aliases of mips-img-linux-gnu
* Use the correct dynamic linker for mips-img-linux-gnu
* Make mips32r6/mips64r6 the default CPU for mips-img-linux-gnu
Subscribers: mpf
Differential Revision: http://reviews.llvm.org/D4436
llvm-svn: 212719
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
Currently, we fail with an error.
Reviewers: rafael
Reviewed By: rafael
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D4347
llvm-svn: 212110
command line option only. Internally we convert them to the "o32" and "n64"
respectively. So we do not need to refer them anywhere after that conversion.
No functional changes.
llvm-svn: 212096
It used to be a feature of UBSan (it could sanitize a standalone
shared object instead of the whole program), but now it causes
more problems, like PR20165.
llvm-svn: 212064
It reverts commits as follows:
r211866: "Driver: use GNU::Link for the Generic_GCC toolchain"
r211895: "Replace GetProgramPath("ld") with GetLinkerPath()."
r211995: "Driver: add a cygwin linker tool"
llvm-svn: 211998
This adds a linker tool for the Windows cygwin environment. This linker
invocation is significantly different from the generic ld invocation. It
requires additional parameters as well as does not accept some normal
parameters. This should fix self-hosting on Cygwin.
llvm-svn: 211995
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
This changes the behaviour of the driver for linking to match that of the
Generic_GCC::Assemble. The default link should use "ld" rather than "gcc" for
the linker as gcc does. This avoids the unnecessary round-tripping through gcc.
It also is much more reasonable behaviour from the user's perspective. This
should have been updated with SVN r195554 which changed the behaviour of
Generic_GCC::Assemble.
The gcc_forward test needs to be updated to mark the fact that -march is a flag
for GCC not ld. This was updated as a typo fix, but added a check for a flag
that is not a link flag.
The bindings test covers the change for testing, and thus no new test was added.
llvm-svn: 211866
The Command will refer back to the Tool as its source,
so it has to outlive the Command.
Having the Tool on the stack would cause us to crash
when using "clang-cl -GR -fallback", because if the
Command fails, Driver::ExecuteCompilation tries to
peek at the Command's source.
Differential Revision: http://reviews.llvm.org/D4314
llvm-svn: 211802
This commit implements the -fuse-ld= option, so that the user
can specify -fuse-ld=bfd to use ld.bfd.
This commit re-applies r194328 with some test case changes.
It seems that r194328 was breaking macosx or mingw build
because clang can't find ld.bfd or ld.gold in the given sysroot.
We should use -B to specify the executable search path instead.
Patch originally by David Chisnall.
llvm-svn: 211785
Summary:
The BSDs and Darwin all forward the whole 'u' group, but gcc only
forwards -u so far as I can tell. I only forward -u, since that's a
minimal change, and many people object to magically recognizing and
forwarding linker arguments.
Reviewers: chandlerc, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4304
llvm-svn: 211756
Summary:
The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or
is the default). It remains ld.so.1 for other cases.
This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008.
Differential Revision: http://reviews.llvm.org/D4273
llvm-svn: 211598
It's more flexible and arguably better layering to set flags to modify
compiling for diagnostics in the CC1 job themselves, rather than
tweaking the driver flags and letting them propagate.
There is one visible change this causes: crash report files will now
get preprocessed names (.i and friends).
llvm-svn: 211411
On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name
instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version).
This fixes the clang driver to pass the appropriate -dynamic-linker
setting, and adds some more tests to linux-ld.c.
llvm-svn: 211360
This mirrors the GCC option for the ARM backend. This option enables the
backend option "-enable-arm-long-calls". The default behaviour is that this is
disabled due to the slight overhead of the generated calls.
If the target of jumps are greater than 64M range of offset-based jumps, then
the target address must be loaded into a register to make an indirect jump. The
backend support for this has been present, but was not previously controllable
by the proper flag.
llvm-svn: 210398
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
llvm-svn: 210293
library. That results in the linker resolving all references to weak symbols in
the DSO to the definition from within that DSO. Ironically, this rarely causes
observable problems, except that it causes ubsan's own dynamic type check to
spuriously fail (because we fail to properly merge type_info object names).
llvm-svn: 210220
Summary:
These two flags are in the same family as -Rpass, but are used in
different situations.
-Rpass-missed is used by optimizers to inform the user when they tried
to apply an optimization but couldn't (or wouldn't).
-Rpass-analysis is used by optimizers to report analysis results back
to the user (e.g., why the transformation could not be applied).
Depends on D3682.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3683
llvm-svn: 209839
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
Call it "libclang_rt.builtins-<arch>.a" to be consistent
with sanitizers/profile libraries naming. Modify Makefile
and CMake build systems and Clang driver accordingly.
Fixes PR19822.
llvm-svn: 209474
Windows on ARM expects ARMv8 (restricted IT) conditional instructions only.
Force enable the restricted IT mode via the backend option when targeting WoA.
llvm-svn: 209086
If `-shared` is specified, pull in a PIC-version of the profile runtime,
which was added to compiler-rt in r208947. I'm hoping this will get the
bots on my side.
llvm-svn: 208948
`clang -S -o - file.c -masm=att` will write assembly to stdout in at&t syntax
(the default), `-masm=intel` will instead output intel style asm.
llvm-svn: 208683
asan_cxx containts replacements for new/delete operators, and should
only be linked in C++ mode. We plan to start building this part
with exception support to make new more standard-compliant.
See https://code.google.com/p/address-sanitizer/issues/detail?id=295
for more details.
llvm-svn: 208610
Summary: The initial support for NaN2008 was added to the back-end in r206396.
Reviewers: atanasyan
Reviewed By: atanasyan
Differential Revision: http://reviews.llvm.org/D3448
llvm-svn: 208220
Don't bother with keeping the old support for x86_64 in 6.99.23+, just
use a single range. Update test cases for the always-on --eh-frame-hdr.
llvm-svn: 208170
After this patch clang will ignore -fdwarf2-cfi-asm and -ffno-dwarf2-cfi-asm and
always print assembly that uses cfi directives.
In llvm, MC itself supports cfi since the end of 2010 (support started
in r119972, is reported in the 2.9 release notes).
In binutils the support has been around for much longer. It looks like
support started to be added in May 2003. It is available in 2.15
(31-Aug-2011, 2.14 is from 12-Jun-2003).
llvm-svn: 207602
Summary:
This patch adds a new flag -Rpass=. The flag indicates the name
of the optimization pass that should emit remarks stating when it
made a transformation to the code.
This implements the design I proposed in:
https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing
Other changes:
- Add DiagnosticIDs::isRemark(). Use it in printDiagnosticOptions to
print "-R" instead of "-W" in the diagnostic message.
- In BackendConsumer::OptimizationRemarkHandler, get a SourceLocation
object out of the file name, line and column number. Use that location
in the call to Diags.Report().
- When -Rpass is used without debug info a note is emitted alerting
the user that they need to use -gline-tables-only -gcolumn-info to
get this information.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3226
llvm-svn: 206401
This introduces the definitions needed for the Windows on ARM target. Add
target definitions for both the MSVC environment and the MSVC + Itanium C++ ABI
environment. The Visual Studio definitions correspond to the definitions
provided by Visual Studio 2012.
llvm-svn: 205650
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012). I've moved the logic to IRGen,
where it should have been in the first place.
I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.
I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.
<rdar://problem/16458307>
llvm-svn: 205023
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.
Patch by Zinovy Nis!
Differential Revision: http://llvm-reviews.chandlerc.com/D3114
llvm-svn: 204742
This is because the PCH is tied to the module files, if one of the module files changes or gets removed
the build system should re-build the PCH file.
rdar://16321245
llvm-svn: 203885
When enabled, always validate the system headers when loading a module.
The end result of this is that when these headers change, we will notice
and rebuild the module.
llvm-svn: 203630
Generating RTTI in the MS ABI is currently not supported, and the failures
are confusing to users, so let's disable it by default for now.
llvm-svn: 202178
The integrated assembler is a feature. This makes the new flags the default
option, and the previous versions aliases. Ideally, at some point the aliases
would be entirely removed.
llvm-svn: 201963
Forward the -no-integrated-as option to -cc1 rather than simply invoking the
appropriate tool. This is useful since this option has been overloaded to
permit disabling of parsing inline assembly at the MC layer.
This re-applies the previous version of the patch with a renaming of the driver
option to the public name rather than the internal name (-target vs -triple).
The actual failure is fixed separately of an overly aggressive negative pattern
match in the MIPS driver tests. It also fixes the incorrect test for targets
that have the integrated assembler disabled by default.
llvm-svn: 201960
Forward the -no-integrated-as option to -cc1 rather than simply invoking the
appropriate tool. This is useful since this option has been overloaded to
permit disabling of parsing inline assembly at the MC layer.
llvm-svn: 201952
Added two new options for -mfpu when targetting ARM:
* fpv4-sp-d16
* fp4-sp-d16
The first is the same spelling as gcc.
The lack of a leading `v' is correct, this is consistent with ARM's
documentation and gcc's spelling of the option.
llvm-svn: 201846
This commit is not strictly correct nor accounts for all uses (shared
objects, for example), but it allows one to test the compiler-rt library
on GNU targets.
Using this patch to run the test-suite has already shown me problems
on ARM. Since this is a Darwin-only flag, nobody is using it, so it
shouldn't be a problem.
I will need extension to deal with the shared cases, but since we're
not compiling libclang_rt.so, that's not yet applicable. Many other
problems will have to be fixed first in compiler-rt (such as removing
the 'arch' name from it and making it trully multi-arch, moving it to
the default lib directory, make both .a and .so variants, etc).
llvm-svn: 201307
These features are new in VS 2013 and are necessary in order to layout
std::ostream correctly. Currently we have an ABI incompatibility when
self-hosting with the 2013 stdlib in our convertible_fwd_ostream wrapper
in gtest.
This change adds another implicit attribute, MSVtorDispAttr, because
implicit attributes are currently the best way to make sure the
information stays on class templates through instantiation.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2746
llvm-svn: 201274
the build
When Clang loads the module, it verifies the user source files that the module
was built from. If any file was changed, the module is rebuilt. There are two
problems with this:
1. correctness: we don't verify system files (there are too many of them, and
stat'ing all of them would take a lot of time);
2. performance: the same module file is verified again and again during a
single build.
This change allows the build system to optimize source file verification. The
idea is based on the fact that while the project is being built, the source
files don't change. This allows us to verify the module only once during a
single build session. The build system passes a flag,
-fbuild-session-timestamp=, to inform Clang of the time when the build started.
The build system also requests to enable this feature by passing
-fmodules-validate-once-per-build-session. If these flags are not passed, the
behavior is not changed. When Clang verifies the module the first time, it
writes out a timestamp file. Then, when Clang loads the module the second
time, it finds a timestamp file, so it can compare the verification timestamp
of the module with the time when the build started. If the verification
timestamp is too old, the module is verified again, and the timestamp file is
updated.
llvm-svn: 201224
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.
This reverts r201203 (i.e. re-applying r201202 with small fixes in
unittests/CMakeLists.txtto make the build bots happy).
review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201205
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.
review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201202
These flags control the inheritance model initially used by the
translation unit.
Differential Revision: http://llvm-reviews.chandlerc.com/D2741
llvm-svn: 201175
This option has the following effects:
* It adds the sspstrong IR attribute to each function within the CU.
* It defines the macro __SSP_STRONG__ with the value of 2.
Differential Revision: http://llvm-reviews.chandlerc.com/D2717
llvm-svn: 201120
hack of passing -fconst-strings to -cc1"
Passing or not a language option based on diagnostic settings is a bad idea, it breaks
using a PCH that was compiled with different diagnostic settings.
Also add a test case to make sure we don't regress.
llvm-svn: 200964
Use the verify hook rather than the compile hook to represent the
-verify-pch action, and move the exising --verify-debug-info action
into its own subclass of VerifyJobAction. Incidentally change the name
printed by -ccc-print-phases for --verify-debug-info.
llvm-svn: 200938
This option will:
- load the given pch file
- verify it is not out of date by stat'ing dependencies, and
- return 0 on success and non-zero on error
llvm-svn: 200884
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
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
The original idea was to implement it all on the driver, but to do that the
driver needs to know the sse level and to do that it has to know the default
features of a cpu.
Benjamin Kramer pointed out that if one day we decide to implement support for
' __attribute__ ((__target__ ("arch=core2")))', then the frontend needs to
keep its knowledge of default features of a cpu.
To avoid duplicating which part of clang handles default cpu features,
it is probably better to handle -mfpmath in the frontend.
For ARM this patch is just a small improvement. Instead of a cpu list, we
check if neon is enabled, which allows us to reject things like
-mcpu=cortex-a9 -mfpu=vfp -mfpmath=neon
For X86, since LLVM doesn't support an independent ssefp feature, we just
make sure the selected -mfpmath matches the sse level.
llvm-svn: 188939
This moves the logic for handling -mfoo -mno-foo from the driver to -cc1. It
also changes -cc1 to apply the options in order, fixing pr16943.
The handling of -mno-mmx -msse is now an explicit special case.
llvm-svn: 188817
AFAIK, there are no -W options for gcc-as and gcc-ld.
It caused failure to build clang with gcc-4.7 on cygwin.
FIXME: Could we recategorize Options for gcc-as and gcc-ld?
llvm-svn: 188668
Summary:
This change turns SanitizerArgs into high-level options
stored in the Driver, which are parsed lazily. This fixes an issue of multiple copies of the same diagnostic message produced by sanitizer arguments parser.
Reviewers: rsmith
Reviewed By: rsmith
CC: chandlerc, eugenis, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1341
llvm-svn: 188660
This updates clang according to a pending patch for llvm to
rename of the -arm-darwin-use-movt to arm-use-movt to make
it available for all of ARM.
note: please apply this close to the llvm change.
Patch by Jeroen Hofstee.
llvm-svn: 188488
This adds support for the /link option, which forwards
subsequent arguments to the linker.
The test for this will only work when targetting win32.
Since that's the only target where clang-cl makes sense,
use that target by default.
Differential Revision: http://llvm-reviews.chandlerc.com/D1388
llvm-svn: 188331
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
This patch adds -mmsa and -mno-msa to the options supported by
clang to enable and disable support for MSA.
When MSA is enabled, a predefined macro '__mips_msa' is defined to 1.
Patch by Daniel Sanders
llvm-svn: 188184
This option prints information about #included files to stderr. Clang could
already do it, this patch just teaches the existing code about the /showIncludes
style and adds the flag.
Differential Revision: http://llvm-reviews.chandlerc.com/D1333
llvm-svn: 188037
This reverts commit r187991 and adjusts the comment. /Za is much more
involved, and we don't want to give anyone the impression we actually
support it.
llvm-svn: 187998
'-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
These flags set some preprocessor macros and injects a dependency
on the runtime library into the object file, which later is picked up
by the linker.
This also adds a new CC1 flag for adding a dependent library.
Differential Revision: http://llvm-reviews.chandlerc.com/D1315
llvm-svn: 187945
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D966
llvm-svn: 187925
> This adds a bunch of options to clang-cl. Notably, this includes
> all the options that get passed when doing a default build of a
> command-line project with msbuild.exe in Debug and Release modes,
> and I believe all flags from Reid's original patch.
The original commit was reverted in r187640 after it broke the Mac build.
This should now be fixed, by Clang r187668, LLVM r187675, and putting
a -- before %s in the test.
llvm-svn: 187679
It broke the "phase1 - sanity" buildbot. Reverting until
we can figure out what's going on.
And Eric says it broke all current Mac builds actually.
llvm-svn: 187640
This adds a bunch of options to clang-cl. Notably, this includes
all the options that get passed when doing a default build of a
command-line project with msbuild.exe in Debug and Release modes,
and I believe all flags from Reid's original patch.
Differential Revision: http://llvm-reviews.chandlerc.com/D1264
llvm-svn: 187637
Patch by Ana Pazos
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
llvm-svn: 187568
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
llvm-svn: 187180
They seemed to have the same implications, and this makes for one
less flag to worry about.
Differential Revision: http://llvm-reviews.chandlerc.com/D1219
llvm-svn: 187168
Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)
I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.
llvm-svn: 187156
and add a new option --driver-mode= to control it explicitly.
The CCCIsCXX and CCCIsCPP flags were non-overlapping, i.e. there
are currently really three modes that Clang can run in: gcc, g++
or cpp, so it makes sense to represent them as an enum.
Having a command line flag to control it helps testing.
llvm-svn: 186605
When the -maltivec flag is present, altivec.h is auto-included for the
compilation. This is not appropriate when the job action is to
preprocess a file containing assembly code. So don't do that.
I was unable to convert the test in the bug report into a regression
test. The original symptom was exposed with:
% touch x.S
% ./bin/clang -target powerpc64-unknown-linux-gnu -maltivec -S -o - x.S
I tried this test (and numerous variants) on a PPC64 system:
----------------------------------------------------------------------------
// RUN: touch %t
// RUN: %clang -maltivec -S %t -o - | FileCheck %s
// Verify that assembling an empty file does not auto-include altivec.h.
// CHECK-NOT: static vector
----------------------------------------------------------------------------
However, this test passes for some reason even on a clang built
without the fix. I'd be happy to add a test case but at this point
I'm not able to figure one out, and I don't want to hold up the patch
unnecessarily. Please let me know if you have ideas.
Thanks,
Bill
llvm-svn: 185544
Darwin systems currently do not support dwarf version 3 or above. When we are
ready, we can bump the default to gdwarf-4 for Darwin.
For other systems, the default is dwarf version 3, if everything goes smoothly,
we can bump the version to 4.
rdar://13591116
llvm-svn: 185483
when specifying --coverage (or related) flags.
The system for doing this was based on the old LLVM-hosted profile_rt
library, and hadn't been updated for Linux to use the new compiler-rt
library. Also, it couldn't possibly work on multiarch or biarch systems
in many cases. The whole thing now works much the same as the sanitizer
libraries that are built and used out of the compiler-rt repo.
Note that other target OSes haven't been updated because I don't know if
they're doing anything special with the installation path of profile_rt.
I suspect however that *all* of these are wrong and would encourage
maintainers of each target to take a hard look at how compiler-rt
runtime libraries are linked on their platforms.
llvm-svn: 184666
gcc's inputs are already added by the InputInfoList passed to
Action::ConstructJob.
Fixes a regression from r183989. This was manifesting when targetting
mingw as an extra input argument to gcc when assembling. It presumably
affects other situations where clang calls gcc.
Prior to r183989, forwardToGCC() was returning false because the INPUT
option defined in OptParser.td had the DriverOption flag set on it.
LLVM's Option library does not set this flag for INPUT.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D999
llvm-svn: 184308
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
llvm-svn: 184276
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere
As discussed in the review, this change includes using directives in
header files. I'll make follow up changes to remove those in favor of
name specifiers.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D975
llvm-svn: 183989
When choosing a default CPU, clang used to pick ARM7TDMI (which has Thumb) even
when the more restrictive armv4 triple was specified. This should fix that.
Patch by Jeroen Hofstee.
llvm-svn: 183905
integrated assembler then go ahead and still split the dwarf anyhow.
Add two tests, one to exercise existing behavior of not splitting
when we're just emitting assembly files and the other to test
that we split when we're not in integrated as mode.
llvm-svn: 183355
This option is used to select a dynamic loader prefix to be used
at runtime. Currently this is implemented for the Linux toolchain.
Differential Revision: http://llvm-reviews.chandlerc.com/D851
llvm-svn: 182744
If -fsanitize=leak is specified, link the program with the
LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified,
because AddressSanitizer has this functionality built in.
llvm-svn: 182729
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
llvm-svn: 182645
imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.
I've fixed this to follow the logic:
1) If the last dominating flag is -fno-math-errno, -ffast-math, or
-Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
math-errno.
3) Otherwise, use the toolchain default.
This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.
I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.
llvm-svn: 182203
This patch then adds all the usual platform-specific pieces for SystemZ:
driver support, basic target info, register names and constraints,
ABI info and vararg support. It also adds new tests to verify pre-defined
macros and inline asm, and updates a test for the minimum alignment change.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181211
We've added the RS880 variant in the LLVM backend to represent an R600
GPU with no vertex cache, so we need to update the GPU mappings for
-mcpu.
llvm-svn: 181202
The existing code also failed to allocate a buffer for it so getcwd corrupted
the stack. sys::fs::current_path takes care of the memory management.
llvm-svn: 180669
make the gdb tests and the Windows bots happy.
The Path::GetCurrentDirectory API is not equivalent to ::getcwd(), so
r180652 causes a gdb tests to fail. On the other hand, <sys/param.h>
isn't defined on Windows systems, so that causes Windows builds to fail.
rdar://12237559
llvm-svn: 180661
Specifically, allow the flags that fall under this umbrella (i.e., -O3,
-ffast-math, and -fstrict-aliasing) to be overridden/disabled with the
individual -O[0|1|2|s|z]/-fno- flags.
This also fixes the handling of various floating point optimization
flags that are modified by -ffast-math (and thus -Ofast as well).
Part of rdar://13622687
llvm-svn: 180204
- There is no reason to have a modules specific flag for disabling
autolinking. Instead, convert the existing flag into -fno-autolink (which
should cover other autolinking code generation paths like #pragmas if and
when we support them).
llvm-svn: 179612
two new options –msingle-float and –mdouble-float. These options can be
used simultaneously with float ABI selection options (-mfloat-abi,
-mhard-float, -msoft-float). They mark whether a floating-point
coprocessor supports double-precision operations.
llvm-svn: 179481
This new option is the default, but it is useful to have a flag to override
-mno-implicit-float by putting -mimplicit-float later on the command line.
llvm-svn: 179309
As mentioned in the previous commit message, the use-after-free and
double-free warnings for 'delete' are worth enabling even while the
leak warnings still have false positives.
llvm-svn: 178891
Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to
the actual type and 0, and are updated in EmitLValueForField.
Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar.
Added command line option -struct-path-tbaa.
llvm-svn: 178797
however, it doesn't do that unless we're optimizing. Change
that and haul out to a helper function. Also make this a driver
test appropriate rather than an assembly test.
llvm-svn: 178606
gcc provides -mmfcrf and -mno-mfcrf for controlling what we call
the mfocrf target feature. Also, PPC is now making use of the
static function AddTargetFeature used by the Mips Driver code.
llvm-svn: 178227
This option can be useful for end users who want to know why they
ended up with a ton of different variants of the "std" module in their
module cache. This problem should go away over time, as we reduce the
need for module variants, but it will never go away entirely.
llvm-svn: 178148
linker via --dynamic-list instead of using --export-dynamic. This reduces the
size of the dynamic symbol table, and thus of the binary (in some cases by up
to ~30%).
llvm-svn: 177783
We now put the Clang module cache in
<system-temp-directory>/org.llvm.clang/ModuleCache. Perhaps some day
there will be other caches under <system-temp-directory>/org.llvm.clang>.
llvm-svn: 177671
* libclang_rt-san-* is sanitizer_common, and is linked in only if no other
sanitizer runtime is present.
* libclang_rt-ubsan-* is the piece of the runtime which doesn't depend on
a C++ ABI library, and is always linked in.
* libclang_rt-ubsan_cxx-* is the piece of the runtime which depends on a
C++ ABI library, and is only linked in when linking a C++ binary.
This change also switches us to using -whole-archive for the ubsan runtime
(which is made possible by the above split), and switches us to only linking
the sanitizer runtime into the main binary and not into DSOs (which is made
possible by using -whole-archive).
The motivation for this is to only link a single copy of sanitizer_common
into any binary. This is becoming important now because we want to share
more state between multiple sanitizers in the same process (for instance,
we want a single shared output mutex).
The Darwin ubsan runtime is unchanged; because we use a DSO there, we don't
need this complexity.
llvm-svn: 177605
We were checking "Arch == llvm::Triple::x86_64 || Arch
== llvm::Triple::x86_64", but the rhs should actually check for
powerpc64.
Found while experimenting with a potential new Clang warning.
llvm-svn: 177496
Nico Weber