tryEvaluateString was returning an std::optional, but the other try* API
was not. Update tryEvaluateObjectSize and tryEvaluateStrLen to return an
std::optional<uint64_t>.
Fixes#179128.
This patch fixes a false negative where Clang failed to detect
out-of-bounds access when calling a member function on an invalid array
index. It adds handling for CXXMemberCallExpr in CheckArrayAccess.
Signed-off-by: prajwal jalwadi<prajwaljalwadi@gmail.com>
ptrauth intrinsic to safely construct relative ptr for swift coroutines.
A ptrauth intrinsic for swift co-routine support that allows creation of
signed pointer
from offset stored at address relative to the pointer.
Following C-like pseudo code (ignoring keys,discriminators) explains its
operation:
let rawptr = PACauth(inputptr);
return PACsign( rawptr + signextend64( *(int32*)(rawptr+addend) ))
What: Authenticate a signed pointer, load a 32bit value at offset
'addend' from pointer,
add this value to pointer, sign this new pointer.
builtin: __builtin_ptrauth_auth_load_relative_and_sign
intrinsic: ptrauth_auth_resign_load_relative
Summary:
The `__scoped_atomic` builtins are supposed to match the standard
GNU-flavored `__atomic` builtins. We added a scoped builtin without a
corresponding standard one before the fork so this should be added in
the release candidate. These were originally added in
https://github.com/llvm/llvm-project/pull/168666
Also, the name `uinc_wrap` does not follow the naming convention. The
GNU atomics use `fetch_xyz` to indicate that the builtin returns the
previous location's value as part of the RMW operation, which these do.
This PR renames it and its uses.
This patch adds type-generic rotate builtins that accept any unsigned
integer
type. These builtins provide:
- Support for all unsigned integer types, including _BitInt
- Constexpr evaluation capability
- Automatic normalization of rotation counts modulo the bit-width
- Proper handling of negative rotation counts (converted to equivalent
positive rotations in the opposite direction)
- Implicit conversion support for both arguments for
types with conversion operators.
The builtins follow C23 naming conventions.
Resolves https://github.com/llvm/llvm-project/issues/122819
We proceeded with frontend/clang changes, until we figure out how ABI
for BE should look like. Once it is final, we will proceed with codegen
changes.
In this patch several things addressed:
- Define riscv32be/riscv64be target triples
- Set correct data layout for BE targets
- Handle BE-specific ABI details
- Emit warning for BE case since it is still experimental
Reverts llvm/llvm-project#166542
It caused clang to assert with: `!isa<CXXDestructorDecl>(D) && "Use
other ctor with dtor decls!"`
see comment on the PR.
- ThreadSanitizer currently does not support `std::atomic_thread_fence`,
leading to false positives:
https://github.com/llvm/llvm-project/issues/52942.
- GCC produces a warning when `std::atomic_thread_fence` is used with
`-fsanitize=thread` while Clang doesn't.
- This PR introduces a matching warning in Clang to avoid confusion as
in the linked issue.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Introduce `__builtin_allow_sanitize_check("name")` which returns true if
the specified sanitizer is enabled for the function (after inlining).
Supported sanitizers are "address", "thread", "memory", "hwaddress", and
their "kernel-" variants, matching the names of the
`no_sanitize("name")`
usage.
This builtin enables conditional execution of explicit checks only when
the sanitizer is enabled, respecting `no_sanitize` attributes, even when
used from `always_inline` functions that may be used in sanitized or
no_sanitize functions.
Since we must defer until after inlining and cannot determine the result
statically, Clang must lower to the `llvm.allow.sanitize.*` intrinsics,
which are then resolved by the `LowerAllowCheckPass`.
*Original Motivation:* The Linux kernel has a number of low-level
primitives that use inline assembly not visible to the sanitizers, but
use explicitly inserted checks to avoid coverage loss. Many of those
low-level helpers, however, are also used from so-called `noinstr`
functions, which use `no_sanitize(..)` to prohibit instrumentation;
these are used for very brittle code (such as when the kernel sets up a
task context *before* normal memory is accessible), and any
instrumentation, incl. from explicit instrumentation, is prohibited.
Many such helpers themselves are macros or `always_inline`, however, are
unable to be used from such brittle contexts because they contain
explicit instrumentation. This requires awkward workarounds to avoid the
instrumentation.
The ideal solution is this new builtin, that can be used to determine if
instrumentation is enabled in a given function or not, which the helper
can then use to insert instrumentation only where instrumentation is
allowed.
A recent such case came up in [1], where file-level instrumentation had
already been disabled for KASAN and KCSAN, which had not been necessary
if the new builtin were available.
[1] https://lore.kernel.org/all/20251208-gcov-inline-noinstr-v1-0-623c48ca5714@google.com/
fixes#171049fixes#171050
- Allow Bools for matrix type when in HLSL mode
- use ConvertTypeForMem to figure out the bool size
- Add Bool matrix types to hlsl_basic_types.h
---------
Co-authored-by: Helena Kotas <hekotas@microsoft.com>
fixes#167621
- define the new options in `Options.td` limit the naming to row-major
or column-major.
- In `ToolChains/Clang.cpp` limit the opt usage to only when
`-fenable-matrix` is used.
---------
Co-authored-by: Florian Hahn <flo@fhahn.com>
Implements the `-Wmissing-format-attribute` diagnostic as a subgroup of
`-Wformat-nonliteral`. It suggests adding format attributes to function
declarations that call other format functions and pass the format string
to them.
This is an updated implementation of #105479.
---------
Co-authored-by: Budimir Arandjelovic <budimir.arandjelovic@htecgroup.com>
The __builtin_counted_by_ref builtin was previously limited to flexible
array members (FAMs). This change extends it to also support pointer
members that have the 'counted_by' attribute.
The 'counted_by' attribute can be applied to both FAMs and pointer
members:
struct fam_struct {
int count;
int array[] __attribute__((counted_by(count)));
};
struct ptr_struct {
int count;
int *buf __attribute__((counted_by(count)));
};
With this change, __builtin_counted_by_ref works with both:
*__builtin_counted_by_ref(p->array) = size; // FAM - already worked
*__builtin_counted_by_ref(p->buf) = size; // pointer - now works
This enables the same allocation pattern for pointer members that was
previously only available for FAMs:
#define alloc_buf(P, MEMBER, COUNT) ({ \
typeof(P) __p = malloc(sizeof(*__p)); \
__p->MEMBER = malloc(sizeof(*__p->MEMBER) * COUNT); \
*_Generic(__builtin_counted_by_ref(__p->MEMBER), \
void *: &(size_t){0}, \
default: __builtin_counted_by_ref(__p->MEMBER)) = COUNT; \
__p; \
})
The builtin returns:
- A pointer to the count field if the member has 'counted_by'
- void* (null) if the member is an array or pointer without 'counted_by'
- An error for other member types (e.g., int, struct)
This was requested by upstream Linux kernel devs:
https://lore.kernel.org/linux-hardening/202512041215.44484FCACD@keescook/
fixes#168737fixes#168755
This change fixes adds support for Matrix truncations via the
ICK_HLSL_Matrix_Truncation enum. That ends up being most of the files
changed.
It also allows Matrix as an HLSL Elementwise cast as long as the cast
does not perform a shape transformation ie 3x2 to 2x3.
Tests for the new elementwise and truncation behavior were added. As
well as sema tests to make sure we error n the shape transformation
cast.
I am punting right now on the ConstExpr Matrix support. That will need
to be addressed later. Will file a seperate issue for that if reviewers
agree it can wait.
This PR extends __scoped_atomic builtins with inc and dec functions.
They map to LLVM IR `atomicrmw uinc_wrap` and `atomicrmw udec_wrap`.
These enable implementation of OpenCL-style atomic_inc / atomic_dec with
wrap semantics on targets supporting scoped atomics (e.g. GPUs).
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Using the builtin failed on 32-bit architectures:
```
clang/lib/AST/ExprConstant.cpp:14299: [..]: Assertion `I.getBitWidth() == Info.Ctx.getIntWidth(E->getType()) && "Invalid evaluation result."' failed.
```
The return type is meant to be size_t. Fix it.
With the C++23 explicit object parameter feature, it is no longer
sufficient to only check if a function is an instance method to
determine if it has an implicit this argument. That causes problems in
attributes that have parameter indexes.
Commit b194cf1e401a changed this function for the case where attribute
`cfi_unchecked_callee` is added in a function conversion. But this
introduces a hole (issue #162798), and it seems the change was
unnecessary: the preceding `TryFunctionConversion` will already allow
adding the `cfi_unchecked_callee` attribute, and will update `FromType`
if it succeeds. So we revert the changes to `IsStandardConversion`. We
also remove the helper function `AddingCFIUncheckedCallee` which is no
longer needed, and simplify the corresponding
`DiscardingCFIUncheckedCallee`.
Fixes: #162798
Update `.Cases` and `.CasesLower` with 4+ args to use the
`initializer_list` overload. The deprecation of these functions will
come in a separate PR.
For more context, see: https://github.com/llvm/llvm-project/pull/163405.
fixes#160190fixes#116710
This change just makes MaxMatrixDimension configurable by language mode.
It was previously introduced in
94b43118e2
when there was not a need to make dimensions configurable.
Current testing to this effect exists in:
- clang/test/Sema/matrix-type-builtins.c
- clang/test/SemaCXX/matrix-type-builtins.cpp
- clang/test/SemaHLSL/BuiltIns/matrix-basic_types-errors.hlsl
New Tests to confirm configurability by language mode:
- clang/unittests/Frontend/CompilerInvocationTest.cpp
I considered adding a driver flag to
`clang/include/clang/Driver/Options.td` but HLSL matrix max dim is
always 4 so we don't need this configurable beyond that size for our use
case.
This rename was made as part of
https://github.com/llvm/llvm-project/pull/147835 in order to ease
rebasing the PR, and give a nice window for other patches to get rebased
as well.
It has been a while already, so lets go ahead and rename it back.
This reverts commit 8f77621574176387f906b8ceef9e1abb90bf22f6 (#161314).
Reason: Causing crashes when building https://github.com/google/highway.
See the original PR for details.
Update the `operator%` overload that accepts `CharUnits` to return
`CharUnits` to match the other `operator%`. This is more logical than
returning an `int64` and cleans up users that want to continue to do
math with the result.
Many users of this were explicitly comparing against 0. I considered
updating these to compare against `CharUnits::Zero` or even introducing
an `explicit operator bool()`, but they all feel clearer if we update
them to use the existing `isMultipleOf()` function instead.
This patch teaches clang accepts gnu_printf, gnu_scanf, gnu_strftime and
gnu_strfmon. These attributes are aliases for printf, scanf, strftime and
strfmon.
Ref: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.htmlFixes: #16219
---------
Co-authored-by: Sirraide <aeternalmail@gmail.com>
Summary:
Right now these enformce alignment, which isn't convenient for the user
on platforms that support unaligned accesses. The options are to either
permit passing the alignment manually, or just assume it's unaligned
unless the user specifies it.
I've added https://github.com/llvm/llvm-project/pull/156057 which should
make the requiested alignment show up on the intrinsic if the user
passed `__builtin_assume_aligned`, however that's only with
optimizations. This shouldn't cause issues unless the backend
categorically decides to reject an unaligned access.
Resolves https://github.com/llvm/llvm-project/issues/33409.
The information `IsListInit` is already passed to function
`CheckImplicitConversion` for another use-case which makes adding a
condition for the double-promotion case simple.
Also adds tests, both for the changed list-initialization case as well
as for normal explicit casts which already would have passed before this
PR. These negative tests are added directly next to the positive tests
in `warn-double-promotion.c` or for the C++-specific cases in a new .cpp
version of that file.
Update Sema::checkCall to handle the case where a call involves a
streaming mode transition and passes or returns scalable vector types.
Previously, Clang always issued a warning in this case, noting that the
streaming and non-streaming vector lengths may differ at runtime. With
this change:
- if both `-msve-vector-bits` and `-msve-streaming-vector-bits` are
specified and produce different fixed VL values, Clang now emits an
error rather than a warning
- If either flag is missing or vector lengths are equal, the diagnostic
remains a warning
Summary:
This patch exposes `__builtin_masked_gather` and
`__builtin_masked_scatter` to clang. These map to the underlying
intrinsic relatively cleanly, needing only a level of indirection to
take a vector of indices and a base pointer to a vector of pointers.
Summary:
The added bit counting builtins for vectors used `cttz` and `ctlz`,
which is consistent with the LLVM naming convention. However, these are
clang builtins and implement exactly the `__builtin_ctzg` and
`__builtin_clzg` behavior. It is confusing to people familiar with other
other builtins that these are the only bit counting intrinsics named
differently. This includes the additional operation for the undefined
zero case, which was added as a `clzg` extension.
This is not implemented at compile time and asserts in assertion builds,
so reject it here.
Fixed the coding style in `BuiltinShuffleVector` at the same time.
Fixes#158471
Summary:
The interface here is nearly indentical to the already added masked
loads and stores. These bind to very similar intrinsics so we add them
here.
For scalars we directly compare their unqualified types. But even if we
compare unqualified vector types, a difference in qualifiers in the
element types can make the vector types be considered not equal. For
example, vector of 4 'const float' values vs vector of 4 'float' values.
So we compare unqualified types of their elements and number of
elements.
Fixes#155405
