This corrects the codegen for the final class optimization to
correct handle the case where there is no path to perform the
cast, and also corrects the codegen to handle ptrauth protected
vtable pointers.
As part of this fix we separate out the path computation as
that makes it easier to reason about the failure code paths
and more importantly means we can know what the type of the
this object is during the cast.
The allows us to use the GetVTablePointer interface which
correctly performs the authentication operations required when
pointer authentication is enabled. This still leaves incorrect
authentication behavior in the multiple inheritance case but
currently the optimization is disabled entirely if pointer
authentication is enabled.
Fixes#137518
Forward SourceLocation to `EmitCall` so that clang triggers an error
when a function inside `[[gnu::cleanup(func)]]` is annotated with
`[[gnu::error("some message")]]`.
resolves#146520
HandleMemberPointerAccess considered whether the lvalue path in a member
pointer access matched the bases of the containing class of the member,
but neglected to check the same for the containing class of the member
itself, thereby ignoring access attempts to members in direct sibling
classes.
Fixes#150705.
Fixes#150709.
1. Added %commands to documentation
2. Added %help command to clang repl
3. Expanded parsing to throw unique errors in the case of users entering
an invalid %command or using %lib without an argument
4. Added tests to check the behvaior of %help, %lib, and bad %commands
This fixes an ambiguous type type_info when you try and reference the
`type_info` type while using clang modulemaps with `-fms-compatibility`
enabled
Fixes#38400
This adds alpha.core.StoreToImmutable, a new alpha checker that detects
writes
to immutable memory regions, implementing part of SEI CERT Rule ENV30-C.
The
original proposal only handled global const variables, but this
implementation
extends it to also detect writes to:
- Local const variables
- String literals
- Const parameters and struct members
- Const arrays and pointers to const data
This checker is the continuation of the work started by zukatsinadze.
Discussion: https://reviews.llvm.org/D124244
* Fills out the terminology section
* Removes the basic usage section (we should bring it back someday
though!)
* Updates the list of supported language versions
* Adds information about what versions of Clang are officially supported
* Moves some extensions into the intentionally unsupported extensions
section.
There are likely far more updates that could be done, but this seemed
worth posting just to get things moving.
- Closes#151787
Insert the right parenthesis one token later to correctly enclose the
expression.
---------
Co-authored-by: Corentin Jabot <corentinjabot@gmail.com>
As the COFF linker is usually invoked independently, update the Clang
DTLTO section to show an example. This follows what is done earlier in
the document.
Also some minor fixes and improvements:
- Use generic distributor names to avoid implying anything about what an
Incredibuild distributor may or should support.
- Use subheadings for readability.
- Correct a mis-cased hyperlink.
The documentation of the cross translation unit analysis mentioned a
certain flag of `CodeChecker` (an external open source tool that can be
used to drive the static analysis), but the information about it was
obsolete: apparently the name of the flag, the names of the possible
values, and the default value were all changed.
Currently `CodeChecker analyze --help` displays this flag as
```
--ctu-ast-mode {load-from-pch,parse-on-demand}
Choose the way ASTs are loaded during CTU analysis. Only available if
CTU mode is enabled. Mode 'load-from-pch' generates PCH format
serialized ASTs during the 'collect' phase. Mode 'parse-on-demand'
only generates the invocations needed to parse the ASTs. Mode 'load-
from-pch' can use significant disk-space for the serialized ASTs,
while mode 'parse-on-demand' can incur some runtime CPU overhead in
the second phase of the analysis. (default: parse-on-demand)
```
and I tried to follow this in the commands that I adjusted.
Note that this documentation file probably contains other obsolete
details as well, but I didn't try to find or fix them.
## Motivation
`-Wunreachable-code` missed—or in rare cases crashed on—tautological
comparisons such as
```cpp
x != 0 || x != 1.0 // always true
x == 0 && x == 1.0 // always false
```
when the *same* variable appears on both sides but one operand goes
through a floating‑rank promotion that is target‑dependent. On back‑ends
with **native half‑precision** (`_Float16` / `__fp16`) such as
AArch64 `+fullfp16`, no promotion occurs, so the cast stacks between the
two operands differ and the existing heuristic bails out.
## Technical description
* **Extends `Expr::isSameComparisonOperand()`** – the helper now ignores
parentheses **and value‑preserving implicit casts**
(`CK_LValueToRValue`, floating‑rank `CK_FloatingCast`) before comparing
the underlying operands. This prevents floating‑rank promotions and
lvalue‑to‑rvalue conversions from blocking the unreachable‑code
diagnostic on targets with native FP16.
*No change needed in `CheckIncorrectLogicOperator`; it simply benefits
from the improved helper.*
* **Regression test** – `warn-unreachable_crash.cpp` updated to cover
both the promoted case (x86‑64) and the native‑half case
(AArch64 `+fullfp16`).
* **Docs** – release‑note bullet added under *Bug Fixes in This
Version*.
@ziqingluo-90 @yronglin Could you please review promptly? (feel free to
also merge it on my behalf) Thanks!
Fixes#149967
Co-authored-by: Zeeshan Siddiqui <mzs@ntdev.microsoft.com>
Changed the warning message:
- **From**: 'Attempt to free released memory'
**To**: 'Attempt to release already released memory'
- **From**: 'Attempt to free non-owned memory'
**To**: 'Attempt to release non-owned memory'
- **From**: 'Use of memory after it is freed'
**To**: 'Use of memory after it is released'
All connected tests and their expectations have been changed
accordingly.
Inspired by [this
PR](https://github.com/llvm/llvm-project/pull/147542#discussion_r2195197922)
This patch adds a human readable trap category and message to UBSan
traps. The category and message are encoded in a fake frame in the debug
info where the function is a fake inline function where the name encodes
the trap category and message. This is the same mechanism used by
Clang’s `__builtin_verbose_trap()`.
This change allows consumers of binaries built with trapping UBSan to
more easily identify the reason for trapping. In particular LLDB already
has a frame recognizer that recognizes the fake function names emitted
in debug info by this patch. A patch testing this behavior in LLDB will
be added in a separately.
The human readable trap messages are based on the messages currently
emitted by the userspace runtime for UBSan in compiler-rt. Note the
wording is not identical because the userspace UBSan runtime has access
to dynamic information that is not available during Clang’s codegen.
Test cases for each UBSan trap kind are included.
This complements the [`-fsanitize-annotate-debug-info`
feature](https://github.com/llvm/llvm-project/pull/141997). While
`-fsanitize-annotate-debug-info` attempts to annotate all UBSan-added
instructions, this feature (`-fsanitize-debug-trap-reasons`) only
annotates the final trap instruction using SanitizerHandler information.
This work is part of a GSoc 2025 project.
CodeGenFunction::EmitCXXDeleteExpr contains logic to go from a pointer
to an array to a pointer to the first element of the array using a
getelementptr LLVM IR instruction. This was done for pointers that were
not variable length arrays, as pointers to variable length arrays never
existed in LLVM IR, but rather than checking for arrays that were not
variable length arrays, it checked for arrays that had a constant bound.
This caused incomplete arrays to be inadvertently omitted.
This getelementptr was necessary back when LLVM IR used typed pointers,
but they have been gone for a while, a gep with a constant zero offset
does nothing now, so we can simplify the code by removing that.
This commit provides a brief documentation for the checker
optin.portability.UnixAPI.
Unfortunately the name of this checker is meaninglessly vague and its
functionality is very closely related to unix.Malloc, so it should be
eventually "rebranded" to a more user-friendly presentation.
When release notes were cleared on ``main``, there were some notes lost
because the changes happened after the branch point for 21.x. This
restores the lost notes.
Do not warn on deprecated member used in an implicit definition (such as a defaulted special member function).
Co-authored-by: Corentin Jabot <corentinjabot@gmail.com>
Fixes#147293
In OpenMP 6.0 specification, section 5.2.5 Array Sections, page 166,
lines 28-28:
When the length is absent and the size of the dimension is not known,
the array section is an assumed-size array.
Testing
- Updated LIT test
- check-all
- OpenMP_VV (formerly sollve) test case
tests/6.0/target/test_target_assumed_array_size.c
If the need_device_addr adjust-op modifier is present, each list item
that appears in the clause must refer to an argument in the declaration
of the function variant that has a reference type.
Reference:
OpenMP 6.0 [Sec 9.6.2, page 332, line 31-33, adjust_args clause,
Restrictions]
This (mostly) removes one of the largest remaining limitations of
`hipstdpar` based algorithm acceleration, by adding support for global
variable usage in offloaded algorithms. It is mean to compose with a run
time component that will live in the support library, and fires iff a
special variable is provided by the latter. In short, things work as
follows:
- We replace uses some global `G` with an indirect access via an
implicitly created anonymous global `F`, which is of pointer type and is
expected to hold the program-wide address of `G`;
- We append 'F', alongside 'G''s name, to an table structure;
- At run-time, the support library uses the table to look-up the
program-wide address of a contained symbol based on its name, and then
stores the address via the paired pointer.
This doesn't handle internal linkage symbols (`static foo` or `namespace
{ foo }`) if they are not unique i.e. if there's a name clash that is
solved by the linker, as the resolution would not be visible. Also,
initially we will only support "true" globals in RDC mode. Things would
be much simpler if we had direct access to the accelerator loader, but
since the expectation is to compose at the HIP RT level we have to jump
through additional hoops.
As documented in 20.x, we'd like to keep reduced BMI off by default for
1~2 versions. And now we're in 22.x.
I rarely receive bug reports for reduced BMI. I am not sure about the
reason. Maybe not a lot of people are using it. Or it is really stable
enough.
And also, we've been enabling the reduced BMI internally for roughly half a
year.
So I think it's the time to move on. See the document changes for other
information.
The 'Extra Clang Tools' section does not mention any other clang tool
except clang-tidy. This adds all missing extra tools to sync
documentation between this page and the main page of Extra Clang Tools.
Fixes#148538
The checks for the 'z' and 't' format specifiers added in the original
PR #143653 had some issues and were overly strict, causing some build
failures and were consequently reverted at
4c85bf2fe8.
In the latest commit
27c58629ec,
I relaxed the checks for the 'z' and 't' format specifiers, so warnings
are now only issued when they are used with mismatched types.
The original intent of these checks was to diagnose code that assumes
the underlying type of `size_t` is `unsigned` or `unsigned long`, for
example:
```c
printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long
```
However, it produced a significant number of false positives. This was
partly because Clang does not treat the `typedef` `size_t` and
`__size_t` as having a common "sugar" type, and partly because a large
amount of existing code either assumes `unsigned` (or `unsigned long`)
is `size_t`, or they define the equivalent of size_t in their own way
(such as
sanitizer_internal_defs.h).2e67dcfdcd/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h (L203)
This patch addresses the lack of support for parenthesized
initialization in the Clang Static Analyzer's `ExprEngine`. Previously,
initializations such as `V v(1, 2);` were not modeled properly, which
could lead to false negatives in analyses like `DivideZero`.
```cpp
struct A {
int x;
A(int v) : x(v) {}
};
int t() {
A a(42);
return 1 / (a.x - 42); // expected-warning {{Division by zero}}
}
```
Fixes#148875
This is another case where untransformed constraint expressions led to
inconsistent transforms.
We did fix some of those issues by looking at parent scopes, however the
parent instantiation scope is not always available because we could also
reach here after the parents get instantiated.
Fixes#146614