2019-07-18 19:51:05 +08:00
|
|
|
========================================
|
|
|
|
|
Clang 10.0.0 (In-Progress) Release Notes
|
|
|
|
|
========================================
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
:local:
|
|
|
|
|
:depth: 2
|
|
|
|
|
|
2018-09-10 16:51:25 +08:00
|
|
|
Written by the `LLVM Team <https://llvm.org/>`_
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
These are in-progress notes for the upcoming Clang 10 release.
|
2017-02-10 07:26:34 +08:00
|
|
|
Release notes for previous releases can be found on
|
2018-09-10 16:51:25 +08:00
|
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
This document contains the release notes for the Clang C/C++/Objective-C
|
2019-07-18 19:51:05 +08:00
|
|
|
frontend, part of the LLVM Compiler Infrastructure, release 10.0.0. Here we
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08: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
|
2018-09-10 16:51:25 +08:00
|
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
releases may be downloaded from the `LLVM releases web
|
2018-09-10 16:51:25 +08:00
|
|
|
site <https://llvm.org/releases/>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
2017-08-31 02:35:44 +08:00
|
|
|
For more information about Clang or LLVM, including information about the
|
2018-09-10 16:51:25 +08:00
|
|
|
latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the
|
|
|
|
|
`LLVM Web Site <https://llvm.org>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
Note that if you are reading this file from a Subversion 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
|
2018-09-10 16:51:25 +08:00
|
|
|
see the `releases page <https://llvm.org/releases/>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
What's New in Clang 10.0.0?
|
|
|
|
|
===========================
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08: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
|
|
|
|
|
------------------
|
|
|
|
|
|
2019-01-16 18:57:02 +08:00
|
|
|
- ...
|
2013-12-13 00:07:11 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
Improvements to Clang's diagnostics
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2019-09-21 10:37:10 +08:00
|
|
|
- -Wtautological-overlap-compare will warn on negative numbers and non-int
|
|
|
|
|
types.
|
2019-09-21 11:02:26 +08:00
|
|
|
- -Wtautological-compare for self comparisons and
|
|
|
|
|
-Wtautological-overlap-compare will now look through member and array
|
|
|
|
|
access to determine if two operand expressions are the same.
|
[Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)
Summary:
This has just bit me, so i though it would be nice to avoid that next time :)
Motivational case:
https://godbolt.org/g/cq9UNk
Basically, it's likely to happen if you don't like shadowing issues,
and use `-Wshadow` and friends. And it won't be diagnosed by clang.
The reason is, these self-assign diagnostics only work for builtin assignment
operators. Which makes sense, one could have a very special operator=,
that does something unusual in case of self-assignment,
so it may make sense to not warn on that.
But while it may be intentional in some cases, it may be a bug in other cases,
so it would be really great to have some diagnostic about it...
Reviewers: aaron.ballman, rsmith, rtrieu, nikola, rjmccall, dblaikie
Reviewed By: rjmccall
Subscribers: EricWF, lebedev.ri, thakis, Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D44883
llvm-svn: 329493
2018-04-07 18:39:21 +08:00
|
|
|
|
2017-07-27 02:04:45 +08:00
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
|
-------------------------------------------------
|
|
|
|
|
|
[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour
Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4 When an expression J that has integral type is added to or subtracted
from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
elements ([dcl.array]), the expressions P + J and J + P
(where J has the value j) point to the (possibly-hypothetical) array
element i+j of x if 0≤i+j≤n and the expression P - J points to the
(possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```
Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)
To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".
Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566
Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.
`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown
Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers
Reviewed By: rsmith
Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67122
llvm-svn: 374293
2019-10-10 17:25:02 +08:00
|
|
|
* In both C and C++ (C17 ``6.5.6p8``, C++ ``[expr.add]``), pointer arithmetic is
|
|
|
|
|
only permitted within arrays. In particular, the behavior of a program is not
|
|
|
|
|
defined if it adds a non-zero offset (or in C, any offset) to a null pointer,
|
|
|
|
|
or if it forms a null pointer by subtracting an integer from a non-null
|
|
|
|
|
pointer, and the LLVM optimizer now uses those guarantees for transformations.
|
|
|
|
|
This may lead to unintended behavior in code that performs these operations.
|
|
|
|
|
The Undefined Behavior Sanitizer ``-fsanitize=pointer-overflow`` check has
|
|
|
|
|
been extended to detect these cases, so that code relying on them can be
|
|
|
|
|
detected and fixed.
|
|
|
|
|
|
2019-09-12 07:54:36 +08:00
|
|
|
- For X86 target, -march=skylake-avx512, -march=icelake-client,
|
|
|
|
|
-march=icelake-server, -march=cascadelake, -march=cooperlake will default to
|
|
|
|
|
not using 512-bit zmm registers in vectorized code unless 512-bit intrinsics
|
|
|
|
|
are used in the source code. 512-bit operations are known to cause the CPUs
|
|
|
|
|
to run at a lower frequency which can impact performance. This behavior can be
|
|
|
|
|
changed by passing -mprefer-vector-width=512 on the command line.
|
2018-12-06 02:32:05 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
New Compiler Flags
|
|
|
|
|
------------------
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
2017-10-22 00:45:08 +08:00
|
|
|
|
2017-07-02 05:36:21 +08:00
|
|
|
Deprecated Compiler Flags
|
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
The following options are deprecated and ignored. They will be removed in
|
|
|
|
|
future versions of Clang.
|
|
|
|
|
|
2019-08-30 02:09:02 +08:00
|
|
|
- -mmpx used to enable the __MPX__ preprocessor define for the Intel MPX
|
|
|
|
|
instructions. There were no MPX intrinsics.
|
|
|
|
|
- -mno-mpx used to disable -mmpx and is the default behavior.
|
|
|
|
|
|
2017-07-19 22:14:07 +08:00
|
|
|
- ...
|
2017-07-02 05:36:21 +08:00
|
|
|
|
2018-03-07 19:34:02 +08:00
|
|
|
Modified Compiler Flags
|
|
|
|
|
-----------------------
|
|
|
|
|
|
2019-05-15 03:40:42 +08:00
|
|
|
- ...
|
2018-03-07 19:34:02 +08:00
|
|
|
|
2014-06-18 08:51:32 +08:00
|
|
|
New Pragmas in Clang
|
2018-05-16 05:45:01 +08:00
|
|
|
--------------------
|
2014-06-18 08:51:32 +08:00
|
|
|
|
2019-01-16 18:57:02 +08:00
|
|
|
- ...
|
2016-07-19 01:19:12 +08:00
|
|
|
|
|
|
|
|
Attribute Changes in Clang
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2017-07-19 22:14:07 +08:00
|
|
|
- ...
|
2014-07-22 02:08:34 +08:00
|
|
|
|
2014-08-05 08:21:23 +08:00
|
|
|
Windows Support
|
|
|
|
|
---------------
|
|
|
|
|
|
2019-09-25 19:53:17 +08:00
|
|
|
- Previous Clang versions contained a work-around to avoid an issue with the
|
|
|
|
|
standard library headers in Visual Studio 2019 versions prior to 16.3. This
|
|
|
|
|
work-around has now been removed, and users of Visual Studio 2019 are
|
|
|
|
|
encouraged to upgrade to 16.3 or later, otherwise they may see link errors as
|
|
|
|
|
below:
|
|
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
|
|
error LNK2005: "bool const std::_Is_integral<int>" (??$_Is_integral@H@std@@3_NB) already defined
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-05 08:21:23 +08:00
|
|
|
|
2013-12-13 17:27:34 +08:00
|
|
|
C Language Changes in Clang
|
|
|
|
|
---------------------------
|
|
|
|
|
|
2019-06-05 11:47:02 +08:00
|
|
|
- ...
|
2013-12-13 17:27:34 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
C11 Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
C++ Language Changes in Clang
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2019-09-27 20:25:19 +08:00
|
|
|
- The behaviour of the `gnu_inline` attribute now matches GCC, for cases
|
|
|
|
|
where used without the `extern` keyword. As this is a change compared to
|
|
|
|
|
how it behaved in previous Clang versions, a warning is emitted for this
|
|
|
|
|
combination.
|
2016-05-06 02:40:37 +08:00
|
|
|
|
|
|
|
|
C++1z Feature Support
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
Objective-C Language Changes in Clang
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
2013-11-11 14:36:33 +08:00
|
|
|
OpenCL C Language Changes in Clang
|
|
|
|
|
----------------------------------
|
|
|
|
|
|
2013-11-20 18:13:37 +08:00
|
|
|
...
|
2013-11-11 14:36:33 +08:00
|
|
|
|
2018-10-27 03:26:45 +08:00
|
|
|
ABI Changes in Clang
|
|
|
|
|
--------------------
|
|
|
|
|
|
2019-09-06 14:02:13 +08:00
|
|
|
- gcc passes vectors of __int128 in memory on X86-64. Clang historically
|
|
|
|
|
broke the vectors into multiple scalars using two 64-bit values for each
|
|
|
|
|
element. Clang now matches the gcc behavior on Linux and NetBSD. You can
|
|
|
|
|
switch back to old API behavior with flag: -fclang-abi-compat=9.0.
|
2018-10-27 03:26:45 +08:00
|
|
|
|
2016-05-31 19:17:08 +08:00
|
|
|
OpenMP Support in Clang
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
-----------------------
|
2016-05-31 19:17:08 +08:00
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2016-05-31 19:17:08 +08:00
|
|
|
|
2018-04-20 21:04:54 +08:00
|
|
|
CUDA Support in Clang
|
|
|
|
|
---------------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2018-04-20 21:04:54 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
Internal API Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
These are major API changes that have happened since the 9.0.0 release of
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
Clang. If upgrading an external codebase that uses Clang as a library,
|
|
|
|
|
this section should help get you past the largest hurdles of upgrading.
|
|
|
|
|
|
2019-08-30 17:29:34 +08:00
|
|
|
- libTooling APIs that transfer ownership of `FrontendAction` objects now pass
|
|
|
|
|
them by `unique_ptr`, making the ownership transfer obvious in the type
|
|
|
|
|
system. `FrontendActionFactory::create()` now returns a
|
|
|
|
|
`unique_ptr<FrontendAction>`. `runToolOnCode`, `runToolOnCodeWithArgs`,
|
|
|
|
|
`ToolInvocation::ToolInvocation()` now take a `unique_ptr<FrontendAction>`.
|
|
|
|
|
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
Build System Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
These are major changes to the build system that have happened since the 9.0.0
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
release of Clang. Users of the build system should adjust accordingly.
|
|
|
|
|
|
|
|
|
|
- In 8.0.0 and below, the install-clang-headers target would install clang's
|
|
|
|
|
resource directory headers. This installation is now performed by the
|
|
|
|
|
install-clang-resource-headers target. Users of the old install-clang-headers
|
2019-03-12 02:53:57 +08:00
|
|
|
target should switch to the new install-clang-resource-headers target. The
|
|
|
|
|
install-clang-headers target now installs clang's API headers (corresponding
|
|
|
|
|
to its libraries), which is consistent with the install-llvm-headers target.
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
|
2019-08-15 00:49:52 +08:00
|
|
|
- In 9.0.0 and later Clang added a new target, clang-cpp, which generates a
|
|
|
|
|
shared library comprised of all the clang component libraries and exporting
|
|
|
|
|
the clang C++ APIs. Additionally the build system gained the new
|
|
|
|
|
"CLANG_LINK_CLANG_DYLIB" option, which defaults Off, and when set to On, will
|
|
|
|
|
force clang (and clang-based tools) to link the clang-cpp library instead of
|
|
|
|
|
statically linking clang's components. This option will reduce the size of
|
|
|
|
|
binary distributions at the expense of compiler performance.
|
|
|
|
|
|
|
|
|
|
- ...
|
2015-05-14 08:22:12 +08:00
|
|
|
|
2015-09-17 21:47:22 +08:00
|
|
|
AST Matchers
|
|
|
|
|
------------
|
|
|
|
|
|
2019-03-23 06:47:34 +08:00
|
|
|
- ...
|
2017-03-14 17:43:55 +08:00
|
|
|
|
|
|
|
|
clang-format
|
|
|
|
|
------------
|
|
|
|
|
|
2019-10-02 17:52:52 +08:00
|
|
|
- The ``Standard`` style option specifies which version of C++ should be used
|
|
|
|
|
when parsing and formatting C++ code. The set of allowed values has changed:
|
2019-10-06 00:08:17 +08:00
|
|
|
|
2019-10-02 17:52:52 +08:00
|
|
|
- ``Latest`` will always enable new C++ language features.
|
|
|
|
|
- ``c++03``, ``c++11``, ``c++14``, ``c++17``, ``c++20`` will pin to exactly
|
|
|
|
|
that language version.
|
|
|
|
|
- ``Auto`` is the default and detects style from the code (this is unchanged).
|
2019-10-06 00:08:17 +08:00
|
|
|
|
|
|
|
|
The previous values of ``Cpp03`` and ``Cpp11`` are deprecated. Note that
|
|
|
|
|
``Cpp11`` is treated as ``Latest``, as this was always clang-format's behavior.
|
|
|
|
|
(One motivation for this change is the new name describes the behavior better).
|
2017-12-05 17:23:47 +08:00
|
|
|
|
2013-04-24 15:33:52 +08:00
|
|
|
libclang
|
|
|
|
|
--------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2013-04-24 15:33:52 +08:00
|
|
|
|
2016-08-07 04:23:54 +08:00
|
|
|
|
2013-04-26 07:14:38 +08:00
|
|
|
Static Analyzer
|
2013-04-26 08:01:34 +08:00
|
|
|
---------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2013-04-26 08:01:34 +08:00
|
|
|
|
[clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang part
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:
```
unsigned char store = 0;
bool consume(unsigned int val);
void test(unsigned long val) {
if (consume(val)) {
// the 'val' is `unsigned long`, but `consume()` takes `unsigned int`.
// If their bit widths are different on this platform, the implicit
// truncation happens. And if that `unsigned long` had a value bigger
// than UINT_MAX, then you may or may not have a bug.
// Similarly, integer addition happens on `int`s, so `store` will
// be promoted to an `int`, the sum calculated (0+768=768),
// and the result demoted to `unsigned char`, and stored to `store`.
// In this case, the `store` will still be 0. Again, not always intended.
store = store + 768; // before addition, 'store' was promoted to int.
}
// But yes, sometimes this is intentional.
// You can either make the conversion explicit
(void)consume((unsigned int)val);
// or mask the value so no bits will be *implicitly* lost.
(void)consume((~((unsigned int)0)) & val);
}
```
Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, there are cases where it does **not** warn.
So a Sanitizer is needed. I don't have any motivational numbers, but i know
i had this kind of problem 10-20 times, and it was never easy to track down.
The logic to detect whether an truncation has happened is pretty simple
if you think about it - https://godbolt.org/g/NEzXbb - basically, just
extend (using the new, not original!, signedness) the 'truncated' value
back to it's original width, and equality-compare it with the original value.
The most non-trivial thing here is the logic to detect whether this
`ImplicitCastExpr` AST node is **actually** an implicit conversion, //or//
part of an explicit cast. Because the explicit casts are modeled as an outer
`ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children.
https://godbolt.org/g/eE1GkJ
Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set
on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`.
So if that flag is **not** set, then it is an actual implicit conversion.
As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`.
There are potentially some more implicit conversions to be warned about.
Namely, implicit conversions that result in sign change; implicit conversion
between different floating point types, or between fp and an integer,
when again, that conversion is lossy.
One thing i know isn't handled is bitfields.
This is a clang part.
The compiler-rt part is D48959.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions)
Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane
Reviewed By: rsmith, vsk, erichkeane
Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D48958
llvm-svn: 338288
2018-07-31 02:58:30 +08:00
|
|
|
.. _release-notes-ubsan:
|
|
|
|
|
|
2017-06-13 10:52:31 +08:00
|
|
|
Undefined Behavior Sanitizer (UBSan)
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour
Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4 When an expression J that has integral type is added to or subtracted
from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
elements ([dcl.array]), the expressions P + J and J + P
(where J has the value j) point to the (possibly-hypothetical) array
element i+j of x if 0≤i+j≤n and the expression P - J points to the
(possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```
Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)
To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".
Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566
Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.
`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown
Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers
Reviewed By: rsmith
Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67122
llvm-svn: 374293
2019-10-10 17:25:02 +08:00
|
|
|
- * The ``pointer-overflow`` check was extended added to catch the cases where
|
|
|
|
|
a non-zero offset is applied to a null pointer, or the result of
|
|
|
|
|
applying the offset is a null pointer.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
#include <cstdint> // for intptr_t
|
|
|
|
|
|
|
|
|
|
static char *getelementpointer_inbounds(char *base, unsigned long offset) {
|
|
|
|
|
// Potentially UB.
|
|
|
|
|
return base + offset;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
char *getelementpointer_unsafe(char *base, unsigned long offset) {
|
|
|
|
|
// Always apply offset. UB if base is ``nullptr`` and ``offset`` is not
|
|
|
|
|
// zero, or if ``base`` is non-``nullptr`` and ``offset`` is
|
|
|
|
|
// ``-reinterpret_cast<intptr_t>(base)``.
|
|
|
|
|
return getelementpointer_inbounds(base, offset);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
char *getelementpointer_safe(char *base, unsigned long offset) {
|
|
|
|
|
// Cast pointer to integer, perform usual arithmetic addition,
|
|
|
|
|
// and cast to pointer. This is legal.
|
|
|
|
|
char *computed =
|
|
|
|
|
reinterpret_cast<char *>(reinterpret_cast<intptr_t>(base) + offset);
|
|
|
|
|
// If either the pointer becomes non-``nullptr``, or becomes
|
|
|
|
|
// ``nullptr``, we must use ``computed`` result.
|
|
|
|
|
if (((base == nullptr) && (computed != nullptr)) ||
|
|
|
|
|
((base != nullptr) && (computed == nullptr)))
|
|
|
|
|
return computed;
|
|
|
|
|
// Else we can use ``getelementpointer_inbounds()``.
|
|
|
|
|
return getelementpointer_inbounds(base, offset);
|
|
|
|
|
}
|
|
|
|
|
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
|
2013-04-26 08:01:34 +08:00
|
|
|
Core Analysis Improvements
|
|
|
|
|
==========================
|
2013-04-26 07:14:38 +08:00
|
|
|
|
2013-06-04 14:17:46 +08:00
|
|
|
- ...
|
2013-04-26 08:01:34 +08:00
|
|
|
|
|
|
|
|
New Issues Found
|
|
|
|
|
================
|
|
|
|
|
|
2013-06-04 14:17:46 +08:00
|
|
|
- ...
|
2013-04-26 07:14:38 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
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
|
2018-09-10 16:51:25 +08:00
|
|
|
page <https://clang.llvm.org/>`_. The web page contains versions of the
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
API documentation which are up-to-date with the Subversion version of
|
|
|
|
|
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
|
|
|
|
|
contact us via the `mailing
|
2018-09-10 16:51:25 +08:00
|
|
|
list <https://lists.llvm.org/mailman/listinfo/cfe-dev>`_.
|