mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 06:16:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/docs/ReleaseNotes.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

217 lines
5.5 KiB
ReStructuredText
Raw Normal View History

[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
===========================================
Clang |release| |ReleaseNotesTitle|
===========================================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
.. contents::
:local:
:depth: 2
Written by the `LLVM Team <https://llvm.org/>`_
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
.. only:: PreRelease
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
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
Fix broken link on Clang documentation page While browsing the latest [clang manual](https://clang.llvm.org/docs/ReleaseNotes.html), I came across this warning and clicked, but it leads to a broken page, apparently because it's missing the trailing `/`. Seems to be the only place where it's missing in the whole of LLVM monorepo. {F26690053} {F26690057} Reviewed By: brenoguim, royjacobson Differential Revision: https://reviews.llvm.org/D145047
2023-03-05 00:56:15 +02:00
`the Releases Page <https://llvm.org/releases/>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Introduction
============
This document contains the release notes for the Clang C/C++/Objective-C
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
frontend, part of the LLVM Compiler Infrastructure, release |release|. Here we
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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/>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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>`_.
Add a "Potentially Breaking Changes" section to the Clang release notes Sometimes we make changes to the compiler that we expect may cause disruption for users. For example, we may strengthen a warning to default to be an error, or fix an accepts-invalid bug that's been around for a long time, etc which may cause previously accepted code to now be rejected. Rather than hope users discover that information by reading all of the release notes, it's better that we call these out in one location at the top of the release notes. Based on feedback collected in the discussion at: https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/ Differential Revision: https://reviews.llvm.org/D133771
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][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C/C++ Language Potentially Breaking Changes
-------------------------------------------
Reland: [clang][ExprConstant] fix __builtin_object_size for flexible array members As reported by @kees, GCC treats __builtin_object_size of structures containing flexible array members (aka arrays with incomplete type) not just as the sizeof the underlying type, but additionally the size of the members in a designated initializer list. Fixes: https://github.com/llvm/llvm-project/issues/62789 Reviewed By: erichkeane, efriedma Differential Revision: https://reviews.llvm.org/D150892
2023-05-23 14:41:43 -07:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++ Specific Potentially Breaking Changes
-----------------------------------------
ABI Changes in This Version
---------------------------
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
What's New in Clang |release|?
==============================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++ Language Changes
--------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Clang] Fix Unevaluated Lambdas Unlike other types, when lambdas are instanciated, they are recreated from scratch. When an unevaluated lambdas appear in the type of a function, parameter it is instanciated in the wrong declaration context, as parameters are transformed before the function. To support lambda in function parameters, we try to compute whether they are dependant without looking at the declaration context. This is a short term stopgap solution to avoid clang iceing. A better fix might be to inject some kind of transparent declaration with correctly computed dependency for function parameters, variable templates, etc. Fixes https://github.com/llvm/llvm-project/issues/50376 Fixes https://github.com/llvm/llvm-project/issues/51414 Fixes https://github.com/llvm/llvm-project/issues/51416 Fixes https://github.com/llvm/llvm-project/issues/51641 Fixes https://github.com/llvm/llvm-project/issues/54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532
2022-03-12 20:49:01 +01:00
[clang] Use -std=c++23 instead of -std=c++2b During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D149553
2023-04-30 15:27:00 +02:00
C++23 Feature Support
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
^^^^^^^^^^^^^^^^^^^^^
Add C++26 compile flags. Now that we've updated to C++23, we need to add C++26/C++2c command line flags, as discussed in https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383 Differential Revision: https://reviews.llvm.org/D150450
2023-05-12 07:30:21 -07:00
C++2c Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Resolutions to C++ Defect Reports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C Language Changes
------------------
C2x Feature Support
^^^^^^^^^^^^^^^^^^^
[C2x] Update 'nullptr' implementation based on CD comments We filed some CD ballot comments which WG14 considered during the ballot comment resolution meetings in Jan and Feb 2023, and this updates our implementation based on the decisions reached. Those decisions were (paraphrased for brevity): US 9-034 (REJECTED) allow (void *)nullptr to be a null pointer constant US 10-035 (ACCEPTED) accept the following code, as in C++: void func(nullptr_t); func(0); US 22-058 (REJECTED) accept the following code, as in C++: nullptr_t val; (void)(1 ? val : 0); (void)(1 ? nullptr : 0); US 23-062 (REJECTED) reject the following code, as in C++: nullptr_t val; bool b1 = val; bool b2 = nullptr; US 24-061 (ACCEPTED) accept the following code, as in C++: nullptr_t val; val = 0; US 21-068 (ACCEPTED) accept the following code, as in C++: (nullptr_t)nullptr; GB-071 (ACCEPTED) accept the following code, as in C++: nullptr_t val; (void)(val == nullptr); This patch updates the implementation as appropriate, but is primarily focused around US 10-035, US 24-061, and US 23-062 in terms of functional changes. Differential Revision: https://reviews.llvm.org/D148800
2023-05-03 14:06:04 -04:00
Fix the Sphinx build bot This addresses an accidental break from 41667a8b9b624e282e7c08fadf7091223728d1c1
2022-08-26 10:04:06 -04:00
Non-comprehensive list of changes in this release
-------------------------------------------------
Diagnosing the Future Keywords The patch diagnoses an identifier as a future keyword if it exists in a future language mode, such as: int restrict; in C modes earlier than C99. We now give a warning to the user that such an identifier is a future keyword. Handles keywords from C as well as C++. Differential Revision: https://reviews.llvm.org/D131683
2022-08-26 09:17:14 -04:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
New Compiler Flags
------------------
[Driver] Add -dumpdir and change -gsplit-dwarf .dwo names for linking When the final phase is linking, Clang currently places `.dwo` files in the current directory (like the `-c` behavior for multiple inputs). Strangely, -fdebug-compilation-dir=/-ffile-compilation-dir= is considered, which is untested. GCC has a more useful behavior that derives auxiliary filenames from the final output (-o). ``` gcc -c -g -gsplit-dwarf d/a.c d/b.c # a.dwo b.dwo gcc -g -gsplit-dwarf d/a.c d/b.c -o e/x # e/x-a.dwo e/x-b.dwo gcc -g -gsplit-dwarf d/a.c d/b.c # a-a.dwo a-b.dwo ``` Port a useful subset of GCC behaviors that are easy to describe to Clang. * Add a driver and cc1 option -dumpdir * When the final phase is link, add a default -dumpdir if not specified by the user * Forward -dumpdir to -cc1 command lines * tools::SplitDebugName prefers -dumpdir when constructing the .dwo filename GCC provides -dumpbase. If we use just one of -dumpdir and -dumpbase, -dumpbase isn't very useful as it appends a dash. ``` gcc -g -gsplit-dwarf -dumpdir e d/a.c # ea.dwo gcc -g -gsplit-dwarf -dumpdir e/ d/a.c # e/a.dwo gcc -g -gsplit-dwarf -dumpbase e d/a.c # e-a.dwo gcc -g -gsplit-dwarf -dumpbase e/ d/a.c # e/-a.dwo ``` If we specify both `-dumpdir` and `-dumpbase`, we can avoid the influence of the source filename when there is one input file. ``` gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c # f/x.dwo gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c d/b.c # f/x-a.dwo f/x-b.dwo ``` Given the above examples, I think -dumpbase is not useful. GCC -save-temps has interesting interaction with -dumpdir as -save-temps generated files are considered auxiliary files like .dwo files. For Clang, with this patch, -save-temps and -dumpdir are orthogonal, which is easier to explain. ``` gcc -g -gsplit-dwarf d/a.c -o e/x -dumpdir f/ -save-temps=obj # e/a.{i,s,o,dwo} gcc -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # f/a.{i,s,o,dwo} clang -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # e/a.{i,s,o} f/a.dwo ``` Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D149193
2023-05-09 14:43:46 -07:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Deprecated Compiler Flags
-------------------------
Modified Compiler Flags
-----------------------
[docs] Add release notes for news in 16.x done by me, or otherwise relating to MinGW targets Differential Revision: https://reviews.llvm.org/D142346
2023-01-23 13:25:55 +02:00
clang-cl: Remove /Zd flag cl.exe doesn't understand Zd (in either MSVC 2017 or 2019), so neiter should we. It used to do the same as `-gline-tables-only` which is exposed as clang-cl flag as well, so if you want this behavior, use `gline-tables-only`. That makes it clear that it's a clang-cl-only flag that won't work with cl.exe. Motivated by the discussion in D92958. Differential Revision: https://reviews.llvm.org/D93458
2020-12-17 09:23:02 -05:00
Removed Compiler Flags
-------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Attribute Changes in Clang
--------------------------
[AArch64] Function multi-versioning release notes added. NFC. Differential Revision: https://reviews.llvm.org/D142265
2023-01-20 23:31:53 +00:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Improvements to Clang's diagnostics
-----------------------------------
[-Wunsafe-buffer-usage] Introduce the unsafe_buffer_usage attribute Differential Revision: https://reviews.llvm.org/D138940
2023-01-31 11:43:34 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes in This Version
-------------------------
Commit to a primary definition for a class when we load its first member. Previously, we wouldn't do this if the first member loaded is within a definition that's added to a class via an update record, which happens when template instantiation adds a class definition to a declaration that was imported from an AST file. This would lead to classes having member functions whose getParent returned a class declaration that wasn't the primary definition, which in turn caused the vtable builder to build broken vtables. I don't yet have a reduced testcase for the wrong-code bug here, because the setup required to get us into the broken state is very subtle, but have confirmed that this fixes it.
2023-07-24 17:34:08 -07:00
- Fixed an issue where a class template specialization whose declaration is
instantiated in one module and whose definition is instantiated in another
module may end up with members associated with the wrong declaration of the
class, which can result in miscompiles in some cases.
[clang] Handle __declspec() attributes in using This patch fixes so that declspec attributes are forwarded to the alias declaration. Before this patch this would assert: class Test { int a; }; using AlignedTest = __declspec(align(16)) const Test; static_assert(alignof(AlignedTest) == 16, "error"); But afterwards it behaves the same as MSVC does and doesn't assert. Fixes: llvm/llvm-project#60513 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D143632
2023-02-09 10:53:39 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to Compiler Builtins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[clang][AIX] Don't ignore XCOFF visibility by default D87451 added -mignore-xcoff-visibility for AIX targets and made it the default (which mimicked the behaviour of the XL 16.1 compiler on AIX). However, ignoring hidden visibility has unwanted side effects and some libraries depend on visibility to hide non-ABI facing entities from user headers and reserve the right to change these implementation details based on this (https://libcxx.llvm.org/DesignDocs/VisibilityMacros.html). This forces us to use internal linkage fallbacks for these cases on AIX and creates an unwanted divergence in implementations on the plaform. For these reasons, it's preferable to not add -mignore-xcoff-visibility by default, which is what this patch does. Reviewed By: DiggerLin Differential Revision: https://reviews.llvm.org/D125141
2022-05-02 17:06:04 -04:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to Attribute Support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[clang][Sema] check default argument promotions for printf The main focus of this patch is to make ArgType::matchesType check for possible default parameter promotions when the argType is not a pointer. If so, no warning will be given for `int`, `unsigned int` types as corresponding arguments to %hhd and %hd. However, the usage of %hhd corresponding to short is relatively rare, and it is more likely to be a misuse. This patch keeps the original behavior of clang like this as much as possible, while making it more convenient to consider the default arguments promotion. Fixes https://github.com/llvm/llvm-project/issues/57102 Reviewed By: aaron.ballman, nickdesaulniers, #clang-language-wg Differential Revision: https://reviews.llvm.org/D132568
2022-08-26 19:26:32 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to C++ Support
^^^^^^^^^^^^^^^^^^^^^^^^
Diagnose extensions in 'offsetof' https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very clear that it is an UB having type definitions with in offsetof. Clang supports defining a type as the first argument as a conforming extension due to how many projects use the construct in C99 and earlier to calculate the alignment of a type. GCC also supports defining a type as the first argument. This adds extension warnings and documentation for the functionality Clang explicitly supports. Fixes #57065 Reverts the revert of 39da55e8f548a11f7dadefa73ea73d809a5f1729 Co-authored-by: Yingchi Long <i@lyc.dev> Co-authored-by: Aaron Ballman <aaron@aaronballman.com> Differential Revision: https://reviews.llvm.org/D133574
2023-01-18 08:49:45 -05:00
[Clang] Improve the handling of large arrays evaluation. This is a temporary fix (for clang 17) that caps the size of any array we try to constant evaluate: There are 2 limits: * We cap to UINT_MAX the size of ant constant evaluated array, because the constant evaluator does not support size_t. * We cap to `-fconstexpr-steps` elements the size of each individual array and dynamic array allocations. This works out because the number of constexpr steps already limits how many array elements can be initialized, which makes this new limit conservatively generous. This ensure that the compiler does not crash when attempting to constant-fold valid programs. If the limit is reached by a given array, constant evaluation will fail, and the program will be ill-formed, until a bigger limit is given. Or, constant folding will fail and the array will be evaluated at runtime. Fixes #63562 Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D155955
2023-07-03 13:01:17 +02:00
- Clang limits the size of arrays it will try to evaluate at compile time
to avoid memory exhaustion.
This limit can be modified by `-fconstexpr-steps`.
(`#63562 <https://github.com/llvm/llvm-project/issues/63562>`_)
Fix handling of medial hyphens in Unicode Names. In a Unicode name was stored in a way that caused a medial hyphen to be at the end of a a chunk, it would not be properly ignored by the loose matching algorithm. For example if `LEFT-TO-RIGHT OVERRIDE` was stored as `LEFT-` [...], the `-` would not be ignored. The generators now ensures nodes are not cut accross medial hyphen boundaries. Fixes #64161 Differential Revision: https://reviews.llvm.org/D156518
2023-07-28 10:07:47 +02:00
- Fix a crash caused by some named unicode escape sequences designating
a Unicode character whose name contains a ``-``.
(`Fixes #64161 <https://github.com/llvm/llvm-project/issues/64161>_`)
[Clang] Fix member lookup so that we don't ignore ambiguous lookups in some cases There are some cases during member lookup we are aggressively suppressing diagnostics when we should just be suppressing access control diagnostic. In this PR I add the ability to simply suppress access diagnostics while not suppressing ambiguous lookup diagnostics. Fixes: https://github.com/llvm/llvm-project/issues/22413 https://github.com/llvm/llvm-project/issues/29942 https://github.com/llvm/llvm-project/issues/35574 https://github.com/llvm/llvm-project/issues/27224 Differential Revision: https://reviews.llvm.org/D155387
2023-07-28 15:21:57 -07:00
- Fix cases where we ignore ambiguous name lookup when looking up memebers.
(`#22413 <https://github.com/llvm/llvm-project/issues/22413>_`),
(`#29942 <https://github.com/llvm/llvm-project/issues/29942>_`),
(`#35574 <https://github.com/llvm/llvm-project/issues/35574>_`) and
(`#27224 <https://github.com/llvm/llvm-project/issues/27224>_`).
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to AST Handling
^^^^^^^^^^^^^^^^^^^^^^^^^
Forbid implicit conversion of constraint expression to bool As reported in https://github.com/llvm/llvm-project/issues/54524, and later in https://github.com/llvm/llvm-project/issues/60038, we were not properly implmenting temp.constr.atomic P3. This patch stops implicitly converting constraints to bool, and ensures the Rvalue conversion takes place as needed. Differential Revision: https://reviews.llvm.org/D141954
2023-01-17 11:29:04 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Miscellaneous Bug Fixes
^^^^^^^^^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Miscellaneous Clang Crashes Fixed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[CUDA][HIP] support __noinline__ as keyword CUDA/HIP programs use __noinline__ like a keyword e.g. __noinline__ void foo() {} since __noinline__ is defined as a macro __attribute__((noinline)) in CUDA/HIP runtime header files. However, gcc and clang supports __attribute__((__noinline__)) the same as __attribute__((noinline)). Some C++ libraries use __attribute__((__noinline__)) in their header files. When CUDA/HIP programs include such header files, clang will emit error about invalid attributes. This patch fixes this issue by supporting __noinline__ as a keyword, so that CUDA/HIP runtime could remove the macro definition. Reviewed by: Aaron Ballman, Artem Belevich Differential Revision: https://reviews.llvm.org/D124866
2022-05-03 14:13:56 -04:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Target Specific Changes
-----------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang] Always use --no-undefined when linking AMDGPU images AMDGPU uses ELF shared libraries to implement their executable device images. One downside to this method is that it disables regular warnings on undefined symbols. This is because shared libraries expect these to be resolves by later loads. However, the GPU images do not support dynamic linking so any undefined symbol is going to cause a runtime error. This patch adds `--no-undefined` to the `ld.lld` invocation to guarantee that undefined symbols are always caught as linking errors rather than runtime errors. Reviewed By: arsenm, MaskRay, #amdgpu Differential Revision: https://reviews.llvm.org/D145941
2023-03-13 09:33:08 -05:00
AMDGPU Support
^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
X86 Support
^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Arm and AArch64 Support
^^^^^^^^^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Windows Support
^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
LoongArch Support
^^^^^^^^^^^^^^^^^
[docs] Add llvm & clang release notes for LoongArch Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D141750
2023-01-17 20:53:58 +08:00
Reland "[LoongArch] Support -march=native and -mtune=" As described in [1][2], `-mtune=` is used to select the type of target microarchitecture, defaults to the value of `-march`. The set of possible values should be a superset of `-march` values. Currently possible values of `-march=` and `-mtune=` are `native`, `loongarch64` and `la464`. D136146 has supported `-march={loongarch64,la464}` and this patch adds support for `-march=native` and `-mtune=`. A new ProcessorModel called `loongarch64` is defined in LoongArch.td to support `-mtune=loongarch64`. `llvm::sys::getHostCPUName()` returns `generic` on unknown or future LoongArch CPUs, e.g. the not yet added `la664`, leading to `llvm::LoongArch::isValidArchName()` failing to parse the arch name. In this case, use `loongarch64` as the default arch name for 64-bit CPUs. And these two preprocessor macros are defined: - __loongarch_arch - __loongarch_tune [1]: https://github.com/loongson/LoongArch-Documentation/blob/2023.04.20/docs/LoongArch-toolchain-conventions-EN.adoc [2]: https://github.com/loongson/la-softdev-convention/blob/v0.1/la-softdev-convention.adoc Reviewed By: xen0n, wangleiat Differential Revision: https://reviews.llvm.org/D155824
2023-07-26 09:56:49 +08:00
- The ``-march=native`` ``-mtune=`` options and ``__loongarch_{arch,tune}``
macros are now supported.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
RISC-V Support
^^^^^^^^^^^^^^
[RISCV] Change how mtune aliases are implemented. The previous implementation translated from names like sifive-7-series to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32 and sifive-7-rv64 to be valid CPU names. As those are not real CPUs it doesn't make sense to accept them in -mcpu. This patch does away with the translation and adds sifive-7-series directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64. sifive-7-series is only allowed in -mtune. I've also added "rocket" to RISCV.td but have not removed rocket-rv32 or rocket-rv64. To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc, I've added a Feature32Bit to all rv32 CPUs. And made it an error to have an rv32 triple without Feature32Bit. sifive-7-series and rocket do not have Feature32Bit or Feature64Bit set so the user would need to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to avoid the error. SiFive no longer names their newer products with 3, 5, or 7 series. Instead we have p200 series, x200 series, p500 series, and p600 series. Following the previous behavior would require a sifive-p500-rv32 and sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There is currently no p500 product, but it could start getting confusing if there was in the future. I'm open to hearing alternatives for how to achieve my main goal of removing sifive-7-rv32/rv64 as a CPU name. Reviewed By: reames Differential Revision: https://reviews.llvm.org/D131708
2022-08-18 14:39:37 -07:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
CUDA/HIP Language Changes
^^^^^^^^^^^^^^^^^^^^^^^^^
[WebAssembly] Update supported features in the generic CPU configuration Enable sign-ext and mutable-globals in -mcpu=generic. This makes these features enabled by default. These features are all [finished proposals], and all major wasm engines support them. [finished proposals]: https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md Differential Revision: https://reviews.llvm.org/D125728
2022-10-18 10:50:37 -07:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
CUDA Support
^^^^^^^^^^^^
Clang: Change the default DWARF version to 5 (except on platforms that already opt in to specific versions - SCE, Android, and Darwin using DWARFv4 explicitly, for instance)
2022-01-23 20:45:25 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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
[Clang] [AVR] Fix USHRT_MAX for 16-bit int. For AVR, the definition of USHRT_MAX overflows. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D144218
2022-02-06 08:20:54 -05:00
AVR Support
^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
DWARF Support in Clang
----------------------
[Clang][LLVM] Enable __arithmetic_fence and fprotect-parens on AArch64 Enable __arithmetic_fence and fprotect-parens on AArch64. Test plan: ninja check-clang check-clang-tools check-llvm Differential revision: https://reviews.llvm.org/D143781
2023-02-13 18:29:16 +00:00
Making the code compliant to the documentation about Floating Point support default values for C/C++. FPP-MODEL=PRECISE enables FFP-CONTRACT(FMA is enabled). Fix for https://bugs.llvm.org/show_bug.cgi?id=50222
2021-11-09 09:35:25 -05:00
Floating Point Support in Clang
-------------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
AST Matchers
------------
clang-format
------------
libclang
--------
SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e. rename CLANG_SONAME to LIBCLANG_SOVERSION [clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION Differential Revision: https://reviews.llvm.org/D132486
2022-08-25 08:35:46 +02:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Static Analyzer
---------------
[analyzer][docs] Add CSA release notes We'll soon branch off, and start releasing clang-17. Here is a patch, adjusting the release notes for what we achieved since the last release. I used this command to inspect the interesting commits: ``` git log --oneline llvmorg-16.0.0..llvm/main \ clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | \ grep -v NFC | grep -v -i revert ``` This filters in CSA directories and filters out NFC and revert commits. Given that in the release-notes, we usually don't put links to commits, I'll remove them from this patch as well. I just put them there to make it easier to review for you. I tried to group the changes into meaningful chunks, and dropped some of the uninteresting commits. I've also dropped the commits that were backported to clang-16. Check out how it looks, and propose changes like usual. --- FYI the `ninja docs-clang-html` produces the html docs, including the `ReleaseNotes`. And the produced artifact will be at `build/tools/clang/docs/html/ReleaseNotes.html`. Differential Revision: https://reviews.llvm.org/D155445
2023-07-24 08:26:54 +02:00
[clang][msan] Turn on -fsanitize-memory-param-retval by default This eagerly reports use of undef values when passed to noundef parameters or returned from noundef functions. This also decreases binary sizes under msan. To go back to the previous behavior, pass `-fno-sanitize-memory-param-retval`. Reviewed By: vitalybuka, MaskRay Differential Revision: https://reviews.llvm.org/D134669
2022-09-26 17:41:37 -07:00
.. _release-notes-sanitizers:
Sanitizers
----------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[python] Expose clang_Location_isInSystemHeader Add is_in_system_header property for Location class. Corresponding unit test was also added. Differential Revision: https://reviews.llvm.org/D147414
2023-04-04 09:21:04 -04:00
Python Binding Changes
----------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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
clang/release notes: s/Subversion/git/
2020-03-22 22:18:40 +01:00
API documentation which are up-to-date with the Git version of
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
contact us on the `Discourse forums (Clang Frontend category)
Update references to Discourse instead of the mailing lists. Update the references to the old Mailman mailing lists to point to Discourse forums. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D128766
2022-07-01 14:07:48 -07:00
<https://discourse.llvm.org/c/clang/6>`_.
Reference in New Issue Copy Permalink