1======================================== 2Clang 10.0.0 (In-Progress) Release Notes 3======================================== 4 5.. contents:: 6 :local: 7 :depth: 2 8 9Written by the `LLVM Team <https://llvm.org/>`_ 10 11.. warning:: 12 13 These are in-progress notes for the upcoming Clang 10 release. 14 Release notes for previous releases can be found on 15 `the Download Page <https://releases.llvm.org/download.html>`_. 16 17Introduction 18============ 19 20This document contains the release notes for the Clang C/C++/Objective-C 21frontend, part of the LLVM Compiler Infrastructure, release 10.0.0. Here we 22describe the status of Clang in some detail, including major 23improvements from the previous release and new feature work. For the 24general LLVM release notes, see `the LLVM 25documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM 26releases may be downloaded from the `LLVM releases web 27site <https://llvm.org/releases/>`_. 28 29For more information about Clang or LLVM, including information about the 30latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the 31`LLVM Web Site <https://llvm.org>`_. 32 33Note that if you are reading this file from a Subversion checkout or the 34main Clang web page, this document applies to the *next* release, not 35the current one. To see the release notes for a specific release, please 36see the `releases page <https://llvm.org/releases/>`_. 37 38What's New in Clang 10.0.0? 39=========================== 40 41Some of the major new features and improvements to Clang are listed 42here. Generic improvements to Clang as a whole or to its underlying 43infrastructure are described first, followed by language-specific 44sections with improvements to Clang's support for those languages. 45 46Major New Features 47------------------ 48 49- ... 50 51Improvements to Clang's diagnostics 52^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 53 54- -Wtautological-overlap-compare will warn on negative numbers and non-int 55 types. 56- -Wtautological-compare for self comparisons and 57 -Wtautological-overlap-compare will now look through member and array 58 access to determine if two operand expressions are the same. 59- -Wtautological-bitwise-compare is a new warning group. This group has the 60 current warning which diagnoses the tautological comparison of a bitwise 61 operation and a constant. The group also has the new warning which diagnoses 62 when a bitwise-or with a non-negative value is converted to a bool, since 63 that bool will always be true. 64- -Wbitwise-conditional-parentheses will warn on operator precedence issues 65 when mixing bitwise-and (&) and bitwise-or (|) operator with the 66 conditional operator (?:). 67 68Non-comprehensive list of changes in this release 69------------------------------------------------- 70 71* In both C and C++ (C17 ``6.5.6p8``, C++ ``[expr.add]``), pointer arithmetic is 72 only permitted within arrays. In particular, the behavior of a program is not 73 defined if it adds a non-zero offset (or in C, any offset) to a null pointer, 74 or if it forms a null pointer by subtracting an integer from a non-null 75 pointer, and the LLVM optimizer now uses those guarantees for transformations. 76 This may lead to unintended behavior in code that performs these operations. 77 The Undefined Behavior Sanitizer ``-fsanitize=pointer-overflow`` check has 78 been extended to detect these cases, so that code relying on them can be 79 detected and fixed. 80 81- For X86 target, -march=skylake-avx512, -march=icelake-client, 82 -march=icelake-server, -march=cascadelake, -march=cooperlake will default to 83 not using 512-bit zmm registers in vectorized code unless 512-bit intrinsics 84 are used in the source code. 512-bit operations are known to cause the CPUs 85 to run at a lower frequency which can impact performance. This behavior can be 86 changed by passing -mprefer-vector-width=512 on the command line. 87 88New Compiler Flags 89------------------ 90 91- The -fgnuc-version= flag now controls the value of ``__GNUC__`` and related 92 macros. This flag does not enable or disable any GCC extensions implemented in 93 Clang. Setting the version to zero causes Clang to leave ``__GNUC__`` and 94 other GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. 95 96Deprecated Compiler Flags 97------------------------- 98 99The following options are deprecated and ignored. They will be removed in 100future versions of Clang. 101 102- -mmpx used to enable the __MPX__ preprocessor define for the Intel MPX 103 instructions. There were no MPX intrinsics. 104- -mno-mpx used to disable -mmpx and is the default behavior. 105 106- ... 107 108Modified Compiler Flags 109----------------------- 110 111- ... 112 113New Pragmas in Clang 114-------------------- 115 116- ... 117 118Attribute Changes in Clang 119-------------------------- 120 121- ... 122 123Windows Support 124--------------- 125 126- Previous Clang versions contained a work-around to avoid an issue with the 127 standard library headers in Visual Studio 2019 versions prior to 16.3. This 128 work-around has now been removed, and users of Visual Studio 2019 are 129 encouraged to upgrade to 16.3 or later, otherwise they may see link errors as 130 below: 131 132 .. code-block:: console 133 134 error LNK2005: "bool const std::_Is_integral<int>" (??$_Is_integral@H@std@@3_NB) already defined 135 136 137 138 139C Language Changes in Clang 140--------------------------- 141 142- ... 143 144C11 Feature Support 145^^^^^^^^^^^^^^^^^^^ 146 147... 148 149C++ Language Changes in Clang 150----------------------------- 151 152- The behaviour of the `gnu_inline` attribute now matches GCC, for cases 153 where used without the `extern` keyword. As this is a change compared to 154 how it behaved in previous Clang versions, a warning is emitted for this 155 combination. 156 157C++1z Feature Support 158^^^^^^^^^^^^^^^^^^^^^ 159 160... 161 162Objective-C Language Changes in Clang 163------------------------------------- 164 165- ... 166 167OpenCL C Language Changes in Clang 168---------------------------------- 169 170... 171 172ABI Changes in Clang 173-------------------- 174 175- gcc passes vectors of __int128 in memory on X86-64. Clang historically 176 broke the vectors into multiple scalars using two 64-bit values for each 177 element. Clang now matches the gcc behavior on Linux and NetBSD. You can 178 switch back to old API behavior with flag: -fclang-abi-compat=9.0. 179 180OpenMP Support in Clang 181----------------------- 182 183- ... 184 185CUDA Support in Clang 186--------------------- 187 188- ... 189 190Internal API Changes 191-------------------- 192 193These are major API changes that have happened since the 9.0.0 release of 194Clang. If upgrading an external codebase that uses Clang as a library, 195this section should help get you past the largest hurdles of upgrading. 196 197- libTooling APIs that transfer ownership of `FrontendAction` objects now pass 198 them by `unique_ptr`, making the ownership transfer obvious in the type 199 system. `FrontendActionFactory::create()` now returns a 200 `unique_ptr<FrontendAction>`. `runToolOnCode`, `runToolOnCodeWithArgs`, 201 `ToolInvocation::ToolInvocation()` now take a `unique_ptr<FrontendAction>`. 202 203Build System Changes 204-------------------- 205 206These are major changes to the build system that have happened since the 9.0.0 207release of Clang. Users of the build system should adjust accordingly. 208 209- In 8.0.0 and below, the install-clang-headers target would install clang's 210 resource directory headers. This installation is now performed by the 211 install-clang-resource-headers target. Users of the old install-clang-headers 212 target should switch to the new install-clang-resource-headers target. The 213 install-clang-headers target now installs clang's API headers (corresponding 214 to its libraries), which is consistent with the install-llvm-headers target. 215 216- In 9.0.0 and later Clang added a new target, clang-cpp, which generates a 217 shared library comprised of all the clang component libraries and exporting 218 the clang C++ APIs. Additionally the build system gained the new 219 "CLANG_LINK_CLANG_DYLIB" option, which defaults Off, and when set to On, will 220 force clang (and clang-based tools) to link the clang-cpp library instead of 221 statically linking clang's components. This option will reduce the size of 222 binary distributions at the expense of compiler performance. 223 224- ... 225 226AST Matchers 227------------ 228 229- ... 230 231clang-format 232------------ 233 234- The ``Standard`` style option specifies which version of C++ should be used 235 when parsing and formatting C++ code. The set of allowed values has changed: 236 237 - ``Latest`` will always enable new C++ language features. 238 - ``c++03``, ``c++11``, ``c++14``, ``c++17``, ``c++20`` will pin to exactly 239 that language version. 240 - ``Auto`` is the default and detects style from the code (this is unchanged). 241 242 The previous values of ``Cpp03`` and ``Cpp11`` are deprecated. Note that 243 ``Cpp11`` is treated as ``Latest``, as this was always clang-format's behavior. 244 (One motivation for this change is the new name describes the behavior better). 245 246libclang 247-------- 248 249- ... 250 251 252Static Analyzer 253--------------- 254 255- The Clang analyzer checker ``DeadStores`` gets a new option called 256 ``WarnForDeadNestedAssignments`` to detect nested dead assignments 257 (enabled by default). 258- ... 259 260.. _release-notes-ubsan: 261 262Undefined Behavior Sanitizer (UBSan) 263------------------------------------ 264 265- * The ``pointer-overflow`` check was extended added to catch the cases where 266 a non-zero offset is applied to a null pointer, or the result of 267 applying the offset is a null pointer. 268 269 .. code-block:: c++ 270 271 #include <cstdint> // for intptr_t 272 273 static char *getelementpointer_inbounds(char *base, unsigned long offset) { 274 // Potentially UB. 275 return base + offset; 276 } 277 278 char *getelementpointer_unsafe(char *base, unsigned long offset) { 279 // Always apply offset. UB if base is ``nullptr`` and ``offset`` is not 280 // zero, or if ``base`` is non-``nullptr`` and ``offset`` is 281 // ``-reinterpret_cast<intptr_t>(base)``. 282 return getelementpointer_inbounds(base, offset); 283 } 284 285 char *getelementpointer_safe(char *base, unsigned long offset) { 286 // Cast pointer to integer, perform usual arithmetic addition, 287 // and cast to pointer. This is legal. 288 char *computed = 289 reinterpret_cast<char *>(reinterpret_cast<intptr_t>(base) + offset); 290 // If either the pointer becomes non-``nullptr``, or becomes 291 // ``nullptr``, we must use ``computed`` result. 292 if (((base == nullptr) && (computed != nullptr)) || 293 ((base != nullptr) && (computed == nullptr))) 294 return computed; 295 // Else we can use ``getelementpointer_inbounds()``. 296 return getelementpointer_inbounds(base, offset); 297 } 298 299 300Core Analysis Improvements 301========================== 302 303- ... 304 305New Issues Found 306================ 307 308- ... 309 310Python Binding Changes 311---------------------- 312 313The following methods have been added: 314 315- ... 316 317Significant Known Problems 318========================== 319 320Additional Information 321====================== 322 323A wide variety of additional information is available on the `Clang web 324page <https://clang.llvm.org/>`_. The web page contains versions of the 325API documentation which are up-to-date with the Subversion version of 326the source code. You can access versions of these documents specific to 327this release by going into the "``clang/docs/``" directory in the Clang 328tree. 329 330If you have any questions or comments about Clang, please feel free to 331contact us via the `mailing 332list <https://lists.llvm.org/mailman/listinfo/cfe-dev>`_. 333