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.
|
|
|
|
|
|
2024-08-06 08:35:56 -04:00
|
|
|
- The ``le32`` and ``le64`` targets have been removed.
|
|
|
|
|
|
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
|
|
|
|
|
-----------------------------------------
|
2024-05-22 18:32:25 +02:00
|
|
|
|
2024-08-04 10:34:04 +02:00
|
|
|
- The type trait builtin ``__is_nullptr`` has been removed, since it has very
|
|
|
|
|
few users and can be written as ``__is_same(__remove_cv(T), decltype(nullptr))``,
|
|
|
|
|
which GCC supports as well.
|
|
|
|
|
|
2024-08-14 20:51:45 +02:00
|
|
|
- Clang will now correctly diagnose as ill-formed a constant expression where an
|
|
|
|
|
enum without a fixed underlying type is set to a value outside the range of
|
|
|
|
|
the enumeration's values.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
enum E { Zero, One, Two, Three, Four };
|
|
|
|
|
constexpr E Val1 = (E)3; // Ok
|
|
|
|
|
constexpr E Val2 = (E)7; // Ok
|
|
|
|
|
constexpr E Val3 = (E)8; // Now ill-formed, out of the range [0, 7]
|
|
|
|
|
constexpr E Val4 = (E)-1; // Now ill-formed, out of the range [0, 7]
|
|
|
|
|
|
|
|
|
|
Since Clang 16, it has been possible to suppress the diagnostic via
|
|
|
|
|
`-Wno-enum-constexpr-conversion`, to allow for a transition period for users.
|
|
|
|
|
Now, in Clang 20, **it is no longer possible to suppress the diagnostic**.
|
|
|
|
|
|
2024-08-15 00:55:54 +02:00
|
|
|
- Extraneous template headers are now ill-formed by default.
|
|
|
|
|
This error can be disable with ``-Wno-error=extraneous-template-head``.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
template <> // error: extraneous template head
|
|
|
|
|
template <typename T>
|
|
|
|
|
void f();
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
ABI Changes in This Version
|
|
|
|
|
---------------------------
|
2024-07-04 10:17:32 -07:00
|
|
|
|
2023-10-26 19:28:28 +01:00
|
|
|
AST Dumping Potentially Breaking Changes
|
|
|
|
|
----------------------------------------
|
|
|
|
|
|
2024-01-30 09:30:20 -08:00
|
|
|
Clang Frontend Potentially Breaking Changes
|
|
|
|
|
-------------------------------------------
|
2024-05-14 16:09:57 -04:00
|
|
|
|
2024-06-14 11:19:28 +02:00
|
|
|
Clang Python Bindings Potentially Breaking Changes
|
|
|
|
|
--------------------------------------------------
|
2024-07-30 15:21:02 +01:00
|
|
|
- Parts of the interface returning string results will now return
|
2024-08-11 10:39:29 +01:00
|
|
|
the empty string ``""`` when no result is available, instead of ``None``.
|
|
|
|
|
- Calling a property on the ``CompletionChunk`` or ``CompletionString`` class
|
|
|
|
|
statically now leads to an error, instead of returning a ``CachedProperty`` object
|
2024-07-30 15:21:02 +01:00
|
|
|
that is used internally. Properties are only available on instances.
|
2024-08-16 00:32:58 +02:00
|
|
|
- For a single-line ``SourceRange`` and a ``SourceLocation`` in the same line,
|
|
|
|
|
but after the end of the ``SourceRange``, ``SourceRange.__contains__``
|
|
|
|
|
used to incorrectly return ``True``. (#GH22617), (#GH52827)
|
2024-06-14 11:19:28 +02:00
|
|
|
|
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
|
|
|
|
|
--------------------
|
2024-08-08 23:38:08 -03:00
|
|
|
- Allow single element access of GCC vector/ext_vector_type object to be
|
|
|
|
|
constant expression. Supports the `V.xyzw` syntax and other tidbits
|
2024-08-07 16:11:08 +05:30
|
|
|
as seen in OpenCL. Selecting multiple elements is left as a future work.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-04-26 12:05:15 -04:00
|
|
|
C++17 Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2024-05-22 12:37:27 +08:00
|
|
|
C++14 Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
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
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2024-07-24 08:09:06 +02:00
|
|
|
- Removed the restriction to literal types in constexpr functions in C++23 mode.
|
2023-12-07 14:52:10 +01:00
|
|
|
|
2023-05-12 07:30:21 -07:00
|
|
|
C++2c Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2024-08-14 20:15:56 +04:00
|
|
|
- Add ``__builtin_is_implicit_lifetime`` intrinsic, which supports
|
|
|
|
|
`P2647R1 A trait for implicit lifetime types <https://wg21.link/p2674r1>`_
|
|
|
|
|
|
2024-07-26 11:09:54 +04:00
|
|
|
- Add ``__builtin_is_virtual_base_of`` intrinsic, which supports
|
|
|
|
|
`P2985R0 A type trait for detecting virtual base classes <https://wg21.link/p2985r0>`_
|
|
|
|
|
|
2024-08-15 21:16:30 +02:00
|
|
|
- Implemented `P2893R3 Variadic Friends <https://wg21.link/P2893>`_
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Resolutions to C++ Defect Reports
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2024-06-17 18:31:54 +01:00
|
|
|
|
[Clang] Implement CWG2137 (list-initialization from objects of the same type) (#94355)
[CWG2137](https://cplusplus.github.io/CWG/issues/2137.html)
This was previously implemented and then reverted in Clang 18 as #77768
This also implements a workaround for
[CWG2311](https://cplusplus.github.io/CWG/issues/2311.html), similarly
to the 2024-03-01 comment for
[CWG2742](https://cplusplus.github.io/CWG/issues/2742.html).
The exact wording this tries to implement, relative to the C++26 draft:
[over.match.list]p(1.2)
> Otherwise, or if no viable initializer-list constructor is found
<ins>and the initializer list does not consist of exactly a single
element with the same cv-unqualified class type as `T`</ins>, overload
resolution is performed again, [...]
[dcl.init.list]p(3.7)
> Otherwise, if `T` is a class type, constructors are considered. The
applicable constructors are enumerated and the best one is chosen
through overload resolution. <ins>If no constructor is found and the
initializer list consists of exactly a single element with the same
cv-unqualified class type as `T`, the object is initialized from that
element (by copy-initialization for copy-list-initialization, or by
direct-initialization for direct-list-initialization). Otherwise,</ins>
if a narrowing conversion (see below) is required [...]
2024-08-08 16:11:21 +01:00
|
|
|
- Allow calling initializer list constructors from initializer lists with
|
|
|
|
|
a single element of the same type instead of always copying.
|
|
|
|
|
(`CWG2137: List-initialization from object of same type <https://cplusplus.github.io/CWG/issues/2137.html>`)
|
|
|
|
|
|
|
|
|
|
- Speculative resolution for CWG2311 implemented so that the implementation of CWG2137 doesn't remove
|
|
|
|
|
previous cases where guaranteed copy elision was done. Given a prvalue ``e`` of class type
|
|
|
|
|
``T``, ``T{e}`` will try to resolve an initializer list constructor and will use it if successful.
|
|
|
|
|
Otherwise, if there is no initializer list constructor, the copy will be elided as if it was ``T(e)``.
|
|
|
|
|
(`CWG2311: Missed case for guaranteed copy elision <https://cplusplus.github.io/CWG/issues/2311.html>`)
|
|
|
|
|
|
2024-08-09 13:46:28 +01:00
|
|
|
- Casts from a bit-field to an integral type is now not considered narrowing if the
|
|
|
|
|
width of the bit-field means that all potential values are in the range
|
|
|
|
|
of the target type, even if the type of the bit-field is larger.
|
|
|
|
|
(`CWG2627: Bit-fields and narrowing conversions <https://cplusplus.github.io/CWG/issues/2627.html>`_)
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C Language Changes
|
|
|
|
|
------------------
|
|
|
|
|
|
2024-07-02 06:58:41 -04:00
|
|
|
C2y Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2023-08-10 14:18:36 -04:00
|
|
|
C23 Feature Support
|
2023-02-15 23:53:38 +02:00
|
|
|
^^^^^^^^^^^^^^^^^^^
|
Handle constant "pointers" for `__atomic_always_lock_free`/`__atomic_is_lock_free`. (#99340)
The second argument passed to these builtins is used to validate whether
the object's alignment is sufficient for atomic operations of the given
size.
Currently, the builtins can be folded at compile time only when the
argument is 0/nullptr, or if the _type_ of the pointer guarantees
appropriate alignment.
This change allows the compiler to also evaluate non-null constant
pointers, which enables callers to check a specified alignment, instead
of only the type or an exact object. E.g.:
`__atomic_is_lock_free(sizeof(T), (void*)4)`
can be potentially evaluated to true at compile time, instead of
generating a libcall. This is also supported by GCC, and used by
libstdc++, and is also useful for libc++'s atomic_ref.
Also helps with (but doesn't fix) issue #75081.
This also fixes a crash bug, when the second argument was a non-pointer
implicitly convertible to a pointer (such as an array, or a function).
2024-07-22 14:20:25 -04:00
|
|
|
|
2024-08-07 16:39:09 +01:00
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
|
-------------------------------------------------
|
|
|
|
|
|
2024-08-18 10:50:42 +01:00
|
|
|
- The floating point comparison builtins (``__builtin_isgreater``,
|
|
|
|
|
``__builtin_isgreaterequal``, ``__builtin_isless``, etc.) and
|
|
|
|
|
``__builtin_signbit`` can now be used in constant expressions.
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
New Compiler Flags
|
|
|
|
|
------------------
|
2024-07-19 13:03:21 +01:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Deprecated Compiler Flags
|
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
Modified Compiler Flags
|
|
|
|
|
-----------------------
|
2024-07-10 08:32:48 -07:00
|
|
|
|
2020-12-17 09:23:02 -05:00
|
|
|
Removed Compiler Flags
|
|
|
|
|
-------------------------
|
|
|
|
|
|
2024-08-14 20:51:45 +02:00
|
|
|
- The compiler flag `-Wenum-constexpr-conversion` (and the `Wno-`, `Wno-error-`
|
|
|
|
|
derivatives) is now removed, since it's no longer possible to suppress the
|
|
|
|
|
diagnostic (see above). Users can expect an `unknown warning` diagnostic if
|
|
|
|
|
it's still in use.
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Attribute Changes in Clang
|
|
|
|
|
--------------------------
|
2024-06-24 00:51:31 -10:00
|
|
|
|
2024-07-24 14:15:08 +03:00
|
|
|
- Clang now disallows more than one ``__attribute__((ownership_returns(class, idx)))`` with
|
|
|
|
|
different class names attached to one function.
|
|
|
|
|
|
2024-07-25 18:57:14 -04:00
|
|
|
- Introduced a new format attribute ``__attribute__((format(syslog, 1, 2)))`` from OpenBSD.
|
|
|
|
|
|
2024-07-27 14:29:05 +02:00
|
|
|
- The ``hybrid_patchable`` attribute is now supported on ARM64EC targets. It can be used to specify
|
|
|
|
|
that a function requires an additional x86-64 thunk, which may be patched at runtime.
|
|
|
|
|
|
2024-08-18 17:07:47 +01:00
|
|
|
- ``[[clang::lifetimebound]]`` is now explicitly disallowed on explicit object member functions
|
|
|
|
|
where they were previously silently ignored.
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Improvements to Clang's diagnostics
|
|
|
|
|
-----------------------------------
|
2024-07-11 14:21:21 +02:00
|
|
|
|
2024-07-23 07:31:49 -04:00
|
|
|
- Some template related diagnostics have been improved.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
2024-08-01 16:44:08 -03:00
|
|
|
|
2024-07-23 07:31:49 -04:00
|
|
|
void foo() { template <typename> int i; } // error: templates can only be declared in namespace or class scope
|
|
|
|
|
|
|
|
|
|
struct S {
|
|
|
|
|
template <typename> int i; // error: non-static data member 'i' cannot be declared as a template
|
|
|
|
|
};
|
|
|
|
|
|
2024-07-29 09:40:35 -04:00
|
|
|
- Clang now has improved diagnostics for functions with explicit 'this' parameters. Fixes #GH97878
|
|
|
|
|
|
2024-07-24 15:58:52 +02:00
|
|
|
- Clang now diagnoses dangling references to fields of temporary objects. Fixes #GH81589.
|
|
|
|
|
|
2024-07-24 12:36:08 -07:00
|
|
|
- Clang now diagnoses undefined behavior in constant expressions more consistently. This includes invalid shifts, and signed overflow in arithmetic.
|
|
|
|
|
|
2024-07-26 19:28:37 +02:00
|
|
|
- -Wdangling-assignment-gsl is enabled by default.
|
2024-08-04 23:28:54 -03:00
|
|
|
- Clang now always preserves the template arguments as written used
|
|
|
|
|
to specialize template type aliases.
|
2024-07-26 19:28:37 +02:00
|
|
|
|
2024-08-08 02:15:35 +03:00
|
|
|
- Clang now diagnoses the use of ``main`` in an ``extern`` context as invalid according to [basic.start.main] p3. Fixes #GH101512.
|
|
|
|
|
|
2024-08-18 13:45:20 +03:00
|
|
|
- Clang now diagnoses when the result of a [[nodiscard]] function is discarded after being cast in C. Fixes #GH104391.
|
|
|
|
|
|
2023-09-01 15:30:44 +01:00
|
|
|
Improvements to Clang's time-trace
|
|
|
|
|
----------------------------------
|
|
|
|
|
|
2024-06-19 07:15:19 +09:00
|
|
|
Improvements to Coverage Mapping
|
|
|
|
|
--------------------------------
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes in This Version
|
|
|
|
|
-------------------------
|
2024-07-19 11:00:30 +02:00
|
|
|
|
2024-07-24 05:53:39 -07:00
|
|
|
- Fixed the definition of ``ATOMIC_FLAG_INIT`` in ``<stdatomic.h>`` so it can
|
|
|
|
|
be used in C++.
|
2024-08-02 15:42:04 +03:00
|
|
|
- Fixed a failed assertion when checking required literal types in C context. (#GH101304).
|
2024-08-07 02:37:29 +02:00
|
|
|
- Fixed a crash when trying to transform a dependent address space type. Fixes #GH101685.
|
2024-08-08 07:32:39 -04:00
|
|
|
- Fixed a crash when diagnosing format strings and encountering an empty
|
|
|
|
|
delimited escape sequence (e.g., ``"\o{}"``). #GH102218
|
2024-07-24 05:53:39 -07: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
|
|
|
|
2024-07-24 12:02:45 -04:00
|
|
|
- Fixed a crash when an expression with a dependent ``__typeof__`` type is used as the operand of a unary operator. (#GH97646)
|
[Clang] Fix Handling of Init Capture with Parameter Packs in LambdaScopeForCallOperatorInstantiationRAII (#100766)
This PR addresses issues related to the handling of `init capture` with
parameter packs in Clang's
`LambdaScopeForCallOperatorInstantiationRAII`.
Previously, `addInstantiatedCapturesToScope` would add `init capture`
containing packs to the scope using the type of the `init capture` to
determine the expanded pack size. However, this approach resulted in a
pack size of 0 because `getType()->containsUnexpandedParameterPack()`
returns `false`. After extensive testing, it appears that the correct
pack size can only be inferred from `getInit`.
But `getInit` may reference parameters and `init capture` from an outer
lambda, as shown in the following example:
```cpp
auto L = [](auto... z) {
return [... w = z](auto... y) {
// ...
};
};
```
To address this, `addInstantiatedCapturesToScope` in
`LambdaScopeForCallOperatorInstantiationRAII` should be called last.
Additionally, `addInstantiatedCapturesToScope` has been modified to only
add `init capture` to the scope. The previous implementation incorrectly
called `MakeInstantiatedLocalArgPack` for other non-init captures
containing packs, resulting in a pack size of 0.
### Impact
This patch affects scenarios where
`LambdaScopeForCallOperatorInstantiationRAII` is passed with
`ShouldAddDeclsFromParentScope = false`, preventing the correct addition
of the current lambda's `init capture` to the scope. There are two main
scenarios for `ShouldAddDeclsFromParentScope = false`:
1. **Constraints**: Sometimes constraints are instantiated in place
rather than delayed. In this case,
`LambdaScopeForCallOperatorInstantiationRAII` does not need to add `init
capture` to the scope.
2. **`noexcept` Expressions**: The expressions inside `noexcept` have
already been transformed, and the packs referenced within have been
expanded. Only `RebuildLambdaInfo` needs to add the expanded captures to
the scope, without requiring `addInstantiatedCapturesToScope` from
`LambdaScopeForCallOperatorInstantiationRAII`.
### Considerations
An alternative approach could involve adding a data structure within the
lambda to record the expanded size of the `init capture` pack. However,
this would increase the lambda's size and require extensive
modifications.
This PR is a prerequisite for implmenting
https://github.com/llvm/llvm-project/issues/61426
2024-08-09 23:13:11 +08:00
|
|
|
- Fixed incorrect pack expansion of init-capture references in requires expresssions.
|
2024-07-25 15:08:18 +03:00
|
|
|
- Fixed a failed assertion when checking invalid delete operator declaration. (#GH96191)
|
2024-07-29 19:39:30 +03:00
|
|
|
- Fix a crash when checking destructor reference with an invalid initializer. (#GH97230)
|
2024-07-29 14:01:00 -04:00
|
|
|
- Clang now correctly parses potentially declarative nested-name-specifiers in pointer-to-member declarators.
|
2024-08-01 16:44:08 -03:00
|
|
|
- Fix a crash when checking the initialzier of an object that was initialized
|
|
|
|
|
with a string literal. (#GH82167)
|
2024-08-03 00:36:48 -03:00
|
|
|
- Fix a crash when matching template template parameters with templates which have
|
|
|
|
|
parameters of different class type. (#GH101394)
|
2024-08-04 19:00:54 -03:00
|
|
|
- Clang now correctly recognizes the correct context for parameter
|
|
|
|
|
substitutions in concepts, so it doesn't incorrectly complain of missing
|
|
|
|
|
module imports in those situations. (#GH60336)
|
2024-08-05 09:16:55 +01:00
|
|
|
- Fix init-capture packs having a size of one before being instantiated. (#GH63677)
|
2024-08-06 10:54:45 +08:00
|
|
|
- Clang now preserves the unexpanded flag in a lambda transform used for pack expansion. (#GH56852), (#GH85667),
|
|
|
|
|
(#GH99877).
|
2024-08-06 11:33:50 -04:00
|
|
|
- Fixed a bug when diagnosing ambiguous explicit specializations of constrained member functions.
|
2024-08-14 19:56:39 +02:00
|
|
|
- Fixed an assertion failure when selecting a function from an overload set that includes a
|
2024-08-12 13:11:21 -04:00
|
|
|
specialization of a conversion function template.
|
2024-08-14 19:56:39 +02:00
|
|
|
- Correctly diagnose attempts to use a concept name in its own definition;
|
|
|
|
|
A concept name is introduced to its scope sooner to match the C++ standard. (#GH55875)
|
2024-08-15 16:12:11 +01:00
|
|
|
- Properly reject defaulted relational operators with invalid types for explicit object parameters,
|
|
|
|
|
e.g., ``bool operator==(this int, const Foo&)`` (#GH100329), and rvalue reference parameters.
|
|
|
|
|
- Properly reject defaulted copy/move assignment operators that have a non-reference explicit object parameter.
|
2024-08-15 21:42:39 +03:00
|
|
|
- Clang now properly handles the order of attributes in `extern` blocks. (#GH101990).
|
2024-08-15 20:47:14 +03:00
|
|
|
- Fixed an assertion failure by preventing null explicit object arguments from being deduced. (#GH102025).
|
2024-07-24 12:02:45 -04:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to AST Handling
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
2023-01-17 11:29:04 -08:00
|
|
|
|
2024-08-18 23:32:44 +08:00
|
|
|
- Fixed a crash that occurred when dividing by zero in complex integer division. (#GH55390).
|
|
|
|
|
|
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
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-05-03 14:13:56 -04:00
|
|
|
|
2024-07-26 20:39:46 +08:00
|
|
|
- Fixed a crash in C due to incorrect lookup that members in nested anonymous struct/union
|
|
|
|
|
can be found as ordinary identifiers in struct/union definition. (#GH31295)
|
|
|
|
|
|
2024-08-01 17:56:15 +04:00
|
|
|
- Fixed a crash caused by long chains of ``sizeof`` and other similar operators
|
|
|
|
|
that can be followed by a non-parenthesized expression. (#GH45061)
|
|
|
|
|
|
2023-11-17 06:29:02 -08:00
|
|
|
OpenACC Specific Changes
|
|
|
|
|
------------------------
|
|
|
|
|
|
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-02-15 23:53:38 +02:00
|
|
|
X86 Support
|
|
|
|
|
^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (#96540)
The MMX instruction set is legacy, and the SSE2 variants are in every
way superior, when they are available -- and they have been available
since the Pentium 4 was released, 20 years ago.
Therefore, we are switching the "MMX" intrinsics to depend on SSE2,
unconditionally. This change entirely drops the ability to generate
vectorized code using compiler intrinsics for chips with MMX but without
SSE2: the Intel Pentium MMX, Pentium, II, and Pentium III (released
1997-1999), as well as AMD K6 and K7 series chips of around the same
timeframe. Targeting these older CPUs remains supported -- simply
without the ability to use MMX compiler intrinsics.
Migrating away from the use of MMX registers also fixes a rather
non-obvious requirement. The long-standing programming model for these
MMX intrinsics requires that the programmer be aware of the x87/MMX
mode-switching semantics, and manually call `_mm_empty()` between using
any MMX instruction and any x87 FPU instruction. If you neglect to, then
every future x87 operation will return a NaN result. This requirement is
not at all obvious to users of these these intrinsic functions, and
causes very difficult to detect bugs.
Worse, even if the user did write code that correctly calls
`_mm_empty()` in the right places, LLVM may sometimes reorder x87 and
mmx operations around each-other, unaware of this mode switching issue.
Eliminating the use of MMX registers eliminates this problem.
This change also deletes the now-unnecessary MMX `__builtin_ia32_*`
functions from Clang. Only 3 MMX-related builtins remain in use --
`__builtin_ia32_emms`, used by `_mm_empty`, and
`__builtin_ia32_vec_{ext,set}_v4si`, used by `_mm_insert_pi16` and
`_mm_extract_pi16`. Note particularly that the latter two lower to
generic, non-MMX, IR. Support for the LLVM intrinsics underlying these
removed builtins still remains, for the moment.
The file `clang/www/builtins.py` has been updated with mappings from the
newly-removed `__builtin_ia32` functions to the still-supported
equivalents in `mmintrin.h`.
(Originally uploaded at https://reviews.llvm.org/D86855 and
https://reviews.llvm.org/D94252)
Fixes issue #41665
Works towards #98272
2024-07-24 17:00:12 -04:00
|
|
|
- The MMX vector intrinsic functions from ``*mmintrin.h`` which
|
|
|
|
|
operate on `__m64` vectors, such as ``_mm_add_pi8``, have been
|
|
|
|
|
reimplemented to use the SSE2 instruction-set and XMM registers
|
|
|
|
|
unconditionally. These intrinsics are therefore *no longer
|
|
|
|
|
supported* if MMX is enabled without SSE2 -- either from targeting
|
|
|
|
|
CPUs from the Pentium-MMX through the Pentium 3, or explicitly via
|
2024-07-24 18:39:16 -04:00
|
|
|
passing arguments such as ``-mmmx -mno-sse2``. MMX assembly code
|
|
|
|
|
remains supported without requiring SSE2, including inside
|
|
|
|
|
inline-assembly.
|
Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (#96540)
The MMX instruction set is legacy, and the SSE2 variants are in every
way superior, when they are available -- and they have been available
since the Pentium 4 was released, 20 years ago.
Therefore, we are switching the "MMX" intrinsics to depend on SSE2,
unconditionally. This change entirely drops the ability to generate
vectorized code using compiler intrinsics for chips with MMX but without
SSE2: the Intel Pentium MMX, Pentium, II, and Pentium III (released
1997-1999), as well as AMD K6 and K7 series chips of around the same
timeframe. Targeting these older CPUs remains supported -- simply
without the ability to use MMX compiler intrinsics.
Migrating away from the use of MMX registers also fixes a rather
non-obvious requirement. The long-standing programming model for these
MMX intrinsics requires that the programmer be aware of the x87/MMX
mode-switching semantics, and manually call `_mm_empty()` between using
any MMX instruction and any x87 FPU instruction. If you neglect to, then
every future x87 operation will return a NaN result. This requirement is
not at all obvious to users of these these intrinsic functions, and
causes very difficult to detect bugs.
Worse, even if the user did write code that correctly calls
`_mm_empty()` in the right places, LLVM may sometimes reorder x87 and
mmx operations around each-other, unaware of this mode switching issue.
Eliminating the use of MMX registers eliminates this problem.
This change also deletes the now-unnecessary MMX `__builtin_ia32_*`
functions from Clang. Only 3 MMX-related builtins remain in use --
`__builtin_ia32_emms`, used by `_mm_empty`, and
`__builtin_ia32_vec_{ext,set}_v4si`, used by `_mm_insert_pi16` and
`_mm_extract_pi16`. Note particularly that the latter two lower to
generic, non-MMX, IR. Support for the LLVM intrinsics underlying these
removed builtins still remains, for the moment.
The file `clang/www/builtins.py` has been updated with mappings from the
newly-removed `__builtin_ia32` functions to the still-supported
equivalents in `mmintrin.h`.
(Originally uploaded at https://reviews.llvm.org/D86855 and
https://reviews.llvm.org/D94252)
Fixes issue #41665
Works towards #98272
2024-07-24 17:00:12 -04:00
|
|
|
|
|
|
|
|
- The compiler builtins such as ``__builtin_ia32_paddb`` which
|
|
|
|
|
formerly implemented the above MMX intrinsic functions have been
|
|
|
|
|
removed. Any uses of these removed functions should migrate to the
|
|
|
|
|
functions defined by the ``*mmintrin.h`` headers. A mapping can be
|
|
|
|
|
found in the file ``clang/www/builtins.py``.
|
|
|
|
|
|
2024-08-03 09:26:07 +08:00
|
|
|
- Support ISA of ``AVX10.2``.
|
2024-08-05 11:06:02 +08:00
|
|
|
* Supported MINMAX intrinsics of ``*_(mask(z)))_minmax(ne)_p[s|d|h|bh]`` and
|
|
|
|
|
``*_(mask(z)))_minmax_s[s|d|h]``.
|
2024-08-03 09:26:07 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Arm and AArch64 Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-08-31 18:04:56 -07:00
|
|
|
Android Support
|
|
|
|
|
^^^^^^^^^^^^^^^
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Windows Support
|
|
|
|
|
^^^^^^^^^^^^^^^
|
[clang] [MinGW] Add the option -fno-auto-import
In GCC, the .refptr stubs are only generated for x86_64, and only
for code models medium and larger (and medium is the default for
x86_64 since this was introduced). They can be omitted for
projects that are conscious about performance and size, and don't
need automatically importing dll data members, by passing -mcmodel=small.
In Clang/LLVM, such .refptr stubs are generated for any potentially
symbol reference that might end up autoimported. The .refptr stubs
are emitted for three separate reasons:
- Without .refptr stubs, undefined symbols are mostly referenced
with 32 bit wide relocations. If the symbol ends up autoimported
from a different DLL, a 32 bit relative offset might not be
enough to reference data in a different DLL, depending on runtime
loader layout.
- Without .refptr stubs, the runtime pseudo relocation mechanism
will need to temporarily make sections read-write-executable
if there are such relocations in the text section
- On ARM and AArch64, the immediate addressing encoded into
instructions isn't in the form of a plain 32 bit relative offset,
but is expressed with various bits scattered throughout two
instructions - the mingw runtime pseudo relocation mechanism
doesn't support updating offsets in that form.
If autoimporting is known not to be needed, the user can now
compile with -fno-auto-import, avoiding the extra overhead of
the .refptr stubs.
However, omitting them is potentially fragile as the code
might still rely on automatically importing some symbol without
the developer knowing. If this happens, linking still usually
will succeed, but users may encounter issues at runtime.
Therefore, if the new option -fno-auto-import is passed to the compiler
when driving linking, it passes the flag --disable-auto-import to
the linker, making sure that no symbols actually are autoimported
when the generated code doesn't expect it.
Differential Revision: https://reviews.llvm.org/D61670
2019-05-08 11:45:26 +03:00
|
|
|
|
2024-08-15 18:02:08 -07:00
|
|
|
- Clang no longer allows references inside a union when emulating MSVC 1900+ even if `fms-extensions` is enabled.
|
|
|
|
|
Starting with VS2015, MSVC 1900, this Microsoft extension is no longer allowed and always results in an error.
|
|
|
|
|
Clang now follows the MSVC behavior in this scenario.
|
|
|
|
|
When `-fms-compatibility-version=18.00` or prior is set on the command line this Microsoft extension is still
|
|
|
|
|
allowed as VS2013 and prior allow it.
|
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
LoongArch Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^
|
2024-01-23 15:27:06 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
RISC-V Support
|
|
|
|
|
^^^^^^^^^^^^^^
|
2023-12-15 11:16:05 +08: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
|
|
|
|
2024-07-22 19:31:01 -04:00
|
|
|
NetBSD Support
|
|
|
|
|
^^^^^^^^^^^^^^
|
|
|
|
|
|
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
|
|
|
|
|
-------------------------------
|
|
|
|
|
|
2024-02-14 14:11:56 -08:00
|
|
|
Fixed Point Support in Clang
|
|
|
|
|
----------------------------
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
AST Matchers
|
|
|
|
|
------------
|
|
|
|
|
|
2024-07-29 19:11:02 +01:00
|
|
|
- Fixed an issue with the `hasName` and `hasAnyName` matcher when matching
|
|
|
|
|
inline namespaces with an enclosing namespace of the same name.
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
clang-format
|
|
|
|
|
------------
|
|
|
|
|
|
2024-08-10 16:28:33 -04:00
|
|
|
- Adds ``BreakBinaryOperations`` option.
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
libclang
|
|
|
|
|
--------
|
2024-08-16 00:32:58 +02:00
|
|
|
- Add ``clang_isBeforeInTranslationUnit``. Given two source locations, it determines
|
|
|
|
|
whether the first one comes strictly before the second in the source code.
|
2022-08-25 08:35:46 +02:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Static Analyzer
|
|
|
|
|
---------------
|
2023-07-24 08:26:54 +02:00
|
|
|
|
2024-07-10 16:53:12 +02:00
|
|
|
New features
|
|
|
|
|
^^^^^^^^^^^^
|
|
|
|
|
|
2024-07-24 14:15:08 +03:00
|
|
|
- MallocChecker now checks for ``ownership_returns(class, idx)`` and ``ownership_takes(class, idx)``
|
|
|
|
|
attributes with class names different from "malloc". Clang static analyzer now reports an error
|
|
|
|
|
if class of allocation and deallocation function mismatches.
|
|
|
|
|
`Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#unix-mismatcheddeallocator-c-c>`__.
|
|
|
|
|
|
2024-07-10 16:53:12 +02:00
|
|
|
Crash and bug fixes
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2023-12-28 15:48:59 +01:00
|
|
|
Improvements
|
|
|
|
|
^^^^^^^^^^^^
|
|
|
|
|
|
2024-07-29 19:43:50 +03:00
|
|
|
- Improved the handling of the ``ownership_returns`` attribute. Now, Clang reports an
|
|
|
|
|
error if the attribute is attached to a function that returns a non-pointer value.
|
|
|
|
|
Fixes (#GH99501)
|
|
|
|
|
|
2023-12-28 15:48:59 +01:00
|
|
|
Moved checkers
|
|
|
|
|
^^^^^^^^^^^^^^
|
|
|
|
|
|
2024-08-14 15:07:42 +02:00
|
|
|
- The checker ``alpha.security.MallocOverflow`` was deleted because it was
|
|
|
|
|
badly implemented and its agressive logic produced too many false positives.
|
|
|
|
|
To detect too large arguments passed to malloc, consider using the checker
|
|
|
|
|
``alpha.taint.TaintedAlloc``.
|
|
|
|
|
|
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
|
|
|
|
|
----------------------
|
2024-08-02 14:25:30 +01:00
|
|
|
- Fixed an issue that led to crashes when calling ``Type.get_exception_specification_kind``.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-03-12 13:42:43 +01:00
|
|
|
OpenMP Support
|
|
|
|
|
--------------
|
2024-08-05 12:37:07 +01:00
|
|
|
- Added support for 'omp assume' directive.
|
2024-03-12 13:42:43 +01:00
|
|
|
|
2024-08-02 17:22:40 -07:00
|
|
|
Improvements
|
|
|
|
|
^^^^^^^^^^^^
|
|
|
|
|
- Improve the handling of mapping array-section for struct containing nested structs with user defined mappers
|
|
|
|
|
|
2024-08-10 09:54:58 -04:00
|
|
|
- `num_teams` and `thead_limit` now accept multiple expressions when it is used
|
|
|
|
|
along in ``target teams ompx_bare`` construct. This allows the target region
|
|
|
|
|
to be launched with multi-dim grid on GPUs.
|
2024-08-06 10:55:15 -04:00
|
|
|
|
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>`_.
|