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
|
|
|
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
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
|
|
|
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
|
|
|
|
|
releases may be downloaded from the `LLVM releases web
|
|
|
|
|
site <https://llvm.org/releases/>`_.
|
|
|
|
|
|
|
|
|
|
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>`_.
|
|
|
|
|
|
|
|
|
|
Note that if you are reading this file from a Git checkout or the
|
|
|
|
|
main Clang web page, this document applies to the *next* release, not
|
|
|
|
|
the current one. To see the release notes for a specific release, please
|
|
|
|
|
see the `releases page <https://llvm.org/releases/>`_.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
- 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
|
2022-09-17 08:43:17 -04:00
|
|
|
|
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 diagnosed as out of the range [0, 7]
|
|
|
|
|
constexpr E Val4 = (E)-1; // Now diagnosed as out of the range [0, 7]
|
|
|
|
|
|
|
|
|
|
Due to the extended period of time this bug was present in major C++
|
|
|
|
|
implementations (including Clang), this error has the ability to be
|
|
|
|
|
downgraded into a warning (via: ``-Wno-error=enum-constexpr-conversion``) to
|
|
|
|
|
provide a transition period for users. This diagnostic is expected to turn
|
|
|
|
|
into an error-only diagnostic in the next Clang release. Fixes
|
|
|
|
|
`Issue 50055 <https://github.com/llvm/llvm-project/issues/50055>`_.
|
|
|
|
|
|
2022-10-09 23:39:23 +01:00
|
|
|
|
- The ``-Wimplicit-function-declaration`` and ``-Wimplicit-int`` warnings
|
|
|
|
|
now default to an error in C99, C11, and C17. As of C2x,
|
|
|
|
|
support for implicit function declarations and implicit int has been removed,
|
|
|
|
|
and the warning options will have no effect. Specifying ``-Wimplicit-int`` in
|
|
|
|
|
C89 mode will now issue warnings instead of being a noop.
|
|
|
|
|
|
|
|
|
|
**NOTE**: We recommend that projects using configure scripts verify that the
|
|
|
|
|
results do not change before/after setting
|
|
|
|
|
``-Werror=implicit-function-declarations`` or ``-Wimplicit-int`` to avoid
|
|
|
|
|
incompatibility with Clang 16.
|
|
|
|
|
|
2022-09-15 07:29:49 -04:00
|
|
|
|
- ``-Wincompatible-function-pointer-types`` now defaults to an error in all C
|
|
|
|
|
language modes. It may be downgraded to a warning with
|
|
|
|
|
``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with
|
2022-10-10 14:45:11 -04:00
|
|
|
|
``-Wno-incompatible-function-pointer-types``.
|
2022-09-17 08:43:17 -04:00
|
|
|
|
|
|
|
|
|
**NOTE:** We recommend that projects using configure scripts verify that the
|
|
|
|
|
results do not change before/after setting
|
2022-09-15 07:29:49 -04:00
|
|
|
|
``-Werror=incompatible-function-pointer-types`` to avoid incompatibility with
|
|
|
|
|
Clang 16.
|
|
|
|
|
|
2022-09-17 08:43:17 -04:00
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
|
|
void func(const int *i);
|
|
|
|
|
void other(void) {
|
|
|
|
|
void (*fp)(int *) = func; // Previously a warning, now a downgradable error.
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-28 14:33:52 -04:00
|
|
|
|
- Clang now disallows types whose sizes aren't a multiple of their alignments
|
|
|
|
|
to be used as the element type of arrays.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
|
|
typedef char int8_a16 __attribute__((aligned(16)));
|
|
|
|
|
int8_a16 array[4]; // Now diagnosed as the element size not being a multiple of the array alignment.
|
|
|
|
|
|
2022-09-19 01:05:56 +02:00
|
|
|
|
- When compiling for Windows in MSVC compatibility mode (for example by using
|
|
|
|
|
clang-cl), the compiler will now propagate dllimport/export declspecs in
|
|
|
|
|
explicit specializations of class template member functions (`Issue 54717
|
|
|
|
|
<https://github.com/llvm/llvm-project/issues/54717>`_):
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
template <typename> struct __declspec(dllexport) S {
|
|
|
|
|
void f();
|
|
|
|
|
};
|
|
|
|
|
template<> void S<int>::f() {} // clang-cl will now dllexport this.
|
|
|
|
|
|
|
|
|
|
This matches what MSVC does, so it improves compatibility, but it can also
|
|
|
|
|
cause errors for code which clang-cl would previously accept, for example:
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
template <typename> struct __declspec(dllexport) S {
|
|
|
|
|
void f();
|
|
|
|
|
};
|
|
|
|
|
template<> void S<int>::f() = delete; // Error: cannot delete dllexport function.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
template <typename> struct __declspec(dllimport) S {
|
|
|
|
|
void f();
|
|
|
|
|
};
|
|
|
|
|
template<> void S<int>::f() {}; // Error: cannot define dllimport function.
|
|
|
|
|
|
|
|
|
|
These errors also match MSVC's behavior.
|
2022-09-15 07:29:49 -04:00
|
|
|
|
|
2022-10-04 12:41:43 -07:00
|
|
|
|
- Clang now diagnoses indirection of ``void *`` in C++ mode as a warning which
|
|
|
|
|
defaults to an error. This is compatible with ISO C++, GCC, ICC, and MSVC. This
|
|
|
|
|
is also now a SFINAE error so constraint checking and SFINAE checking can be
|
|
|
|
|
compatible with other compilers. It is expected that this will be upgraded to
|
|
|
|
|
an error-only diagnostic in the next Clang release.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
2022-10-10 07:22:41 -07:00
|
|
|
|
void func(void *p) {
|
|
|
|
|
*p; // Now diagnosed as a warning-as-error.
|
|
|
|
|
}
|
2022-10-04 12:41:43 -07:00
|
|
|
|
|
2022-10-07 14:13:46 -07:00
|
|
|
|
- Clang now diagnoses use of a bit-field as an instruction operand in Microsoft
|
|
|
|
|
style inline asm blocks as an error. Previously, a bit-field operand yielded
|
|
|
|
|
the address of the allocation unit the bit-field was stored within; reads or
|
|
|
|
|
writes therefore had the potential to read or write nearby bit-fields. This
|
|
|
|
|
change fixes `issue 57791 <https://github.com/llvm/llvm-project/issues/57791>`_.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
typedef struct S {
|
|
|
|
|
unsigned bf:1;
|
|
|
|
|
} S;
|
|
|
|
|
void f(S s) {
|
|
|
|
|
__asm {
|
|
|
|
|
mov eax, s.bf // Now diagnosed as an error.
|
|
|
|
|
mov s.bf, eax // Now diagnosed as an error.
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-01 16:54:08 -04:00
|
|
|
|
- The ``-fexperimental-new-pass-manager`` and ``-fno-legacy-pass-manager``
|
|
|
|
|
flags have been removed. These have been no-ops since 15.0.0.
|
2022-10-07 14:13:46 -07:00
|
|
|
|
|
2022-11-02 11:54:19 -07:00
|
|
|
|
- As a side effect of implementing DR692/DR1395/DR1432, Clang now rejects some
|
|
|
|
|
overloaded function templates as ambiguous when one of the candidates has a
|
|
|
|
|
trailing parameter pack.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
template <typename T> void g(T, T = T());
|
|
|
|
|
template <typename T, typename... U> void g(T, U...);
|
|
|
|
|
void h() {
|
|
|
|
|
// This is rejected due to ambiguity between the pack and the
|
|
|
|
|
// default argument. Only parameters with arguments are considered during
|
|
|
|
|
// partial ordering of function templates.
|
|
|
|
|
g(42);
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-09 08:05:41 +02:00
|
|
|
|
- Clang's resource dir used to include the full clang version. It will now
|
|
|
|
|
include only the major version. The new resource directory is
|
|
|
|
|
``$prefix/lib/clang/$CLANG_MAJOR_VERSION`` and can be queried using
|
|
|
|
|
``clang -print-resource-dir``, just like before.
|
|
|
|
|
|
2022-11-22 17:01:39 -08:00
|
|
|
|
- To match GCC, ``__ppc64__`` is no longer defined on PowerPC64 targets. Use
|
|
|
|
|
``__powerpc64__`` instead.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Major New Features
|
|
|
|
|
------------------
|
|
|
|
|
|
2022-02-11 08:27:33 +01:00
|
|
|
|
Bug Fixes
|
2022-05-06 08:47:19 -04:00
|
|
|
|
---------
|
2022-09-28 13:24:54 -06:00
|
|
|
|
- Correct ``_Static_assert`` to accept the same set of extended integer
|
|
|
|
|
constant expressions as is accpted in other contexts that accept them.
|
|
|
|
|
This fixes `Issue 57687 <https://github.com/llvm/llvm-project/issues/57687>`_.
|
2022-07-29 13:16:10 -04:00
|
|
|
|
- Fixes an accepts-invalid bug in C when using a ``_Noreturn`` function
|
|
|
|
|
specifier on something other than a function declaration. This fixes
|
|
|
|
|
`Issue 56800 <https://github.com/llvm/llvm-project/issues/56800>`_.
|
2022-08-01 23:47:30 +03:00
|
|
|
|
- Fix `#56772 <https://github.com/llvm/llvm-project/issues/56772>`_ - invalid
|
|
|
|
|
destructor names were incorrectly accepted on template classes.
|
2022-07-29 16:12:49 +02:00
|
|
|
|
- Improve compile-times with large dynamic array allocations with trivial
|
|
|
|
|
constructors. This fixes
|
2022-08-03 10:51:34 +02:00
|
|
|
|
`Issue 56774 <https://github.com/llvm/llvm-project/issues/56774>`_.
|
2022-08-03 14:05:09 -04:00
|
|
|
|
- No longer assert/miscompile when trying to make a vectorized ``_BitInt`` type
|
|
|
|
|
using the ``ext_vector_type`` attribute (the ``vector_size`` attribute was
|
|
|
|
|
already properly diagnosing this case).
|
2022-08-03 17:05:07 +02:00
|
|
|
|
- Fix clang not properly diagnosing the failing subexpression when chained
|
|
|
|
|
binary operators are used in a ``static_assert`` expression.
|
2022-08-04 12:53:06 +02:00
|
|
|
|
- Fix a crash when evaluating a multi-dimensional array's array filler
|
|
|
|
|
expression is element-dependent. This fixes
|
|
|
|
|
`Issue 50601 <https://github.com/llvm/llvm-project/issues/56016>`_.
|
2022-08-11 13:42:47 -04:00
|
|
|
|
- Fixed a crash-on-valid with consteval evaluation of a list-initialized
|
|
|
|
|
constructor for a temporary object. This fixes
|
|
|
|
|
`Issue 55871 <https://github.com/llvm/llvm-project/issues/55871>`_.
|
2022-08-12 02:14:09 +08:00
|
|
|
|
- Fix `#57008 <https://github.com/llvm/llvm-project/issues/57008>`_ - Builtin
|
|
|
|
|
C++ language extension type traits instantiated by a template with unexpected
|
|
|
|
|
number of arguments cause an assertion fault.
|
2022-08-12 21:50:30 +02:00
|
|
|
|
- Fix multi-level pack expansion of undeclared function parameters.
|
|
|
|
|
This fixes `Issue 56094 <https://github.com/llvm/llvm-project/issues/56094>`_.
|
2022-08-15 22:35:39 +08:00
|
|
|
|
- Fix `#57151 <https://github.com/llvm/llvm-project/issues/57151>`_.
|
|
|
|
|
``-Wcomma`` is emitted for void returning functions.
|
2022-08-19 10:46:29 -04:00
|
|
|
|
- ``-Wtautological-compare`` missed warnings for tautological comparisons
|
|
|
|
|
involving a negative integer literal. This fixes
|
|
|
|
|
`Issue 42918 <https://github.com/llvm/llvm-project/issues/42918>`_.
|
2022-08-26 10:20:12 +02:00
|
|
|
|
- Fix a crash when generating code coverage information for an
|
|
|
|
|
``if consteval`` statement. This fixes
|
|
|
|
|
`Issue 57377 <https://github.com/llvm/llvm-project/issues/57377>`_.
|
2022-08-26 09:12:29 -07:00
|
|
|
|
- Fix assert that triggers a crash during template name lookup when a type was
|
|
|
|
|
incomplete but was not also a TagType. This fixes
|
|
|
|
|
`Issue 57387 <https://github.com/llvm/llvm-project/issues/57387>`_.
|
2022-08-29 06:51:09 +02:00
|
|
|
|
- Fix a crash when emitting a concept-related diagnostic. This fixes
|
|
|
|
|
`Issue 57415 <https://github.com/llvm/llvm-project/issues/57415>`_.
|
2022-08-30 18:08:44 -07:00
|
|
|
|
- Fix a crash when attempting to default a virtual constexpr non-special member
|
|
|
|
|
function in a derived class. This fixes
|
|
|
|
|
`Issue 57431 <https://github.com/llvm/llvm-project/issues/57431>`_
|
2022-09-02 17:45:44 -07:00
|
|
|
|
- Fix a crash where we attempt to define a deleted destructor. This fixes
|
|
|
|
|
`Issue 57516 <https://github.com/llvm/llvm-project/issues/57516>`_
|
2022-09-07 12:46:20 -04:00
|
|
|
|
- Fix ``__builtin_assume_aligned`` crash when the 1st arg is array type. This fixes
|
|
|
|
|
`Issue 57169 <https://github.com/llvm/llvm-project/issues/57169>`_
|
2022-09-09 18:23:52 +07:00
|
|
|
|
- Clang configuration files are now read through the virtual file system
|
|
|
|
|
rather than the physical one, if these are different.
|
2022-09-15 12:07:23 -07:00
|
|
|
|
- Clang will now no longer treat a C 'overloadable' function without a prototype as
|
|
|
|
|
a variadic function with the attribute. This should make further diagnostics more
|
|
|
|
|
clear.
|
2022-09-03 18:36:59 +02:00
|
|
|
|
- Fixes to builtin template emulation of regular templates.
|
|
|
|
|
`Issue 42102 <https://github.com/llvm/llvm-project/issues/42102>`_
|
|
|
|
|
`Issue 51928 <https://github.com/llvm/llvm-project/issues/51928>`_
|
2022-06-18 04:21:59 +02:00
|
|
|
|
- A SubstTemplateTypeParmType can now represent the pack index for a
|
|
|
|
|
substitution from an expanded pack.
|
|
|
|
|
`Issue 56099 <https://github.com/llvm/llvm-project/issues/56099>`_
|
2022-09-18 11:54:32 -07:00
|
|
|
|
- Fix `-Wpre-c++17-compat` crashing Clang when compiling C++20 code which
|
|
|
|
|
contains deduced template specializations. This Fixes
|
|
|
|
|
`Issue 57369 <https://github.com/llvm/llvm-project/issues/57369>`_
|
|
|
|
|
`Issue 57643 <https://github.com/llvm/llvm-project/issues/57643>`_
|
|
|
|
|
`Issue 57793 <https://github.com/llvm/llvm-project/issues/57793>`_
|
2022-09-18 23:07:25 +03:00
|
|
|
|
- Respect constructor constraints during class template argument deduction (CTAD).
|
|
|
|
|
This is the suggested resolution to CWG DR2628.
|
|
|
|
|
`Issue 57646 <https://github.com/llvm/llvm-project/issues/57646>`_
|
|
|
|
|
`Issue 43829 <https://github.com/llvm/llvm-project/issues/43829>`_
|
2022-09-17 08:30:30 -07:00
|
|
|
|
- Fixed a crash in C++20 mode in Clang and Clangd when compile source
|
|
|
|
|
with compilation errors.
|
|
|
|
|
`Issue 53628 <https://github.com/llvm/llvm-project/issues/53628>`_
|
2022-09-20 15:18:20 +02:00
|
|
|
|
- The template arguments of a variable template being accessed as a
|
|
|
|
|
member will now be represented in the AST.
|
2022-09-21 16:08:45 +02:00
|
|
|
|
- Fix incorrect handling of inline builtins with asm labels.
|
2022-09-29 11:38:52 -07:00
|
|
|
|
- Finished implementing C++ DR2565, which results in a requirement becoming
|
|
|
|
|
not satisfied in the event of an instantiation failures in a requires expression's
|
|
|
|
|
parameter list. We previously handled this correctly in a constraint evaluation
|
|
|
|
|
context, but not in a requires clause evaluated as a boolean.
|
2022-10-17 10:46:07 +08:00
|
|
|
|
- Address the thread identification problems in coroutines.
|
|
|
|
|
`Issue 47177 <https://github.com/llvm/llvm-project/issues/47177>`_
|
|
|
|
|
`Issue 47179 <https://github.com/llvm/llvm-project/issues/47179>`_
|
2022-10-18 21:56:13 +08:00
|
|
|
|
- Fix a crash upon stray coloncolon token in C2x mode.
|
2022-10-19 14:40:52 -07:00
|
|
|
|
- Reject non-type template arguments formed by casting a non-zero integer
|
|
|
|
|
to a pointer in pre-C++17 modes, instead of treating them as null
|
|
|
|
|
pointers.
|
2020-10-11 15:57:52 -07:00
|
|
|
|
- Fix template arguments of pointer and reference not taking the type as
|
|
|
|
|
part of their identity.
|
|
|
|
|
`Issue 47136 <https://github.com/llvm/llvm-project/issues/47136>`_
|
2022-10-28 10:02:04 -07:00
|
|
|
|
- Fix a crash when trying to form a recovery expression on a call inside a
|
|
|
|
|
constraint, which re-evaluated the same constraint.
|
|
|
|
|
`Issue 53213 <https://github.com/llvm/llvm-project/issues/53213>`_
|
|
|
|
|
`Issue 45736 <https://github.com/llvm/llvm-project/issues/45736>`_
|
2022-10-30 21:33:22 -07:00
|
|
|
|
- Fix an issue when performing constraints partial ordering on non-template
|
|
|
|
|
functions. `Issue 56154 <https://github.com/llvm/llvm-project/issues/56154>`_
|
2022-10-28 22:22:39 +02:00
|
|
|
|
- Fix handling of unexpanded packs in template argument expressions.
|
|
|
|
|
`Issue 58679 <https://github.com/llvm/llvm-project/issues/58679>`_
|
[clang][Sema] Fix a clang crash with btf_type_tag
For the following program,
$ cat t.c
struct t {
int (__attribute__((btf_type_tag("rcu"))) *f)();
int a;
};
int foo(struct t *arg) {
return arg->a;
}
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
......
#5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
#6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
#7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
#8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
#9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
......
The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
BTFTagAttributedType 0x88614e0 'int btf_type_tag(rcu)()' sugar
|-ParenType 0x8861480 'int ()' sugar
| `-FunctionNoProtoType 0x8861450 'int ()' cdecl
| `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.
To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().
Differential Revision: https://reviews.llvm.org/D136807
2022-10-26 16:15:02 -07:00
|
|
|
|
- Fix a crash when a ``btf_type_tag`` attribute is applied to the pointee of
|
|
|
|
|
a function pointer.
|
2022-10-31 08:43:08 -07:00
|
|
|
|
- Fix a number of recursively-instantiated constraint issues, which would possibly
|
|
|
|
|
result in a stack overflow.
|
|
|
|
|
`Issue 44304 <https://github.com/llvm/llvm-project/issues/44304>`_
|
|
|
|
|
`Issue 50891 <https://github.com/llvm/llvm-project/issues/50891>`_
|
2022-11-02 07:56:43 -04:00
|
|
|
|
- Clang 14 predeclared some builtin POSIX library functions in ``gnu2x`` mode,
|
|
|
|
|
and Clang 15 accidentally stopped predeclaring those functions in that
|
|
|
|
|
language mode. Clang 16 now predeclares those functions again. This fixes
|
|
|
|
|
`Issue 56607 <https://github.com/llvm/llvm-project/issues/56607>`_.
|
2022-11-15 15:44:34 +00:00
|
|
|
|
- GNU attributes being applied prior to standard attributes would be handled
|
|
|
|
|
improperly, which was corrected to match the behaviour exhibited by GCC.
|
|
|
|
|
`Issue 58229 <https://github.com/llvm/llvm-project/issues/58229>`_
|
2022-11-23 22:26:31 +02:00
|
|
|
|
- The builtin type trait ``__is_aggregate`` now returns ``true`` for arrays of incomplete
|
2022-11-29 12:01:25 -05:00
|
|
|
|
types in accordance with the suggested fix for `LWG3823 <https://cplusplus.github.io/LWG/issue3823>`_
|
2022-03-12 20:49:01 +01:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Improvements to Clang's diagnostics
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-08-03 10:07:31 +08:00
|
|
|
|
- Clang will now check compile-time determinable string literals as format strings.
|
2022-08-07 12:42:15 +08:00
|
|
|
|
Fixes `Issue 55805: <https://github.com/llvm/llvm-project/issues/55805>`_.
|
2022-08-04 10:26:31 -07:00
|
|
|
|
- ``-Wformat`` now recognizes ``%b`` for the ``printf``/``scanf`` family of
|
|
|
|
|
functions and ``%B`` for the ``printf`` family of functions. Fixes
|
|
|
|
|
`Issue 56885: <https://github.com/llvm/llvm-project/issues/56885>`_.
|
2022-08-31 09:23:45 -04:00
|
|
|
|
- Introduced ``-Wsingle-bit-bitfield-constant-conversion``, grouped under
|
|
|
|
|
``-Wbitfield-constant-conversion``, which diagnoses implicit truncation when
|
|
|
|
|
``1`` is assigned to a 1-bit signed integer bitfield. This fixes
|
|
|
|
|
`Issue 53253 <https://github.com/llvm/llvm-project/issues/53253>`_. To reduce
|
|
|
|
|
potential false positives, this diagnostic will not diagnose use of the
|
|
|
|
|
``true`` macro (from ``<stdbool.h>>`) in C language mode despite the macro
|
|
|
|
|
being defined to expand to ``1``.
|
2022-08-01 14:12:32 +02:00
|
|
|
|
- Clang will now print more information about failed static assertions. In
|
|
|
|
|
particular, simple static assertion expressions are evaluated to their
|
|
|
|
|
compile-time value and printed out if the assertion fails.
|
2022-08-11 11:22:00 +02:00
|
|
|
|
- Diagnostics about uninitialized ``constexpr`` varaibles have been improved
|
|
|
|
|
to mention the missing constant initializer.
|
2022-08-26 09:17:14 -04:00
|
|
|
|
- Correctly diagnose a future keyword if it exist as a keyword in the higher
|
|
|
|
|
language version and specifies in which version it will be a keyword. This
|
|
|
|
|
supports both c and c++ language.
|
2022-06-17 22:29:27 +02:00
|
|
|
|
- When diagnosing multi-level pack expansions of mismatched lengths, Clang will
|
|
|
|
|
now, in most cases, be able to point to the relevant outer parameter.
|
2022-09-17 08:21:33 -04:00
|
|
|
|
- ``no_sanitize("...")`` on a global variable for known but not relevant
|
|
|
|
|
sanitizers is now just a warning. It now says that this will be ignored
|
|
|
|
|
instead of incorrectly saying no_sanitize only applies to functions and
|
|
|
|
|
methods.
|
2022-09-12 07:47:18 -04:00
|
|
|
|
- No longer mention ``reinterpet_cast`` in the invalid constant expression
|
|
|
|
|
diagnostic note when in C mode.
|
2022-09-12 22:21:17 +08:00
|
|
|
|
- Clang will now give a more suitale diagnostic for declaration of block
|
|
|
|
|
scope identifiers that have external/internal linkage that has an initializer.
|
|
|
|
|
Fixes `Issue 57478: <https://github.com/llvm/llvm-project/issues/57478>`_.
|
2022-07-19 11:02:32 +02:00
|
|
|
|
- New analysis pass will now help preserve sugar when combining deductions, in an
|
|
|
|
|
order agnostic way. This will be in effect when deducing template arguments,
|
|
|
|
|
when deducing function return type from multiple return statements, for the
|
|
|
|
|
conditional operator, and for most binary operations. Type sugar is combined
|
|
|
|
|
in a way that strips the sugar which is different between terms, and preserves
|
|
|
|
|
those which are common.
|
2022-09-17 07:55:10 -04:00
|
|
|
|
- Correctly diagnose use of an integer literal without a suffix whose
|
|
|
|
|
underlying type is ``long long`` or ``unsigned long long`` as an extension in
|
|
|
|
|
C89 mode . Clang previously only diagnosed if the literal had an explicit
|
|
|
|
|
``LL`` suffix.
|
2022-09-01 15:15:29 +02:00
|
|
|
|
- Clang now correctly diagnoses index that refers past the last possible element
|
|
|
|
|
of FAM-like arrays.
|
2022-09-24 22:18:04 +08:00
|
|
|
|
- Clang now correctly diagnoses a warning when defercencing a void pointer in C mode.
|
|
|
|
|
This fixes `Issue 53631 <https://github.com/llvm/llvm-project/issues/53631>`_
|
2022-09-26 06:57:25 -07:00
|
|
|
|
- Clang will now diagnose an overload set where a candidate has a constraint that
|
|
|
|
|
refers to an expression with a previous error as nothing viable, so that it
|
|
|
|
|
doesn't generate strange cascading errors, particularly in cases where a
|
|
|
|
|
subsuming constraint fails, which would result in a less-specific overload to
|
|
|
|
|
be selected.
|
2022-10-04 19:38:09 +01:00
|
|
|
|
- Add a fix-it hint for the ``-Wdefaulted-function-deleted`` warning to
|
|
|
|
|
explicitly delete the function.
|
2022-10-06 10:07:16 -04:00
|
|
|
|
- Fixed an accidental duplicate diagnostic involving the declaration of a
|
|
|
|
|
function definition without a prototype which is preceded by a static
|
|
|
|
|
declaration of the function with a prototype. Fixes
|
|
|
|
|
`Issue 58181 <https://github.com/llvm/llvm-project/issues/58181>`_.
|
Thread safety analysis: Support copy-elided production of scoped capabilities through arbitrary calls
When support for copy elision was initially added in e97654b2f2807, it
was taking attributes from a constructor call, although that constructor
call is actually not involved. It seems more natural to use attributes
on the function returning the scoped capability, which is where it's
actually coming from. This would also support a number of interesting
use cases, like producing different scope kinds without the need for tag
types, or producing scopes from a private mutex.
Changing the behavior was surprisingly difficult: we were not handling
CXXConstructorExpr calls like regular calls but instead handled them
through the DeclStmt they're contained in. This was based on the
assumption that constructors are basically only called in variable
declarations (not true because of temporaries), and that variable
declarations necessitate constructors (not true with C++17 anymore).
Untangling this required separating construction from assigning a
variable name. When a call produces an object, we use a placeholder
til::LiteralPtr for `this`, and we collect the call expression and
placeholder in a map. Later when going through a DeclStmt, we look up
the call expression and set the placeholder to the new VarDecl.
The change has a couple of nice side effects:
* We don't miss constructor calls not contained in DeclStmts anymore,
allowing patterns like
MutexLock{&mu}, requiresMutex();
The scoped lock temporary will be destructed at the end of the full
statement, so it protects the following call without the need for a
scope, but with the ability to unlock in case of an exception.
* We support lifetime extension of temporaries. While unusual, one can
now write
const MutexLock &scope = MutexLock(&mu);
and have it behave as expected.
* Destructors used to be handled in a weird way: since there is no
expression in the AST for implicit destructor calls, we instead
provided a made-up DeclRefExpr to the variable being destructed, and
passed that instead of a CallExpr. Then later in translateAttrExpr
there was special code that knew that destructor expressions worked a
bit different.
* We were producing dummy DeclRefExprs in a number of places, this has
been eliminated. We now use til::SExprs instead.
Technically this could break existing code, but the current handling
seems unexpected enough to justify this change.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129755
2022-07-14 01:47:52 +02:00
|
|
|
|
- Copy-elided initialization of lock scopes is now handled differently in
|
|
|
|
|
``-Wthread-safety-analysis``: annotations on the move constructor are no
|
|
|
|
|
longer taken into account, in favor of annotations on the function returning
|
|
|
|
|
the lock scope by value. This could result in new warnings if code depended
|
|
|
|
|
on the previous undocumented behavior. As a side effect of this change,
|
|
|
|
|
constructor calls outside of initializer expressions are no longer ignored,
|
|
|
|
|
which can result in new warnings (or make existing warnings disappear).
|
2022-10-20 11:55:38 -07:00
|
|
|
|
- The wording of diagnostics regarding arithmetic on fixed-sized arrays and
|
|
|
|
|
pointers is improved to include the type of the array and whether it's cast
|
|
|
|
|
to another type. This should improve comprehension for why an index is
|
|
|
|
|
out-of-bounds.
|
2022-10-24 15:01:46 -04:00
|
|
|
|
- Clang now correctly points to the problematic parameter for the ``-Wnonnull``
|
|
|
|
|
warning. This fixes
|
|
|
|
|
`Issue 58273 <https://github.com/llvm/llvm-project/issues/58273>`_.
|
2022-11-07 22:55:24 +00:00
|
|
|
|
- Introduced ``-Wcast-function-type-strict`` and
|
|
|
|
|
``-Wincompatible-function-pointer-types-strict`` to warn about function type
|
|
|
|
|
mismatches in casts and assignments that may result in runtime indirect call
|
|
|
|
|
`Control-Flow Integrity (CFI)
|
|
|
|
|
<https://clang.llvm.org/docs/ControlFlowIntegrity.html>`_ failures. The
|
|
|
|
|
``-Wcast-function-type-strict`` diagnostic is grouped under
|
|
|
|
|
``-Wcast-function-type`` as it identifies a more strict set of potentially
|
|
|
|
|
problematic function type casts.
|
2022-10-28 08:18:38 -04:00
|
|
|
|
- Clang will now disambiguate NTTP types when printing diagnostic that contain NTTP types.
|
|
|
|
|
Fixes `Issue 57562 <https://github.com/llvm/llvm-project/issues/57562>`_.
|
2022-10-28 18:23:02 +02:00
|
|
|
|
- Better error recovery for pack expansion of expressions.
|
|
|
|
|
`Issue 58673 <https://github.com/llvm/llvm-project/issues/58673>`_.
|
2022-11-01 11:37:35 -07:00
|
|
|
|
- Better diagnostics when the user has missed `auto` in a declaration.
|
|
|
|
|
`Issue 49129 <https://github.com/llvm/llvm-project/issues/49129>`_.
|
2022-11-03 08:27:56 -04:00
|
|
|
|
- Clang now diagnoses use of invalid or reserved module names in a module
|
|
|
|
|
export declaration. Both are diagnosed as an error, but the diagnostic is
|
|
|
|
|
suppressed for use of reserved names in a system header.
|
2022-11-15 11:06:59 -08:00
|
|
|
|
- ``-Winteger-overflow`` will diagnose overflow in more cases. This fixes
|
|
|
|
|
`Issue 58944 <https://github.com/llvm/llvm-project/issues/58944>`_.
|
2022-11-09 15:45:54 -08:00
|
|
|
|
- Clang has an internal limit of 2GB of preprocessed source code per
|
|
|
|
|
compilation, including source reachable through imported AST files such as
|
|
|
|
|
PCH or modules. When Clang hits this limit, it now produces notes mentioning
|
|
|
|
|
which header and source files are consuming large amounts of this space.
|
|
|
|
|
``#pragma clang __debug sloc_usage`` can also be used to request this report.
|
2022-11-28 10:21:38 -08:00
|
|
|
|
- Clang no longer permits the keyword 'bool' in a concept declaration as a
|
|
|
|
|
concepts-ts compatibility extension.
|
2022-08-26 09:17:14 -04:00
|
|
|
|
|
2022-08-26 10:04:06 -04:00
|
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
|
-------------------------------------------------
|
2022-09-01 04:17:06 +02:00
|
|
|
|
- It's now possible to set the crash diagnostics directory through
|
|
|
|
|
the environment variable ``CLANG_CRASH_DIAGNOSTICS_DIR``.
|
|
|
|
|
The ``-fcrash-diagnostics-dir`` flag takes precedence.
|
2022-09-06 17:10:55 -07:00
|
|
|
|
- When using header modules, inclusion of a private header and violations of
|
|
|
|
|
the `use-declaration rules
|
|
|
|
|
<https://clang.llvm.org/docs/Modules.html#use-declaration>`_ are now
|
|
|
|
|
diagnosed even when the includer is a textual header. This change can be
|
|
|
|
|
temporarily reversed with ``-Xclang
|
|
|
|
|
-fno-modules-validate-textual-header-includes``, but this flag will be
|
|
|
|
|
removed in a future Clang release.
|
2022-09-13 20:09:56 +02:00
|
|
|
|
- Unicode support has been updated to support Unicode 15.0.
|
|
|
|
|
New unicode codepoints are supported as appropriate in diagnostics,
|
|
|
|
|
C and C++ identifiers, and escape sequences.
|
2022-09-29 20:58:35 +02:00
|
|
|
|
- Clang now supports loading multiple configuration files. The files from
|
|
|
|
|
default configuration paths are loaded first, unless ``--no-default-config``
|
|
|
|
|
option is used. All files explicitly specified using ``--config=`` option
|
|
|
|
|
are loaded afterwards.
|
|
|
|
|
- When loading default configuration files, clang now unconditionally uses
|
|
|
|
|
the real target triple (respecting options such as ``--target=`` and ``-m32``)
|
|
|
|
|
rather than the executable prefix. The respective configuration files are
|
|
|
|
|
also loaded when clang is called via an executable without a prefix (e.g.
|
|
|
|
|
plain ``clang``).
|
|
|
|
|
- Default configuration paths were partially changed. Clang now attempts to load
|
|
|
|
|
``<triple>-<driver>.cfg`` first, and falls back to loading both
|
|
|
|
|
``<driver>.cfg`` and ``<triple>.cfg`` if the former is not found. `Triple`
|
|
|
|
|
is the target triple and `driver` first tries the canonical name
|
|
|
|
|
for the driver (respecting ``--driver-mode=``), and then the name found
|
|
|
|
|
in the executable.
|
2022-10-12 11:55:26 -07:00
|
|
|
|
- If the environment variable ``SOURCE_DATE_EPOCH`` is set, it specifies a UNIX
|
|
|
|
|
timestamp to be used in replacement of the current date and time in
|
|
|
|
|
the ``__DATE__``, ``__TIME__``, and ``__TIMESTAMP__`` macros. See
|
|
|
|
|
`<https://reproducible-builds.org/docs/source-date-epoch/>`_.
|
2022-10-21 11:22:50 +00:00
|
|
|
|
- Clang now supports ``__has_constexpr_builtin`` function-like macro that
|
|
|
|
|
evaluates to 1 if the builtin is supported and can be constant evaluated.
|
|
|
|
|
It can be used to writing conditionally constexpr code that uses builtins.
|
2022-10-15 17:11:40 +00:00
|
|
|
|
- The time profiler (using ``-ftime-trace`` option) now traces various constant
|
|
|
|
|
evaluation events.
|
2022-08-26 09:17:14 -04:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
New Compiler Flags
|
|
|
|
|
------------------
|
|
|
|
|
|
2022-09-22 10:59:39 +08:00
|
|
|
|
- Implemented `-fcoro-aligned-allocation` flag. This flag implements
|
|
|
|
|
Option 2 of P2014R0 aligned allocation of coroutine frames
|
|
|
|
|
(`P2014R0 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2014r0.pdf>`_).
|
|
|
|
|
With this flag, the coroutines will try to lookup aligned allocation
|
|
|
|
|
function all the time. The compiler will emit an error if it fails to
|
|
|
|
|
find aligned allocation function. So if the user code implemented self
|
|
|
|
|
defined allocation function for coroutines, the existing code will be
|
|
|
|
|
broken. A little divergence with P2014R0 is that clang will lookup
|
|
|
|
|
`::operator new(size_t, std::aligned_val_t, nothrow_t)` if there is
|
|
|
|
|
`get_return_object_on_allocation_failure`. We feel this is more consistent
|
|
|
|
|
with the intention.
|
[clang] Implement -fstrict-flex-arrays=3
The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays.
No number, including 0, is allowed in the FAM. In the cases where a "0"
is used, the resulting size is the same as if a zero-sized object were
substituted.
This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel,
among other reasons. So while the only reason for specifying a
zero-length array at the end of a structure is for specify a FAM,
treating it as such will cause _FORTIFY_SOURCE not to work correctly;
__builtin_object_size will report -1 instead of 0 for a destination
buffer size to keep any kernel internals from using the deprecated
members as fake FAMs.
For example:
struct broken {
int foo;
int fake_fam[0];
struct something oops;
};
There have been bugs where the above struct was created because "oops"
was added after "fake_fam" by someone not realizing. Under
__FORTIFY_SOURCE, doing:
memcpy(p->fake_fam, src, len);
raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1
and may stomp on "oops."
Omitting a warning when using the (invalid) zero-length array is how GCC
treats -fstrict-flex-arrays=3. A warning in that situation is likely an
irritant, because requesting this option level is explicitly requesting
this behavior.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
|
|
|
|
|
2022-09-29 20:58:35 +02:00
|
|
|
|
- Added ``--no-default-config`` to disable automatically loading configuration
|
|
|
|
|
files using default paths.
|
2022-09-22 10:59:39 +08:00
|
|
|
|
|
[clang] Implement -fstrict-flex-arrays=3
The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays.
No number, including 0, is allowed in the FAM. In the cases where a "0"
is used, the resulting size is the same as if a zero-sized object were
substituted.
This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel,
among other reasons. So while the only reason for specifying a
zero-length array at the end of a structure is for specify a FAM,
treating it as such will cause _FORTIFY_SOURCE not to work correctly;
__builtin_object_size will report -1 instead of 0 for a destination
buffer size to keep any kernel internals from using the deprecated
members as fake FAMs.
For example:
struct broken {
int foo;
int fake_fam[0];
struct something oops;
};
There have been bugs where the above struct was created because "oops"
was added after "fake_fam" by someone not realizing. Under
__FORTIFY_SOURCE, doing:
memcpy(p->fake_fam, src, len);
raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1
and may stomp on "oops."
Omitting a warning when using the (invalid) zero-length array is how GCC
treats -fstrict-flex-arrays=3. A warning in that situation is likely an
irritant, because requesting this option level is explicitly requesting
this behavior.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
|
|
|
|
- Added the new level, ``3``, to the ``-fstrict-flex-arrays=`` flag. The new
|
|
|
|
|
level is the strict, standards-conforming mode for flexible array members. It
|
|
|
|
|
recognizes only incomplete arrays as flexible array members (which is how the
|
|
|
|
|
feature is defined by the C standard).
|
|
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
|
|
struct foo {
|
|
|
|
|
int a;
|
|
|
|
|
int b[]; // Flexible array member.
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct bar {
|
|
|
|
|
int a;
|
|
|
|
|
int b[0]; // NOT a flexible array member.
|
|
|
|
|
};
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Deprecated Compiler Flags
|
|
|
|
|
-------------------------
|
2022-05-06 12:47:43 -07:00
|
|
|
|
- ``-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang``
|
|
|
|
|
has been deprecated. The flag will be removed in Clang 18.
|
|
|
|
|
``-ftrivial-auto-var-init=zero`` is now available unconditionally, to be
|
|
|
|
|
compatible with GCC.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
|
|
Modified Compiler Flags
|
|
|
|
|
-----------------------
|
2022-09-29 20:58:35 +02:00
|
|
|
|
- Clang now permits specifying ``--config=`` multiple times, to load multiple
|
|
|
|
|
configuration files.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
2020-12-17 09:23:02 -05:00
|
|
|
|
Removed Compiler Flags
|
|
|
|
|
-------------------------
|
2022-11-21 06:30:47 -08:00
|
|
|
|
- Clang now no longer supports ``-cc1 -fconcepts-ts``. This flag has been deprecated
|
|
|
|
|
and encouraged use of ``-std=c++20`` since Clang 10, so we're now removing it.
|
2020-12-17 09:23:02 -05:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
New Pragmas in Clang
|
|
|
|
|
--------------------
|
|
|
|
|
- ...
|
|
|
|
|
|
|
|
|
|
Attribute Changes in Clang
|
|
|
|
|
--------------------------
|
2022-08-23 23:08:05 +03:00
|
|
|
|
- Added support for ``__attribute__((guard(nocf)))`` and C++-style
|
|
|
|
|
``[[clang::guard(nocf)]]``, which is equivalent to ``__declspec(guard(nocf))``
|
|
|
|
|
when using the MSVC environment. This is to support enabling Windows Control
|
|
|
|
|
Flow Guard checks with the ability to disable them for specific functions when
|
2022-08-29 11:27:27 +03:00
|
|
|
|
using the MinGW environment. This attribute is only available for Windows
|
|
|
|
|
targets.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
2022-08-24 12:24:54 -07:00
|
|
|
|
- Introduced a new function attribute ``__attribute__((nouwtable))`` to suppress
|
|
|
|
|
LLVM IR ``uwtable`` function attribute.
|
|
|
|
|
|
2022-09-13 08:09:55 -04:00
|
|
|
|
- Updated the value returned by ``__has_c_attribute(nodiscard)`` to ``202003L``
|
|
|
|
|
based on the final date specified by the C2x committee draft. We already
|
|
|
|
|
supported the ability to specify a message in the attribute, so there were no
|
|
|
|
|
changes to the attribute behavior.
|
|
|
|
|
|
2022-09-13 11:06:01 -04:00
|
|
|
|
- Updated the value returned by ``__has_c_attribute(fallthrough)`` to ``201910L``
|
|
|
|
|
based on the final date specified by the C2x committee draft. We previously
|
|
|
|
|
used ``201904L`` (the date the proposal was seen by the committee) by mistake.
|
|
|
|
|
There were no other changes to the attribute behavior.
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Windows Support
|
|
|
|
|
---------------
|
2022-09-09 09:18:02 +03:00
|
|
|
|
- For the MinGW driver, added the options ``-mguard=none``, ``-mguard=cf`` and
|
|
|
|
|
``-mguard=cf-nochecks`` (equivalent to ``/guard:cf-``, ``/guard:cf`` and
|
|
|
|
|
``/guard:cf,nochecks`` in clang-cl) for enabling Control Flow Guard checks
|
|
|
|
|
and generation of address-taken function table.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
2022-11-19 12:34:58 -05:00
|
|
|
|
- Switched from SHA1 to BLAKE3 for PDB type hashing / ``-gcodeview-ghash``
|
|
|
|
|
|
2022-05-02 17:06:04 -04:00
|
|
|
|
AIX Support
|
|
|
|
|
-----------
|
2022-09-17 08:21:33 -04:00
|
|
|
|
* When using ``-shared``, the clang driver now invokes llvm-nm to create an
|
[AIX][clang][driver] Check the command string to the linker for exportlist opts
Summary:
Some of code in the patch are contributed by David Tenty.
1. We currently only check driver Wl options and don't check for the plain -b, -Xlinker or other options which get passed through to the linker when we decide whether to run llvm-nm --export-symbols, so we may run it in situations where we wouldn't if the user had used the equivalent -Wl, prefixed options. If we run the export list utility when the user has specified an export list, we could export more symbols than they intended.
2. Add a new functionality to allow redirecting the stdin, stdout, stderr of individual Jobs, if redirects are set for the Job use them, otherwise fall back to the global Compilation redirects if any.
Reviewers: David Tenty, Fangrui Song, Steven Wan
Differential Revision: https://reviews.llvm.org/D119147
2022-08-30 10:38:38 -04:00
|
|
|
|
export list if the user doesn't specify one via linker flag or pass an
|
|
|
|
|
alternative export control option.
|
2022-05-02 17:06:04 -04:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
C Language Changes in Clang
|
|
|
|
|
---------------------------
|
2022-08-26 19:26:32 +08:00
|
|
|
|
- Adjusted ``-Wformat`` warnings according to `WG14 N2562 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdf>`_.
|
2022-09-17 08:21:33 -04:00
|
|
|
|
Clang will now consider default argument promotions in ``printf``, and remove
|
|
|
|
|
unnecessary warnings. Especially ``int`` argument with specifier ``%hhd`` and
|
|
|
|
|
``%hd``.
|
2022-08-26 19:26:32 +08:00
|
|
|
|
|
2022-02-14 09:33:48 -05:00
|
|
|
|
C2x Feature Support
|
|
|
|
|
-------------------
|
2022-09-13 09:27:13 -04:00
|
|
|
|
- Implemented `WG14 N2662 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2662.pdf>`_,
|
|
|
|
|
so the [[maybe_unused]] attribute may be applied to a label to silence an
|
|
|
|
|
``-Wunused-label`` warning.
|
2022-09-19 07:37:41 -04:00
|
|
|
|
- Implemented `WG14 N2508 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf>`_,
|
2022-09-14 18:08:34 +00:00
|
|
|
|
so labels can placed everywhere inside a compound statement.
|
[C2x] implement typeof and typeof_unqual
This implements WG14 N2927 and WG14 N2930, which together define the
feature for typeof and typeof_unqual, which get the type of their
argument as either fully qualified or fully unqualified. The argument
to either operator is either a type name or an expression. If given a
type name, the type information is pulled directly from the given name.
If given an expression, the type information is pulled from the
expression. Recursive use of these operators is allowed and has the
expected behavior (the innermost operator is resolved to a type, and
that's used to resolve the next layer of typeof specifier, until a
fully resolved type is determined.
Note, we already supported typeof in GNU mode as a non-conforming
extension and we are *not* exposing typeof_unqual as a non-conforming
extension in that mode, nor are we exposing typeof or typeof_unqual as
a nonconforming extension in other language modes. The GNU variant of
typeof supports a form where the parentheses are elided from the
operator when given an expression (e.g., typeof 0 i = 12;). When in C2x
mode, we do not support this extension.
Differential Revision: https://reviews.llvm.org/D134286
2022-09-28 13:25:58 -04:00
|
|
|
|
- Implemented `WG14 N2927 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm>`_,
|
|
|
|
|
the Not-so-magic ``typeof`` operator. Also implemented
|
|
|
|
|
`WG14 N2930 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2930.pdf>`_,
|
|
|
|
|
renaming ``remove_quals``, so the ``typeof_unqual`` operator is also
|
|
|
|
|
supported. Both of these operators are supported only in C2x mode. The
|
|
|
|
|
``typeof`` operator specifies the type of the given parenthesized expression
|
|
|
|
|
operand or type name, including all qualifiers. The ``typeof_unqual``
|
|
|
|
|
operator is similar to ``typeof`` except that all qualifiers are removed,
|
|
|
|
|
including atomic type qualification and type attributes which behave like a
|
|
|
|
|
qualifier, such as an address space attribute.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
|
|
__attribute__((address_space(1))) const _Atomic int Val;
|
|
|
|
|
typeof(Val) OtherVal; // type is '__attribute__((address_space(1))) const _Atomic int'
|
|
|
|
|
typeof_unqual(Val) OtherValUnqual; // type is 'int'
|
2022-09-14 18:08:34 +00:00
|
|
|
|
|
2022-10-14 10:04:34 -04:00
|
|
|
|
- Implemented `WG14 N3042 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm>`_,
|
|
|
|
|
Introduce the nullptr constant. This introduces a new type ``nullptr_t``,
|
|
|
|
|
declared in ``<stddef.h>`` which represents the type of the null pointer named
|
|
|
|
|
constant, ``nullptr``. This constant is implicitly convertible to any pointer
|
|
|
|
|
type and represents a type-safe null value.
|
|
|
|
|
|
|
|
|
|
Note, there are some known incompatibilities with this same feature in C++.
|
|
|
|
|
The following examples were discovered during implementation and are subject
|
|
|
|
|
to change depending on how national body comments are resolved by WG14 (C
|
|
|
|
|
status is based on standard requirements, not necessarily implementation
|
|
|
|
|
behavior):
|
|
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
|
|
nullptr_t null_val;
|
|
|
|
|
(nullptr_t)nullptr; // Rejected in C, accepted in C++, Clang accepts
|
|
|
|
|
(void)(1 ? nullptr : 0); // Rejected in C, accepted in C++, Clang rejects
|
|
|
|
|
(void)(1 ? null_val : 0); // Rejected in C, accepted in C++, Clang rejects
|
|
|
|
|
bool b1 = nullptr; // Accepted in C, rejected in C++, Clang rejects
|
|
|
|
|
b1 = null_val; // Accepted in C, rejected in C++, Clang rejects
|
|
|
|
|
null_val = 0; // Rejected in C, accepted in C++, Clang rejects
|
|
|
|
|
|
|
|
|
|
void func(nullptr_t);
|
|
|
|
|
func(0); // Rejected in C, accepted in C++, Clang rejects
|
|
|
|
|
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
C++ Language Changes in Clang
|
|
|
|
|
-----------------------------
|
2022-11-02 11:54:19 -07:00
|
|
|
|
- Implemented `DR692 <https://wg21.link/cwg692>`_, `DR1395 <https://wg21.link/cwg1395>`_,
|
|
|
|
|
and `DR1432 <https://wg21.link/cwg1432>`_. The fix for DR1432 is speculative since the
|
|
|
|
|
issue is still open and has no proposed resolution at this time. A speculative fix
|
|
|
|
|
for DR1432 is needed to prevent regressions that would otherwise occur due to DR692.
|
2022-09-08 08:22:04 +00:00
|
|
|
|
- Clang's default C++/ObjC++ standard is now ``gnu++17`` instead of ``gnu++14``.
|
|
|
|
|
This means Clang will by default accept code using features from C++17 and
|
|
|
|
|
conforming GNU extensions. Projects incompatible with C++17 can add
|
|
|
|
|
``-std=gnu++14`` to their build settings to restore the previous behaviour.
|
2022-11-01 17:37:06 +01:00
|
|
|
|
- Implemented DR2358 allowing init captures in lambdas in default arguments.
|
2022-11-29 15:31:21 +01:00
|
|
|
|
- implemented `DR2654 <https://wg21.link/cwg2654>`_ which undeprecates
|
|
|
|
|
all compound assignements operations on volatile qualified variables.
|
2022-08-11 12:53:41 -07:00
|
|
|
|
|
2021-04-14 04:18:23 -07:00
|
|
|
|
C++20 Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2022-03-30 14:27:44 +02:00
|
|
|
|
- Support capturing structured bindings in lambdas
|
2022-09-29 23:16:17 +03:00
|
|
|
|
(`P1091R3 <https://wg21.link/p1091r3>`_ and `P1381R1 <https://wg21.link/P1381R1>`_).
|
2022-09-17 08:21:33 -04:00
|
|
|
|
This fixes issues `Issue 52720 <https://github.com/llvm/llvm-project/issues/52720>`_,
|
|
|
|
|
`Issue 54300 <https://github.com/llvm/llvm-project/issues/54300>`_,
|
|
|
|
|
`Issue 54301 <https://github.com/llvm/llvm-project/issues/54301>`_,
|
|
|
|
|
and `Issue 49430 <https://github.com/llvm/llvm-project/issues/49430>`_.
|
2022-08-09 12:05:26 +02:00
|
|
|
|
- Consider explicitly defaulted constexpr/consteval special member function
|
|
|
|
|
template instantiation to be constexpr/consteval even though a call to such
|
|
|
|
|
a function cannot appear in a constant expression.
|
|
|
|
|
(C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358))
|
2022-08-17 16:44:41 +02:00
|
|
|
|
- Correctly defer dependent immediate function invocations until template instantiation.
|
2022-09-17 08:21:33 -04:00
|
|
|
|
This fixes `Issue 55601 <https://github.com/llvm/llvm-project/issues/55601>`_.
|
2022-08-26 00:51:06 +03:00
|
|
|
|
- Implemented "Conditionally Trivial Special Member Functions" (`P0848 <https://wg21.link/p0848r3>`_).
|
|
|
|
|
Note: The handling of deleted functions is not yet compliant, as Clang
|
|
|
|
|
does not implement `DR1496 <https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1496>`_
|
|
|
|
|
and `DR1734 <https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1734>`_.
|
2022-08-26 10:17:44 +02:00
|
|
|
|
- Class member variables are now in scope when parsing a ``requires`` clause. Fixes
|
2022-09-17 08:21:33 -04:00
|
|
|
|
`Issue 55216 <https://github.com/llvm/llvm-project/issues/55216>`_.
|
2022-08-25 16:05:50 +02:00
|
|
|
|
- Correctly set expression evaluation context as 'immediate function context' in
|
|
|
|
|
consteval functions.
|
2022-09-17 08:21:33 -04:00
|
|
|
|
This fixes `Issue 51182 <https://github.com/llvm/llvm-project/issues/51182>`_.
|
2022-08-29 16:27:46 +00:00
|
|
|
|
- Fixes an assert crash caused by looking up missing vtable information on ``consteval``
|
2022-09-17 08:21:33 -04:00
|
|
|
|
virtual functions. Fixes `Issue 55065 <https://github.com/llvm/llvm-project/issues/55065>`_.
|
2022-08-30 16:57:07 +02:00
|
|
|
|
- Skip rebuilding lambda expressions in arguments of immediate invocations.
|
2022-09-17 08:21:33 -04:00
|
|
|
|
This fixes `Issue 56183 <https://github.com/llvm/llvm-project/issues/56183>`_,
|
|
|
|
|
`Issue 51695 <https://github.com/llvm/llvm-project/issues/51695>`_,
|
|
|
|
|
`Issue 50455 <https://github.com/llvm/llvm-project/issues/50455>`_,
|
|
|
|
|
`Issue 54872 <https://github.com/llvm/llvm-project/issues/54872>`_,
|
|
|
|
|
`Issue 54587 <https://github.com/llvm/llvm-project/issues/54587>`_.
|
2022-08-19 13:57:45 -07:00
|
|
|
|
- Clang now correctly delays the instantiation of function constraints until
|
|
|
|
|
the time of checking, which should now allow the libstdc++ ranges implementation
|
|
|
|
|
to work for at least trivial examples. This fixes
|
|
|
|
|
`Issue 44178 <https://github.com/llvm/llvm-project/issues/44178>`_.
|
2022-09-14 10:42:34 -07:00
|
|
|
|
- Clang implements DR2621, correcting a defect in ``using enum`` handling. The
|
|
|
|
|
name is found via ordinary lookup so typedefs are found.
|
2022-09-06 20:33:54 -04:00
|
|
|
|
- Implemented `P0634r3 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0634r3.html>`_,
|
|
|
|
|
which removes the requirement for the ``typename`` keyword in certain contexts.
|
2022-09-23 15:02:28 +02:00
|
|
|
|
- Implemented The Equality Operator You Are Looking For (`P2468 <http://wg21.link/p2468r2>`_).
|
[C++20] Implement P2113R0: Changes to the Partial Ordering of Constrained Functions
This implementation matches GCC behavior in that [[ https://eel.is/c++draft/temp.func.order#6.2.1 | temp.func.order p6.2.1 ]] is not implemented [1]. I reached out to the GCC author to confirm that some changes elsewhere to overload resolution are probably needed, but no solution has been developed sufficiently [3].
Most of the wordings are implemented straightforwardly. However,
for [[ https://eel.is/c++draft/temp.func.order#6.2.2 | temp.func.order p6.2.2 ]] "... or if the function parameters that positionally correspond between the two templates are not of the same type", the "same type" is not very clear ([2] is a bug related to this). Here is a quick example
```
template <C T, C U> int f(T, U);
template <typename T, C U> int f(U, T);
int x = f(0, 0);
```
Is the `U` and `T` from different `f`s the "same type"? The answer is NO even though both `U` and `T` are deduced to be `int` in this case. The reason is that `U` and `T` are dependent types, according to [[ https://eel.is/c++draft/temp.over.link#3 | temp.over.link p3 ]], they can not be the "same type".
To check if two function parameters are the "same type":
* For //function template//: compare the function parameter canonical types and return type between two function templates.
* For //class template/partial specialization//: by [[ https://eel.is/c++draft/temp.spec.partial.order#1.2 | temp.spec.partial.order p1.2 ]], compare the injected template arguments between two templates using hashing(TemplateArgument::Profile) is enough.
[1] https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=57b4daf8dc4ed7b669cc70638866ddb00f5b7746
[2] https://github.com/llvm/llvm-project/issues/49308
[3] https://lists.isocpp.org/core/2020/06/index.php#msg9392
Fixes https://github.com/llvm/llvm-project/issues/54039
Fixes https://github.com/llvm/llvm-project/issues/49308 (PR49964)
Reviewed By: royjacobson, #clang-language-wg, mizvekov
Differential Revision: https://reviews.llvm.org/D128750
2022-10-18 11:51:02 -07:00
|
|
|
|
- Implemented `P2113R0: Proposed resolution for 2019 comment CA 112 <https://wg21.link/P2113R0>`_
|
|
|
|
|
([temp.func.order]p6.2.1 is not implemented, matching GCC).
|
2022-10-27 06:27:02 -07:00
|
|
|
|
- Implemented `P0857R0 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0857r0.html>`_,
|
|
|
|
|
which specifies constrained lambdas and constrained template *template-parameter*\s.
|
2022-11-17 15:24:05 +00:00
|
|
|
|
- Required parameter pack to be provided at the end of the concept parameter list. This
|
|
|
|
|
fixes `Issue 48182 <https://github.com/llvm/llvm-project/issues/48182>`_.
|
[C++20] Implement P2113R0: Changes to the Partial Ordering of Constrained Functions
This implementation matches GCC behavior in that [[ https://eel.is/c++draft/temp.func.order#6.2.1 | temp.func.order p6.2.1 ]] is not implemented [1]. I reached out to the GCC author to confirm that some changes elsewhere to overload resolution are probably needed, but no solution has been developed sufficiently [3].
Most of the wordings are implemented straightforwardly. However,
for [[ https://eel.is/c++draft/temp.func.order#6.2.2 | temp.func.order p6.2.2 ]] "... or if the function parameters that positionally correspond between the two templates are not of the same type", the "same type" is not very clear ([2] is a bug related to this). Here is a quick example
```
template <C T, C U> int f(T, U);
template <typename T, C U> int f(U, T);
int x = f(0, 0);
```
Is the `U` and `T` from different `f`s the "same type"? The answer is NO even though both `U` and `T` are deduced to be `int` in this case. The reason is that `U` and `T` are dependent types, according to [[ https://eel.is/c++draft/temp.over.link#3 | temp.over.link p3 ]], they can not be the "same type".
To check if two function parameters are the "same type":
* For //function template//: compare the function parameter canonical types and return type between two function templates.
* For //class template/partial specialization//: by [[ https://eel.is/c++draft/temp.spec.partial.order#1.2 | temp.spec.partial.order p1.2 ]], compare the injected template arguments between two templates using hashing(TemplateArgument::Profile) is enough.
[1] https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=57b4daf8dc4ed7b669cc70638866ddb00f5b7746
[2] https://github.com/llvm/llvm-project/issues/49308
[3] https://lists.isocpp.org/core/2020/06/index.php#msg9392
Fixes https://github.com/llvm/llvm-project/issues/54039
Fixes https://github.com/llvm/llvm-project/issues/49308 (PR49964)
Reviewed By: royjacobson, #clang-language-wg, mizvekov
Differential Revision: https://reviews.llvm.org/D128750
2022-10-18 11:51:02 -07:00
|
|
|
|
|
2022-10-27 11:50:43 +02:00
|
|
|
|
- Do not hide templated base members introduced via using-decl in derived class
|
|
|
|
|
(useful specially for constrained members). Fixes `GH50886 <https://github.com/llvm/llvm-project/issues/50886>`_.
|
2022-11-28 12:09:58 -08:00
|
|
|
|
- Implemented CWG2635 as a Defect Report, which prohibits structured bindings from being constrained.
|
2022-10-27 11:50:43 +02:00
|
|
|
|
|
2021-04-14 04:18:23 -07:00
|
|
|
|
C++2b Feature Support
|
2020-02-13 22:46:33 +01:00
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2022-09-14 18:08:34 +00:00
|
|
|
|
- Support label at end of compound statement (`P2324 <https://wg21.link/p2324r2>`_).
|
2022-11-21 00:30:59 +02:00
|
|
|
|
- Implemented `P1169R4: static operator() <https://wg21.link/P1169R4>`_ and `P2589R1: static operator[] <https://wg21.link/P2589R1>`_.
|
2022-10-21 14:33:26 +02:00
|
|
|
|
- Implemented "char8_t Compatibility and Portability Fix" (`P2513R3 <https://wg21.link/P2513R3>`_).
|
2022-11-28 21:05:07 +01:00
|
|
|
|
This change was applied to C++20 as a Defect Report.
|
|
|
|
|
- Implemented "Permitting static constexpr variables in constexpr functions" (`P2647R1 <https://wg21.link/P2647R1>_`).
|
2022-09-14 18:08:34 +00:00
|
|
|
|
|
2022-05-03 14:13:56 -04:00
|
|
|
|
CUDA/HIP Language Changes in Clang
|
|
|
|
|
----------------------------------
|
|
|
|
|
|
2022-11-04 07:25:22 +00:00
|
|
|
|
- Allow the use of ``__noinline__`` as a keyword (instead of ``__attribute__((noinline))``)
|
|
|
|
|
in lambda declarations.
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Objective-C Language Changes in Clang
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
OpenCL C Language Changes in Clang
|
|
|
|
|
----------------------------------
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
ABI Changes in Clang
|
|
|
|
|
--------------------
|
|
|
|
|
|
2022-10-13 21:11:41 +00:00
|
|
|
|
- GCC doesn't pack non-POD members in packed structs unless the packed
|
|
|
|
|
attribute is also specified on the member. Clang historically did perform
|
|
|
|
|
such packing. Clang now matches the gcc behavior (except on Darwin and PS4).
|
|
|
|
|
You can switch back to the old ABI behavior with the flag:
|
|
|
|
|
``-fclang-abi-compat=15.0``.
|
2022-10-27 20:41:22 +00:00
|
|
|
|
- GCC allows POD types to have defaulted special members. Clang historically
|
2022-10-28 22:29:50 +00:00
|
|
|
|
classified such types as non-POD (for the purposes of Itanium ABI). Clang now
|
|
|
|
|
matches the gcc behavior (except on Darwin and PS4). You can switch back to
|
|
|
|
|
the old ABI behavior with the flag: ``-fclang-abi-compat=15.0``.
|
2022-10-13 21:11:41 +00:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
OpenMP Support in Clang
|
|
|
|
|
-----------------------
|
|
|
|
|
|
2022-04-19 08:45:51 -04:00
|
|
|
|
...
|
2022-02-02 13:06:55 -05:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
CUDA Support in Clang
|
|
|
|
|
---------------------
|
|
|
|
|
|
2022-08-09 17:28:30 -07:00
|
|
|
|
- Clang now supports CUDA SDK up to 11.8
|
|
|
|
|
- Added support for targeting sm_{87,89,90} GPUs.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
2022-08-18 14:39:37 -07:00
|
|
|
|
RISC-V Support in Clang
|
|
|
|
|
-----------------------
|
2022-09-17 08:21:33 -04:00
|
|
|
|
- ``sifive-7-rv32`` and ``sifive-7-rv64`` are no longer supported for ``-mcpu``.
|
|
|
|
|
Use ``sifive-e76``, ``sifive-s76``, or ``sifive-u74`` instead.
|
2022-11-07 10:40:19 +08:00
|
|
|
|
- Native detections via ``-mcpu=native`` and ``-mtune=native`` are supported.
|
2022-08-18 14:39:37 -07:00
|
|
|
|
|
2020-08-20 21:37:51 +01:00
|
|
|
|
X86 Support in Clang
|
|
|
|
|
--------------------
|
2022-07-29 17:47:49 +08:00
|
|
|
|
- Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk.
|
2022-09-20 08:44:11 +08:00
|
|
|
|
- Fix 32-bit ``__fastcall`` and ``__vectorcall`` ABI mismatch with MSVC.
|
2022-10-22 06:24:47 +08:00
|
|
|
|
- Add ISA of ``AMX-FP16`` which support ``_tile_dpfp16ps``.
|
2022-10-19 16:26:54 +08:00
|
|
|
|
- Switch ``AVX512-BF16`` intrinsics types from ``short`` to ``__bf16``.
|
2022-10-20 08:44:52 +08:00
|
|
|
|
- Add support for ``PREFETCHI`` instructions.
|
2022-10-25 13:49:14 +08:00
|
|
|
|
- Support ISA of ``CMPCCXADD``.
|
|
|
|
|
* Support intrinsic of ``__cmpccxadd_epi32``.
|
|
|
|
|
* Support intrinsic of ``__cmpccxadd_epi64``.
|
2022-10-27 17:08:49 +08:00
|
|
|
|
- Add support for ``RAO-INT`` instructions.
|
|
|
|
|
* Support intrinsic of ``_aadd_i32/64``
|
|
|
|
|
* Support intrinsic of ``_aand_i32/64``
|
|
|
|
|
* Support intrinsic of ``_aor_i32/64``
|
|
|
|
|
* Support intrinsic of ``_axor_i32/64``
|
2022-10-28 09:11:29 +08:00
|
|
|
|
- Support ISA of ``AVX-IFMA``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_madd52hi_avx_epu64``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_madd52lo_avx_epu64``.
|
2022-10-28 09:43:38 +08:00
|
|
|
|
- Support ISA of ``AVX-VNNI-INT8``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_dpbssd(s)_epi32``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_dpbsud(s)_epi32``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_dpbuud(s)_epi32``.
|
2022-10-31 23:01:31 +08:00
|
|
|
|
- Support ISA of ``AVX-NE-CONVERT``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_bcstnebf16_ps``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_bcstnesh_ps``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_cvtneebf16_ps``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_cvtneeph_ps``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_cvtneobf16_ps``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_cvtneoph_ps``.
|
|
|
|
|
* Support intrinsic of ``_mm(256)_cvtneps_avx_pbh``.
|
2022-11-04 09:04:57 +08:00
|
|
|
|
- ``-march=raptorlake`` and ``-march=meteorlake`` are now supported.
|
2022-11-09 09:19:24 -05:00
|
|
|
|
- ``-march=sierraforest``, ``-march=graniterapids`` and ``-march=grandridge`` are now supported.
|
2022-07-29 17:47:49 +08:00
|
|
|
|
|
2022-10-18 10:50:37 -07:00
|
|
|
|
WebAssembly Support in Clang
|
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
|
|
The -mcpu=generic configuration now enables sign-ext and mutable-globals. These
|
|
|
|
|
proposals are standardized and available in all major engines.
|
|
|
|
|
|
2022-01-23 20:45:25 -08:00
|
|
|
|
DWARF Support in Clang
|
|
|
|
|
----------------------
|
|
|
|
|
|
2022-10-10 14:35:15 +00:00
|
|
|
|
Previously when emitting DWARFv4 and tuning for GDB, Clang would use DWARF v2's
|
|
|
|
|
``DW_AT_bit_offset`` and ``DW_AT_data_member_location``. Clang now uses DWARF v4's
|
|
|
|
|
``DW_AT_data_bit_offset`` regardless of tuning.
|
|
|
|
|
|
|
|
|
|
Support for ``DW_AT_data_bit_offset`` was added in GDB 8.0. For earlier versions,
|
|
|
|
|
you can use the ``-gdwarf-3`` option to emit compatible DWARF.
|
|
|
|
|
|
2021-10-15 14:29:57 +01:00
|
|
|
|
Arm and AArch64 Support in Clang
|
|
|
|
|
--------------------------------
|
[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
|
|
|
|
|
|
|
|
|
- The target(..) function attributes for AArch64 now accept:
|
|
|
|
|
|
|
|
|
|
* ``"arch=<arch>"`` strings, that specify the architecture for a function as per the ``-march`` option.
|
|
|
|
|
* ``"cpu=<cpu>"`` strings, that specify the cpu for a function as per the ``-mcpu`` option.
|
|
|
|
|
* ``"tune=<cpu>"`` strings, that specify the tune 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.
|
2022-09-17 08:21:33 -04:00
|
|
|
|
- ``-march`` values for targeting armv2, armv2A, armv3 and armv3M have been removed.
|
2022-09-01 13:30:39 +00:00
|
|
|
|
Their presence gave the impression that Clang can correctly generate code for
|
|
|
|
|
them, which it cannot.
|
2022-10-28 16:06:00 +01:00
|
|
|
|
- Support has been added for the following processors (-mcpu identifiers in parenthesis):
|
|
|
|
|
|
|
|
|
|
* Arm Cortex-A715 (cortex-a715).
|
2022-10-19 14:03:57 +01:00
|
|
|
|
* Arm Cortex-X3 (cortex-x3).
|
|
|
|
|
* Arm Neoverse V2 (neoverse-v2)
|
2022-10-26 14:00:45 +01:00
|
|
|
|
- Strict floating point has been enabled for AArch64, which means that
|
|
|
|
|
``-ftrapping-math``, ``-frounding-math``, ``-ffp-model=strict``, and
|
|
|
|
|
``-ffp-exception-behaviour=<arg>`` are now accepted.
|
2022-09-01 13:30:39 +00:00
|
|
|
|
|
2021-11-09 09:35:25 -05:00
|
|
|
|
Floating Point Support in Clang
|
|
|
|
|
-------------------------------
|
2022-10-03 15:15:48 -04:00
|
|
|
|
- The driver option ``-menable-unsafe-fp-math`` has been removed. To enable
|
|
|
|
|
unsafe floating-point optimizations use ``-funsafe-math-optimizations`` or
|
|
|
|
|
``-ffast-math`` instead.
|
2022-11-10 22:49:35 -08:00
|
|
|
|
- Add ``__builtin_elementwise_sin`` and ``__builtin_elementwise_cos`` builtins for floating point types only.
|
2021-11-09 09:35:25 -05:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Internal API Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
Build System Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
AST Matchers
|
|
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
clang-format
|
|
|
|
|
------------
|
2022-09-29 10:24:55 +03:00
|
|
|
|
- Add ``RemoveSemicolon`` option for removing ``;`` after a non-empty function definition.
|
|
|
|
|
- Add ``RequiresExpressionIndentation`` option for configuring the alignment of requires-expressions.
|
|
|
|
|
The default value of this option is ``OuterScope``, which differs in behavior from clang-format 15.
|
|
|
|
|
To match the default behavior of clang-format 15, use the ``Keyword`` value.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
2022-07-05 13:45:32 +02:00
|
|
|
|
clang-extdef-mapping
|
|
|
|
|
--------------------
|
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
libclang
|
|
|
|
|
--------
|
2022-09-17 08:21:33 -04:00
|
|
|
|
- Introduced the new function ``clang_getUnqualifiedType``, which mimics
|
|
|
|
|
the behavior of ``QualType::getUnqualifiedType`` for ``CXType``.
|
|
|
|
|
- Introduced the new function ``clang_getNonReferenceType``, which mimics
|
|
|
|
|
the behavior of ``QualType::getNonReferenceType`` for ``CXType``.
|
2022-09-21 11:12:48 -04:00
|
|
|
|
- Introduced the new function ``clang_CXXMethod_isDeleted``, which queries
|
|
|
|
|
whether the method is declared ``= delete``.
|
Add clang_CXXMethod_isCopyAssignmentOperator to libclang
The new method is a wrapper of `CXXMethodDecl::isCopyAssignmentOperator` and
can be used to recognized copy-assignment operators in libclang.
An export for the method, together with its documentation, was added to
"clang/include/clang-c/Index.h" with an implementation provided in
"clang/tools/libclang/CIndex.cpp". The implementation was based on
similar `clang_CXXMethod.*` implementations, following the same
structure but calling `CXXMethodDecl::isCopyAssignmentOperator` for its
main logic.
The new symbol was further added to "clang/tools/libclang/libclang.map"
to be exported, under the LLVM16 tag.
"clang/tools/c-index-test/c-index-test.c" was modified to print a
specific tag, "(copy-assignment operator)", for cursors that are
recognized by `clang_CXXMethod_isCopyAssignmentOperator`.
A new regression test file,
"clang/test/Index/copy-assignment-operator.cpp", was added to ensure
that the correct constructs were recognized or not by the new function.
The "clang/test/Index/get-cursor.cpp" regression test file was updated
as it was affected by the new "(copy-assignment operator)" tag.
A binding for the new function was added to libclang's python's
bindings, in "clang/bindings/python/clang/cindex.py", adding a new
method for `Cursor`, `is_copy_assignment_operator_method`.
The current release note, `clang/docs/ReleaseNotes.rst`, was modified to
report the new addition under the "libclang" section.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D136604
2022-10-27 06:42:35 +02:00
|
|
|
|
- Introduced the new function ``clang_CXXMethod_isCopyAssignmentOperator``,
|
|
|
|
|
which identifies whether a method cursor is a copy-assignment
|
|
|
|
|
operator.
|
Add clang_CXXMethod_isMoveAssignmentOperator to libclang
The new method is a wrapper of `CXXMethodDecl::isMoveAssignmentOperator` and
can be used to recognized move-assignment operators in libclang.
An export for the function, together with its documentation, was added to
"clang/include/clang-c/Index.h" with an implementation provided in
"clang/tools/libclang/CIndex.cpp". The implementation was based on
similar `clang_CXXMethod.*` implementations, following the same
structure but calling `CXXMethodDecl::isMoveAssignmentOperator` for its
main logic.
The new symbol was further added to "clang/tools/libclang/libclang.map"
to be exported, under the LLVM16 tag.
"clang/tools/c-index-test/c-index-test.c" was modified to print a
specific tag, "(move-assignment operator)", for cursors that are
recognized by `clang_CXXMethod_isMoveAssignmentOperator`.
A new regression test file,
"clang/test/Index/move-assignment-operator.cpp", was added to ensure
whether the correct constructs were recognized or not by the new function.
The "clang/test/Index/get-cursor.cpp" regression test file was updated
as it was affected by the new "(move-assignment operator)" tag.
A binding for the new function was added to libclang's python's
bindings, in "clang/bindings/python/clang/cindex.py", adding a new
method for `Cursor`, `is_move_assignment_operator_method`.
An accompanying test was added to
`clang/bindings/python/tests/cindex/test_cursor.py`, testing the new
function with the same methodology as the corresponding libclang test.
The current release note, `clang/docs/ReleaseNotes.rst`, was modified to
report the new addition under the "libclang" section.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D137246
2022-11-14 15:17:22 +01:00
|
|
|
|
- Introduced the new function ``clang_CXXMethod_isMoveAssignmentOperator``,
|
|
|
|
|
which identifies whether a method cursor is a move-assignment
|
|
|
|
|
operator.
|
Add clang_CXXMethod_isCopyAssignmentOperator to libclang
The new method is a wrapper of `CXXMethodDecl::isCopyAssignmentOperator` and
can be used to recognized copy-assignment operators in libclang.
An export for the method, together with its documentation, was added to
"clang/include/clang-c/Index.h" with an implementation provided in
"clang/tools/libclang/CIndex.cpp". The implementation was based on
similar `clang_CXXMethod.*` implementations, following the same
structure but calling `CXXMethodDecl::isCopyAssignmentOperator` for its
main logic.
The new symbol was further added to "clang/tools/libclang/libclang.map"
to be exported, under the LLVM16 tag.
"clang/tools/c-index-test/c-index-test.c" was modified to print a
specific tag, "(copy-assignment operator)", for cursors that are
recognized by `clang_CXXMethod_isCopyAssignmentOperator`.
A new regression test file,
"clang/test/Index/copy-assignment-operator.cpp", was added to ensure
that the correct constructs were recognized or not by the new function.
The "clang/test/Index/get-cursor.cpp" regression test file was updated
as it was affected by the new "(copy-assignment operator)" tag.
A binding for the new function was added to libclang's python's
bindings, in "clang/bindings/python/clang/cindex.py", adding a new
method for `Cursor`, `is_copy_assignment_operator_method`.
The current release note, `clang/docs/ReleaseNotes.rst`, was modified to
report the new addition under the "libclang" section.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D136604
2022-10-27 06:42:35 +02:00
|
|
|
|
- ``clang_Cursor_getNumTemplateArguments``, ``clang_Cursor_getTemplateArgumentKind``,
|
|
|
|
|
``clang_Cursor_getTemplateArgumentType``, ``clang_Cursor_getTemplateArgumentValue`` and
|
2022-09-23 11:05:31 -04:00
|
|
|
|
``clang_Cursor_getTemplateArgumentUnsignedValue`` now work on struct, class,
|
|
|
|
|
and partial template specialization cursors in addition to function cursors.
|
2022-08-25 08:35:46 +02:00
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
|
Static Analyzer
|
|
|
|
|
---------------
|
2022-08-23 18:39:21 +02:00
|
|
|
|
- Removed the deprecated ``-analyzer-store`` and
|
|
|
|
|
``-analyzer-opt-analyze-nested-blocks`` analyzer flags.
|
|
|
|
|
``scanbuild`` was also updated accordingly.
|
|
|
|
|
Passing these flags will result in a hard error.
|
|
|
|
|
|
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead
By default, clang assumes that all trailing array objects could be a
FAM. So, an array of undefined size, size 0, size 1, or even size 42 is
considered as FAMs for optimizations at least.
One needs to override the default behavior by supplying the
`-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of
FAM candidates. Value `3` is the most restrictive and `0` is the most
permissive on this scale.
0: all trailing arrays are FAMs
1: only incomplete, zero and one-element arrays are FAMs
2: only incomplete, zero-element arrays are FAMs
3: only incomplete arrays are FAMs
If the user is happy with consdering single-element arrays as FAMs, they
just need to remove the
`consider-single-element-arrays-as-flexible-array-members` from the
command line.
Otherwise, if they don't want to recognize such cases as FAMs, they
should specify `-fstrict-flex-arrays` anyway, which will be picked up by
CSA.
Any use of the deprecated analyzer-config value will trigger a warning
explaining what to use instead.
The `-analyzer-config-help` is updated accordingly.
Depends on D138657
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
|
|
|
|
- Deprecate the ``consider-single-element-arrays-as-flexible-array-members``
|
|
|
|
|
analyzer-config option.
|
|
|
|
|
This option will be still accepted, but a warning will be displayed.
|
|
|
|
|
This option will be rejected, thus turned into a hard error starting with
|
|
|
|
|
``clang-17``. Use ``-fstrict-flex-array=<N>`` instead if necessary.
|
|
|
|
|
|
[analyzer] Consider single-elem arrays as FAMs by default
According to my measurement in https://reviews.llvm.org/D108230#3933232,
it seems like there is no drawback to enabling this analyzer-config by default.
Actually, enabling this by default would make it consistent with the
codegen of clang, which according to `-fstrict-flex-arrays`, assumes
by default that all trailing arrays could be FAMs, let them be of size
undefined, zero, one, or anything else.
Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate
the analyzer-config FAM option in favor of that flag. That way, CSA will
always be in sync with what the codegen will think of FAMs.
So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0,
CSA will also make sure that only arrays of the right size will be
considered as FAMs.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
|
|
|
|
- Trailing array objects of structs with single elements will be considered
|
|
|
|
|
as flexible-array-members. Use ``-fstrict-flex-array=<N>`` to define
|
|
|
|
|
what should be considered as flexible-array-member if needed.
|
|
|
|
|
|
2022-09-26 17:41:37 -07:00
|
|
|
|
.. _release-notes-sanitizers:
|
|
|
|
|
|
|
|
|
|
Sanitizers
|
|
|
|
|
----------
|
|
|
|
|
- ``-fsanitize-memory-param-retval`` is turned on by default. With
|
|
|
|
|
``-fsanitize=memory``, passing uninitialized variables to functions and
|
|
|
|
|
returning uninitialized variables from functions is more aggressively
|
|
|
|
|
reported. ``-fno-sanitize-memory-param-retval`` restores the previous
|
|
|
|
|
behavior.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
|
|
Core Analysis Improvements
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
- ...
|
|
|
|
|
|
|
|
|
|
New Issues Found
|
|
|
|
|
================
|
|
|
|
|
|
|
|
|
|
- ...
|
|
|
|
|
|
|
|
|
|
Python Binding Changes
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
The following methods have been added:
|
|
|
|
|
|
|
|
|
|
- ...
|
|
|
|
|
|
|
|
|
|
Significant Known Problems
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
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
|
2022-07-01 14:07:48 -07:00
|
|
|
|
contact us on the Discourse forums (Clang Frontend category)
|
|
|
|
|
<https://discourse.llvm.org/c/clang/6>`_.
|