Skip to content
Permalink
Browse files

Merge LLVM 313000

  • Loading branch information...
yrnkrn committed Jul 5, 2018
1 parent 2c88635 commit f23c9ba283c4ff8a81203829bc0c3e83062ae1c5
Showing 2,779 changed files with 138,990 additions and 46,184 deletions.
@@ -203,10 +203,6 @@ include(VersionFromVCS)
option(LLVM_APPEND_VC_REV
"Embed the version control system revision id in LLVM" ON)

if( LLVM_APPEND_VC_REV )
add_version_info_from_vcs(PACKAGE_VERSION)
endif()

set(PACKAGE_NAME LLVM)
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
set(PACKAGE_BUGREPORT "http://llvm.org/bugs/")
@@ -41,9 +41,13 @@ E: andrey.churbanov@intel.com
D: OpenMP runtime library

N: Greg Clayton
E: gclayton@apple.com
E: clayborg@gmail.com
D: LLDB

N: Pete Couperus
E: petecoup@synopsys.com
D: ARC backend (lib/Target/ARC/*)

N: Sanjoy Das
E: sanjoy@playingwithpointers.com
D: IndVar Simplify, Scalar Evolution
@@ -101,4 +101,4 @@ Additional zapcc-only code in

### When was the source last merged with LLVM trunk?

This open-source release was last merged with LLVM 311100 on 2017-08-17.
This open-source release was last merged with LLVM 313000 on 2017-09-12.
@@ -16,3 +16,4 @@ documentation setup.
If you are writing a package for LLVM, see docs/Packaging.rst for our
suggestions.


@@ -8,6 +8,7 @@ include(CheckIncludeFileCXX)
include(CheckLibraryExists)
include(CheckSymbolExists)
include(CheckFunctionExists)
include(CheckCCompilerFlag)
include(CheckCXXSourceCompiles)
include(TestBigEndian)

@@ -179,6 +180,14 @@ check_symbol_exists(arc4random "stdlib.h" HAVE_DECL_ARC4RANDOM)
find_package(Backtrace)
set(HAVE_BACKTRACE ${Backtrace_FOUND})
set(BACKTRACE_HEADER ${Backtrace_HEADER})

# Prevent check_symbol_exists from using API that is not supported for a given
# deployment target.
check_c_compiler_flag("-Werror=unguarded-availability-new" "C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW")
if(C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -Werror=unguarded-availability-new")
endif()

check_symbol_exists(_Unwind_Backtrace "unwind.h" HAVE__UNWIND_BACKTRACE)
check_symbol_exists(getpagesize unistd.h HAVE_GETPAGESIZE)
check_symbol_exists(sysconf unistd.h HAVE_SYSCONF)
@@ -892,6 +892,18 @@ macro(add_llvm_utility name)
endif()
endmacro(add_llvm_utility name)

macro(add_llvm_fuzzer name)
cmake_parse_arguments(ARG "" "DUMMY_MAIN" "" ${ARGN})
if( LLVM_USE_SANITIZE_COVERAGE )
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=fuzzer")
set(LLVM_OPTIONAL_SOURCES ${ARG_DUMMY_MAIN})
add_llvm_executable(${name} ${ARG_UNPARSED_ARGUMENTS})
set_target_properties(${name} PROPERTIES FOLDER "Fuzzers")
elseif( ARG_DUMMY_MAIN )
add_llvm_executable(${name} ${ARG_DUMMY_MAIN} ${ARG_UNPARSED_ARGUMENTS})
set_target_properties(${name} PROPERTIES FOLDER "Fuzzers")
endif()
endmacro()

macro(add_llvm_target target_name)
include_directories(BEFORE
@@ -1488,3 +1500,36 @@ function(setup_dependency_debugging name)
set(sandbox_command "sandbox-exec -p '(version 1) (allow default) ${deny_attributes_gen} ${deny_intrinsics_gen}'")
set_target_properties(${name} PROPERTIES RULE_LAUNCH_COMPILE ${sandbox_command})
endfunction()

# Figure out if we can track VC revisions.
function(find_first_existing_file out_var)
foreach(file ${ARGN})
if(EXISTS "${file}")
set(${out_var} "${file}" PARENT_SCOPE)
return()
endif()
endforeach()
endfunction()

macro(find_first_existing_vc_file out_var path)
find_program(git_executable NAMES git git.exe git.cmd)
# Run from a subdirectory to force git to print an absolute path.
execute_process(COMMAND ${git_executable} rev-parse --git-dir
WORKING_DIRECTORY ${path}/cmake
RESULT_VARIABLE git_result
OUTPUT_VARIABLE git_dir
ERROR_QUIET)
if(git_result EQUAL 0)
string(STRIP "${git_dir}" git_dir)
set(${out_var} "${git_dir}/logs/HEAD")
# some branchless cases (e.g. 'repo') may not yet have .git/logs/HEAD
if (NOT EXISTS "${git_dir}/logs/HEAD")
file(WRITE "${git_dir}/logs/HEAD" "")
endif()
else()
find_first_existing_file(${out_var}
"${path}/.svn/wc.db" # SVN 1.7
"${path}/.svn/entries" # SVN 1.6
)
endif()
endmacro()
@@ -84,7 +84,7 @@ endmacro()
function(get_source_info path revision repository)
if (EXISTS "${path}/.svn")
get_source_info_svn("${path}" revision repository)
elseif (EXISTS "${path}/.git/svn")
elseif (EXISTS "${path}/.git/svn/refs")
get_source_info_git_svn("${path}" revision repository)
elseif (EXISTS "${path}/.git")
get_source_info_git("${path}" revision repository)
@@ -233,8 +233,12 @@ if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
endif( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )

# If building on a GNU specific 32-bit system, make sure off_t is 64 bits
# so that off_t can stored offset > 2GB
if( CMAKE_SIZEOF_VOID_P EQUAL 4 )
# so that off_t can stored offset > 2GB.
# Android until version N (API 24) doesn't support it.
if (ANDROID AND (ANDROID_NATIVE_API_LEVEL LESS 24))
set(LLVM_FORCE_SMALLFILE_FOR_ANDROID TRUE)
endif()
if( CMAKE_SIZEOF_VOID_P EQUAL 4 AND NOT LLVM_FORCE_SMALLFILE_FOR_ANDROID)
add_definitions( -D_LARGEFILE_SOURCE )
add_definitions( -D_FILE_OFFSET_BITS=64 )
endif()
@@ -303,13 +307,13 @@ if( MSVC )
# especially so std::equal(nullptr, nullptr, nullptr) will not assert.
add_definitions("-D_DEBUG_POINTER_IMPL=")
endif()

include(ChooseMSVCCRT)

if( MSVC11 )
add_definitions(-D_VARIADIC_MAX=10)
endif()

# Add definitions that make MSVC much less annoying.
add_definitions(
# For some reason MS wants to deprecate a bunch of standard functions...
@@ -370,7 +374,7 @@ if( MSVC )

string(FIND "${upper_exe_flags} ${upper_module_flags} ${upper_shared_flags}"
"/INCREMENTAL" linker_flag_idx)

if (${linker_flag_idx} GREATER -1)
message(WARNING "/Brepro not compatible with /INCREMENTAL linking - builds will be non-deterministic")
else()
@@ -383,6 +387,7 @@ elseif( LLVM_COMPILER_IS_GCC_COMPATIBLE )
append_if(LLVM_ENABLE_WERROR "-Werror" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append_if(LLVM_ENABLE_WERROR "-Wno-error" CMAKE_REQUIRED_FLAGS)
add_flag_if_supported("-Werror=date-time" WERROR_DATE_TIME)
add_flag_if_supported("-Werror=unguarded-availability-new" WERROR_UNGUARDED_AVAILABILITY_NEW)
if (LLVM_ENABLE_CXX1Y)
check_cxx_compiler_flag("-std=c++1y" CXX_SUPPORTS_CXX1Y)
append_if(CXX_SUPPORTS_CXX1Y "-std=c++1y" CMAKE_CXX_FLAGS)
@@ -664,7 +669,7 @@ if(LLVM_USE_SANITIZER)
FSANITIZE_USE_AFTER_SCOPE_FLAG)
endif()
if (LLVM_USE_SANITIZE_COVERAGE)
append("-fsanitize-coverage=trace-pc-guard,indirect-calls,trace-cmp" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append("-fsanitize=fuzzer-no-link" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
endif()

@@ -791,7 +796,7 @@ endif()
# Plugin support
# FIXME: Make this configurable.
if(WIN32 OR CYGWIN)
if(BUILD_SHARED_LIBS)
if(BUILD_SHARED_LIBS OR LLVM_BUILD_LLVM_DYLIB)
set(LLVM_ENABLE_PLUGINS ON)
else()
set(LLVM_ENABLE_PLUGINS OFF)
@@ -248,9 +248,10 @@ LLVM-specific variables

**LLVM_APPEND_VC_REV**:BOOL
Embed version control revision info (svn revision number or Git revision id).
This is used among other things in the LLVM version string (stored in the
PACKAGE_VERSION macro). For this to work cmake must be invoked before the
build. Defaults to ON.
The version info is provided by the ``LLVM_REVISION`` macro in
``llvm/include/llvm/Support/VCSRevision.h``. Developers using git who don't
need revision info can disable this option to avoid re-linking most binaries
after a branch switch. Defaults to ON.

**LLVM_ENABLE_THREADS**:BOOL
Build with threads support, if available. Defaults to ON.
@@ -167,10 +167,9 @@ Other Types

Variables that are cached or specified on the command line can have types
associated with them. The variable's type is used by CMake's UI tool to display
the right input field. The variable's type generally doesn't impact evaluation.
One of the few examples is PATH variables, which CMake does have some special
handling for. You can read more about the special handling in `CMake's set
documentation
the right input field. A variable's type generally doesn't impact evaluation,
however CMake does have special handling for some variables such as PATH.
You can read more about the special handling in `CMake's set documentation
<https://cmake.org/cmake/help/v3.5/command/set.html#set-cache-entry>`_.

Scope
@@ -203,7 +202,7 @@ Control Flow
============

CMake features the same basic control flow constructs you would expect in any
scripting language, but there are a few quarks because, as with everything in
scripting language, but there are a few quirks because, as with everything in
CMake, control flow constructs are commands.

If, ElseIf, Else
@@ -334,21 +333,23 @@ When defining a CMake command handling arguments is very useful. The examples
in this section will all use the CMake ``function`` block, but this all applies
to the ``macro`` block as well.

CMake commands can have named arguments, but all commands are implicitly
variable argument. If the command has named arguments they are required and must
be specified at every call site. Below is a trivial example of providing a
wrapper function for CMake's built in function ``add_dependencies``.
CMake commands can have named arguments that are requried at every call site. In
addition, all commands will implicitly accept a variable number of extra
arguments (In C parlance, all commands are varargs functions). When a command is
invoked with extra arguments (beyond the named ones) CMake will store the full
list of arguments (both named and unnamed) in a list named ``ARGV``, and the
sublist of unnamed arguments in ``ARGN``. Below is a trivial example of
providing a wrapper function for CMake's built in function ``add_dependencies``.

.. code-block:: cmake

function(add_deps target)
add_dependencies(${target} ${ARGV})
add_dependencies(${target} ${ARGN})
endfunction()

This example defines a new macro named ``add_deps`` which takes a required first
argument, and just calls another function passing through the first argument and
all trailing arguments. When variable arguments are present CMake defines them
in a list named ``ARGV``, and the count of the arguments is defined in ``ARGN``.
all trailing arguments.

CMake provides a module ``CMakeParseArguments`` which provides an implementation
of advanced argument parsing. We use this all over LLVM, and it is recommended
@@ -811,6 +811,21 @@ As a rule of thumb, use ``auto &`` unless you need to copy the result, and use
for (const auto *Ptr : Container) { observe(*Ptr); }
for (auto *Ptr : Container) { Ptr->change(); }
Beware of non-determinism due to ordering of pointers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In general, there is no relative ordering among pointers. As a result,
when unordered containers like sets and maps are used with pointer keys
the iteration order is undefined. Hence, iterating such containers may
result in non-deterministic code generation. While the generated code
might not necessarily be "wrong code", this non-determinism might result
in unexpected runtime crashes or simply hard to reproduce bugs on the
customer side making it harder to debug and fix.

As a rule of thumb, in case an ordered result is expected, remember to
sort an unordered container before iteration. Or use ordered containers
like vector/MapVector/SetVector if you want to iterate pointer keys.

Style Issues
============

@@ -941,8 +956,8 @@ loops. A silly example is something like this:

.. code-block:: c++

for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
if (BinaryOperator *BO = dyn_cast<BinaryOperator>(II)) {
for (Instruction &I : BB) {
if (auto *BO = dyn_cast<BinaryOperator>(&I)) {
Value *LHS = BO->getOperand(0);
Value *RHS = BO->getOperand(1);
if (LHS != RHS) {
@@ -961,8 +976,8 @@ It is strongly preferred to structure the loop like this:

.. code-block:: c++

for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
BinaryOperator *BO = dyn_cast<BinaryOperator>(II);
for (Instruction &I : BB) {
auto *BO = dyn_cast<BinaryOperator>(&I);
if (!BO) continue;
Value *LHS = BO->getOperand(0);
@@ -1232,6 +1247,12 @@ builds), ``llvm_unreachable`` becomes a hint to compilers to skip generating
code for this branch. If the compiler does not support this, it will fall back
to the "abort" implementation.

Neither assertions or ``llvm_unreachable`` will abort the program on a release
build. If the error condition can be triggered by user input then the
recoverable error mechanism described in :doc:`ProgrammersManual` should be
used instead. In cases where this is not practical, ``report_fatal_error`` may
be used.

Another issue is that values used only by assertions will produce an "unused
value" warning when assertions are disabled. For example, this code will warn:

@@ -1316,19 +1337,31 @@ that the enum expression may take any representable value, not just those of
individual enumerators. To suppress this warning, use ``llvm_unreachable`` after
the switch.

Use range-based ``for`` loops wherever possible
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The introduction of range-based ``for`` loops in C++11 means that explicit
manipulation of iterators is rarely necessary. We use range-based ``for``
loops wherever possible for all newly added code. For example:

.. code-block:: c++

BasicBlock *BB = ...
for (Instruction &I : *BB)
... use I ...

Don't evaluate ``end()`` every time through a loop
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Because C++ doesn't have a standard "``foreach``" loop (though it can be
emulated with macros and may be coming in C++'0x) we end up writing a lot of
loops that manually iterate from begin to end on a variety of containers or
through other data structures. One common mistake is to write a loop in this
style:
In cases where range-based ``for`` loops can't be used and it is necessary
to write an explicit iterator-based loop, pay close attention to whether
``end()`` is re-evaluted on each loop iteration. One common mistake is to
write a loop in this style:

.. code-block:: c++

BasicBlock *BB = ...
for (BasicBlock::iterator I = BB->begin(); I != BB->end(); ++I)
for (auto I = BB->begin(); I != BB->end(); ++I)
... use I ...
The problem with this construct is that it evaluates "``BB->end()``" every time
@@ -1339,7 +1372,7 @@ convenient way to do this is like so:
.. code-block:: c++

BasicBlock *BB = ...
for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I)
for (auto I = BB->begin(), E = BB->end(); I != E; ++I)
... use I ...
The observant may quickly point out that these two loops may have different
@@ -235,6 +235,12 @@ OPTIONS

Show code coverage only for functions with the given name.

.. option:: -name-whitelist=<FILE>

Show code coverage only for functions listed in the given file. Each line in
the file should start with `whitelist_fun:`, immediately followed by the name
of the function to accept. This name can be a wildcard expression.

.. option:: -name-regex=<PATTERN>

Show code coverage only for functions that match the given regular expression.
@@ -119,7 +119,7 @@ ABI
===

* `System V Application Binary Interface <http://www.sco.com/developers/gabi/latest/contents.html>`_
* `Itanium C++ ABI <http://mentorembedded.github.io/cxx-abi/>`_
* `Itanium C++ ABI <http://itanium-cxx-abi.github.io/cxx-abi/>`_

Linux
-----

0 comments on commit f23c9ba

Please sign in to comment.
You can’t perform that action at this time.