2022-02-01 23:13:01 -08:00
|
|
|
===========================================
|
|
|
|
Clang |release| |ReleaseNotesTitle|
|
|
|
|
===========================================
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
.. contents::
|
|
|
|
:local:
|
|
|
|
:depth: 2
|
|
|
|
|
|
|
|
Written by the `LLVM Team <https://llvm.org/>`_
|
|
|
|
|
2022-02-01 23:13:01 -08:00
|
|
|
.. only:: PreRelease
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2022-02-01 23:13:01 -08:00
|
|
|
.. warning::
|
|
|
|
These are in-progress notes for the upcoming Clang |version| release.
|
|
|
|
Release notes for previous releases can be found on
|
2023-03-05 00:56:15 +02:00
|
|
|
`the Releases Page <https://llvm.org/releases/>`_.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
Introduction
|
|
|
|
============
|
|
|
|
|
|
|
|
This document contains the release notes for the Clang C/C++/Objective-C
|
2022-02-01 23:13:01 -08:00
|
|
|
frontend, part of the LLVM Compiler Infrastructure, release |release|. Here we
|
2020-02-13 22:46:33 +01:00
|
|
|
describe the status of Clang in some detail, including major
|
|
|
|
improvements from the previous release and new feature work. For the
|
|
|
|
general LLVM release notes, see `the LLVM
|
2023-02-15 23:53:38 +02:00
|
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. For the libc++ release notes,
|
|
|
|
see `this page <https://libcxx.llvm.org/ReleaseNotes.html>`_. All LLVM releases
|
|
|
|
may be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
For more information about Clang or LLVM, including information about the
|
|
|
|
latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the
|
|
|
|
`LLVM Web Site <https://llvm.org>`_.
|
|
|
|
|
2022-09-15 07:29:49 -04:00
|
|
|
Potentially Breaking Changes
|
|
|
|
============================
|
|
|
|
These changes are ones which we think may surprise users when upgrading to
|
|
|
|
Clang |release| because of the opportunity they pose for disruption to existing
|
|
|
|
code bases.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
|
|
|
|
C/C++ Language Potentially Breaking Changes
|
|
|
|
-------------------------------------------
|
2023-05-23 14:41:43 -07:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C++ Specific Potentially Breaking Changes
|
|
|
|
-----------------------------------------
|
|
|
|
|
|
|
|
ABI Changes in This Version
|
|
|
|
---------------------------
|
|
|
|
|
2022-02-01 23:13:01 -08:00
|
|
|
What's New in Clang |release|?
|
|
|
|
==============================
|
2020-02-13 22:46:33 +01:00
|
|
|
Some of the major new features and improvements to Clang are listed
|
|
|
|
here. Generic improvements to Clang as a whole or to its underlying
|
|
|
|
infrastructure are described first, followed by language-specific
|
|
|
|
sections with improvements to Clang's support for those languages.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C++ Language Changes
|
|
|
|
--------------------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C++20 Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2022-03-12 20:49:01 +01:00
|
|
|
|
2023-04-30 15:27:00 +02:00
|
|
|
C++23 Feature Support
|
2023-02-15 23:53:38 +02:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
2023-05-12 07:30:21 -07:00
|
|
|
C++2c Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
2023-06-22 14:18:38 +02:00
|
|
|
- Implemented `P2169R4: A nice placeholder with no name <https://wg21.link/P2169R4>`_. This allows using ``_``
|
|
|
|
as a variable name multiple times in the same scope and is supported in all C++ language modes as an extension.
|
|
|
|
An extension warning is produced when multiple variables are introduced by ``_`` in the same scope.
|
|
|
|
Unused warnings are no longer produced for variables named ``_``.
|
|
|
|
Currently, inspecting placeholders variables in a debugger when more than one are declared in the same scope
|
|
|
|
is not supported.
|
|
|
|
|
|
|
|
.. code-block:: cpp
|
2023-08-04 11:43:07 -04:00
|
|
|
|
2023-06-22 14:18:38 +02:00
|
|
|
struct S {
|
|
|
|
int _, _; // Was invalid, now OK
|
|
|
|
};
|
|
|
|
void func() {
|
|
|
|
int _, _; // Was invalid, now OK
|
|
|
|
}
|
|
|
|
void other() {
|
|
|
|
int _; // Previously diagnosed under -Wunused, no longer diagnosed
|
|
|
|
}
|
|
|
|
|
2021-07-10 15:52:54 +02:00
|
|
|
- Attributes now expect unevaluated strings in attributes parameters that are string literals.
|
|
|
|
This is applied to both C++ standard attributes, and other attributes supported by Clang.
|
2023-08-17 15:44:57 +08:00
|
|
|
This completes the implementation of `P2361R6 Unevaluated Strings <https://wg21.link/P2361R6>`_
|
2023-06-22 14:18:38 +02:00
|
|
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Resolutions to C++ Defect Reports
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2023-08-17 22:57:42 +08:00
|
|
|
- Implemented `CWG1473 <https://wg21.link/CWG1473>`_ which allows spaces after ``operator""``.
|
|
|
|
Clang used to err on the lack of space when the literal suffix identifier was invalid in
|
|
|
|
all the language modes, which contradicted the deprecation of the whitespaces.
|
|
|
|
Also turn on ``-Wdeprecated-literal-operator`` by default in all the language modes.
|
2023-02-15 23:53:38 +02:00
|
|
|
|
|
|
|
C Language Changes
|
|
|
|
------------------
|
2023-08-02 15:23:47 -07:00
|
|
|
- ``structs``, ``unions``, and ``arrays`` that are const may now be used as
|
|
|
|
constant expressions. This change is more consistent with the behavior of
|
|
|
|
GCC.
|
2023-02-15 23:53:38 +02:00
|
|
|
|
2023-08-10 14:18:36 -04:00
|
|
|
C23 Feature Support
|
2023-02-15 23:53:38 +02:00
|
|
|
^^^^^^^^^^^^^^^^^^^
|
2023-08-10 13:56:15 -04:00
|
|
|
- Clang now accepts ``-std=c23`` and ``-std=gnu23`` as language standard modes,
|
|
|
|
and the ``__STDC_VERSION__`` macro now expands to ``202311L`` instead of its
|
|
|
|
previous placeholder value. Clang continues to accept ``-std=c2x`` and
|
|
|
|
``-std=gnu2x`` as aliases for C23 and GNU C23, respectively.
|
[C2x] Update 'nullptr' implementation based on CD comments
We filed some CD ballot comments which WG14 considered during the
ballot comment resolution meetings in Jan and Feb 2023, and this
updates our implementation based on the decisions reached. Those
decisions were (paraphrased for brevity):
US 9-034 (REJECTED)
allow (void *)nullptr to be a null pointer constant
US 10-035 (ACCEPTED)
accept the following code, as in C++:
void func(nullptr_t); func(0);
US 22-058 (REJECTED)
accept the following code, as in C++:
nullptr_t val; (void)(1 ? val : 0); (void)(1 ? nullptr : 0);
US 23-062 (REJECTED)
reject the following code, as in C++:
nullptr_t val; bool b1 = val; bool b2 = nullptr;
US 24-061 (ACCEPTED)
accept the following code, as in C++:
nullptr_t val; val = 0;
US 21-068 (ACCEPTED)
accept the following code, as in C++:
(nullptr_t)nullptr;
GB-071 (ACCEPTED)
accept the following code, as in C++:
nullptr_t val; (void)(val == nullptr);
This patch updates the implementation as appropriate, but is primarily
focused around US 10-035, US 24-061, and US 23-062 in terms of
functional changes.
Differential Revision: https://reviews.llvm.org/D148800
2023-05-03 14:06:04 -04:00
|
|
|
|
2022-08-26 10:04:06 -04:00
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
-------------------------------------------------
|
2022-08-26 09:17:14 -04:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
New Compiler Flags
|
|
|
|
------------------
|
[Driver] Add -dumpdir and change -gsplit-dwarf .dwo names for linking
When the final phase is linking, Clang currently places `.dwo` files in the
current directory (like the `-c` behavior for multiple inputs).
Strangely, -fdebug-compilation-dir=/-ffile-compilation-dir= is considered, which
is untested.
GCC has a more useful behavior that derives auxiliary filenames from the final
output (-o).
```
gcc -c -g -gsplit-dwarf d/a.c d/b.c # a.dwo b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c -o e/x # e/x-a.dwo e/x-b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c # a-a.dwo a-b.dwo
```
Port a useful subset of GCC behaviors that are easy to describe to Clang.
* Add a driver and cc1 option -dumpdir
* When the final phase is link, add a default -dumpdir if not specified by the user
* Forward -dumpdir to -cc1 command lines
* tools::SplitDebugName prefers -dumpdir when constructing the .dwo filename
GCC provides -dumpbase. If we use just one of -dumpdir and -dumpbase,
-dumpbase isn't very useful as it appends a dash.
```
gcc -g -gsplit-dwarf -dumpdir e d/a.c # ea.dwo
gcc -g -gsplit-dwarf -dumpdir e/ d/a.c # e/a.dwo
gcc -g -gsplit-dwarf -dumpbase e d/a.c # e-a.dwo
gcc -g -gsplit-dwarf -dumpbase e/ d/a.c # e/-a.dwo
```
If we specify both `-dumpdir` and `-dumpbase`, we can avoid the influence of the
source filename when there is one input file.
```
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c # f/x.dwo
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c d/b.c # f/x-a.dwo f/x-b.dwo
```
Given the above examples, I think -dumpbase is not useful.
GCC -save-temps has interesting interaction with -dumpdir as -save-temps
generated files are considered auxiliary files like .dwo files.
For Clang, with this patch, -save-temps and -dumpdir are orthogonal, which is
easier to explain.
```
gcc -g -gsplit-dwarf d/a.c -o e/x -dumpdir f/ -save-temps=obj # e/a.{i,s,o,dwo}
gcc -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # f/a.{i,s,o,dwo}
clang -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # e/a.{i,s,o} f/a.dwo
```
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D149193
2023-05-09 14:43:46 -07:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Deprecated Compiler Flags
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
Modified Compiler Flags
|
|
|
|
-----------------------
|
2023-01-23 13:25:55 +02:00
|
|
|
|
2023-08-18 09:15:37 -07:00
|
|
|
* ``-Woverriding-t-option`` is renamed to ``-Woverriding-option``.
|
|
|
|
|
2020-12-17 09:23:02 -05:00
|
|
|
Removed Compiler Flags
|
|
|
|
-------------------------
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Attribute Changes in Clang
|
|
|
|
--------------------------
|
2023-01-20 23:31:53 +00:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Improvements to Clang's diagnostics
|
|
|
|
-----------------------------------
|
2023-07-31 17:05:56 +09:00
|
|
|
- Clang constexpr evaluator now prints template arguments when displaying
|
|
|
|
template-specialization function calls.
|
2023-08-08 15:53:17 +09:00
|
|
|
- Clang contexpr evaluator now displays notes as well as an error when a constructor
|
|
|
|
of a base class is not called in the constructor of its derived class.
|
2023-08-08 13:41:17 -07:00
|
|
|
- Clang no longer emits ``-Wmissing-variable-declarations`` for variables declared
|
|
|
|
with the ``register`` storage class.
|
2023-08-17 17:55:48 +09:00
|
|
|
- Clang's ``-Wtautological-negation-compare`` flag now diagnoses logical
|
|
|
|
tautologies like ``x && !x`` and ``!x || x`` in expressions. This also
|
|
|
|
makes ``-Winfinite-recursion`` diagnose more cases.
|
|
|
|
(`#56035: <https://github.com/llvm/llvm-project/issues/56035>`_).
|
2023-01-31 11:43:34 -08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes in This Version
|
|
|
|
-------------------------
|
2023-07-24 17:34:08 -07:00
|
|
|
- Fixed an issue where a class template specialization whose declaration is
|
|
|
|
instantiated in one module and whose definition is instantiated in another
|
|
|
|
module may end up with members associated with the wrong declaration of the
|
|
|
|
class, which can result in miscompiles in some cases.
|
2023-08-04 01:00:44 -07:00
|
|
|
- Fix crash on use of a variadic overloaded operator.
|
2023-08-17 07:10:00 -04:00
|
|
|
(`#42535 <https://github.com/llvm/llvm-project/issues/42535>_`)
|
|
|
|
- Fix a hang on valid C code passing a function type as an argument to
|
|
|
|
``typeof`` to form a function declaration.
|
|
|
|
(`#64713 <https://github.com/llvm/llvm-project/issues/64713>_`)
|
2023-02-09 10:53:39 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to Compiler Builtins
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-05-02 17:06:04 -04:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to Attribute Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-08-26 19:26:32 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to C++ Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
2023-01-18 08:49:45 -05:00
|
|
|
|
2023-07-03 13:01:17 +02:00
|
|
|
- Clang limits the size of arrays it will try to evaluate at compile time
|
|
|
|
to avoid memory exhaustion.
|
|
|
|
This limit can be modified by `-fconstexpr-steps`.
|
|
|
|
(`#63562 <https://github.com/llvm/llvm-project/issues/63562>`_)
|
|
|
|
|
2023-07-28 10:07:47 +02:00
|
|
|
- Fix a crash caused by some named unicode escape sequences designating
|
|
|
|
a Unicode character whose name contains a ``-``.
|
2023-08-17 15:44:57 +08:00
|
|
|
(Fixes `#64161 <https://github.com/llvm/llvm-project/issues/64161>`_)
|
2023-07-28 10:07:47 +02:00
|
|
|
|
2023-08-18 23:36:04 -07:00
|
|
|
- Fix cases where we ignore ambiguous name lookup when looking up members.
|
2023-08-17 15:44:57 +08:00
|
|
|
(`#22413 <https://github.com/llvm/llvm-project/issues/22413>`_),
|
|
|
|
(`#29942 <https://github.com/llvm/llvm-project/issues/29942>`_),
|
|
|
|
(`#35574 <https://github.com/llvm/llvm-project/issues/35574>`_) and
|
|
|
|
(`#27224 <https://github.com/llvm/llvm-project/issues/27224>`_).
|
2023-07-28 15:21:57 -07:00
|
|
|
|
2023-08-08 00:51:40 -07:00
|
|
|
- Clang emits an error on substitution failure within lambda body inside a
|
|
|
|
requires-expression. This fixes:
|
2023-08-17 15:44:57 +08:00
|
|
|
(`#64138 <https://github.com/llvm/llvm-project/issues/64138>`_).
|
2023-08-08 00:51:40 -07:00
|
|
|
|
2023-08-17 13:44:05 +08:00
|
|
|
- Update ``FunctionDeclBitfields.NumFunctionDeclBits``. This fixes:
|
|
|
|
(`#64171 <https://github.com/llvm/llvm-project/issues/64171>`_).
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to AST Handling
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
2023-08-02 10:54:18 +08:00
|
|
|
- Fixed an import failure of recursive friend class template.
|
|
|
|
`Issue 64169 <https://github.com/llvm/llvm-project/issues/64169>`_
|
2023-08-02 11:05:14 +08:00
|
|
|
- Remove unnecessary RecordLayout computation when importing UnaryOperator. The
|
|
|
|
computed RecordLayout is incorrect if fields are not completely imported and
|
|
|
|
should not be cached.
|
|
|
|
`Issue 64170 <https://github.com/llvm/llvm-project/issues/64170>`_
|
2023-01-17 11:29:04 -08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Miscellaneous Bug Fixes
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Miscellaneous Clang Crashes Fixed
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2023-08-03 12:14:08 +08:00
|
|
|
- Fixed a crash when parsing top-level ObjC blocks that aren't properly
|
|
|
|
terminated. Clang should now also recover better when an @end is missing
|
|
|
|
between blocks.
|
|
|
|
`Issue 64065 <https://github.com/llvm/llvm-project/issues/64065>`_
|
2023-08-10 14:29:06 +08:00
|
|
|
- Fixed a crash when check array access on zero-length element.
|
|
|
|
`Issue 64564 <https://github.com/llvm/llvm-project/issues/64564>`_
|
2022-05-03 14:13:56 -04:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Target Specific Changes
|
|
|
|
-----------------------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-03-13 09:33:08 -05:00
|
|
|
AMDGPU Support
|
|
|
|
^^^^^^^^^^^^^^
|
2023-08-11 16:37:42 -07:00
|
|
|
- Use pass-by-reference (byref) in stead of pass-by-value (byval) for struct
|
|
|
|
arguments in C ABI. Callee is responsible for allocating stack memory and
|
|
|
|
copying the value of the struct if modified. Note that AMDGPU backend still
|
|
|
|
supports byval for struct arguments.
|
2023-03-13 09:33:08 -05:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
X86 Support
|
|
|
|
^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Arm and AArch64 Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Windows Support
|
|
|
|
^^^^^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
LoongArch Support
|
|
|
|
^^^^^^^^^^^^^^^^^
|
2023-01-17 20:53:58 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
RISC-V Support
|
|
|
|
^^^^^^^^^^^^^^
|
2023-08-03 17:46:46 +08:00
|
|
|
- Unaligned memory accesses can be toggled by ``-m[no-]unaligned-access`` or the
|
|
|
|
aliases ``-m[no-]strict-align``.
|
2022-08-18 14:39:37 -07:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
CUDA/HIP Language Changes
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-10-18 10:50:37 -07:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
CUDA Support
|
|
|
|
^^^^^^^^^^^^
|
2022-01-23 20:45:25 -08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
AIX Support
|
|
|
|
^^^^^^^^^^^
|
[Clang][AArch64] Support AArch64 target(..) attribute formats.
This adds support under AArch64 for the target("..") attributes. The
current parsing is very X86-shaped, this patch attempts to bring it line
with the GCC implementation from
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes.
The supported formats are:
- "arch=<arch>" strings, that specify the architecture features for a
function as per the -march=arch+feature option.
- "cpu=<cpu>" strings, that specify the target-cpu and any implied
atributes as per the -mcpu=cpu+feature option.
- "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as
per -mtune.
- "+<feature>", "+no<feature>" enables/disables the specific feature, for
compatibility with GCC target attributes.
- "<feature>", "no-<feature>" enabled/disables the specific feature, for
backward compatibility with previous releases.
To do this, the parsing of target attributes has been moved into
TargetInfo to give the target the opportunity to override the existing
parsing. The only non-aarch64 change should be a minor alteration to the
error message, specifying using "CPU" to describe the cpu, not
"architecture", and the DuplicateArch/Tune from ParsedTargetAttr have
been combined into a single option.
Differential Revision: https://reviews.llvm.org/D133848
2022-10-01 15:40:59 +01:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
WebAssembly Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
[ARM] Allow selecting hard-float ABI in integer-only MVE.
Armv8.1-M can be configured to support the integer subset of the MVE
vector instructions, and no floating point. In that situation, the FP
and vector registers still exist, and so do the load, store and move
instructions that transfer data in and out of them. So there's no
reason the hard floating point ABI can't be supported, and you might
reasonably want to use it, for the sake of intrinsics-based code
passing explicit MVE vector types between functions.
But the selection of the hard float ABI in the backend was gated on
Subtarget->hasVFP2Base(), which is false in the case of integer MVE
and no FP.
As a result, you'd silently get the soft float ABI even if you
deliberately tried to select it, e.g. with clang options such as
--target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+nofp+mve
The hard float ABI should have been gated on the weaker condition
Subtarget->hasFPRegs(), because the only requirement for being able to
pass arguments in the FP registers is that the registers themselves
should exist.
I haven't added a new test, because changing the existing
CodeGen/Thumb2/float-ops.ll test seemed sufficient. But I've added a
comment explaining why the results are expected to be what they are.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D142703
2023-01-31 17:31:33 +00:00
|
|
|
|
2022-02-06 08:20:54 -05:00
|
|
|
AVR Support
|
|
|
|
^^^^^^^^^^^
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
DWARF Support in Clang
|
|
|
|
----------------------
|
2023-02-13 18:29:16 +00:00
|
|
|
|
2021-11-09 09:35:25 -05:00
|
|
|
Floating Point Support in Clang
|
|
|
|
-------------------------------
|
2023-07-31 10:15:58 -07:00
|
|
|
- Add ``__builtin_elementwise_log`` builtin for floating point types only.
|
|
|
|
- Add ``__builtin_elementwise_log10`` builtin for floating point types only.
|
|
|
|
- Add ``__builtin_elementwise_log2`` builtin for floating point types only.
|
|
|
|
- Add ``__builtin_elementwise_exp`` builtin for floating point types only.
|
|
|
|
- Add ``__builtin_elementwise_exp2`` builtin for floating point types only.
|
|
|
|
- Add ``__builtin_set_flt_rounds`` builtin for X86, x86_64, Arm and AArch64 only.
|
|
|
|
- Add ``__builtin_elementwise_pow`` builtin for floating point types only.
|
|
|
|
- Add ``__builtin_elementwise_bitreverse`` builtin for integer types only.
|
2023-07-31 16:18:45 -04:00
|
|
|
- Add ``__builtin_elementwise_sqrt`` builtin for floating point types only.
|
2021-11-09 09:35:25 -05:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
AST Matchers
|
|
|
|
------------
|
2023-08-07 21:53:14 +08:00
|
|
|
- Add ``convertVectorExpr``.
|
2023-08-07 21:48:28 +08:00
|
|
|
- Add ``dependentSizedExtVectorType``.
|
2023-08-15 10:57:04 +08:00
|
|
|
- Add ``macroQualifiedType``.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
clang-format
|
|
|
|
------------
|
|
|
|
|
|
|
|
libclang
|
|
|
|
--------
|
2022-08-25 08:35:46 +02:00
|
|
|
|
2023-08-11 10:02:06 -04:00
|
|
|
- Exposed arguments of ``clang::annotate``.
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Static Analyzer
|
|
|
|
---------------
|
2023-07-24 08:26:54 +02:00
|
|
|
|
2023-05-31 14:58:49 +02:00
|
|
|
- Added a new checker ``core.BitwiseShift`` which reports situations where
|
|
|
|
bitwise shift operators produce undefined behavior (because some operand is
|
|
|
|
negative or too large).
|
|
|
|
|
2022-09-26 17:41:37 -07:00
|
|
|
.. _release-notes-sanitizers:
|
|
|
|
|
|
|
|
Sanitizers
|
|
|
|
----------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-04-04 09:21:04 -04:00
|
|
|
Python Binding Changes
|
|
|
|
----------------------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
Additional Information
|
|
|
|
======================
|
|
|
|
|
|
|
|
A wide variety of additional information is available on the `Clang web
|
|
|
|
page <https://clang.llvm.org/>`_. The web page contains versions of the
|
2020-03-22 22:18:40 +01:00
|
|
|
API documentation which are up-to-date with the Git version of
|
2020-02-13 22:46:33 +01:00
|
|
|
the source code. You can access versions of these documents specific to
|
|
|
|
this release by going into the "``clang/docs/``" directory in the Clang
|
|
|
|
tree.
|
|
|
|
|
|
|
|
If you have any questions or comments about Clang, please feel free to
|
2023-02-15 23:53:38 +02:00
|
|
|
contact us on the `Discourse forums (Clang Frontend category)
|
2022-07-01 14:07:48 -07:00
|
|
|
<https://discourse.llvm.org/c/clang/6>`_.
|