Summary:
r291918 changed `HandleLLVMOptions.cmake` to add `-fsanitize-blacklist=<llvm-file>` when `LLVM_USE_SANITIZER=Undefined` is specified. This breaks out-of-tree users of `LLVM_USE_SANITIZER` since that file is not present.
This patch fixes the issue by checking if the file exists first.
Reviewers: mgorny, bogner, vitalybuka, krasin
Reviewed By: krasin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29686
llvm-svn: 294367
Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them.
llvm-svn: 294334
In r292256, we started adding -fsanitize-use-after-scope when using
the address sanitizer, but that flag wasn't always available. This
fixes the config to only add the flag if the host compiler supports
it.
llvm-svn: 292423
Summary:
This string parameter is passed to -fuse-ld when linking. It can be
an absolute path to your custom linker, otherwise clang will look for
`ld.{name}`.
Reviewers: davide, tejohnson, pcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28738
llvm-svn: 292047
Summary:
libstdc++ has some undefined behavior in bits/stl_tree.h that
has recently became excercised by some of the LLVM code.
Given that fixing libstdc++ will take years, adding the file
into a blacklist to fix bots seems like a necessity.
Reviewers: vitalybuka
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28686
llvm-svn: 291918
COFF has a 2**16 section limit, and on Win64, every COMDAT function
creates at least 3 sections: .text, .pdata, and .xdata. For MSVC, we
enable bigobj on a file-by-file basis, but GCC appears to hit the limit
on different files.
Fixes PR25953
llvm-svn: 290358
Summary:
The motivation for this is to enable correct detection of dlopen() on Android.
Android does not provide a static version of libdl, so if we add the -static flag
after performing the check, it will succeed even though subsequent link steps
will fail. With this change we correctly detect the absence of libdl in a
LLVM_BUILD_STATIC build on Android.
The link itself still does not succeed because the code does not check the result
of this check properly, but I plan to fix that in a separate change.
Reviewers: beanz
Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits
Differential Revision: https://reviews.llvm.org/D26463
llvm-svn: 287220
This reverts commit 3db82f646a0890eb7664d0351b5a3c79622e8bef.
Vassil already fixed this and I mechanically undid his fix without looking
too close at what I'm actually doing. Need more coffee.
llvm-svn: 274242
This fixes a typo introduced in r274196.
Thanks to Vassil Vassilev for noticing!
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274240
On Darwin it is currently impossible to build LLVM with modules
because the Darwin system module map is not compatible with
-fmodules-local-submodule-visibility at this point in time. This
patch makes the flag optional and off by default on Darwin so it
becomes possible to build LLVM with modules again.
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274196
With CMP0056, try_compile() uses also CMAKE_EXE_LINKER_FLAG.
It caused mismatch between CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS, to fail to examine CXX_SUPPORTS_CXX11 with -m32.
FYI, before this, try_compile() tries without -m32 regardless of LLVM_BUILD_32_BITS.
llvm-svn: 271871
The problem with plugins on Windows is that when building a plugin DLL it needs
to explicitly link against something (an exe or DLL) if it uses symbols from
that thing, and that thing must explicitly export those symbols. Also there's a
limit of 65535 symbols that can be exported. This means that currently plugins
only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with
MSVC.
This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled
automatically exports from all LLVM tools the symbols that a plugin could want
to use so that a plugin can link against a tool directly. Plugins can specify
what tool they link against by using PLUGIN_TOOL argument to llvm_add_library.
The option can also be enabled on Linux, though there all it should do is
restrict the set of symbols that are exported as by default all symbols are
exported.
This option is currently OFF by default, as while I've verified that it works
with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no
idea what will happen on OSX. Also unfortunately we can't turn on
LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be
loaded by both bugpoint.exe and opt.exe which is incompatible with this
approach. Also currently clang plugins don't work with this approach, which
will be fixed in future patches.
Differential Revision: http://reviews.llvm.org/D18826
llvm-svn: 270839
Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.
The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.
With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.
See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html
Reviewers: bogner, silvas, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19892
llvm-svn: 268670
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
llvm-svn: 268050
1) We need to add this flag prior to adding any other, in case the user has
specified a -fmodule-cache-path= flag in their custom CXXFLAGS. Such a flag
causes -Werror builds to fail, and thus all config checks fail, until we add
the corresponding -fmodules flag. The modules selfhost bot does this, for
instance.
2) Delete module maps that were putting .cpp files into modules.
3) Enable -fmodules-local-submodule-visibility, to get proper module
visibility rules applied across submodules of the same module. Disable
-fmodules for C builds, since that flag is not available there.
llvm-svn: 266502
What we are really trying to do here is to figure out if we are using
the 2015 STL. Unfortunately, so far as I know the MSVC STL does not
define a version macro that we can check directly. Instead I wrote a
check to see if char16_t works.
llvm-svn: 264881
Otherwise users get messages from CheckAtomic about missing libatomic
instead of a sensible message that says "use GCC 4.7 or newer".
I structured the change along the lines of HandleLLVMStdlib.cmake, so
that the standalone build of Clang still gets the compiler version
check.
Reviewers: beanz
Differential Revision: http://reviews.llvm.org/D17789
llvm-svn: 262491
Very often in LLVM we have APIs that take a bitwidth and a uint64_t that
we pass immediates such as ~0U to. Consider APInt, Constant, and
MachineInstrBuilder::addImm. Fixing all uses of these APIs to manually
extend their arguments to uint64_t doesn't seem worth it.
llvm-svn: 260416
Mehdi suggested in a review of r259766 that it's also useful to easily
set the type of LTO. Augment the cmake variable to support that.
llvm-svn: 260143
Enable more strict standards conformance in MSVC for rvalue casting and string literal type conversion to non-const types. Also enables generation of intrinsics for more functions.
Patch by Alexander Riccio
llvm-svn: 258687
I think I fixed all instances of this in the codebase
(r258202, 258200, 258190). Also, the suppression didn't
have an effect on bots using make anyways, and it looks
like many bots still use configure/make bots.
llvm-svn: 258210
LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's
binaries. Turning it off is useful for deterministic builds.
r246905 made it so that the define suddenly also controls if the binaries that
the llvm binaries _create_ embed timestamps or not – but this shouldn't be a
configure-time option. r256203/r256204 added a driver option to toggle this on
and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS
builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is
deterministic – but the built clang can still write timestamps into other
executables when requested.
This also allows removing some of the test machinery added in r292012 to work
around this problem.
See PR24740 for background.
http://reviews.llvm.org/D15783
llvm-svn: 256958
This should fix many many -Wunused-parameter warnings in self-host builds on
Windows after r255382. cl.exe doesn't care about the order of /W4 and
/wd flags, but clang-cl currently does (just like -Wno-foo -Wall order
matters for clang). We might want to change how clang-cl behaves in
the future, but until then this change makes self-host builds much more
silent.
llvm-svn: 256315
Clang has better diagnostics in this case. It is not necessary therefore
to change the destructor to avoid what is effectively an invalid warning
in gcc. Instead, better handle the warning flags given to the compiler.
llvm-svn: 255905
This is the first step in supporting PGO data generation via CMake. I've marked the option as advanced and experimental until it is fleshed out further.
llvm-svn: 255298
This is similar to the fix for FreeBSD in r226862. Without this patch,
the build aborts when linkling libLTO.so, complaining about undefined
references to assert2, cxa_atexit, etc.
Patch by Stefan Kempf!
http://reviews.llvm.org/D14236
llvm-svn: 253769
I'm unaware of any reasons why -fvisibility-inlines-hidden would depend on PIC, and since autoconf supports this flag without PIC, we should support it in CMake too.
llvm-svn: 253517
This reverts commit r248963.
Seems there's some standard libraries (and libcxxabi implementations)
that aren't -Wdeprecated clean... hrm.
llvm-svn: 248972
This particularly helps enforce the C++ Rule of 5 (for new move ops this
is already an error, but for a type only using C++98 features (copy
ctor/assign, dtor) it is only deprecated, not invalid)
Applying the flag for any GCC compatible compiler - GCC doesn't warn on
the Rule of 5 cases that C++11 deprecates, but it doesn't have other
false positives so far as I could see (compiling with GCC 4.8 didn't
produce any -Wdeprecated warnings I could spot).
Reviewers: aaron.ballman
Differential Revision: http://reviews.llvm.org/D13314
llvm-svn: 248963
Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER
value, there's a cmake warning and the build goes on with no
sanitizers at all. This isn't a good behaviour, since cmake warnings
are fairly easy to miss and the resulting behaviour is that it looks
like the build is sanitizer clean.
Upgrade these warnings to errors so misconfigurations are more
obvious.
llvm-svn: 246531
such as std::equal on the third argument. This reverts previous workarounds.
Predefining _DEBUG_POINTER_IMPL disables Visual C++ 2013 headers from defining
it to a function performing the null pointer check. In practice, it's not that
bad since any function actually using the nullptr will seg fault. The other
iterator sanity checks remain enabled in the headers.
Reviewed by Aaron Ballmanþ and Duncan P. N. Exon Smith.
llvm-svn: 245711
This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.
Differential Revision: http://reviews.llvm.org/D10707
llvm-svn: 243419
Prior to CMAKE 2.8.4 that was covered by the WIN32 conditional but
from 2.8.4 CMAKE no longer defined WIN32 when running under Cygwin
and it needs its own test.
Patch by Martell Malone!
http://reviews.llvm.org/D11347
llvm-svn: 242993
I can't actually test this properly because uninstalling MSVC 2015 CTP 6
and reinstalling the 2015 RC takes hours. I can only verify that this
doesn't mess up MSVC 2013 and 2015 CTP 6 builds, which is what I've
done.
Should fix PR23513.
llvm-svn: 237743
Certain versions of CMake specify /W3 as part of CMAKE_CXX_FLAGS
by default, before you do anything. Appending /W4 to the end of
this and using the Ninja generator results in
cl : Command line warning D9025 : overriding '/W3' with '/W4'.
It is not possible to suppress this since it is a command line
warning and not a compiler warning, so we must fix the command
line to contain only one value for /Wn.
llvm-svn: 234907
Unfortunately, on ELF there is not used attribute on the .o files,
so there is no easy way to keep the dump function alive.
If we are not gcing, we may as well produce non gcable files and
avoid the cost.
Linking a debug clang now takes 18.856225992 seconds, before it
took 21.206897447.
I will try avoiding --gc-sections -O3 on a followup patch.
llvm-svn: 234159
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.
Reviewers: chandlerc, dexonsmith, rnk, zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8351
llvm-svn: 233310
NFC currently but required as a prerequisite for using
the Microsoft resource compiler in conjunction with
CMake's ninja generator, which knows how to filter flags
appropriately, but not definitions.
Differential Revision: http://reviews.llvm.org/D8188
llvm-svn: 232727
NFC currently but required as a prerequisite for using
the Microsoft resource compiler in conjunction with
CMake's ninja generator, which knows how to filter flags
appropriately, but not definitions.
Differential Revision: http://reviews.llvm.org/D8188
llvm-svn: 231924
Introduce -mllvm -sanitizer-coverage-8bit-counters=1
which adds imprecise thread-unfriendly 8-bit coverage counters.
The run-time library maps these 8-bit counters to 8-bit bitsets in the same way
AFL (http://lcamtuf.coredump.cx/afl/technical_details.txt) does:
counter values are divided into 8 ranges and based on the counter
value one of the bits in the bitset is set.
The AFL ranges are used here: 1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+.
These counters provide a search heuristic for single-threaded
coverage-guided fuzzers, we do not expect them to be useful for other purposes.
Depending on the value of -fsanitize-coverage=[123] flag,
these counters will be added to the function entry blocks (=1),
every basic block (=2), or every edge (=3).
Use these counters as an optional search heuristic in the Fuzzer library.
Add a test where this heuristic is critical.
llvm-svn: 231166
This allows clang-cl to self-host cleanly with no magic setup
steps required.
After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.
These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.
llvm-svn: 230539
If we're using clang-cl, that's a pretty good indication that we're
going to use MSVC's STL.
This simplifies the clang-cl ninja self-host configuration down to:
CC=clang-cl CXX=clang-cl cmake .. -GNinja
Modified version of zturner's patch:
Differential Revision: http://reviews.llvm.org/D7824
llvm-svn: 230239
Previous versions of MSVC 2013 would miscompile ASTMatchers (and/or their
tests). Bump up the requirement and make sure we know about the minor
revision.
Minimum required version found by Michael Edwards!
llvm-svn: 229584
Summary:
Handle LLVM_USE_SANITIZER=Address;Undefined to enable ASan and UBSan
If UBSan is compatible with more of the other sanitizers, maybe we should
deal with this in a better way where we allow combining UBSan with any of
the other sanitizers.
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7024
llvm-svn: 228219
Summary:
When LLVM_USE_SANITIZE_COVERAGE=YES
and one of the sanitizers is used -fsanitize-coverage=3 will be added
to build flag. This will be used to run a coverage-guided fuzzer on various
llvm libraries.
Test Plan: n/a
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7116
llvm-svn: 227216
ELF linkers by default allow shared libraries to contain undefined references
and it is up to the dynamic linker to look for them.
On COFF and MachO, that is not the case.
This creates a situation where a .so might build on an ELF system, but the build
of the corresponding .dylib or .dll will fail.
This patch changes the cmake build to use -Wl,-z,defs when linking and updates
the dependencies so that -DBUILD_SHARED_LIBS=ON build still works.
llvm-svn: 226611
Presumably it was added to the CMake system when MAXPATHLEN was still
used by code built for Windows. Currently only lib/Support/Path.inc uses
MAXPATHLEN, and it should be available on all Unices.
llvm-svn: 223139
Summary: This will help in testing libc++ and libc++abi with tsan.
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D6283
llvm-svn: 222258
Eric Fiselier