CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
llvm-svn: 239481
This matches the cl.exe behavior (tested with 18.00.31101). In order to
specify an output file for /P, use the /Fi option instead.
Differential Revision: http://reviews.llvm.org/D10313
llvm-svn: 239393
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
llvm-svn: 239388
Encoding the version into the triple will allow us to communicate to
LLVM what functions it can expect to depend upon in the implementation.
llvm-svn: 239273
Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9
layout for sparc (32bit), sparc (32bit) with lib64 multilib, and
sparc64.
The test cases added here also cover r239047, which fixed the linker
paths.
llvm-svn: 239154
The main effect of this is to fix anomalies where certain -mfpu options didn't
disable everything that they should causing strange behaviour when combined
with -mcpu or -march values that themselves enabled fpu subtarget features,
e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as
-mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled.
Invalid -mfpu options now also give an error, which is consistent with the
handling of the .fpu directive.
Differential Revision: http://reviews.llvm.org/D10239
llvm-svn: 239152
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
llvm-svn: 239059
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
getCanonicalArchName can return an empty string for an architecture
that is well-formed but meaningless. Use parseArch to determine if
it's actually valid or not.
Differential Revision: http://reviews.llvm.org/D10120
llvm-svn: 238553
This isn't an actual revert of r237769, it just restores the behavior of
the Clang driver prior to it while completely re-implementing how that
behavior works.
This also re-does the work of making the default OpenMP runtime
selectable at CMake (or configure) time to work in the way all of our
other such hooks do (config.h, configure and cmake hooks, etc.).
I've re-implemented how we manage the '-fopenmp' flagset in an important
way. Now, the "default" hook just makes '-fopenmp' equivalent to
'-fopenmp=<default>' rather than a separate special beast. Also, there
is an '-fno-openmp' flag which does the obvious thing. Also, the code is
shared between all the places to select a known OpenMP runtime and act
on it.
Finally, and most significantly, I've taught the driver to inspect the
selected runtime when choosing whether to propagate the '-fopenmp' flag
to the frontend in the CC1 commandline. Without this, it isn't possible
to use Clang with libgomp, even if you were happy with the serial,
boring way in which it worked previously (ignoring all #pragmas but
linking in the library to satisfy direct calls into the runtime).
While I'm here, I've gone ahead and sketched out a path for the future
name of LLVM's OpenMP runtime (libomp) and the legacy support for its
current name (libiomp5) in what seems a more reasonable way.
To re-enable LLVM's OpenMP runtime (which I think should wait until the
normal getting started instructions are a reasonable way for falks to
check out, build, and install Clang with the runtime) all that needs to
change is the default string in the CMakeLists.txt and configure.ac
file. No code changes necessary.
I also added a test for the driver's behavior around OpenMP since it was
*completely missing* previously. Makes it unsurprising that we got it
wrong.
llvm-svn: 238389
Using the target cpu to determine some behaviour is sprinkled in
several places in the driver, but in almost all the information that
is needed can be found in the triple. Restructure things so that the
triple is used, and the cpu is only used if the exact cpu name is
needed.
Also add a check that the -mcpu argument is valid, and correct the
-march argument checking so that it handles -march=native correctly. I
would have liked to move these checks into the computation of the
triple, but the triple is calculated several times in several places
and that would lead to multiple error messages for the same thing.
Differential Revision: http://reviews.llvm.org/D9879
llvm-svn: 237894
Don't print unused-argument warning for sanitizer-specific feature flag
if this sanitizer was eanbled, and later disabled in the command line.
For example, now:
clang -fsanitize=address -fsanitize-coverage=bb -fno-sanitize=address a.cc
doesn't print warning, but
clang -fsanitize-coverage=bb
does. Same holds for -fsanitize-address-field-padding= and
-fsanitize-memory-track-origins= flags.
Fixes PR23604.
llvm-svn: 237870
-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option that allows to override effect of -fopenmp and link libgomp library (if -fopenmp=libgomp is specified).
Differential Revision: http://reviews.llvm.org/D9736
llvm-svn: 237769
sys/time.h on Solaris (and possibly other systems) defines "SEC" as "1"
using a cpp macro. The result is that this fails to compile.
Fixes https://llvm.org/PR23482
llvm-svn: 237113
The MachO toolchain has an isTargetIOSBased method, but it isn't
virtual so it isn't very meaningful to call it. After thinking about
this, I guess that putting this logic in the MachO class is a bit of a
layering violation anyway. Do this more like how we handle
AddLinkRuntimeLibArgs instead.
llvm-svn: 237095
Compiler-rt's Profiling library isn't part of the stdlib, so -nostdlib
shouldn't prevent it from being linked. This makes Darwin behave like
other toolchains, and link in the profile runtime irrespective of
-nostdlib, since the resulting program can't be run unless you link
this.
I've also added a test to show that other toolchains already behave
like this.
llvm-svn: 237074
This is a starting point for using the TargetParser in Clang, in a simple
enough part of the code that can be used without disrupting the crazy
platform support that we need to be compatible with other toolchains.
Also adding a few FIXME on obvious places that need replacing, but those
cases will indeed break a few of the platform assumptions, as arch/cpu names
change multiple times in the driver.
Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since
-mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option
string is still supported as an alias to "neon".
llvm-svn: 236901
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
Patch by Gabor Ballabas.
llvm-svn: 236859
llvm::Triple::getARMCPUForArch now returns nullptr for invalid -march
values, instead of silently translating it to arm7tdmi. Use this to
give an error message, which is consistent with how gcc behaves.
Differential Revision: http://reviews.llvm.org/D9602
llvm-svn: 236846
Summary:
Possible coverage levels are:
* -fsanitize-coverage=func - function-level coverage
* -fsanitize-coverage=bb - basic-block-level coverage
* -fsanitize-coverage=edge - edge-level coverage
Extra features are:
* -fsanitize-coverage=indirect-calls - coverage for indirect calls
* -fsanitize-coverage=trace-bb - tracing for basic blocks
* -fsanitize-coverage=trace-cmp - tracing for cmp instructions
* -fsanitize-coverage=8bit-counters - frequency counters
Levels and features can be combined in comma-separated list, and
can be disabled by subsequent -fno-sanitize-coverage= flags, e.g.:
-fsanitize-coverage=bb,trace-bb,8bit-counters -fno-sanitize-coverage=trace-bb
is equivalient to:
-fsanitize-coverage=bb,8bit-counters
Original semantics of -fsanitize-coverage flag is preserved:
* -fsanitize-coverage=0 disables the coverage
* -fsanitize-coverage=1 is a synonym for -fsanitize-coverage=func
* -fsanitize-coverage=2 is a synonym for -fsanitize-coverage=bb
* -fsanitize-coverage=3 is a synonym for -fsanitize-coverage=edge
* -fsanitize-coverage=4 is a synonym for -fsanitize-coverage=edge,indirect-calls
Driver tries to diagnose invalid flag usage, in particular:
* At most one level (func,bb,edge) must be specified.
* "trace-bb" and "8bit-counters" features require some level to be specified.
See test case for more examples.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9577
llvm-svn: 236790
Summary:
The next step is to add user-friendly control over these options
to driver via -fsanitize-coverage= option.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9545
llvm-svn: 236756
This patch adds support for the z13 architecture type. For compatibility
with GCC, a pair of options -mvx / -mno-vx can be used to selectively
enable/disable use of the vector facility.
When the vector facility is present, we default to the new vector ABI.
This is characterized by two major differences:
- Vector types are passed/returned in vector registers
(except for unnamed arguments of a variable-argument list function).
- Vector types are at most 8-byte aligned.
The reason for the choice of 8-byte vector alignment is that the hardware
is able to efficiently load vectors at 8-byte alignment, and the ABI only
guarantees 8-byte alignment of the stack pointer, so requiring any higher
alignment for vectors would require dynamic stack re-alignment code.
However, for compatibility with old code that may use vector types, when
*not* using the vector facility, the old alignment rules (vector types
are naturally aligned) remain in use.
These alignment rules are not only implemented at the C language level,
but also at the LLVM IR level. This is done by selecting a different
DataLayout string depending on whether the vector ABI is in effect or not.
Based on a patch by Richard Sandiford.
llvm-svn: 236531
This change is the third of 3 patches to add support for specifying
the profile output from the command line via -fprofile-instr-generate=<path>,
where the specified output path/file will be overridden by the
LLVM_PROFILE_FILE environment variable.
This patch adds the necessary support to the clang frontend, and adds a
new test.
The compiler-rt and llvm parts are r236055 and r236288, respectively.
Patch by Teresa Johnson. Thanks!
llvm-svn: 236289
Embed UBSan runtime into TSan and MSan runtimes in the same as we do
in ASan. Extend UBSan test suite to also run tests for these
combinations.
llvm-svn: 235953
For now tsan_cxx and msan_cxx contain only operator new/delete
replacements. In the future, when we add support for running UBSan+TSan
and UBSan+MSan, they will also contain bits ubsan_cxx runtime.
llvm-svn: 235924
NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.
Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.
Differential Revision: http://reviews.llvm.org/D9260
llvm-svn: 235903
Before this patch, passing a non-existent absolute path to clang-cl would cause
stat'ing of impossible paths. For example, `clang-cl -c d:\adsfasdf.txt` would
cause a stat of
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIBd:\asdfadsf.cc
llvm-svn: 235787
Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc).
Note that despite its generic name, it *doesn't* do the right thing when
-emit-llvm (LLVM assembly) yet. I'll hook that up soon.
This doesn't really change the behaviour of the driver. The default is
still to preserve use-lists for `clang -emit-llvm` and `clang
-save-temps`, and nothing else. But it stops relying on global state
(and also is a nicer interface for hackers using `clang -cc1`).
llvm-svn: 234962
Change `clang` to set `-preserve-bc-uselistorder` for the driver options
`-emit-llvm` and `-save-temps`. The former is useful for reproducing
results from `clang` in `opt` or `llc`, while the latter prevents
`-save-temps` from affecting the output. This is part of PR5680.
`-preserve-bc-uselistorder=true` is currently on by default, but a
follow-up commit in LLVM will reverse it.
llvm-svn: 234920
This patch generates a warning for invalid combination of '-mnan' and
'-march' options, it properly sets NaN encoding for a given '-march',
and it passes a proper NaN encoding to the assembler.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D8170
llvm-svn: 234882
Follow-up to r234666. With this, the -m[no-]global-merge options
have the expected behavior. Previously, -mglobal-merge was ignored,
and there was no way of enabling the optimization.
llvm-svn: 234668
Summary:
tools::arm::getARMFloatABI() was falling back to guessing soft-float because
it wasn't seeing the GNUEABIHF environment from ComputeEffectivClangTriple
when it was called from gnutools::Assemble::ConstructJob.
Fix by using the effective clang triple in gnutools::Assemble, which now
matches the -triple flag used by cc1 and ClangAs jobs.
Reviewers: jvoung
Subscribers: rengolin, jfb, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D8902
llvm-svn: 234661
The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
generation in IR.
Note that this change does not actually enable the optimization for
any target. The reassociation optimization that this flag specifies
was implemented by http://reviews.llvm.org/D6334 :
http://llvm.org/viewvc/llvm-project?view=revision&revision=222510
Because the optimization is done in the backend rather than IR,
the backend must be modified to understand instruction-level
fast-math-flags or a new function-level attribute must be created.
Also note that -freciprocal-math is independent of any target-specific
usage of reciprocal estimate hardware instructions. That requires
its own flag ('-mrecip').
https://llvm.org/bugs/show_bug.cgi?id=20912
llvm-svn: 234493
Adds ARM Cortex-R4 and R4F support and tests in Clang. Though Cortex-R4
support was present, the support for hwdiv in thumb-mode was not defined
or tested properly. This has also been added.
llvm-svn: 234488
Currently if you use -mmacosx-version-min or -mios-version-min without
specifying a version number, clang silently sets the minimum version to
"0.0.0". This is almost certainly not what was intended, so it is better
to report it as an error. rdar://problem/20433945
llvm-svn: 234270
- Debian jessie will be released this month, add the next testing version to the list.
- RHEL7 was released last june.
- Ubuntu utopic was released last october, vivid will follow later this month.
llvm-svn: 234149
Original message:
Don't use unique section names by default if using the integrated as.
This saves some IO and ccache space by not creating long section names. It
should work with every ELF linker.
llvm-svn: 234143
This reverts commit r233398, bringing back 233393 now that LLVM is fixed.
Original message:
Don't use unique section names by default if using the integrated as.
This saves some IO and ccache space by not creating long section names. It
should work with every ELF linker.
llvm-svn: 234101
This uses the same class metadata currently used for virtual call and
cast checks.
The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr
flag has been renamed -fsanitize=cfi-vcall.
Differential Revision: http://reviews.llvm.org/D8756
llvm-svn: 233874
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change doesn't
modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8645
llvm-svn: 233860
The zEC12 provides the transactional-execution facility. This is exposed
to users via a set of builtin routines on other compilers. This patch
adds clang support to enable those builtins. In partciular, the patch:
- enables the transactional-execution feature by default on zEC12
- allows to override presence of that feature via the -mhtm/-mno-htm options
- adds a predefined macro __HTM__ if the feature is enabled
- adds support for the transactional-execution GCC builtins
- adds Sema checking to verify the __builtin_tabort abort code
- adds the s390intrin.h header file (for GCC compatibility)
- adds s390 sections to the htmintrin.h and htmxlintrin.h header files
Since this is first use of target-specific intrinsics on the platform,
the patch creates the include/clang/Basic/BuiltinsSystemZ.def file and
hooks it up in TargetBuiltins.h and lib/Basic/Targets.cpp.
An associated LLVM patch adds the required LLVM IR intrinsics.
For reference, the transactional-execution instructions are documented
in the z/Architecture Principles of Operation for the zEC12:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/DZ9ZR009.pdf
The associated builtins are documented in the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc/S_002f390-System-z-Built-in-Functions.html
The htmxlintrin.h intrinsics provided for compatibility with the IBM XL
compiler are documented in the "z/OS XL C/C++ Programming Guide".
llvm-svn: 233804
This is necessary because not aall Sandybridge, Ivybrige, Haswell, and Broadwell CPUs support AVX. Currently we modify the CPU name back to Nehalem for this case, but that turns off additional features for these CPUs.
llvm-svn: 233672
Add Tool and ToolChain support for clang to target the NaCl OS using the NaCl
SDK for x86-32, x86-64 and ARM.
Includes nacltools::Assemble and Link which are derived from gnutools. They
are similar to Linux but different enought that they warrant their own class.
Also includes a NaCl_TC in ToolChains derived from Generic_ELF with library
and include paths suitable for an SDK and independent of the system tools.
Differential Revision: http://reviews.llvm.org/D8590
llvm-svn: 233594
Unlike most of the other platforms supported by Clang, CloudABI only
supports static linkage, for the reason that global filesystem access is
prohibited. Functions provided by dlfcn.h are not present. As we know
that applications will not try to do any symbol lookups at run-time, we
can garbage collect unused code quite aggressively. Because of this, it
makes sense to enable -ffunction-sections and -fdata-sections by
default.
Object files will be a bit larger than usual, but the resulting binary
will not be affected, as the sections are merged again. However, when
--gc-sections is used, the linker is able to remove unused code far more
more aggressively. It also has the advantage that transitive library
dependencies only need to be provided to the linker in case that
functionality is actually used.
Differential Revision: http://reviews.llvm.org/D8635
Reviewed by: echristo
llvm-svn: 233299
Now that CloudABI's target information and header search logic for Clang
has been submitted, the only thing that remains to be done is adding
support for CloudABI's linker.
CloudABI uses Binutils ld, although there is some work to use lld
instead. This means that this code is largely based on what we use on
FreeBSD. There are some exceptions, however:
- Only static linking is performed. CloudABI does not support any
dynamically linked executables.
- CloudABI uses compiler-rt, libc++ and libc++abi unconditionally. Link
in these libraries instead of using libgcc_s, libstdc++, etc.
- We must ensure that the .eh_frame_hdr is present to make C++
exceptions work properly.
Differential Revision: http://reviews.llvm.org/D8250
llvm-svn: 233269
Summary:
UBSan is now used in the same way as ASan, and is supported on
OSX and on iOS simulator. At the moment ASan and UBSan can't be used
together due to PR21112, but I hope to resolve it soon by
embedding UBSan into ASan.
Test Plan: regression test suite.
Reviewers: zaks.anna, kubabrecka
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8471
llvm-svn: 233035
Get rid of "libclang_rt.san" library that used to contain
sanitizer_common pieces required by UBSan if it's used in a standalone
mode. Instead, build two variants of UBSan runtime: "ubsan" and
"ubsan_standalone" (same for "ubsan_cxx" and "ubsan_standalone_cxx").
Later "ubsan" and "ubsan_cxx" libraries will go away, as they will
embedded it into corresponding ASan runtimes.
llvm-svn: 233010
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
N.B. CodeGen support is still ongoing.
llvm-svn: 232906
Alexei Starovoitov