https://github.com/hvdijk approved this pull request.
https://github.com/llvm/llvm-project/pull/150592
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5988,11 +5988,9 @@ bool clang::IsArmStreamingFunction(const FunctionDecl
*FD,
if (FD->hasAttr())
return true;
- if (const Type *Ty = FD->getType().getTypePtrOrNull())
hvdijk wrote:
> It was never previously valid to call it with an object that
@@ -5988,11 +5988,9 @@ bool clang::IsArmStreamingFunction(const FunctionDecl
*FD,
if (FD->hasAttr())
return true;
- if (const Type *Ty = FD->getType().getTypePtrOrNull())
hvdijk wrote:
Changing a previously valid call to have undefined behavior do
@@ -5988,11 +5988,9 @@ bool clang::IsArmStreamingFunction(const FunctionDecl
*FD,
if (FD->hasAttr())
return true;
- if (const Type *Ty = FD->getType().getTypePtrOrNull())
hvdijk wrote:
This change looks like it should not be necessary for your mai
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/149406
>From 94e652bc0bd6a04ef61a9f9b703257d464c7b714 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 17 Jul 2025 21:47:30 +0100
Subject: [PATCH 1/7] More fixes for P3144R2 implementation
P3144R2 made it ill-
https://github.com/hvdijk closed
https://github.com/llvm/llvm-project/pull/150359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/150359
>From 0f98715c538b32268ff3061c27221384ffee1eb3 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 24 Jul 2025 03:04:09 +0100
Subject: [PATCH 1/3] clang: Handle deleting pointers to incomplete array types
@@ -2146,30 +2146,12 @@ void CodeGenFunction::EmitCXXDeleteExpr(const
CXXDeleteExpr *E) {
return;
}
- // We might be deleting a pointer to array. If so, GEP down to the
- // first non-array element.
- // (this assumes that A(*)[3][7] is converted to [3 x [7 x %A]]*)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/150359
>From 0f98715c538b32268ff3061c27221384ffee1eb3 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 24 Jul 2025 03:04:09 +0100
Subject: [PATCH 1/3] clang: Handle deleting pointers to incomplete array types
@@ -2146,30 +2146,12 @@ void CodeGenFunction::EmitCXXDeleteExpr(const
CXXDeleteExpr *E) {
return;
}
- // We might be deleting a pointer to array. If so, GEP down to the
- // first non-array element.
- // (this assumes that A(*)[3][7] is converted to [3 x [7 x %A]]*)
@@ -76,27 +76,45 @@ namespace test1 {
~A();
};
- // CHECK-LABEL: define{{.*}} void @_ZN5test14testEPA10_A20_NS_1AE(
- void test(A (*arr)[10][20]) {
+ // CHECK-LABEL: define{{.*}} void @_ZN5test11fEPA10_A20_NS_1AE(
+ void f(A (*arr)[10][20]) {
delete [] arr;
@@ -76,27 +76,45 @@ namespace test1 {
~A();
};
- // CHECK-LABEL: define{{.*}} void @_ZN5test14testEPA10_A20_NS_1AE(
- void test(A (*arr)[10][20]) {
+ // CHECK-LABEL: define{{.*}} void @_ZN5test11fEPA10_A20_NS_1AE(
+ void f(A (*arr)[10][20]) {
delete [] arr;
hvdijk wrote:
> This broke compilation with Xcode Clang 12 (roughly corresponding to upstream
> Clang 10):
It's not limited to that, I was seeing it too, it's breaking on 32-bit targets
with older compilers that do not implicitly move between non-identical types.
I've pushed the obvious fix.
Author: Harald van Dijk
Date: 2025-07-23T12:48:44+01:00
New Revision: d65cc97ab1bdc61b22e853f3882c9ba267764e53
URL:
https://github.com/llvm/llvm-project/commit/d65cc97ab1bdc61b22e853f3882c9ba267764e53
DIFF:
https://github.com/llvm/llvm-project/commit/d65cc97ab1bdc61b22e853f3882c9ba267764e53.dif
@@ -595,6 +595,10 @@ struct GH99278_2 {
} f;
};
GH99278_2 e;
+void GH99278_3(int(*p)[]) {
+ delete p;
+ // expected-warning@-1 {{'delete' applied to a pointer-to-array type 'int
(*)[]' treated as 'delete[]'}}
+};
hvdijk wrote:
I've changed the array tests
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/149406
>From 94e652bc0bd6a04ef61a9f9b703257d464c7b714 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 17 Jul 2025 21:47:30 +0100
Subject: [PATCH 1/7] More fixes for P3144R2 implementation
P3144R2 made it ill-
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/149406
>From 94e652bc0bd6a04ef61a9f9b703257d464c7b714 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 17 Jul 2025 21:47:30 +0100
Subject: [PATCH 1/6] More fixes for P3144R2 implementation
P3144R2 made it ill-
@@ -595,6 +595,10 @@ struct GH99278_2 {
} f;
};
GH99278_2 e;
+void GH99278_3(int(*p)[]) {
+ delete p;
+ // expected-warning@-1 {{'delete' applied to a pointer-to-array type 'int
(*)[]' treated as 'delete[]'}}
+};
hvdijk wrote:
> The general issue here is
https://github.com/hvdijk edited
https://github.com/llvm/llvm-project/pull/149406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk edited
https://github.com/llvm/llvm-project/pull/149406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete expression with pointer-to-'void' type %0">
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/149406
>From 94e652bc0bd6a04ef61a9f9b703257d464c7b714 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 17 Jul 2025 21:47:30 +0100
Subject: [PATCH 1/4] More fixes for P3144R2 implementation
P3144R2 made it ill-
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete expression with pointer-to-'void' type %0">
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete pointer to %0">;
def ext_delete_void_ptr_o
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete pointer to %0">;
def ext_delete_void_ptr_o
hvdijk wrote:
How about this? For an incomplete class C, we used to generate the misleading
"cannot delete pointer to incomplete type 'C'", now "cannot delete pointer to
incomplete class 'C'", for a pointer to void, matching wording can just be
"cannot delete pointer to 'void'". Does that look
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/149406
>From 94e652bc0bd6a04ef61a9f9b703257d464c7b714 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 17 Jul 2025 21:47:30 +0100
Subject: [PATCH 1/3] More fixes for P3144R2 implementation
P3144R2 made it ill-
hvdijk wrote:
Release note added, and diagnostics updated to use
`%select{struct|interface|union|class|enum}` based on `getTagKind()` which is
already used for other diagnostics too (look for `|interface|` in the same
file).
I do take your point about `pointer-to-'void'` being clumsy wording,
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/149406
>From 94e652bc0bd6a04ef61a9f9b703257d464c7b714 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 17 Jul 2025 21:47:30 +0100
Subject: [PATCH 1/2] More fixes for P3144R2 implementation
P3144R2 made it ill-
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete expression with pointer-to-'void' type %0">
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete expression with pointer-to-'void' type %0">
@@ -8392,17 +8392,19 @@ def ext_default_init_const : ExtWarn<
"is a Microsoft extension">,
InGroup;
def err_delete_operand : Error<"cannot delete expression of type %0">;
+def err_delete_void_ptr_operand : Error<
+ "cannot delete expression with pointer-to-'void' type %0">
hvdijk wrote:
> Please add an entry to clang/docs/ReleaseNotes.rst in the section the most
> adapted to the change, and referencing any Github issue this change fixes.
> Thanks!
There is no separate GitHub issue for this, but will add a release note.
https://github.com/llvm/llvm-project/pull
hvdijk wrote:
Apologies for the repeated review request, not sure why GitHub removed one when
I only tried to request an additional reviewer.
https://github.com/llvm/llvm-project/pull/149406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
https://github.com/hvdijk edited
https://github.com/llvm/llvm-project/pull/149406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/149406
P3144R2 made it ill-formed to delete a pointer to an incomplete class type, and
asserted that incomplete class types were the only incomplete types that were
possible to pass to the delete operator. This asserti
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/145904
>From 0bf37a6f6edec4161f47d5eebb7e19931b6c454d Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 26 Jun 2025 15:29:23 +0100
Subject: [PATCH 1/2] [NFC] Remove getDefaultCallingConvention IsBuiltin
ASTCont
hvdijk wrote:
> > Would it not still be important for that for RVV intrinsics?
>
> Pretty sure we bypass all the normal calling convention lowering, in this
> context.
Ah, this is confusing. There's two types of RVV intrinsics that use this code.
Many use `ManualCodegen` which indeed bypasses
hvdijk wrote:
The calling convention doesn't just apply at the LLVM level though. For that,
you're right it wouldn't make a difference for RVV intrinsics, but it also
applies at the Clang level to determine whether Clang passes arguments by value
or by reference, and whether it promotes argume
hvdijk wrote:
@erichkeane Since you commited 000228183bf17a0f64afccdda35867553c9b75f6 which
was the last significant change to the function, would you be able to comment
on whether this seems reasonable to you?
https://github.com/llvm/llvm-project/pull/145904
__
hvdijk wrote:
> This patch does not make assumption that it is for the same architecture as
> host. Rather, it is inline with other toolchain objects that supports
> GCCInstallation which have ld as the default linker.
Thus breaking the case where it is not for the same architecture as host.
hvdijk wrote:
> Moreover, this patch makes gnuld the default linker for baremetal
> toolchain object. User need to pass -fuse-ld=lld explicitly to driver to
> select
> lld
This seems like an unrelated change, it was not mentioned in the RFC, and it
breaks things: baremetal toolchains generally
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/145904
ASTContext::getDefaultCallingConvention() was documented as returning "the
default calling convention for the current target", but did not do this, and
was never intended to do this, it has always been controlle
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/145698
For a kernel such as
kernel void foo(__global double3 *z) {
double3 x = {0.6631661088,0.6612268107,0.1513627528};
int3 y = {-1980459213,-660855407,615708204};
*z = pown(x, y);
}
we were not stori
hvdijk wrote:
Specifically here, `ScaledNumber` is a class template, that's what is causing
it to be emitted in every translation unit that uses `ScaledNumber`,
even user code that isn't otherwise using it, and it's being emitted according
to the then-current definition of `NDEBUG`.
> The iss
hvdijk wrote:
Minimal reproducer is
```c++
#include
int main() {}
```
Compile and link this without any special options (specifically: without
`-DNDEBUG`) against an LLVM release build, and it will now fail.
https://github.com/llvm/llvm-project/pull/139938
_
hvdijk wrote:
This approach causes issues when LLVM is built in release mode (with
`-DNDEBUG`) and external projects build against it in debug mode (with
`-UNDEBUG`). I appreciate that it does what the comment says should be done,
but I think what the comment says is wrong. Specifically, I now
@@ -63,11 +63,11 @@ multiclass RVVVLEFFBuiltin types> {
if ((PolicyAttrs & RVV_VTA) && (PolicyAttrs & RVV_VMA))
Ops.insert(Ops.begin(), llvm::PoisonValue::get(ResultType));
Ops.push_back(ConstantInt::get(Ops.back()->getType(), PolicyAttrs));
-
hvdijk wrote:
> This PR is too huge and it almost makes my Chrome broken. :-(
I don't think there is a way to meaningfully split this up, sorry. The changes
to `llvm/include/llvm/IR/IntrinsicsRISCV.td` are the main changes, everything
else is the minimal required to allow those changes.
https
https://github.com/hvdijk closed
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/135564
>From 6e4491f58b96f4bff2cfcac774e1b15785f0e57c Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 16 Apr 2025 03:08:42 +0100
Subject: [PATCH] [ARM, AArch64] Fix passing of structures with aligned base
cla
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/135564
>From 6e4491f58b96f4bff2cfcac774e1b15785f0e57c Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 16 Apr 2025 03:08:42 +0100
Subject: [PATCH] [ARM, AArch64] Fix passing of structures with aligned base
cla
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
hvdijk wrote:
Updated to use `BaseAlign`. Knowing that it does not affect Apple and Microsoft
calling conventions, is it okay to merge then?
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/135564
>From 146ac68a2838c0b51551abd11b3404152bcbfc75 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Sun, 13 Apr 2025 21:47:54 +0100
Subject: [PATCH] [ARM, AArch64] Fix passing of structures with aligned base
cla
https://github.com/hvdijk edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hvdijk edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
https://github.com/hvdijk edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
hvdijk wrote:
Not entirely sure who to ask for reviews, adding @rjmccall for the Itanium C++
ABI aspect as it interacts with the AAPCS ABIs, and @efriedma-quic who approved
https://reviews.llvm.org/D46013 originally.
https://github.com/llvm/llvm-project/pull/135564
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/135564
RecordLayout::UnadjustedAlignment was documented as "Maximum of the alignments
of the record members in characters", but
RecordLayout::getUnadjustedAlignment(), which just returns UnadjustedAlignment,
was docum
hvdijk wrote:
Both agreed with @nikic that this PR is a good idea and with @efriedma-quic
that this does not solve the problem in general. I don't think the latter
should stop this from being merged but it would be nice to find something that
addresses all cases.
> Another fix may be to gener
hvdijk wrote:
I did include "as non-SPIR-V SYCL targets need the same handling" already in my
first comment, so not sure why it gets that strong immediate reaction that
ignores that part of it.
https://github.com/llvm/llvm-project/pull/126956
___
cfe
hvdijk wrote:
It's not a bikeshedding problem that it doesn't handle other SYCL targets
consistently though. In some places there are checks for SYCL, in other places
there are checks for SPIR-V.
https://github.com/llvm/llvm-project/pull/126956
___
c
hvdijk wrote:
> Seems reasonable so long as we know that `SPIR-V` is always a GPU. I'll defer
> to SPIR people.
It's not. SPIR-V is mostly-device-agnostic and implementations may run it on
GPU, on CPU, or on any other device. I'm looking at this while trying to update
94229, I think `isGPU()`
https://github.com/hvdijk closed
https://github.com/llvm/llvm-project/pull/126967
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
This is a reland of #126059 with `insertDeclare`'s overload taking `BasicBlock
*` restored, and the changes to calls to that overload reverted. We previously
had nothing that relied on its peculiar behavior, therefore the change in its
behavior passed testing, but it crossed path
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/126967
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an Inser
hvdijk wrote:
The buildbot failures look like something conflicted with changes that have
since gone in on LLVM. I have reverted the change for now and will check what
is going on and update.
https://github.com/llvm/llvm-project/pull/126059
___
cfe-c
Author: Harald van Dijk
Date: 2025-02-12T17:50:39Z
New Revision: 23209eb1d9df57ca3419f5abc6b2edcdc0d1dead
URL:
https://github.com/llvm/llvm-project/commit/23209eb1d9df57ca3419f5abc6b2edcdc0d1dead
DIFF:
https://github.com/llvm/llvm-project/commit/23209eb1d9df57ca3419f5abc6b2edcdc0d1dead.diff
LO
@@ -1686,7 +1686,8 @@ LLVMDbgRecordRef LLVMDIBuilderInsertDeclareRecordBefore(
DbgInstPtr DbgInst = unwrap(Builder)->insertDeclare(
unwrap(Storage), unwrap(VarInfo),
unwrap(Expr), unwrap(DL),
- unwrap(Instr));
+ Instr ? InsertPosition(unwrap(Instr)->getI
https://github.com/hvdijk closed
https://github.com/llvm/llvm-project/pull/126059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1686,7 +1686,8 @@ LLVMDbgRecordRef LLVMDIBuilderInsertDeclareRecordBefore(
DbgInstPtr DbgInst = unwrap(Builder)->insertDeclare(
unwrap(Storage), unwrap(VarInfo),
unwrap(Expr), unwrap(DL),
- unwrap(Instr));
+ Instr ? InsertPosition(unwrap(Instr)->getI
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/126059
>From 6929e0ab55c0b5ed9904ec93ae6f7c284b46081b Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Fri, 7 Feb 2025 17:39:18 +
Subject: [PATCH] [DebugInfo] Update DIBuilder insertion to take InsertPosition
A
hvdijk wrote:
> Is this intended to be cherry-picked into the release branch or not?
Yes, I was hoping that we were still early enough to be able to cherry-pick it
without issues, especially as the aim is to restore a certain level of
compatibility with previous LLVM releases. If that is not t
@@ -1708,19 +1706,9 @@ static void insertDbgValueOrDbgVariableRecord(DIBuilder
&Builder, Value *DV,
static void insertDbgValueOrDbgVariableRecordAfter(
DIBuilder &Builder, Value *DV, DILocalVariable *DIVar, DIExpression
*DIExpr,
-const DebugLoc &NewLoc, BasicBlock::i
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/126059
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an Inser
hvdijk wrote:
ping @sdkrystian
FWIW, `getTemplateArgsAsWritten()` is implemented as
```c++
/// Retrieve the template argument list as written in the sources,
/// if any.
const ASTTemplateArgumentListInfo *getTemplateArgsAsWritten() const {
if (auto *Info = ExplicitInfo.dyn_cast())
hvdijk wrote:
The rebase apparently conflicted with #95224. In the test I added, I checked
that I preserved the existing behaviour with `-target-feature -neon`, but that
behaviour has since changed. Updated to remove that bit of the test.
https://github.com/llvm/llvm-project/pull/94229
___
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/94229
>From b1a53997e9378954da353ea1f0d8f03a8f19736f Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 23 Dec 2024 13:19:56 +
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attrib
hvdijk wrote:
Rebased to address a conflict with changes that have gone in since I first
submitted this, the PR remains otherwise identical and waiting to be reviewed.
https://github.com/llvm/llvm-project/pull/94229
___
cfe-commits mailing list
cfe-co
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/94229
>From 481f6c53379abb4b7240f25b55fb90b54b9454c1 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 3 Jun 2024 15:03:17 +0100
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attribu
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/118635
This change allows external projects to call for host versions of
clang-offload-bundler, clang-offload-packager, and llvm-ar.
This has no effect in LLVM itself, which does not make use of this, but is
going to
hvdijk wrote:
> I don't know what others would think about this, but without the subsequent
> changes that make use of this, I don't think this should be landed in LLVM.
> After all, plans might change, the community might refuse the subsequent PRs
> etc, resulting in dead code lying around.
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/110899
>From a334eb150b2d47e7e7cf13123f01c4513832e848 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 2 Oct 2024 18:14:38 +0100
Subject: [PATCH] [RecursiveASTVisitor] Skip implicit instantiations.
In DEF_TRAV
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemp
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemp
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemp
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/110899
In DEF_TRAVERSE_TMPL_SPEC_DECL, we attempted to skip implicit instantiations by
detecting that D->getTemplateArgsAsWritten() returns nullptr, but as this test
shows, it is possible for that to return a non-null
hvdijk wrote:
> > Apologies, but I'm having a bit of trouble understanding the scenario that
> > this PR addresses.
>
> Nixpkgs adds the tools being used to `$PATH` so find program needs to use
> path.
This PR enables inadvertent errors on non-Nix systems though. When a specific
LLVM path is
hvdijk wrote:
Apologies, but I'm having a bit of trouble understanding the scenario that this
PR addresses. It looks like it's meant to handle the case where
`LLVM_TOOLS_BINARY_DIR` does not contain the LLVM binaries, is that right? In
that case, why can `LLVM_TOOLS_BINARY_DIR` not instead be
@@ -55,7 +55,7 @@ if( LIBCLC_STANDALONE_BUILD OR CMAKE_SOURCE_DIR STREQUAL
CMAKE_CURRENT_SOURCE_DI
# Import required tools
if( NOT EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
foreach( tool IN ITEMS clang llvm-as llvm-link opt )
- find_program( LLVM_TOOL_${tool
hvdijk wrote:
Both buildbot failures appear to be unrelated to this PR: neither fails in
libclc, the first has resolved itself and passes in later attempts, the second
looks like the builder has just run out of disk space. If I am wrong and there
is something I should look into please let me k
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
ping
https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
The SPIRV-LLVM-Translator change that this depended on has been merged, so this
PR no longer depends on external changes.
https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/hvdijk edited https://github.com/llvm/llvm-project/pull/97811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 137 matches
Mail list logo
