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.
2024-09-21 19:53:35 +02:00
- `` clang -m32 `` defaults to `` -mcpu=v9 `` on SPARC Linux now. Distros
still supporting SPARC V8 CPUs need to specify `` -mcpu=v8 `` with a
`config file
<https://clang.llvm.org/docs/UsersManual.html#configuration-files>`_.
2024-09-24 22:57:07 -03:00
2024-09-18 08:25:58 -04:00
- The `` clang-rename `` tool has been removed.
2024-10-28 12:48:42 -04:00
- Removed support for RenderScript targets. This technology is
`officially deprecated <https://developer.android.com/guide/topics/renderscript/compute> `_
and users are encouraged to
`migrate to Vulkan <https://developer.android.com/guide/topics/renderscript/migrate> `_
or other options.
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();
2024-08-19 19:03:21 +02:00
2024-09-26 15:56:33 -07:00
- During constant evaluation, comparisons between different evaluations of the
same string literal are now correctly treated as non-constant, and comparisons
between string literals that cannot possibly overlap in memory are now treated
as constant. This updates Clang to match the anticipated direction of open core
issue `CWG2765 <http://wg21.link/CWG2765>` , but is subject to change once that
issue is resolved.
.. code-block :: c++
constexpr const char *f() { return "hello"; }
constexpr const char *g() { return "world"; }
// Used to evaluate to false, now error: non-constant comparison.
constexpr bool a = f() == f();
// Might evaluate to true or false, as before.
bool at_runtime() { return f() == f(); }
// Was error, now evaluates to false.
constexpr bool b = f() == g();
2024-10-17 16:50:47 +02:00
- Clang will now correctly not consider pointers to non classes for covariance
and disallow changing return type to a type that doesn't have the same or less cv-qualifications.
2024-10-16 16:02:25 +02:00
.. code-block :: c++
struct A {
virtual const int *f() const;
2024-10-17 16:50:47 +02:00
virtual const std::string *g() const;
2024-10-16 16:02:25 +02:00
};
struct B : A {
// Return type has less cv-qualification but doesn't point to a class.
// Error will be generated.
int *f() const override;
2024-10-17 16:50:47 +02:00
// Return type doesn't have more cv-qualification also not the same or
// less cv-qualification.
// Error will be generated.
volatile std::string *g() const override;
2024-10-16 16:02:25 +02:00
};
2024-10-11 06:10:03 -07:00
- The warning `` -Wdeprecated-literal-operator `` is now on by default, as this is
something that WG21 has shown interest in removing from the language. The
result is that anyone who is compiling with `` -Werror `` should see this
diagnostic. To fix this diagnostic, simply removing the space character from
between the `` operator"" `` and the user defined literal name will make the
source no longer deprecated. This is consistent with `CWG2521 <https://cplusplus.github.io/CWG/issues/2521.html>_` .
.. code-block :: c++
// Now diagnoses by default.
unsigned operator"" _udl_name(unsigned long long);
// Fixed version:
unsigned operator""_udl_name(unsigned long long);
2024-10-25 15:31:57 +02:00
- Clang will now produce an error diagnostic when [[clang::lifetimebound]] is
2024-11-07 09:05:46 +01:00
applied on a parameter or an implicit object parameter of a function that
returns void. This was previously ignored and had no effect. (#GH107556)
2024-10-25 15:31:57 +02:00
.. code-block :: c++
// Now diagnoses with an error.
void f(int& i [[clang::lifetimebound]]);
2023-02-15 23:53:38 +02:00
ABI Changes in This Version
---------------------------
2024-07-04 10:17:32 -07:00
2024-08-24 12:25:46 -07:00
- Fixed Microsoft name mangling of placeholder, auto and decltype(auto), return types for MSVC 1920+. This change resolves incompatibilities with code compiled by MSVC 1920+ but will introduce incompatibilities with code compiled by earlier versions of Clang unless such code is built with the compiler option -fms-compatibility-version=19.14 to imitate the MSVC 1914 mangling behavior.
2024-09-29 11:43:28 +08:00
- Fixed the Itanium mangling of the construction vtable name. This change will introduce incompatibilities with code compiled by Clang 19 and earlier versions, unless the -fclang-abi-compat=19 option is used. (#GH108015)
2024-10-02 15:40:10 +02:00
- Mangle member-like friend function templates as members of the enclosing class. (#GH110247, #GH110503)
2024-08-24 12:25:46 -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.
2024-09-24 22:57:07 -03:00
- Implement `CWG1815 <https://wg21.link/CWG1815> `_ . Support lifetime extension
2024-09-12 06:29:48 +08:00
of temporary created by aggregate initialization using a default member
initializer.
2020-02-13 22:46:33 +01:00
2024-09-05 16:38:08 +01:00
- Accept C++26 user-defined `` static_assert `` messages in C++11 as an extension.
2024-09-18 08:19:52 -07:00
- Add `` __builtin_elementwise_popcount `` builtin for integer types only.
2024-09-05 16:38:08 +01:00
2024-09-27 14:26:06 -07:00
- Add `` __builtin_elementwise_fmod `` builtin for floating point types only.
2024-10-01 15:39:23 -07:00
- Add `` __builtin_elementwise_minimum `` and `` __builtin_elementwise_maximum ``
builtin for floating point types only.
2024-09-22 09:25:52 +02:00
- The builtin type alias `` __builtin_common_type `` has been added to improve the
performance of `` std::common_type `` .
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> `_
2024-08-23 17:24:08 +02:00
- Implemented `P2747R2 constexpr placement new <https://wg21.link/P2747R2> `_ .
2024-09-05 13:42:59 +01:00
- Added the `` __builtin_is_within_lifetime `` builtin, which supports
`P2641R4 Checking if a union alternative is active <https://wg21.link/p2641r4> `_
2024-08-23 10:51:25 +11:00
C++23 Feature Support
^^^^^^^^^^^^^^^^^^^^^
- Removed the restriction to literal types in constexpr functions in C++23 mode.
2024-10-11 00:04:02 +08:00
- Extend lifetime of temporaries in mem-default-init for P2718R0. Clang now fully
2024-10-11 08:15:27 +08:00
supports `P2718R0 Lifetime extension in range-based for loops <https://wg21.link/P2718R0> `_ .
2024-10-11 00:04:02 +08:00
2024-08-23 10:51:25 +11:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
2024-08-23 17:24:08 +02:00
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> `_ )
2024-08-20 17:31:52 +01:00
- `` nullptr `` is now promoted to `` void* `` when passed to a C-style variadic function.
(`CWG722: Can nullptr be passed to an ellipsis? <https://cplusplus.github.io/CWG/issues/722.html> `_ )
[Clang] Implement CWG2351 `void{}` (#78060)
Per [CWG2351](https://wg21.link/CWG2351), allow `void{}`, treated the
same as `void()`: a prvalue expression of type `void` that performs no
initialization.
Note that the AST for the expression `T{}` looks like:
```
// using T = int;
CXXFunctionalCastExpr 'T':'int' functional cast to T <NoOp>
`-InitListExpr 'T':'int'
// using T = const int;
CXXFunctionalCastExpr 'int' functional cast to T <NoOp>
`-InitListExpr 'int'
// using T = void;
CXXFunctionalCastExpr 'T':'void' functional cast to T <ToVoid>
`-InitListExpr 'void'
// using T = const void;
CXXFunctionalCastExpr 'void' functional cast to T <ToVoid>
`-InitListExpr 'void'
```
As for `void()`/`T() [T = const void]`, that looked like
`CXXScalarValueInitExpr 'void'` and is unchanged after this.
For reference, C++98 [5.2.3p2] says:
> The expression `T()`, where `T` is a simple-type-specifier (7.1.5.2)
for a non-array complete object type or the (possibly cv-qualified) void
type, creates an rvalue of the specified type, whose value is determined
by default-initialization (8.5; no initialization is done for the
`void()` case). [*Note:* if `T` is a non-class type that is
*cv-qualified*, the `cv-qualifiers` are ignored when determining the
type of the resulting rvalue (3.10). ]
Though it is a bit of a misnomer that, for `T = void`,
`CXXScalarValueInitExpr` does not perform value initialization, it would
be a breaking change to change the AST node for `void()`, so I simply
reworded the doc comment.
2024-08-21 09:09:08 +01:00
- Allow `` void{} `` as a prvalue of type `` void `` .
(`CWG2351: void{} <https://cplusplus.github.io/CWG/issues/2351.html> `_ ).
[clang] Implement CWG2398 provisional TTP matching to class templates (#94981)
This extends default argument deduction to cover class templates as
well, applying only to partial ordering, adding to the provisional
wording introduced in https://github.com/llvm/llvm-project/pull/89807.
This solves some ambuguity introduced in P0522 regarding how template
template parameters are partially ordered, and should reduce the
negative impact of enabling `-frelaxed-template-template-args` by
default.
Given the following example:
```C++
template <class T1, class T2 = float> struct A;
template <class T3> struct B;
template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1
template <class T6, class T7> struct B<A<T6, T7>>; // #2
template struct B<A<int>>;
```
Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This
patch restores the pre-P0522 behavior, `#2` is picked again.
2024-09-07 15:49:07 -03:00
- Clang now has improved resolution to CWG2398, allowing class templates to have
2024-10-11 14:47:21 +02:00
default arguments deduced when partial ordering.
[clang] Implement CWG2398 provisional TTP matching to class templates (#94981)
This extends default argument deduction to cover class templates as
well, applying only to partial ordering, adding to the provisional
wording introduced in https://github.com/llvm/llvm-project/pull/89807.
This solves some ambuguity introduced in P0522 regarding how template
template parameters are partially ordered, and should reduce the
negative impact of enabling `-frelaxed-template-template-args` by
default.
Given the following example:
```C++
template <class T1, class T2 = float> struct A;
template <class T3> struct B;
template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1
template <class T6, class T7> struct B<A<T6, T7>>; // #2
template struct B<A<int>>;
```
Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This
patch restores the pre-P0522 behavior, `#2` is picked again.
2024-09-07 15:49:07 -03:00
2024-09-05 13:23:08 +01:00
- Clang now allows comparing unequal object pointers that have been cast to `` void * ``
in constant expressions. These comparisons always worked in non-constant expressions.
(`CWG2749: Treatment of "pointer to void" for relational comparisons <https://cplusplus.github.io/CWG/issues/2749.html> `_ ).
2024-09-17 20:35:49 +01:00
- Reject explicit object parameters with type `` void `` (`` this void `` ).
(`CWG2915: Explicit object parameters of type void <https://cplusplus.github.io/CWG/issues/2915.html> `_ ).
2024-10-01 07:27:15 +08:00
- Clang now allows trailing requires clause on explicit deduction guides.
(`CWG2707: Deduction guides cannot have a trailing requires-clause <https://cplusplus.github.io/CWG/issues/2707.html> `_ ).
2024-10-11 06:10:03 -07:00
- Clang now diagnoses a space in the first production of a `` literal-operator-id ``
by default.
(`CWG2521: User-defined literals and reserved identifiers <https://cplusplus.github.io/CWG/issues/2521.html> `_ ).
2023-02-15 23:53:38 +02:00
C Language Changes
------------------
2024-11-14 18:39:08 +00:00
- Extend clang's `` <limits.h> `` to define `` LONG_LONG_* `` macros for Android's bionic.
2024-07-02 06:58:41 -04:00
C2y Feature Support
^^^^^^^^^^^^^^^^^^^
2024-11-07 10:59:16 -05:00
- Updated conformance for `N3298 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3298.htm> `_
which adds the `` i `` and `` j `` suffixes for the creation of a `` _Complex ``
constant value. Clang has always supported these suffixes as a GNU extension,
so `` -Wgnu-imaginary-constant `` no longer has effect in C modes, as this is
2024-11-13 00:02:36 +11:00
now a C2y extension in C. `` -Wgnu-imaginary-constant `` still applies in C++
2024-11-07 10:59:16 -05:00
modes.
2024-11-07 06:53:29 -05:00
- Clang updated conformance for `N3370 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3370.htm> `_
case range expressions. This feature was previously supported by Clang as a
GNU extension, so `` -Wgnu-case-range `` no longer has effect in C modes, as
this is now a C2y extension in C. `` -Wgnu-case-range `` still applies in C++
modes.
2024-11-07 10:34:00 -05:00
- Clang implemented support for `N3344 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3344.pdf> `_
which disallows a `` void `` parameter from having a qualifier or storage class
specifier. Note that `` register void `` was previously accepted in all C
language modes but is now rejected (all of the other qualifiers and storage
class specifiers were previously rejected).
2024-11-07 11:53:59 -05:00
- Updated conformance for `N3364 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3364.pdf> `_
on floating-point translation-time initialization with signaling NaN. This
paper adopts Clang's existing practice, so there were no changes to compiler
behavior.
2024-11-08 13:07:05 -05:00
- Implemented support for `N3341 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3341.pdf> `_
which makes empty structure and union objects implementation-defined in C.
`` -Wgnu-empty-struct `` will be emitted in C23 and earlier modes because the
behavior is a conforming GNU extension in those modes, but will no longer
have an effect in C2y mode.
2024-11-08 11:25:39 -05:00
- Updated conformance for `N3342 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3342.pdf> `_
which made qualified function types implementation-defined rather than
undefined. Clang has always accepted `` const `` and `` volatile `` qualified
function types by ignoring the qualifiers.
2024-11-08 12:43:19 -05:00
- Updated conformance for `N3346 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3346.pdf> `_
which changes some undefined behavior around initialization to instead be
constraint violations. This paper adopts Clang's existing practice, so there
were no changes to compiler behavior.
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-09-13 11:11:34 +02:00
- Clang now supports `N3029 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3029.htm> `_ Improved Normal Enumerations.
2024-11-13 00:02:36 +11:00
- Clang now officially supports `N3030 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3030.htm> `_ Enhancements to Enumerations. Clang already supported it as an extension, so there were no changes to compiler behavior.
2024-09-13 11:11:34 +02: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.
2024-10-11 17:28:44 -04:00
- Plugins can now define custom attributes that apply to statements
as well as declarations.
2024-10-18 19:03:50 +08:00
- `` __builtin_abs `` function can now be used in constant expressions.
2024-08-18 10:50:42 +01:00
[Clang] Add __builtin_counted_by_ref builtin (#114495)
The __builtin_counted_by_ref builtin is used on a flexible array
pointer and returns a pointer to the "counted_by" attribute's COUNT
argument, which is a field in the same non-anonymous struct as the
flexible array member. This is useful for automatically setting the
count field without needing the programmer's intervention. Otherwise
it's possible to get this anti-pattern:
ptr = alloc(<ty>, ..., COUNT);
ptr->FAM[9] = 42; /* <<< Sanitizer will complain */
ptr->count = COUNT;
To prevent this anti-pattern, the user can create an allocator that
automatically performs the assignment:
#define alloc(TY, FAM, COUNT) ({ \
TY __p = alloc(get_size(TY, COUNT)); \
if (__builtin_counted_by_ref(__p->FAM)) \
*__builtin_counted_by_ref(__p->FAM) = COUNT; \
__p; \
})
The builtin's behavior is heavily dependent upon the "counted_by"
attribute existing. It's main utility is during allocation to avoid
the above anti-pattern. If the flexible array member doesn't have that
attribute, the builtin becomes a no-op. Therefore, if the flexible
array member has a "count" field not referenced by "counted_by", it
must be set explicitly after the allocation as this builtin will
return a "nullptr" and the assignment will most likely be elided.
---------
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2024-11-07 22:03:55 +00:00
- The new builtin `` __builtin_counted_by_ref `` was added. In contexts where the
programmer needs access to the `` counted_by `` attribute's field, but it's not
available --- e.g. in macros. For instace, it can be used to automatically
set the counter during allocation in the Linux kernel:
.. code-block :: c
/* A simplified version of Linux allocation macros * /
#define alloc(PTR, FAM, COUNT) ({ \
sizeof_t __ignored_assignment; \
typeof(P) __p; \
size_t __size = sizeof(*P) + sizeof(* P->FAM) * COUNT; \
__p = malloc(__size); \
*_Generic( \
__builtin_counted_by_ref(__p->FAM), \
void *: &__ignored_assignment, \
default: __builtin_counted_by_ref(__p->FAM)) = COUNT; \
__p; \
})
The flexible array member (FAM) can now be accessed immediately without causing
issues with the sanitizer because the counter is automatically set.
2024-11-18 20:47:07 +08:00
- `` __builtin_reduce_add `` function 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
2024-08-26 13:11:05 -07:00
- The `` -fc++-static-destructors={all,thread-local,none} `` flag was
added to control which C++ variables have static destructors
registered: all (the default) does so for all variables, thread-local
only for thread-local variables, and none (which corresponds to the
existing `` -fno-c++-static-destructors `` flag) skips all static
destructors registration.
2020-02-13 22:46:33 +01:00
Deprecated Compiler Flags
-------------------------
2024-08-23 15:38:21 -04:00
- `` -fheinous-gnu-extensions `` is deprecated; it is now equivalent to
specifying `` -Wno-error=invalid-gnu-asm-cast `` and may be removed in the
future.
2020-02-13 22:46:33 +01:00
Modified Compiler Flags
-----------------------
2024-07-10 08:32:48 -07:00
2024-08-20 07:11:29 -07:00
- The `` -ffp-model `` option has been updated to enable a more limited set of
optimizations when the `` fast `` argument is used and to accept a new argument,
`` aggressive `` . The behavior of `` -ffp-model=aggressive `` is equivalent
to the previous behavior of `` -ffp-model=fast `` . The updated
`` -ffp-model=fast `` behavior no longer assumes finite math only and uses
the `` promoted `` algorithm for complex division when possible rather than the
less basic (limited range) algorithm.
2024-10-25 13:08:39 +01:00
- The `` -fveclib `` option has been updated to enable `` -fno-math-errno `` for
`` -fveclib=ArmPL `` and `` -fveclib=SLEEF `` . This gives Clang more opportunities
to utilize these vector libraries. The behavior for all other vector function
libraries remains unchanged.
2024-10-28 20:40:52 +00:00
- The `` -Wnontrivial-memaccess `` warning has been updated to also warn about
passing non-trivially-copyable destrination parameter to `` memcpy `` ,
`` memset `` and similar functions for which it is a documented undefined
behavior.
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-10-31 04:15:22 -07:00
- The `` swift_attr `` can now be applied to types. To make it possible to use imported APIs
in Swift safely there has to be a way to annotate individual parameters and result types
with relevant attributes that indicate that e.g. a block is called on a particular actor
or it accepts a Sendable or global-actor (i.e. `` @MainActor `` ) isolated parameter.
For example:
.. code-block :: objc
@interface MyService
-(void) handle: (void (^ __attribute__((swift_attr("@Sendable"))))(id)) handler;
@end
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.
2024-08-28 10:50:17 +02:00
- Clang now automatically adds `` [[clang::lifetimebound]] `` to the parameters of
`` std::span, std::string_view `` constructors, this enables Clang to capture
more cases where the returned reference outlives the object.
(#GH100567)
2024-09-04 12:33:05 -04:00
- Clang now correctly diagnoses the use of `` btf_type_tag `` in C++ and ignores
it; this attribute is a C-only attribute, and caused crashes with template
instantiation by accidentally allowing it in C++ in some circumstances.
(#GH106864)
[Clang] C++20 Coroutines: Introduce Frontend Attribute [[clang::coro_await_elidable]] (#99282)
This patch is the frontend implementation of the coroutine elide
improvement project detailed in this discourse post:
https://discourse.llvm.org/t/language-extension-for-better-more-deterministic-halo-for-c-coroutines/80044
This patch proposes a C++ struct/class attribute
`[[clang::coro_await_elidable]]`. This notion of await elidable task
gives developers and library authors a certainty that coroutine heap
elision happens in a predictable way.
Originally, after we lower a coroutine to LLVM IR, CoroElide is
responsible for analysis of whether an elision can happen. Take this as
an example:
```
Task foo();
Task bar() {
co_await foo();
}
```
For CoroElide to happen, the ramp function of `foo` must be inlined into
`bar`. This inlining happens after `foo` has been split but `bar` is
usually still a presplit coroutine. If `foo` is indeed a coroutine, the
inlined `coro.id` intrinsics of `foo` is visible within `bar`. CoroElide
then runs an analysis to figure out whether the SSA value of
`coro.begin()` of `foo` gets destroyed before `bar` terminates.
`Task` types are rarely simple enough for the destroy logic of the task
to reference the SSA value from `coro.begin()` directly. Hence, the pass
is very ineffective for even the most trivial C++ Task types. Improving
CoroElide by implementing more powerful analyses is possible, however it
doesn't give us the predictability when we expect elision to happen.
The approach we want to take with this language extension generally
originates from the philosophy that library implementations of `Task`
types has the control over the structured concurrency guarantees we
demand for elision to happen. That is, the lifetime for the callee's
frame is shorter to that of the caller.
The ``[[clang::coro_await_elidable]]`` is a class attribute which can be
applied to a coroutine return type.
When a coroutine function that returns such a type calls another
coroutine function, the compiler performs heap allocation elision when
the following conditions are all met:
- callee coroutine function returns a type that is annotated with
``[[clang::coro_await_elidable]]``.
- In caller coroutine, the return value of the callee is a prvalue that
is immediately `co_await`ed.
From the C++ perspective, it makes sense because we can ensure the
lifetime of elided callee cannot exceed that of the caller if we can
guarantee that the caller coroutine is never destroyed earlier than the
callee coroutine. This is not generally true for any C++ programs.
However, the library that implements `Task` types and executors may
provide this guarantee to the compiler, providing the user with
certainty that HALO will work on their programs.
After this patch, when compiling coroutines that return a type with such
attribute, the frontend checks that the type of the operand of
`co_await` expressions (not `operator co_await`). If it's also
attributed with `[[clang::coro_await_elidable]]`, the FE emits metadata
on the call or invoke instruction as a hint for a later middle end pass
to elide the elision.
The original patch version is
https://github.com/llvm/llvm-project/pull/94693 and as suggested, the
patch is split into frontend and middle end solutions into stacked PRs.
The middle end CoroSplit patch can be found at
https://github.com/llvm/llvm-project/pull/99283
The middle end transformation that performs the elide can be found at
https://github.com/llvm/llvm-project/pull/99285
2024-09-08 23:08:58 -07:00
- Introduced a new attribute `` [[clang::coro_await_elidable]] `` on coroutine return types
2024-09-17 22:58:21 -07:00
to express elideability at call sites where the coroutine is invoked under a safe elide context.
- Introduced a new attribute `` [[clang::coro_await_elidable_argument]] `` on function parameters
to propagate safe elide context to arguments if such function is also under a safe elide context.
[Clang] C++20 Coroutines: Introduce Frontend Attribute [[clang::coro_await_elidable]] (#99282)
This patch is the frontend implementation of the coroutine elide
improvement project detailed in this discourse post:
https://discourse.llvm.org/t/language-extension-for-better-more-deterministic-halo-for-c-coroutines/80044
This patch proposes a C++ struct/class attribute
`[[clang::coro_await_elidable]]`. This notion of await elidable task
gives developers and library authors a certainty that coroutine heap
elision happens in a predictable way.
Originally, after we lower a coroutine to LLVM IR, CoroElide is
responsible for analysis of whether an elision can happen. Take this as
an example:
```
Task foo();
Task bar() {
co_await foo();
}
```
For CoroElide to happen, the ramp function of `foo` must be inlined into
`bar`. This inlining happens after `foo` has been split but `bar` is
usually still a presplit coroutine. If `foo` is indeed a coroutine, the
inlined `coro.id` intrinsics of `foo` is visible within `bar`. CoroElide
then runs an analysis to figure out whether the SSA value of
`coro.begin()` of `foo` gets destroyed before `bar` terminates.
`Task` types are rarely simple enough for the destroy logic of the task
to reference the SSA value from `coro.begin()` directly. Hence, the pass
is very ineffective for even the most trivial C++ Task types. Improving
CoroElide by implementing more powerful analyses is possible, however it
doesn't give us the predictability when we expect elision to happen.
The approach we want to take with this language extension generally
originates from the philosophy that library implementations of `Task`
types has the control over the structured concurrency guarantees we
demand for elision to happen. That is, the lifetime for the callee's
frame is shorter to that of the caller.
The ``[[clang::coro_await_elidable]]`` is a class attribute which can be
applied to a coroutine return type.
When a coroutine function that returns such a type calls another
coroutine function, the compiler performs heap allocation elision when
the following conditions are all met:
- callee coroutine function returns a type that is annotated with
``[[clang::coro_await_elidable]]``.
- In caller coroutine, the return value of the callee is a prvalue that
is immediately `co_await`ed.
From the C++ perspective, it makes sense because we can ensure the
lifetime of elided callee cannot exceed that of the caller if we can
guarantee that the caller coroutine is never destroyed earlier than the
callee coroutine. This is not generally true for any C++ programs.
However, the library that implements `Task` types and executors may
provide this guarantee to the compiler, providing the user with
certainty that HALO will work on their programs.
After this patch, when compiling coroutines that return a type with such
attribute, the frontend checks that the type of the operand of
`co_await` expressions (not `operator co_await`). If it's also
attributed with `[[clang::coro_await_elidable]]`, the FE emits metadata
on the call or invoke instruction as a hint for a later middle end pass
to elide the elision.
The original patch version is
https://github.com/llvm/llvm-project/pull/94693 and as suggested, the
patch is split into frontend and middle end solutions into stacked PRs.
The middle end CoroSplit patch can be found at
https://github.com/llvm/llvm-project/pull/99283
The middle end transformation that performs the elide can be found at
https://github.com/llvm/llvm-project/pull/99285
2024-09-08 23:08:58 -07:00
2024-09-23 11:04:08 +02:00
- The documentation of the `` [[clang::musttail]] `` attribute was updated to
note that the lifetimes of all local variables end before the call. This does
not change the behaviour of the compiler, as this was true for previous
versions.
2024-09-23 14:59:30 +02:00
- Fix a bug where clang doesn't automatically apply the `` [[gsl::Owner]] `` or
`` [[gsl::Pointer]] `` to STL explicit template specialization decls. (#GH109442)
2024-11-13 11:07:20 +01:00
- Clang now supports `` [[clang::lifetime_capture_by(X)]] `` . Similar to lifetimebound, this can be
used to specify when a reference to a function parameter is captured by another capturing entity `` X `` .
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.
2024-08-23 17:50:27 +02:00
- Don't emit duplicated dangling diagnostics. (#GH93386).
2024-08-22 23:33:40 +02:00
- Improved diagnostic when trying to befriend a concept. (#GH45182).
2024-08-23 15:38:21 -04:00
- Added the `` -Winvalid-gnu-asm-cast `` diagnostic group to control warnings
about use of "noop" casts for lvalues (a GNU extension). This diagnostic is
a warning which defaults to being an error, is enabled by default, and is
also controlled by the now-deprecated `` -fheinous-gnu-extensions `` flag.
2024-08-26 10:30:58 +08:00
- Added the `` -Wdecls-in-multiple-modules `` option to assist users to identify
multiple declarations in different modules, which is the major reason of the slow
compilation speed with modules. This warning is disabled by default and it needs
to be explicitly enabled or by `` -Weverything `` .
2024-09-03 13:22:33 +09:00
- Improved diagnostic when trying to overload a function in an `` extern "C" `` context. (#GH80235)
2024-09-04 10:09:04 +02:00
- Clang now respects lifetimebound attribute for the assignment operator parameter. (#GH106372).
2024-09-04 13:49:48 +02:00
- The lifetimebound and GSL analysis in clang are coherent, allowing clang to
detect more use-after-free bugs. (#GH100549).
2024-09-06 12:37:21 +02:00
- Clang now diagnoses dangling cases where a gsl-pointer is constructed from a gsl-owner object inside a container (#GH100384).
2024-09-05 09:15:54 +01:00
- Clang now warns for u8 character literals used in C23 with `` -Wpre-c23-compat `` instead of `` -Wpre-c++17-compat `` .
2024-09-14 14:45:50 +08:00
- Clang now diagnose when importing module implementation partition units in module interface units.
2024-09-16 15:21:33 +02:00
- Don't emit bogus dangling diagnostics when `` [[gsl::Owner]] `` and `[[clang::lifetimebound]]` are used together (#GH108272).
2024-09-23 11:04:08 +02:00
- The `` -Wreturn-stack-address `` warning now also warns about addresses of
local variables passed to function calls using the `` [[clang::musttail]] ``
attribute.
2024-09-25 14:12:49 +02:00
- Clang now diagnoses cases where a dangling `` GSLOwner<GSLPointer> `` object is constructed, e.g. `` std::vector<string_view> v = {std::string()}; `` (#GH100526).
2024-10-01 21:39:10 +08:00
- Clang now diagnoses when a `` requires `` expression has a local parameter of void type, aligning with the function parameter (#GH109831).
2024-10-02 22:40:06 +08:00
- Clang now emits a diagnostic note at the class declaration when the method definition does not match any declaration (#GH110638).
2024-10-07 21:14:46 +03:00
- Clang now omits warnings for extra parentheses in fold expressions with single expansion (#GH101863).
2024-10-09 09:12:27 +01:00
- The warning for an unsupported type for a named register variable is now phrased `` unsupported type for named register variable `` ,
instead of `` bad type for named register variable `` . This makes it clear that the type is not supported at all, rather than being
suboptimal in some way the error fails to mention (#GH111550).
2024-10-18 15:42:54 +02:00
2024-10-11 06:10:03 -07:00
- Clang now emits a `` -Wdepredcated-literal-operator `` diagnostic, even if the
name was a reserved name, which we improperly allowed to suppress the
diagnostic.
2024-10-09 09:12:27 +01:00
2024-10-25 10:40:44 +03:00
- Clang now diagnoses `` [[deprecated]] `` attribute usage on local variables (#GH90073).
2024-11-13 16:11:36 +02:00
- Improved diagnostic message for `` __builtin_bit_cast `` size mismatch (#GH115870).
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-10-22 17:03:51 +08:00
- Fixed a crash using `` __array_rank `` on 64-bit targets. (#GH113044).
2024-10-08 11:01:40 +01:00
- The warning emitted for an unsupported register variable type now points to
the unsupported type instead of the `` register `` keyword (#GH109776).
2024-10-30 14:37:04 +08:00
- Fixed a crash when emit ctor for global variant with flexible array init (#GH113187).
2024-10-30 14:34:19 +08:00
- Fixed a crash when GNU statement expression contains invalid statement (#GH113468).
2024-11-14 11:29:52 -05:00
- Fixed a failed assertion when using `` __attribute__((noderef)) `` on an
`` _Atomic `` -qualified type (#GH116124).
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
2024-08-30 15:52:24 +08:00
- Fix crash when atomic builtins are called with pointer to zero-size struct (#GH90330)
- Clang now allows pointee types of atomic builtin arguments to be complete template types
that was not instantiated elsewhere.
- `` __noop `` can now be used in a constant expression. (#GH102064)
2024-10-08 23:03:32 +02:00
- Fix `` __has_builtin `` incorrectly returning `` false `` for some C++ type traits. (#GH111477)
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-08-19 19:03:21 +02:00
- Correctly check constraints of explicit instantiations of member functions. (#GH46029)
2024-08-28 16:53:40 -03:00
- When performing partial ordering of function templates, clang now checks that
the deduction was consistent. Fixes (#GH18291).
2024-08-21 20:33:17 +08:00
- Fixed an assertion failure about a constraint of a friend function template references to a value with greater
template depth than the friend function template. (#GH98258)
2024-08-22 09:22:33 -04:00
- Clang now rebuilds the template parameters of out-of-line declarations and specializations in the context
of the current instantiation in all cases.
2024-08-26 17:50:32 +02:00
- Fix evaluation of the index of dependent pack indexing expressions/types specifiers (#GH105900)
2024-08-26 22:55:32 +02:00
- Correctly handle subexpressions of an immediate invocation in the presence of implicit casts. (#GH105558)
2024-08-28 05:18:20 +08:00
- Clang now correctly handles direct-list-initialization of a structured bindings from an array. (#GH31813)
2024-08-29 18:53:03 -03:00
- Mangle placeholders for deduced types as a template-prefix, such that mangling
of template template parameters uses the correct production. (#GH106182)
2024-08-29 21:45:46 +03:00
- Fixed an assertion failure when converting vectors to int/float with invalid expressions. (#GH105486)
2024-08-31 17:35:51 +08:00
- Template parameter names are considered in the name lookup of out-of-line class template
specialization right before its declaration context. (#GH64082)
[Clang][Concepts] Correct the CurContext for friend declarations (#106890)
`FindInstantiatedDecl()` relies on the `CurContext` to find the
corresponding class template instantiation for a class template
declaration.
Previously, we pushed the semantic declaration context for constraint
comparison, which is incorrect for constraints on friend declarations.
In issue #78101, the semantic context of the friend is the TU, so we
missed the implicit template specialization `Template<void, 4>` when
looking for the instantiation of the primary template `Template` at the
time of checking the member instantiation; instead, we mistakenly picked
up the explicit specialization `Template<float, 5>`, hence the error.
As a bonus, this also fixes a crash when diagnosing constraints. The
DeclarationName is not necessarily an identifier, so it's incorrect to
call `getName()` on e.g. overloaded operators. Since the
DiagnosticBuilder has correctly handled Decl printing, we don't need to
find the printable name ourselves.
Fixes https://github.com/llvm/llvm-project/issues/78101
2024-09-02 13:42:42 +08:00
- Fixed a constraint comparison bug for friend declarations. (#GH78101)
2024-09-03 20:36:15 +02:00
- Fix handling of `` _ `` as the name of a lambda's init capture variable. (#GH107024)
2024-09-04 10:02:55 +02:00
- Fix an issue with dependent source location expressions (#GH106428), (#GH81155), (#GH80210), (#GH85373)
2024-09-04 16:34:27 +08:00
- Fixed a bug in the substitution of empty pack indexing types. (#GH105903)
2024-09-04 10:38:18 +02:00
- Clang no longer tries to capture non-odr used default arguments of template parameters of generic lambdas (#GH107048)
2024-09-05 08:41:39 +01:00
- Fixed a bug where defaulted comparison operators would remove `` const `` from base classes. (#GH102588)
2024-09-05 20:45:31 +02:00
- Fix a crash when using `` source_location `` in the trailing return type of a lambda expression. (#GH67134)
2024-10-22 16:51:43 +08:00
- A follow-up fix was added for (#GH61460), as the previous fix was not entirely correct. (#GH86361), (#GH112352)
2024-09-12 16:36:06 +08:00
- Fixed a crash in the typo correction of an invalid CTAD guide. (#GH107887)
2024-09-12 13:21:26 +02:00
- Fixed a crash when clang tries to subtitute parameter pack while retaining the parameter
2024-09-18 16:34:55 +08:00
pack. (#GH63819), (#GH107560)
2024-09-16 15:58:50 +03:00
- Fix a crash when a static assert declaration has an invalid close location. (#GH108687)
2024-09-18 16:34:55 +08:00
- Avoided a redundant friend declaration instantiation under a certain `` consteval `` context. (#GH107175)
2024-09-18 10:11:03 +02:00
- Fixed an assertion failure in debug mode, and potential crashes in release mode, when
diagnosing a failed cast caused indirectly by a failed implicit conversion to the type of the constructor parameter.
2024-09-20 16:14:26 +03:00
- Fixed an assertion failure by adjusting integral to boolean vector conversions (#GH108326)
2024-11-04 22:28:07 +08:00
- Fixed a crash when mixture of designated and non-designated initializers in union. (#GH113855)
2024-10-01 20:57:47 -03:00
- Fixed an issue deducing non-type template arguments of reference type. (#GH73460)
[Clang][Sema] Retain the expanding index for unevaluated type constraints (#109518)
(This continues the effort of #86265, fixing another piece of issue in
constraint evaluation on variadic lambdas.)
We need the depth of the primary template parameters for constraint
substitution. To that end, we avoided substituting type constraints by
copying the constraint expression when instantiating a template. This,
however, has left an issue in that for lambda's parameters, they can
reference outer template packs that would be expanded in the process of
an instantiation, where these parameters would make their way into the
constraint evaluation, wherein we have no other way to expand them later
in evaluation. For example,
template <class... Ts> void foo() {
bar([](C<Ts> auto value) {}...);
}
The lambda references a pack `Ts` that should be expanded when
instantiating `foo()`. The `Ts` along with the constraint expression
would not be transformed until constraint evaluation, and at that point,
we would have no chance to expand `Ts` anyhow.
This patch takes an approach that transforms `Ts` from an unexpanded
TemplateTypeParmType into a SubstTemplateTypeParmType with the current
pack substitution index, such that we could use that to expand the type
during evaluation.
Fixes #101754
2024-10-01 08:19:35 +08:00
- Fixed an issue in constraint evaluation, where type constraints on the lambda expression
containing outer unexpanded parameters were not correctly expanded. (#GH101754)
2024-10-07 16:46:27 -03:00
- Fixes crashes with function template member specializations, and increases
conformance of explicit instantiation behaviour with MSVC. (#GH111266)
[Clang][Concepts] Normalize SizeOfPackExpr's pack declaration (#110238)
SizeOfPackExpr has a pointer to the referenced pack declaration, which
is left as-is during the transformation process.
The situation could be subtle when a friend class template declaration
comes into play. The declaration per se would be instantiated into its
parent declaration context, and consequently, the template parameter
list would have a depth adjustment; however, as we don't evaluate
constraints during instantiation, those constraints would still
reference the original template parameters, which is fine for constraint
evaluation because we have handled friend cases in the template argument
collection.
However, things are different when we want to profile the constraint
expression with dependent template arguments. The hash algorithm of
SizeOfPackExpr takes its pack declaration as a factor, which is the
original template parameter that might still have untransformed template
depths after the constraint normalization.
This patch transforms the pack declaration when normalizing constraint
expressions and pluses a fix in HandleFunctionTemplateDecl() where the
associated declaration is incorrect for nested specifiers.
Note that the fix in HandleFunctionTemplateDecl(), as well as the
handling logic for NestedNameSpecifier, would be removed once Krystian's
refactoring patch lands. But I still want to incorporate it in the patch
for the correction purpose, though it hasn't caused any problems so far
- I just tripped over that in getFullyPackExpandedSize() when I tried to
extract the transformed declarations from the TemplateArgument.
Fixes #93099
---------
Co-authored-by: Matheus Izvekov <mizvekov@gmail.com>
2024-10-01 12:28:30 +08:00
- Fixed a bug in constraint expression comparison where the `` sizeof... `` expression was not handled properly
in certain friend declarations. (#GH93099)
2024-10-08 13:34:00 +02:00
- Clang now instantiates the correct lambda call operator when a lambda's class type is
merged across modules. (#GH110401)
2024-10-09 15:45:16 +02:00
- Fix a crash when parsing a pseudo destructor involving an invalid type. (#GH111460)
2024-10-10 11:02:21 +03:00
- Fixed an assertion failure when invoking recovery call expressions with explicit attributes
2024-10-15 12:52:31 +08:00
and undeclared templates. (#GH107047), (#GH49093)
2024-10-11 20:03:43 +02:00
- Clang no longer crashes when a lambda contains an invalid block declaration that contains an unexpanded
parameter pack. (#GH109148)
2024-10-12 11:11:36 +03:00
- Fixed overload handling for object parameters with top-level cv-qualifiers in explicit member functions (#GH100394)
2024-10-15 12:52:31 +08:00
- Fixed a bug in lambda captures where `` constexpr `` class-type objects were not properly considered ODR-used in
certain situations. (#GH47400), (#GH90896)
2024-10-15 08:52:02 +03:00
- Fix erroneous templated array size calculation leading to crashes in generated code. (#GH41441)
2024-10-15 10:19:17 +02:00
- During the lookup for a base class name, non-type names are ignored. (#GH16855)
2024-10-18 15:42:54 +02:00
- Fix a crash when recovering an invalid expression involving an explicit object member conversion operator. (#GH112559)
2024-10-22 14:01:20 +05:30
- Clang incorrectly considered a class with an anonymous union member to not be
const-default-constructible even if a union member has a default member initializer.
(#GH95854).
2024-10-29 11:44:01 +02:00
- Fixed an assertion failure when evaluating an invalid expression in an array initializer. (#GH112140)
- Fixed an assertion failure in range calculations for conditional throw expressions. (#GH111854)
2024-10-30 09:24:10 -06:00
- Clang now correctly ignores previous partial specializations of member templates explicitly specialized for
an implicitly instantiated class template specialization. (#GH51051)
2024-11-01 07:13:33 +02:00
- Fixed an assertion failure caused by invalid enum forward declarations. (#GH112208)
2024-11-06 05:10:53 +01:00
- Name independent data members were not correctly initialized from default member initializers. (#GH114069)
2024-11-12 09:45:33 +08:00
- Fixed expression transformation for `` [[assume(...)]] `` , allowing using pack indexing expressions within the
assumption if they also occur inside of a dependent lambda. (#GH114787)
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).
2024-09-20 02:23:58 -04:00
- Fixed a bug in `` ASTContext::getRawCommentForAnyRedecl() `` where the function could
sometimes incorrectly return null even if a comment was present. (#GH108145)
2024-11-12 12:18:28 -07:00
- Clang now correctly parses the argument of the `` relates `` , `` related `` , `` relatesalso `` ,
and `` relatedalso `` comment commands.
2024-08-18 23:32:44 +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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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)
2024-08-21 08:10:26 -07:00
- Fixed an crash when compiling `` #pragma STDC FP_CONTRACT DEFAULT `` with
`` -ffp-contract=fast-honor-pragmas `` . (#GH104830)
2024-08-21 17:38:24 +04:00
- Fixed a crash when function has more than 65536 parameters.
Now a diagnostic is emitted. (#GH35741)
2024-09-19 08:33:37 +08:00
- Fixed `` -ast-dump `` crashes on codes involving `` concept `` with `` -ast-dump-decl-types `` . (#GH94928)
2024-09-24 22:57:07 -03:00
- Fixed internal assertion firing when a declaration in the implicit global
module is found through ADL. (GH#109879)
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
2024-10-07 19:05:23 +02:00
- Clang now implements the Solaris-specific mangling of `` std::tm `` as
`` tm `` , same for `` std::div_t `` , `` std::ldiv_t `` , and
`` std::lconv `` , for Solaris ABI compatibility. (#GH33114)
2023-03-13 09:33:08 -05:00
AMDGPU Support
^^^^^^^^^^^^^^
2024-11-18 10:41:14 -08:00
- Initial support for gfx950
2024-11-15 11:08:06 -06:00
- Added headers `` gpuintrin.h `` and `` amdgpuintrin.h `` that contains common
definitions for GPU builtin functions. This header can be included for OpenMP,
CUDA, HIP, OpenCL, and C/C++.
NVPTX Support
^^^^^^^^^^^^^^
- Added headers `` gpuintrin.h `` and `` nvptxintrin.h `` that contains common
definitions for GPU builtin functions. This header can be included for OpenMP,
CUDA, HIP, OpenCL, and C/C++.
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
2024-10-28 10:46:16 +08:00
- Supported intrinsics for `` SM4 and AVX10.2 `` .
* Supported SM4 intrinsics of `` _mm512_sm4key4_epi32 `` and
`` _mm512_sm4rnds4_epi32 `` .
2024-10-02 15:45:02 +01:00
- All intrinsics in adcintrin.h can now be used in constant expressions.
- All intrinsics in adxintrin.h can now be used in constant expressions.
2024-10-01 11:10:05 +01:00
- All intrinsics in lzcntintrin.h can now be used in constant expressions.
- All intrinsics in bmiintrin.h can now be used in constant expressions.
2024-10-01 15:12:09 +01:00
- All intrinsics in bmi2intrin.h can now be used in constant expressions.
2024-10-01 11:10:05 +01:00
- All intrinsics in tbmintrin.h can now be used in constant expressions.
2024-09-30 15:49:32 +01:00
2024-10-25 09:00:19 +08:00
- Supported intrinsics for `` MOVRS AND AVX10.2 `` .
* Supported intrinsics of `` _mm(256|512)_(mask(z))_loadrs_epi(8|16|32|64) `` .
2024-10-31 10:14:25 +08:00
- Support ISA of `` AMX-FP8 `` .
2024-11-01 16:45:03 +08:00
- Support ISA of `` AMX-TRANSPOSE `` .
2024-11-11 23:05:43 -08:00
- Support ISA of `` AMX-MOVRS `` .
2024-11-09 13:26:10 +08:00
- Support ISA of `` AMX-AVX512 `` .
2024-11-11 15:24:18 +08:00
- Support ISA of `` AMX-TF32 `` .
2024-11-14 05:44:55 -08:00
- Support ISA of `` MOVRS `` .
2024-10-25 09:00:19 +08:00
2024-11-18 10:40:32 +08:00
- Supported `` -march/tune=diamondrapids ``
2023-02-15 23:53:38 +02:00
Arm and AArch64 Support
^^^^^^^^^^^^^^^^^^^^^^^
2020-02-13 22:46:33 +01:00
2024-10-17 20:25:06 +08:00
- In the ARM Target, the frame pointer (FP) of a leaf function can be retained
by using the `` -fno-omit-frame-pointer `` option. If you want to eliminate the FP
in leaf functions after enabling `` -fno-omit-frame-pointer `` , you can do so by adding
the `` -momit-leaf-frame-pointer `` option.
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-10-16 10:06:43 +02:00
- clang-cl now supports `` /std:c++23preview `` which enables C++23 features.
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
2024-09-12 09:11:12 +08:00
- The option `` -mcmodel=large `` for the large code model is supported.
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
^^^^^^^^^^^^
2024-10-14 11:51:05 -07:00
- Clang now supports CUDA SDK up to 12.6
- Added support for sm_100
2024-11-05 10:48:54 -08:00
- Added support for `__grid_constant__` attribute.
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
2024-10-25 13:52:51 -07:00
The default target CPU, "generic", now enables the `-mnontrapping-fptoint`
and `-mbulk-memory` flags, which correspond to the [Bulk Memory Operations]
and [Non-trapping float-to-int Conversions] language features, which are
[widely implemented in engines].
[Bulk Memory Operations]: https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md
[Non-trapping float-to-int Conversions]: https://github.com/WebAssembly/spec/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md
[widely implemented in engines]: https://webassembly.org/features/
2022-02-06 08:20:54 -05:00
AVR Support
^^^^^^^^^^^
2024-10-14 19:08:58 +08:00
- Reject C/C++ compilation for avr1 devices which have no SRAM.
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-10-01 14:41:43 -07:00
- Add `` __builtin_elementwise_atan2 `` builtin for floating point types only.
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.
2024-09-14 21:27:35 +08:00
- Fixed an ordering issue with the `hasOperands` matcher occurring when setting a
2024-08-20 11:44:13 -04:00
binding in the first matcher and using it in the second matcher.
2024-09-17 20:12:01 +08:00
- Fixed a crash when traverse lambda expr with invalid captures. (#GH106444)
2024-10-30 19:57:09 +01:00
- Fixed `` isInstantiated `` and `` isInTemplateInstantiation `` to also match for variable templates. (#GH110666)
2024-10-11 15:23:47 +02:00
- Ensure `` hasName `` matches template specializations across inline namespaces,
making `matchesNodeFullSlow` and `matchesNodeFullFast` consistent.
2020-02-13 22:46:33 +01:00
clang-format
------------
2024-08-10 16:28:33 -04:00
- Adds `` BreakBinaryOperations `` option.
2024-10-02 18:10:56 -07:00
- Adds `` TemplateNames `` option.
2024-10-06 20:46:43 -04:00
- Adds `` AlignFunctionDeclarations `` option to `` AlignConsecutiveDeclarations `` .
2024-10-17 20:21:42 -07:00
- Adds `` IndentOnly `` suboption to `` ReflowComments `` to fix the indentation of
multi-line comments without touching their contents, renames `` false `` to
`` Never `` , and `` true `` to `` Always `` .
- Adds `` RemoveEmptyLinesInUnwrappedLines `` option.
2024-10-23 19:55:32 -07:00
- Adds `` KeepFormFeed `` option and set it to `` true `` for `` GNU `` style.
2024-08-10 16:28:33 -04:00
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-10-03 13:27:25 +03:00
- Now CSA models `__builtin_*_overflow` functions. (#GH102602)
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-10-08 11:06:24 +02:00
- Function effects, e.g. the `` nonblocking `` and `` nonallocating `` "performance constraint"
attributes, are now verified. For example, for functions declared with the `` nonblocking ``
2024-10-02 17:14:51 -07:00
attribute, the compiler can generate warnings about the use of any language features, or calls to
other functions, which may block.
2024-11-13 09:34:23 +01:00
- Introduced `` -warning-suppression-mappings `` flag to control diagnostic
suppressions per file. See `documentation <https://clang.llvm.org/docs/WarningSuppressionMappings.html>_` for details.
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 `` .
2024-10-28 03:53:36 -05:00
- The checkers `` alpha.nondeterministic.PointerSorting `` and
`` alpha.nondeterministic.PointerIteration `` were moved to a new bugprone
checker named `` bugprone-nondeterministic-pointer-iteration-order `` . The
original checkers were implemented only using AST matching and make more
sense as a single clang-tidy check.
2022-09-26 17:41:37 -07:00
.. _release-notes-sanitizers:
Sanitizers
----------
2024-08-23 08:16:52 -07:00
- Introduced Realtime Sanitizer, activated by using the -fsanitize=realtime
flag. This sanitizer detects unsafe system library calls, such as memory
allocations and mutex locks. If any such function is called during invocation
of a function marked with the `` [[clang::nonblocking]] `` attribute, an error
is printed to the console and the process exits non-zero.
2020-02-13 22:46:33 +01:00
2024-08-20 13:13:44 -07:00
- Added the `` -fsanitize-undefined-ignore-overflow-pattern `` flag which can be
used to disable specific overflow-dependent code patterns. The supported
2024-08-23 23:33:23 -07:00
patterns are: `` add-signed-overflow-test `` , `` add-unsigned-overflow-test `` ,
`` negated-unsigned-const `` , and `` unsigned-post-decr-while `` . The sanitizer
instrumentation can be toggled off for all available patterns by specifying
`` all `` . Conversely, you may disable all exclusions with `` none `` which is
the default.
2024-08-20 13:13:44 -07:00
.. code-block :: c++
2024-08-23 23:33:23 -07:00
/// specified with `` -fsanitize-undefined-ignore-overflow-pattern=add-unsigned-overflow-test ``
2024-08-20 13:13:44 -07:00
int common_overflow_check_pattern(unsigned base, unsigned offset) {
if (base + offset < base) { /* ... * / } // The pattern of `a + b < a` , and other re-orderings, won't be instrumented
}
2024-08-23 23:33:23 -07:00
/// specified with `` -fsanitize-undefined-ignore-overflow-pattern=add-signed-overflow-test ``
int common_overflow_check_pattern_signed(signed int base, signed int offset) {
if (base + offset < base) { /* ... * / } // The pattern of `a + b < a` , and other re-orderings, won't be instrumented
}
2024-08-20 13:13:44 -07:00
/// specified with `` -fsanitize-undefined-ignore-overflow-pattern=negated-unsigned-const ``
void negation_overflow() {
unsigned long foo = -1UL; // No longer causes a negation overflow warning
unsigned long bar = -2UL; // and so on...
}
2024-08-23 23:33:23 -07:00
/// specified with `` -fsanitize-undefined-ignore-overflow-pattern=unsigned-post-decr-while ``
2024-08-20 13:13:44 -07:00
void while_post_decrement() {
unsigned char count = 16;
2024-08-23 23:33:23 -07:00
while (count--) { /* ... * / } // No longer causes unsigned-integer-overflow sanitizer to trip
2024-08-20 13:13:44 -07:00
}
Many existing projects have a large amount of these code patterns present.
This new flag should allow those projects to enable integer sanitizers with
less noise.
2024-11-04 16:00:22 -08:00
- `` -fsanitize=signed-integer-overflow `` , `` -fsanitize=unsigned-integer-overflow `` ,
`` -fsanitize=implicit-signed-integer-truncation `` , `` -fsanitize=implicit-unsigned-integer-truncation `` ,
`` -fsanitize=enum `` now properly support the
2024-11-03 23:57:47 -08:00
"type" prefix within `Sanitizer Special Case Lists (SSCL)
<https://clang.llvm.org/docs/SanitizerSpecialCaseList.html>`_. See that link
for examples.
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-09-24 06:16:03 -07:00
- Added support for 'omp scope' directive.
2024-11-05 17:06:41 -08:00
- Added support for allocator-modifier in 'allocate' clause.
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> `_.