1========================== 2Clang 10.0.0 Release Notes 3========================== 4 5.. contents:: 6 :local: 7 :depth: 2 8 9Written by the `LLVM Team <https://llvm.org/>`_ 10 11 12Introduction 13============ 14 15This document contains the release notes for the Clang C/C++/Objective-C 16frontend, part of the LLVM Compiler Infrastructure, release 10.0.0. Here we 17describe the status of Clang in some detail, including major 18improvements from the previous release and new feature work. For the 19general LLVM release notes, see `the LLVM 20documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM 21releases may be downloaded from the `LLVM releases web 22site <https://llvm.org/releases/>`_. 23 24For more information about Clang or LLVM, including information about the 25latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the 26`LLVM Web Site <https://llvm.org>`_. 27 28 29What's New in Clang 10.0.0? 30=========================== 31 32Some of the major new features and improvements to Clang are listed 33here. Generic improvements to Clang as a whole or to its underlying 34infrastructure are described first, followed by language-specific 35sections with improvements to Clang's support for those languages. 36 37Major New Features 38------------------ 39 40- clang used to run the actual compilation in a subprocess ("clang -cc1"). 41 Now compilations are done in-process by default. ``-fno-integrated-cc1`` 42 restores the former behavior. The ``-v`` and ``-###`` flags will print 43 "(in-process)" when compilations are done in-process. 44 45- Concepts support. Clang now supports C++2a Concepts under the -std=c++2a flag. 46 47Improvements to Clang's diagnostics 48^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 49 50- ``-Wtautological-overlap-compare`` will warn on negative numbers and non-int 51 types. 52 53- ``-Wtautological-compare`` for self comparisons and 54 ``-Wtautological-overlap-compare`` will now look through member and array 55 access to determine if two operand expressions are the same. 56 57- ``-Wtautological-bitwise-compare`` is a new warning group. This group has the 58 current warning which diagnoses the tautological comparison of a bitwise 59 operation and a constant. The group also has the new warning which diagnoses 60 when a bitwise-or with a non-negative value is converted to a bool, since 61 that bool will always be true. 62 63- ``-Wbitwise-conditional-parentheses`` will warn on operator precedence issues 64 when mixing bitwise-and (&) and bitwise-or (|) operator with the 65 conditional operator (?:). 66 67- ``-Wrange-loop-analysis`` got several improvements. It no longer warns about a 68 copy being made when the result is bound to an rvalue reference. It no longer 69 warns when an object of a small, trivially copyable type is copied. The 70 warning now offers fix-its. Excluding ``-Wrange-loop-bind-reference`` it is now 71 part of ``-Wall``. To reduce the number of false positives the diagnostic is 72 disabled in macros and template instantiations. 73 74- ``-Wmisleading-indentation`` has been added. This warning is similar to the GCC 75 warning of the same name. It warns about statements that are indented as if 76 they were part of a if/else/for/while statement but are not semantically 77 part of that if/else/for/while. 78 79- ``-Wbitwise-op-parentheses`` and ``-Wlogical-op-parentheses`` are disabled by default. 80 81- The new warnings ``-Wc99-designator`` and ``-Wreorder-init-list`` warn about 82 uses of C99 initializers in C++ mode for cases that are valid in C99 but not 83 in C++20. 84 85- The new warning ``-Wsizeof-array-div`` catches cases like 86 ``int arr[10]; ...sizeof(arr) / sizeof(short)...`` 87 (should be ``sizeof(arr) / sizeof(int)``), and the existing warning 88 ``-Wsizeof-pointer-div`` catches more cases. 89 90- The new warning ``-Wxor-used-as-pow`` warns on cases where it looks like 91 the xor operator ``^`` is used to be mean exponentiation, e.g. ``2 ^ 16``. 92 93- The new warning ``-Wfinal-dtor-non-final-class`` warns on classes that 94 have a final destructor but aren't themselves marked final. 95 96- ``-Wextra`` now enables ``-Wdeprecated-copy``. The warning deprecates 97 move and copy constructors in classes where an explicit destructor is 98 declared. This is for compatibility with GCC 9, and forward looking 99 for a change that's being considered for C++23. You can disable it with 100 ``-Wno-deprecated-copy``. 101 102 103Non-comprehensive list of changes in this release 104------------------------------------------------- 105 106* In both C and C++ (C17 ``6.5.6p8``, C++ ``[expr.add]``), pointer arithmetic is 107 only permitted within arrays. In particular, the behavior of a program is not 108 defined if it adds a non-zero offset (or in C, any offset) to a null pointer, 109 or if it forms a null pointer by subtracting an integer from a non-null 110 pointer, and the LLVM optimizer now uses those guarantees for transformations. 111 This may lead to unintended behavior in code that performs these operations. 112 The Undefined Behavior Sanitizer ``-fsanitize=pointer-overflow`` check has 113 been extended to detect these cases, so that code relying on them can be 114 detected and fixed. 115 116* The Implicit Conversion Sanitizer (``-fsanitize=implicit-conversion``) has 117 learned to sanitize pre/post increment/decrement of types with bit width 118 smaller than ``int``. 119 120* For X86 target, ``-march=skylake-avx512``, ``-march=icelake-client``, 121 ``-march=icelake-server``, ``-march=cascadelake``, ``-march=cooperlake`` will default to 122 not using 512-bit zmm registers in vectorized code unless 512-bit intrinsics 123 are used in the source code. 512-bit operations are known to cause the CPUs 124 to run at a lower frequency which can impact performance. This behavior can be 125 changed by passing ``-mprefer-vector-width=512`` on the command line. 126 127* Clang now defaults to ``.init_array`` on Linux. It used to use ``.ctors`` if 128 the found GCC installation is older than 4.7.0. Add ``-fno-use-init-array`` to 129 get the old behavior (``.ctors``). 130 131* The behavior of the flag ``-flax-vector-conversions`` has been modified to 132 more closely match GCC, as described below. In Clang 10 onwards, command lines 133 specifying this flag do not permit implicit vector bitcasts between integer 134 vectors and floating-point vectors. Such conversions are still permitted by 135 default, however, and the default can be explicitly requested with the 136 Clang-specific flag ``-flax-vector-conversions=all``. In a future release of 137 Clang, we intend to change the default to ``-fno-lax-vector-conversions``. 138 139* Improved support for ``octeon`` MIPS-family CPU. Added ``octeon+`` to 140 the list of of CPUs accepted by the driver. 141 142* For the WebAssembly target, the ``wasm-opt`` tool will now be run if it is 143 found in the PATH, which can reduce code size. 144 145* For the RISC-V target, floating point registers can now be used in inline 146 assembly constraints. 147 148New Compiler Flags 149------------------ 150 151- The ``-fgnuc-version=`` flag now controls the value of ``__GNUC__`` and related 152 macros. This flag does not enable or disable any GCC extensions implemented in 153 Clang. Setting the version to zero causes Clang to leave ``__GNUC__`` and 154 other GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. 155 156- vzeroupper insertion on X86 targets can now be disabled with ``-mno-vzeroupper``. 157 You can also force vzeroupper insertion to be used on CPUs that normally 158 wouldn't with ``-mvzeroupper``. 159 160- The ``-fno-concept-satisfaction-caching`` can be used to disable caching for 161 satisfactions of Concepts. The C++2a draft standard does not currently permit 162 this caching, but disabling it may incur significant compile-time costs. This 163 flag is intended for experimentation purposes and may be removed at any time; 164 please let us know if you encounter a situation where you need to specify this 165 flag for correct program behavior. 166 167- The ``-ffixed-xX`` flags now work on RISC-V. These reserve the corresponding 168 general-purpose registers. 169 170- RISC-V has added ``-mcmodel=medany`` and ``-mcmodel=medlow`` as aliases for 171 ``-mcmodel=small`` and ``-mcmodel=medium`` respectively. Preprocessor definitions 172 for ``__riscv_cmodel_medlow`` and ``__riscv_cmodel_medany`` have been corrected. 173 174- ``-fmacro-prefix-map=OLD=NEW`` substitutes directory prefix ``OLD`` for 175 ``NEW`` in predefined preprocessor macros such as ``__FILE__``. This helps 176 with reproducible builds that are location independent. The new 177 ``-ffile-prefix-map`` option is equivalent to specifying both 178 ``-fdebug-prefix-map`` and ``-fmacro-prefix-map``. 179 180- ``-fpatchable-function-entry=N[,M]`` is added to generate M NOPs before the 181 function entry and N-M NOPs after the function entry. This is used by AArch64 182 ftrace in the Linux kernel. 183 184- ``-mbranches-within-32B-boundaries`` is added as an x86 assembler mitigation 185 for Intel's Jump Condition Code Erratum. 186 187- -ffp-exception-behavior={ignore,maytrap,strict} allows the user to specify 188 the floating-point exception behavior. The default setting is ``ignore``. 189 190- -ffp-model={precise,strict,fast} provides the user an umbrella option to 191 simplify access to the many single purpose floating point options. The default 192 setting is ``precise``. 193 194Deprecated Compiler Flags 195------------------------- 196 197The following options are deprecated and ignored. They will be removed in 198future versions of Clang. 199 200- ``-mmpx`` used to enable the ``__MPX__`` preprocessor define for the Intel MPX 201 instructions. There were no MPX intrinsics. 202 203- ``-mno-mpx`` used to disable ``-mmpx`` and is the default behavior. 204 205- ``-fconcepts-ts`` previously used to enable experimental concepts support. Use 206 -std=c++2a instead to enable Concepts support. 207 208Modified Compiler Flags 209----------------------- 210 211- RISC-V now sets the architecture (riscv32/riscv64) based on the value provided 212 to the ``-march`` flag, overriding the target provided by ``-triple``. 213 214- ``-flax-vector-conversions`` has been split into three different levels of 215 laxness, and has been updated to match the GCC semantics: 216 217 - ``-flax-vector-conversions=all``: This is Clang's current default, and 218 permits implicit vector conversions (performed as bitcasts) between any 219 two vector types of the same overall bit-width. 220 Former synonym: ``-flax-vector-conversions`` (Clang <= 9). 221 222 - ``-flax-vector-conversions=integer``: This permits implicit vector 223 conversions (performed as bitcasts) between any two integer vector types of 224 the same overall bit-width. 225 Synonym: ``-flax-vector-conversions`` (Clang >= 10). 226 227 - ``-flax-vector-conversions=none``: Do not perform any implicit bitcasts 228 between vector types. 229 Synonym: ``-fno-lax-vector-conversions``. 230 231- ``-debug-info-kind`` now has an option ``-debug-info-kind=constructor``, 232 which is one level below ``-debug-info-kind=limited``. This option causes 233 debug info for classes to be emitted only when a constructor is emitted. 234 235- RISC-V now chooses a slightly different sysroot path and defaults to using 236 compiler-rt if no GCC installation is detected. 237 238- RISC-V now supports multilibs in baremetal environments. This support does not 239 extend to supporting multilib aliases. 240 241Attribute Changes in Clang 242-------------------------- 243 244- Support was added for function ``__attribute__((target("branch-protection=...")))`` 245 246Windows Support 247--------------- 248 249- Previous Clang versions contained a work-around to avoid an issue with the 250 standard library headers in Visual Studio 2019 versions prior to 16.3. This 251 work-around has now been removed, and users of Visual Studio 2019 are 252 encouraged to upgrade to 16.3 or later, otherwise they may see link errors as 253 below: 254 255 .. code-block:: console 256 257 error LNK2005: "bool const std::_Is_integral<int>" (??$_Is_integral@H@std@@3_NB) already defined 258 259- The ``.exe`` output suffix is now added implicitly in MinGW mode, when 260 Clang is running on Windows (matching GCC's behaviour) 261 262- Fixed handling of TLS variables that are shared between object files 263 in MinGW environments 264 265- The ``-cfguard`` flag now emits Windows Control Flow Guard checks on indirect 266 function calls. The previous behavior is still available with the 267 ``-cfguard-nochecks`` flag. These checks can be disabled for specific 268 functions using the new ``__declspec(guard(nocf))`` modifier. 269 270 271C++ Language Changes in Clang 272----------------------------- 273 274- The behaviour of the `gnu_inline` attribute now matches GCC, for cases 275 where used without the `extern` keyword. As this is a change compared to 276 how it behaved in previous Clang versions, a warning is emitted for this 277 combination. 278 279Objective-C Language Changes in Clang 280------------------------------------- 281 282- In both Objective-C and 283 Objective-C++, ``-Wcompare-distinct-pointer-types`` will now warn when 284 comparing ObjC ``Class`` with an ObjC instance type pointer. 285 286 .. code-block:: objc 287 288 Class clz = ...; 289 MyType *instance = ...; 290 bool eq = (clz == instance); // Previously undiagnosed, now warns. 291 292- Objective-C++ now diagnoses conversions between ``Class`` and ObjC 293 instance type pointers. Such conversions already emitted an 294 on-by-default ``-Wincompatible-pointer-types`` warning in Objective-C 295 mode, but had inadvertently been missed entirely in 296 Objective-C++. This has been fixed, and they are now diagnosed as 297 errors, consistent with the usual C++ treatment for conversions 298 between unrelated pointer types. 299 300 .. code-block:: objc 301 302 Class clz = ...; 303 MyType *instance = ...; 304 clz = instance; // Previously undiagnosed, now an error. 305 instance = clz; // Previously undiagnosed, now an error. 306 307 One particular issue you may run into is attempting to use a class 308 as a key in a dictionary literal. This will now result in an error, 309 because ``Class`` is not convertible to ``id<NSCopying>``. (Note that 310 this was already a warning in Objective-C mode.) While an arbitrary 311 ``Class`` object is not guaranteed to implement ``NSCopying``, the 312 default metaclass implementation does. Therefore, the recommended 313 solution is to insert an explicit cast to ``id``, which disables the 314 type-checking here. 315 316 .. code-block:: objc 317 318 Class cls = ...; 319 320 // Error: cannot convert from Class to id<NSCoding>. 321 NSDictionary* d = @{cls : @"Hello"}; 322 323 // Fix: add an explicit cast to 'id'. 324 NSDictionary* d = @{(id)cls : @"Hello"}; 325 326OpenCL Kernel Language Changes in Clang 327--------------------------------------- 328 329Generic changes: 330 331- Made ``__private`` to be appear explicitly in diagnostics, AST, etc. 332- Fixed diagnostics of ``enqueue_kernel``. 333 334OpenCL builtin functions: 335 336- The majority of the OpenCL builtin functions are now available through 337 the experimental `TableGen` driven ``-fdeclare-opencl-builtins`` option. 338- Align the ``enqueue_marker`` declaration in standard ``opencl-c.h`` to the 339 OpenCL spec. 340- Avoid a void pointer cast in the ``CLK_NULL_EVENT`` definition. 341- Aligned OpenCL with c11 atomic fetch max/min. 342 343Changes in C++ for OpenCL: 344 345- Fixed language mode predefined macros for C++ mode. 346- Allow OpenCL C style compound vector initialization. 347- Improved destructor support. 348- Implemented address space deduction for pointers/references 349 to arrays and auto variables. 350- Added address spaces support for lambdas and ``constexpr``. 351- Fixed misc address spaces usages in classes. 352 353 354ABI Changes in Clang 355-------------------- 356 357- GCC passes vectors of __int128 in memory on X86-64. Clang historically 358 broke the vectors into multiple scalars using two 64-bit values for each 359 element. Clang now matches the GCC behavior on Linux and NetBSD. You can 360 switch back to old API behavior with flag: ``-fclang-abi-compat=9.0``. 361 362- RISC-V now chooses a default ``-march=`` and ``-mabi=`` to match (in almost 363 all cases) the GCC defaults. On baremetal targets, where neither ``-march=`` 364 nor ``-mabi=`` are specified, Clang now differs from GCC by defaulting to 365 ``-march=rv32imac`` ``-mabi=ilp32`` or ``-march=rv64imac`` ``-mabi=lp64`` 366 depending on the architecture in the target triple. These do not always match 367 the defaults in Clang 9. We strongly suggest that you explicitly pass 368 ``-march=`` and ``-mabi=`` when compiling for RISC-V, due to how extensible 369 this architecture is. 370 371- RISC-V now uses `target-abi` module metadata to encode the chosen psABI. This 372 ensures that the correct lowering will be done by LLVM when LTO is enabled. 373 374- An issue with lowering return types in the RISC-V ILP32D psABI has been fixed. 375 376OpenMP Support in Clang 377----------------------- 378 379New features for OpenMP 5.0 were implemented. Use ``-fopenmp-version=50`` option to activate support for OpenMP 5.0. 380 381- Added support for ``device_type`` clause in declare target directive. 382- Non-static and non-ordered loops are nonmonotonic by default. 383- Teams-based directives can be used as a standalone directive. 384- Added support for collapsing of non-rectangular loops. 385- Added support for range-based loops. 386- Added support for collapsing of imperfectly nested loops. 387- Added support for ``master taskloop``, ``parallel master taskloop``, ``master taskloop simd`` and ``parallel master taskloop simd`` directives. 388- Added support for ``if`` clauses in simd-based directives. 389- Added support for unified shared memory for NVPTX target. 390- Added support for nested atomic and simd directives are allowed in sims-based directives. 391- Added support for non temporal clauses in sims-based directives. 392- Added basic support for conditional lastprivate variables 393 394Other improvements: 395 396- Added basic analysis for use of the uninitialized variables in clauses. 397- Bug fixes. 398 399 400Internal API Changes 401-------------------- 402 403These are major API changes that have happened since the 9.0.0 release of 404Clang. If upgrading an external codebase that uses Clang as a library, 405this section should help get you past the largest hurdles of upgrading. 406 407- libTooling APIs that transfer ownership of `FrontendAction` objects now pass 408 them by `unique_ptr`, making the ownership transfer obvious in the type 409 system. `FrontendActionFactory::create()` now returns a 410 `unique_ptr<FrontendAction>`. `runToolOnCode`, `runToolOnCodeWithArgs`, 411 `ToolInvocation::ToolInvocation()` now take a `unique_ptr<FrontendAction>`. 412 413Build System Changes 414-------------------- 415 416These are major changes to the build system that have happened since the 9.0.0 417release of Clang. Users of the build system should adjust accordingly. 418 419- In 8.0.0 and below, the install-clang-headers target would install clang's 420 resource directory headers. This installation is now performed by the 421 install-clang-resource-headers target. Users of the old install-clang-headers 422 target should switch to the new install-clang-resource-headers target. The 423 install-clang-headers target now installs clang's API headers (corresponding 424 to its libraries), which is consistent with the install-llvm-headers target. 425 426- In 9.0.0 and later Clang added a new target, clang-cpp, which generates a 427 shared library comprised of all the clang component libraries and exporting 428 the clang C++ APIs. Additionally the build system gained the new 429 "CLANG_LINK_CLANG_DYLIB" option, which defaults Off, and when set to On, will 430 force clang (and clang-based tools) to link the clang-cpp library instead of 431 statically linking clang's components. This option will reduce the size of 432 binary distributions at the expense of compiler performance. 433 434 435clang-format 436------------ 437 438- The ``Standard`` style option specifies which version of C++ should be used 439 when parsing and formatting C++ code. The set of allowed values has changed: 440 441 - ``Latest`` will always enable new C++ language features. 442 - ``c++03``, ``c++11``, ``c++14``, ``c++17``, ``c++20`` will pin to exactly 443 that language version. 444 - ``Auto`` is the default and detects style from the code (this is unchanged). 445 446 The previous values of ``Cpp03`` and ``Cpp11`` are deprecated. Note that 447 ``Cpp11`` is treated as ``Latest``, as this was always clang-format's 448 behavior. (One motivation for this change is the new name describes the 449 behavior better). 450 451- Clang-format has a new option called ``--dry-run`` or ``-n`` to emit a 452 warning for clang-format violations. This can be used together 453 with ``--ferror-limit=N`` to limit the number of warnings per file and ``--Werror`` 454 to make warnings into errors. 455 456- Option *IncludeIsMainSourceRegex* has been added to allow for additional 457 suffixes and file extensions to be considered as a source file 458 for execution of logic that looks for "main *include* file" to put 459 it on top. 460 461 By default, clang-format considers *source* files as "main" only when 462 they end with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, 463 ``.m`` or ``.mm`` extensions. This config option allows to 464 extend this set of source files considered as "main". 465 466 For example, if this option is configured to ``(Impl\.hpp)$``, 467 then a file ``ClassImpl.hpp`` is considered "main" (in addition to 468 ``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main 469 include file" logic will be executed (with *IncludeIsMainRegex* setting 470 also being respected in later phase). Without this option set, 471 ``ClassImpl.hpp`` would not have the main include file put on top 472 before any other include. 473 474- Options ``DeriveLineEnding`` and ``UseCRLF`` have been added to allow 475 clang-format to control the newlines. ``DeriveLineEnding`` is by default 476 ``true`` and reflects is the existing mechanism, which based is on majority 477 rule. The new options allows this to be turned off and ``UseCRLF`` to control 478 the decision as to which sort of line ending to use. 479 480- Option ``SpaceBeforeSquareBrackets`` has been added to insert a space before 481 array declarations. 482 483 .. code-block:: c++ 484 485 int a [5]; vs int a[5]; 486 487- Clang-format now supports JavaScript null operators. 488 489 .. code-block:: c++ 490 491 const x = foo ?? default; 492 const z = foo?.bar?.baz; 493 494- Option ``AlwaysBreakAfterReturnType`` now manages all operator functions. 495 496libclang 497-------- 498 499- Various changes to reduce discrepancies in destructor calls between the 500 generated ``CFG`` and the actual ``codegen``. 501 502 In particular: 503 504 - Respect C++17 copy elision; previously it would generate destructor calls 505 for elided temporaries, including in initialization and return statements. 506 507 - Don't generate duplicate destructor calls for statement expressions. 508 509 - Fix initialization lists. 510 511 - Fix comma operator. 512 513 - Change printing of implicit destructors to print the type instead of the 514 class name directly, matching the code for temporary object destructors. 515 The class name was blank for lambdas. 516 517 518Static Analyzer 519--------------- 520 521- New checker: ``alpha.cplusplus.PlacementNew`` to detect whether the storage 522 provided for default placement new is sufficiently large. 523 524- New checker: ``fuchsia.HandleChecker`` to detect leaks related to Fuchsia 525 handles. 526 527- New checker: ``security.insecureAPI.decodeValueOfObjCType`` warns about 528 potential buffer overflows when using ``[NSCoder decodeValueOfObjCType:at:]`` 529 530- ``deadcode.DeadStores`` now warns about nested dead stores. 531 532- Condition values that are relevant to the occurrence of a bug are far better 533 explained in bug reports. 534 535- Despite still being at an alpha stage, checkers implementing taint analyses 536 and C++ iterator rules were improved greatly. 537 538- Numerous smaller fixes. 539 540.. _release-notes-ubsan: 541 542Undefined Behavior Sanitizer (UBSan) 543------------------------------------ 544 545* The ``pointer-overflow`` check was extended added to catch the cases where 546 a non-zero offset is applied to a null pointer, or the result of 547 applying the offset is a null pointer. 548 549 .. code-block:: c++ 550 551 #include <cstdint> // for intptr_t 552 553 static char *getelementpointer_inbounds(char *base, unsigned long offset) { 554 // Potentially UB. 555 return base + offset; 556 } 557 558 char *getelementpointer_unsafe(char *base, unsigned long offset) { 559 // Always apply offset. UB if base is ``nullptr`` and ``offset`` is not 560 // zero, or if ``base`` is non-``nullptr`` and ``offset`` is 561 // ``-reinterpret_cast<intptr_t>(base)``. 562 return getelementpointer_inbounds(base, offset); 563 } 564 565 char *getelementpointer_safe(char *base, unsigned long offset) { 566 // Cast pointer to integer, perform usual arithmetic addition, 567 // and cast to pointer. This is legal. 568 char *computed = 569 reinterpret_cast<char *>(reinterpret_cast<intptr_t>(base) + offset); 570 // If either the pointer becomes non-``nullptr``, or becomes 571 // ``nullptr``, we must use ``computed`` result. 572 if (((base == nullptr) && (computed != nullptr)) || 573 ((base != nullptr) && (computed == nullptr))) 574 return computed; 575 // Else we can use ``getelementpointer_inbounds()``. 576 return getelementpointer_inbounds(base, offset); 577 } 578 579Changes deferred to Clang-11 release 580------------------------------------ 581 582- The next release of clang (clang-11) will upgrade the default C language 583 standard used if not specified via command line from gnu11 to gnu17. 584 585 586Additional Information 587====================== 588 589A wide variety of additional information is available on the `Clang web 590page <https://clang.llvm.org/>`_. The web page contains versions of the 591API documentation which are up-to-date with the Git version of 592the source code. You can access versions of these documents specific to 593this release by going into the "``clang/docs/``" directory in the Clang 594tree. 595 596If you have any questions or comments about Clang, please feel free to 597contact us via the `mailing 598list <https://lists.llvm.org/mailman/listinfo/cfe-dev>`_. 599