Revision tags: llvmorg-21-init |
|
#
820c6ac7 |
| 28-Jan-2025 |
cor3ntin <corentinjabot@gmail.com> |
[Clang] call HandleImmediateInvocation before checking for immediate escacalating expressions (reland) (#124708)
HandleImmediateInvocation can call MarkExpressionAsImmediateEscalating and should al
[Clang] call HandleImmediateInvocation before checking for immediate escacalating expressions (reland) (#124708)
HandleImmediateInvocation can call MarkExpressionAsImmediateEscalating and should always be called before CheckImmediateEscalatingFunctionDefinition. However, we were not doing that in `ActFunctionBody`.
Fixes #119046
show more ...
|
#
0e372c3e |
| 27-Jan-2025 |
cor3ntin <corentinjabot@gmail.com> |
Revert "[Clang] call HandleImmediateInvocation before checking for immediate escacalating expressions" (#124646)
Reverts llvm/llvm-project#124414
Turns out to be an important compile time regressio
Revert "[Clang] call HandleImmediateInvocation before checking for immediate escacalating expressions" (#124646)
Reverts llvm/llvm-project#124414
Turns out to be an important compile time regression, I'll come up with a less disruptive approach
show more ...
|
#
5815a311 |
| 27-Jan-2025 |
cor3ntin <corentinjabot@gmail.com> |
[Clang] call HandleImmediateInvocation before checking for immediate escacalating expressions (#124414)
HandleImmediateInvocation can call MarkExpressionAsImmediateEscalating and should always be ca
[Clang] call HandleImmediateInvocation before checking for immediate escacalating expressions (#124414)
HandleImmediateInvocation can call MarkExpressionAsImmediateEscalating and should always be called before CheckImmediateEscalatingFunctionDefinition.
However, we were not doing that in `ActFunctionBody`.
We simply move CheckImmediateEscalatingFunctionDefinition to PopExpressionEvaluationContext.
Fixes #119046
show more ...
|
#
73db9ee1 |
| 27-Jan-2025 |
Jon Roelofs <jonathan_roelofs@apple.com> |
[clang][Sema][FMV] Add a note to the 'cannot become multiversioned' diagnostic (#124364)
... pointing out the previous declaration.
|
#
563c7c55 |
| 25-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[clang] Migrate away from PointerUnion::dyn_cast (NFC) (#124425)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cas
[clang] Migrate away from PointerUnion::dyn_cast (NFC) (#124425)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T>
This patch migrates uses of PointerUnion::dyn_cast to dyn_cast_if_present (see the definition of PointerUnion::dyn_cast). Note that we cannot use dyn_cast in any of the migrations in this patch; placing
assert(!X.isNull());
just before any of dyn_cast_if_present in this patch triggers some failure in check-clang.
show more ...
|
#
8fb42300 |
| 22-Jan-2025 |
Tom Honermann <tom.honermann@intel.com> |
[SYCL] AST support for SYCL kernel entry point functions. (#122379)
A SYCL kernel entry point function is a non-member function or a static
member function declared with the `sycl_kernel_entry_poin
[SYCL] AST support for SYCL kernel entry point functions. (#122379)
A SYCL kernel entry point function is a non-member function or a static
member function declared with the `sycl_kernel_entry_point` attribute.
Such functions define a pattern for an offload kernel entry point
function to be generated to enable execution of a SYCL kernel on a
device. A SYCL library implementation orchestrates the invocation of
these functions with corresponding SYCL kernel arguments in response to
calls to SYCL kernel invocation functions specified by the SYCL 2020
specification.
The offload kernel entry point function (sometimes referred to as the
SYCL kernel caller function) is generated from the SYCL kernel entry
point function by a transformation of the function parameters followed
by a transformation of the function body to replace references to the
original parameters with references to the transformed ones. Exactly how
parameters are transformed will be explained in a future change that
implements non-trivial transformations. For now, it suffices to state
that a given parameter of the SYCL kernel entry point function may be
transformed to multiple parameters of the offload kernel entry point as
needed to satisfy offload kernel argument passing requirements.
Parameters that are decomposed in this way are reconstituted as local
variables in the body of the generated offload kernel entry point
function.
For example, given the following SYCL kernel entry point function
definition:
```
template<typename KernelNameType, typename KernelType>
[[clang::sycl_kernel_entry_point(KernelNameType)]]
void sycl_kernel_entry_point(KernelType kernel) {
kernel();
}
```
and the following call:
```
struct Kernel {
int dm1;
int dm2;
void operator()() const;
};
Kernel k;
sycl_kernel_entry_point<class kernel_name>(k);
```
the corresponding offload kernel entry point function that is generated
might look as follows (assuming `Kernel` is a type that requires
decomposition):
```
void offload_kernel_entry_point_for_kernel_name(int dm1, int dm2) {
Kernel kernel{dm1, dm2};
kernel();
}
```
Other details of the generated offload kernel entry point function, such
as its name and calling convention, are implementation details that need
not be reflected in the AST and may differ across target devices. For
that reason, only the transformation described above is represented in
the AST; other details will be filled in during code generation.
These transformations are represented using new AST nodes introduced
with this change. `OutlinedFunctionDecl` holds a sequence of
`ImplicitParamDecl` nodes and a sequence of statement nodes that
correspond to the transformed parameters and function body.
`SYCLKernelCallStmt` wraps the original function body and associates it
with an `OutlinedFunctionDecl` instance. For the example above, the AST
generated for the `sycl_kernel_entry_point<kernel_name>` specialization
would look as follows:
```
FunctionDecl 'sycl_kernel_entry_point<kernel_name>(Kernel)'
TemplateArgument type 'kernel_name'
TemplateArgument type 'Kernel'
ParmVarDecl kernel 'Kernel'
SYCLKernelCallStmt
CompoundStmt
<original statements>
OutlinedFunctionDecl
ImplicitParamDecl 'dm1' 'int'
ImplicitParamDecl 'dm2' 'int'
CompoundStmt
VarDecl 'kernel' 'Kernel'
<initialization of 'kernel' with 'dm1' and 'dm2'>
<transformed statements with redirected references of 'kernel'>
```
Any ODR-use of the SYCL kernel entry point function will (with future
changes) suffice for the offload kernel entry point to be emitted. An
actual call to the SYCL kernel entry point function will result in a
call to the function. However, evaluation of a `SYCLKernelCallStmt`
statement is a no-op, so such calls will have no effect other than to
trigger emission of the offload kernel entry point.
Additionally, as a related change inspired by code review feedback,
these changes disallow use of the `sycl_kernel_entry_point` attribute
with functions defined with a _function-try-block_. The SYCL 2020
specification prohibits the use of C++ exceptions in device functions.
Even if exceptions were not prohibited, it is unclear what the semantics
would be for an exception that escapes the SYCL kernel entry point
function; the boundary between host and device code could be an implicit
noexcept boundary that results in program termination if violated, or
the exception could perhaps be propagated to host code via the SYCL
library. Pending support for C++ exceptions in device code and clear
semantics for handling them at the host-device boundary, this change
makes use of the `sycl_kernel_entry_point` attribute with a function
defined with a _function-try-block_ an error.
show more ...
|
#
f597d346 |
| 17-Jan-2025 |
Ilia Kuklin <ikuklin@accesssoftek.com> |
[clang][Sema] Move computing best enum types to a separate function (#120965)
Move the code that computes BestType and BestPromotionType for an enum
to a separate function which can be called from
[clang][Sema] Move computing best enum types to a separate function (#120965)
Move the code that computes BestType and BestPromotionType for an enum
to a separate function which can be called from outside of Sema.
show more ...
|
#
acdcdbca |
| 15-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#123014)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#123014)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T>
Literal migration would result in dyn_cast_if_present (see the definition of PointerUnion::dyn_cast), but this patch uses dyn_cast because we expect EnumUnderlying to be nonnull.
show more ...
|
#
1594413d |
| 14-Jan-2025 |
higher-performance <higher.performance.github@gmail.com> |
Add Clang attribute to ensure that fields are initialized explicitly (#102040)
This is a new Clang-specific attribute to ensure that field
initializations are performed explicitly.
For example,
Add Clang attribute to ensure that fields are initialized explicitly (#102040)
This is a new Clang-specific attribute to ensure that field
initializations are performed explicitly.
For example, if we have
```
struct B {
[[clang::explicit]] int f1;
};
```
then the diagnostic would trigger if we do `B b{};`:
```
field 'f1' is left uninitialized, but was marked as requiring initialization
```
This prevents callers from accidentally forgetting to initialize fields,
particularly when new fields are added to the class.
show more ...
|
#
9988309d |
| 14-Jan-2025 |
Dan Klishch <30951924+DanShaders@users.noreply.github.com> |
[clang] Do not allow unorderable features in [[gnu::target{,_clones}]] (#98426)
This partially addresses #98244.
|
Revision tags: llvmorg-19.1.7 |
|
#
4cc9bf14 |
| 14-Jan-2025 |
higher-performance <higher.performance.github@gmail.com> |
Propagate lifetimebound from formal parameters to those in the canonical declaration and use that for analysis (#107627)
This partially fixes #62072 by making sure that re-declarations of a function
Propagate lifetimebound from formal parameters to those in the canonical declaration and use that for analysis (#107627)
This partially fixes #62072 by making sure that re-declarations of a function do not have the effect of removing lifetimebound from the canonical declaration.
It doesn't handle the implicit 'this' parameter, but that can be addressed in a separate fix.
show more ...
|
#
a56eb7c9 |
| 11-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[Sema] Avoid repeated hash lookups (NFC) (#122588)
|
#
cfe26358 |
| 11-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
Reapply "[clang] Avoid re-evaluating field bitwidth" (#122289)
|
#
4e32271e |
| 10-Jan-2025 |
Kerry McLaughlin <kerry.mclaughlin@arm.com> |
[AArch64][SME] Add diagnostics for SME attributes on lambda functions (#121777)
CheckFunctionDeclaration emits diagnostics if any SME attributes are used
by a function definition without the requir
[AArch64][SME] Add diagnostics for SME attributes on lambda functions (#121777)
CheckFunctionDeclaration emits diagnostics if any SME attributes are used
by a function definition without the required +sme or +sme2 target features.
This patch moves these diagnostics to a new function in SemaARM and
also adds a call to this from ActOnStartOfLambdaDefinition.
show more ...
|
#
8ea8e7f5 |
| 09-Jan-2025 |
Tom Honermann <tom.honermann@intel.com> |
[SYCL] Basic diagnostics for the sycl_kernel_entry_point attribute. (#120327)
The `sycl_kernel_entry_point` attribute is used to declare a function that
defines a pattern for an offload kernel entr
[SYCL] Basic diagnostics for the sycl_kernel_entry_point attribute. (#120327)
The `sycl_kernel_entry_point` attribute is used to declare a function that
defines a pattern for an offload kernel entry point. The attribute requires
a single type argument that specifies a class type that meets the requirements
for a SYCL kernel name as described in section 5.2, "Naming of kernels", of
the SYCL 2020 specification. A unique kernel name type is required for each
function declared with the attribute. The attribute may not first appear on a
declaration that follows a definition of the function. The function is
required to have a non-deduced `void` return type. The function must not be
a non-static member function, be deleted or defaulted, be declared with the
`constexpr` or `consteval` specifiers, be declared with the `[[noreturn]]`
attribute, be a coroutine, or accept variadic arguments.
Diagnostics are not yet provided for the following:
- Use of a type as a kernel name that does not satisfy the forward
declarability requirements specified in section 5.2, "Naming of kernels",
of the SYCL 2020 specification.
- Use of a type as a parameter of the attributed function that does not
satisfy the kernel parameter requirements specified in section 4.12.4,
"Rules for parameter passing to kernels", of the SYCL 2020 specification
(each such function parameter constitutes a kernel parameter).
- Use of language features that are not permitted in device functions as
specified in section 5.4, "Language restrictions for device functions",
of the SYCL 2020 specification.
There are several issues noted by various FIXME comments.
- The diagnostic generated for kernel name conflicts needs additional work
to better detail the relevant source locations; such as the location of
each declaration as well as the original source of each kernel name.
- A number of the tests illustrate spurious errors being produced due to
attributes that appertain to function templates being instantiated too
early (during overload resolution as opposed to after an overload is
selected).
Included changes allow the `SYCLKernelEntryPointAttr` attribute to be
marked as invalid if a `sycl_kernel_entry_point` attribute is used incorrectly.
This is intended to prevent trying to emit an offload kernel entry point
without having to mark the associated function as invalid since doing so
would affect overload resolution; which this attribute should not do.
Unfortunately, Clang eagerly instantiates attributes that appertain to
functions with the result that errors might be issued for function
declarations that are never selected by overload resolution. Tests have
been added to demonstrate this. Further work will be needed to address
these issues (for this and other attributes).
show more ...
|
#
59bdea24 |
| 08-Jan-2025 |
Timm Bäder <tbaeder@redhat.com> |
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp:
lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
show more ...
|
#
81fc3add |
| 08-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply returns the value from the `ConstantExpr` instead of constant-evaluating the bitwidth expression every time it is called.
show more ...
|
#
6586c676 |
| 19-Dec-2024 |
Alexandros Lamprineas <alexandros.lamprineas@arm.com> |
[FMV][AArch64] Emit mangled default version if explicitly specified. (#120022)
Currently we need at least one more version other than the default to
trigger FMV. However we would like a header file
[FMV][AArch64] Emit mangled default version if explicitly specified. (#120022)
Currently we need at least one more version other than the default to
trigger FMV. However we would like a header file declaration
__attribute__((target_version("default"))) void f(void);
to guarantee that there will be f.default
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
efe4bfa6 |
| 06-Dec-2024 |
Kazu Hirata <kazu@google.com> |
[AST] Include clang/Basic/DiagnosticComment.h instead of clang/AST/CommentDiagnostic.h (#117499)
Since:
commit d076608d58d1ec55016eb747a995511e3a3f72aa
Author: Richard Trieu <rtrieu@google.c
[AST] Include clang/Basic/DiagnosticComment.h instead of clang/AST/CommentDiagnostic.h (#117499)
Since:
commit d076608d58d1ec55016eb747a995511e3a3f72aa
Author: Richard Trieu <rtrieu@google.com>
Date: Sat Dec 8 05:05:03 2018 +0000
clang/AST/CommentDiagnostic.h has been forwarding to
clang/Basic/DiagnosticComment.h. This patch includes
clang/Basic/DiagnosticComment.h instead of
clang/AST/CommentDiagnostic.h.
show more ...
|
Revision tags: llvmorg-19.1.5 |
|
#
9ea993f9 |
| 03-Dec-2024 |
Younan Zhang <zyn7109@gmail.com> |
[Clang] Recover GLTemplateParameterList for generic lambdas in RebuildLambdaScopeInfo (#118176)
The NTTP argument appearing inside a trailing return type of a generic lambda would have us check for
[Clang] Recover GLTemplateParameterList for generic lambdas in RebuildLambdaScopeInfo (#118176)
The NTTP argument appearing inside a trailing return type of a generic lambda would have us check for potential lambda captures, where the function needs GLTemplateParameterList of the current LSI to tell whether the lambda is generic.
The lambda scope in this context is rebuilt by the LambdaScopeForCallOperatorInstantiationRAII when substituting the lambda operator during template argument deduction. Thus, I think the template parameter list should be preserved in the rebuilding process, as it seems otherwise innocuous to me.
Fixes #115931
show more ...
|
#
854d7301 |
| 27-Nov-2024 |
Vigneshwar Jayakumar <vigneshwarjayakumar@gmail.com> |
[Clang/AMDGPU] Zero sized arrays not allowed in HIP device code. (#113470)
Added diagnosis to throw error when zero sized arrays are used in the
HIP device code. SWDEV-449592
---------
Co-aut
[Clang/AMDGPU] Zero sized arrays not allowed in HIP device code. (#113470)
Added diagnosis to throw error when zero sized arrays are used in the
HIP device code. SWDEV-449592
---------
Co-authored-by: vigneshwar jayakumar <vigneshwar.jayakumar@amd.com>
show more ...
|
#
b185b851 |
| 27-Nov-2024 |
Bill Wendling <morbo@google.com> |
[Clang] Improve Sema diagnostic performance for __builtin_counted_by_ref (#116719)
Implement the sema checks with a placeholder. We then check for that
placeholder in all of the places we care to e
[Clang] Improve Sema diagnostic performance for __builtin_counted_by_ref (#116719)
Implement the sema checks with a placeholder. We then check for that
placeholder in all of the places we care to emit a diagnostic.
Fixes: #115520
show more ...
|
#
1e3e199e |
| 27-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Sema] Migrate away from PointerUnion::{is,get} (NFC) (#117498)
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_
[Sema] Migrate away from PointerUnion::{is,get} (NFC) (#117498)
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
I'm not touching PointerUnion::dyn_cast for now because it's a bit
complicated; we could blindly migrate it to dyn_cast_if_present, but
we should probably use dyn_cast when the operand is known to be
non-null.
show more ...
|
#
912c502a |
| 22-Nov-2024 |
Utkarsh Saxena <usx@google.com> |
[clang] Infer lifetime_capture_by for STL containers (#117122)
This is behind `-Wdangling-capture` warning which is disabled by default.
|
#
d23449d9 |
| 21-Nov-2024 |
Oleksandr T. <oleksandr.tarasiuk@outlook.com> |
[Clang] Eliminate shadowing warnings for parameters of explicit object member functions (#114813)
Fixes #95707.
|