https://github.com/ldionne requested changes to this pull request.
I think support for wasm mandates a short RFC, like most projects to support
new platforms that require non-trivial changes. There's not a huge amount of
changes in this patch, but it's also unclear to me that this is sufficient
efriedma-quic wrote:
Is there a plan for maintaining these annotations long-term? Like, should
there be a pre-commit action to verify that all the annotations are up-to-date?
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing li
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -finclude-default-header -triple
dxil-pc-shadermodel6.6-library %s -fnative-half-type -disable-llvm-passes
-verify -verify-ignore-unexpected
bob80905 wrote:
Thanks, this revealed a missing open curly brace on line 18!
I got
rnk wrote:
> Is there a plan for maintaining these annotations long-term? Like, should
> there be a pre-commit action to verify that all the annotations are
> up-to-date?
pre-commit actions are expensive, but I think we could afford to do something
here. It is not hard to set up a DLL build o
https://github.com/androm3da updated
https://github.com/llvm/llvm-project/pull/98712
>From 62c2ffac958ee5a235db254ad001875bb2980c1b Mon Sep 17 00:00:00 2001
From: Brian Cain
Date: Fri, 12 Jul 2024 21:34:56 -0700
Subject: [PATCH] [cmake] Add hexagon-linux cmake cache files
These can be used to
augusto2112 wrote:
> As a new feature, this needs a proposal on Discourse.
@efriedma-quic as an RFC under clang? I wasn't aware this was a rule, is this a
recent change?
https://github.com/llvm/llvm-project/pull/110188
___
cfe-commits mailing list
cf
https://github.com/pskrgag updated
https://github.com/llvm/llvm-project/pull/102602
>From 7b4f999b39f4308cab253204e6be41ea7a70f695 Mon Sep 17 00:00:00 2001
From: Pavel Skripkin
Date: Fri, 9 Aug 2024 14:37:47 +0300
Subject: [PATCH 01/12] clang/csa: add initial support for builtin overflow
---
pskrgag wrote:
Ah, this dangling reference to rvalue... I do remember why I bind `get{Min,
Max}Value` to locals -- `ConcreteInt` takes a reference to `APSInt`, so it's
not possible to pass result of these calls directly to constructor.
https://github.com/llvm/llvm-project/pull/102602
_
https://github.com/joaosaffran updated
https://github.com/llvm/llvm-project/pull/109331
>From ef969c536d700a8585f0892952fae49cdd9c42d1 Mon Sep 17 00:00:00 2001
From: Joao Saffran
Date: Thu, 19 Sep 2024 00:13:51 +
Subject: [PATCH 01/12] Codegen builtin
---
clang/include/clang/Basic/Builtin
https://github.com/Prabhuk updated
https://github.com/llvm/llvm-project/pull/109320
>From 6fc7aceab6bc193616fe78e21b796efb4dbffb58 Mon Sep 17 00:00:00 2001
From: prabhukr
Date: Tue, 3 Sep 2024 21:02:15 -0700
Subject: [PATCH 1/2] UEFI backend for x86_64
---
clang/lib/Basic/Targets/OSTargets.h
efriedma-quic wrote:
For a new feature with no existing implementation/language specification, I
want to see community input from people who want to use it, and understand the
potential impact on other projects (in this context, debuggers). There isn't
any formal requirement that happens on D
Artem-B wrote:
Unless HIP explicitly defines wavefront size property for the host (I do not
think so), it would appear that it's a property of a GPU, and as such should
not be treated as a constant on the host, because the host needs to deal with
multiple GPU variants, with different idea of t
https://github.com/joaosaffran updated
https://github.com/llvm/llvm-project/pull/109331
>From ef969c536d700a8585f0892952fae49cdd9c42d1 Mon Sep 17 00:00:00 2001
From: Joao Saffran
Date: Thu, 19 Sep 2024 00:13:51 +
Subject: [PATCH 01/13] Codegen builtin
---
clang/include/clang/Basic/Builtin
Cydox wrote:
> StructAccessBase has two possible results: it finds an lvalue that's the
> base, which can't be peeled apart any further, or it finds a pointer that's
> the base. It shouldn't be possible to confuse a pointer with a MemberExpr: a
> MemberExpr is an lvalue, and a pointer is, in t
https://github.com/joaosaffran updated
https://github.com/llvm/llvm-project/pull/109331
>From 8e0434d7571e693a794d82911557c021c1906fa2 Mon Sep 17 00:00:00 2001
From: Joao Saffran
Date: Thu, 19 Sep 2024 00:13:51 +
Subject: [PATCH 01/13] Codegen builtin
---
clang/include/clang/Basic/Builtin
augusto2112 wrote:
And would that be an RFC under "clang"? Or is there a different section on
Discourse for feature proposals?
https://github.com/llvm/llvm-project/pull/110188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
@@ -1119,6 +1125,18 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
// removed.
MPM.addPass(
PGOIndirectCallPromotion(true /* IsInLTO */, true /* SamplePGO */));
+
+if (InstrumentSampleColdFuncPath.getNumOccurrences() &&
+
bwendling wrote:
The problem we're faced with here is that the `Base` pointer could point to
anywhere within the structure. We already jump through several hoops to get the
flexible array member's `Decl` and the counter's `Decl`.
So because `Base` could be a pointer to anywhere in the struct,
https://github.com/a-tarasyuk updated
https://github.com/llvm/llvm-project/pull/110761
>From 9c69d6584d6b71554aec55f0de52abb4baa9435f Mon Sep 17 00:00:00 2001
From: Oleksandr T
Date: Wed, 2 Oct 2024 02:13:51 +0300
Subject: [PATCH 1/3] [Clang] omit parentheses in fold expressions with a
single
https://github.com/a-tarasyuk ready_for_review
https://github.com/llvm/llvm-project/pull/110761
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15598,6 +15598,9 @@
TreeTransform::TransformCXXFoldExpr(CXXFoldExpr *E) {
return getDerived().RebuildEmptyCXXFoldExpr(E->getEllipsisLoc(),
E->getOperator());
+ if (*NumExpansions == 1)
a-tarasyuk wrote:
Author: Keith Packard
Date: 2024-10-02T16:33:31-07:00
New Revision: ca57e8f23ff042c0ae996b040f364ced433b7507
URL:
https://github.com/llvm/llvm-project/commit/ca57e8f23ff042c0ae996b040f364ced433b7507
DIFF:
https://github.com/llvm/llvm-project/commit/ca57e8f23ff042c0ae996b040f364ced433b7507.diff
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Oleksandr T. (a-tarasyuk)
Changes
Fixes #101863
---
Full diff: https://github.com/llvm/llvm-project/pull/110761.diff
4 Files Affected:
- (modified) clang/docs/ReleaseNotes.rst (+2)
- (modified) clang/lib/Sema/TreeTransform.h (+8-1)
-
github-actions[bot] wrote:
@keith-packard Congratulations on having your first Pull Request (PR) merged
into the LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a
problem with a
https://github.com/topperc closed
https://github.com/llvm/llvm-project/pull/108942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Sirraide wrote:
> I don't think there's a deep reason blocks and lambdas don't use quite the
> same scope mechanics in the compiler, so if you wanted to pursue that, it
> seems reasonable. But this approach also seems viable.
Yeah, there is a comment about parameter packs in block arguments be
efriedma-quic wrote:
> I'm not sure what you mean by "or it finds a pointer that's the base". The
> MemberExpr the visitor returns doesn't have to be a pointer---e.g.
> ptr->a.b.c.d returning ptr->a.b, where b isn't a pointer---or do you mean
> something else?
In an expression which does not
Cydox wrote:
I'm gonna push something real quick to see if I understand were you want us to
go. Didn't check if this breaks any tests yet.
https://github.com/llvm/llvm-project/pull/110497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
efriedma-quic wrote:
Just under "clang" is fine.
https://github.com/llvm/llvm-project/pull/110188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Cydox updated
https://github.com/llvm/llvm-project/pull/110497
>From 15b69329a97706ada7d5e8cbeb76508aa55b418f Mon Sep 17 00:00:00 2001
From: Jan Hendrik Farr
Date: Sun, 29 Sep 2024 21:38:13 +0200
Subject: [PATCH 1/3] [Clang] Fix 'counted_by' for nested struct pointers
Fixes
Cydox wrote:
@efriedma-quic do you mean somthing along those lines?
https://github.com/llvm/llvm-project/pull/110497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10,6 +10,7 @@
//
//===--===//
+#include
bwendling wrote:
Please don't include this (I know it's left from debugging). If you want to
debug things, you can use:
```c++
llvm::errs() <<
@@ -10,6 +10,7 @@
//
//===--===//
+#include
Cydox wrote:
Yeah, this is just a quick commit to show you where my mind is going right now.
Won't be in any final commit
https://github.com/ll
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/109180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Sirraide closed
https://github.com/llvm/llvm-project/pull/99656
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rymiel created
https://github.com/llvm/llvm-project/pull/110942
This patch adjusts the requires clause/expression lookahead heuristic to assume
that some binary operation mean that the requires keyword refers to a clause.
This partially reverts the removed case clauses from
llvmbot wrote:
@llvm/pr-subscribers-clang-format
Author: Emilia Kond (rymiel)
Changes
This patch adjusts the requires clause/expression lookahead heuristic to assume
that some binary operation mean that the requires keyword refers to a clause.
This partially reverts the removed case clau
https://github.com/adam-yang updated
https://github.com/llvm/llvm-project/pull/110802
>From 08f0b8a10f3e5292fe2f91946392141c9239ec2c Mon Sep 17 00:00:00 2001
From: Adam Yang
Date: Wed, 2 Oct 2024 01:21:19 -0700
Subject: [PATCH 1/4] Added radians to clang
---
clang/include/clang/Basic/Builtins
Author: Younan Zhang
Date: 2024-10-03T08:24:20+08:00
New Revision: 5064c4c4f8f5b09c51bab9b18f62a5c3012989c0
URL:
https://github.com/llvm/llvm-project/commit/5064c4c4f8f5b09c51bab9b18f62a5c3012989c0
DIFF:
https://github.com/llvm/llvm-project/commit/5064c4c4f8f5b09c51bab9b18f62a5c3012989c0.diff
https://github.com/zyn0217 closed
https://github.com/llvm/llvm-project/pull/110887
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1119,6 +1125,18 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
// removed.
MPM.addPass(
PGOIndirectCallPromotion(true /* IsInLTO */, true /* SamplePGO */));
+
+if (InstrumentSampleColdFuncPath.getNumOccurrences() &&
+
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/110668
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne approved this pull request.
LGTM assuming the CI is green.
https://github.com/llvm/llvm-project/pull/110777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/110777
>From cb81337ae2828f330424b3c45a4161bc1e88ae18 Mon Sep 17 00:00:00 2001
From: Haowei Wu
Date: Tue, 1 Oct 2024 18:16:44 -0700
Subject: [PATCH] [libunwind] Fix libunwind library path for runtime test
This patch f
ldionne wrote:
I rebased onto `main` to trigger the CI again.
https://github.com/llvm/llvm-project/pull/110777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 616d1d2e998aa7a26059dc36fa04875c469f69cd
43230b5803d28d8f1a4b906e43d14cf4ddc2c363 --e
ldionne wrote:
This can be merged by whoever sees the CI green first.
https://github.com/llvm/llvm-project/pull/110777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AlexVlx wrote:
I don't think we should rely on these on the host at all, the addition was a
design mistake initially, we probably should not double down on it. The wave
size is an intrinsic property of the target, the host doesn't really have that
property; there are canonical ways of querying
https://github.com/a-tarasyuk updated
https://github.com/llvm/llvm-project/pull/110761
>From 9c69d6584d6b71554aec55f0de52abb4baa9435f Mon Sep 17 00:00:00 2001
From: Oleksandr T
Date: Wed, 2 Oct 2024 02:13:51 +0300
Subject: [PATCH 1/2] [Clang] omit parentheses in fold expressions with a
single
@@ -706,6 +706,11 @@ def HasV9_5aOps : SubtargetFeature<"v9.5a",
"HasV9_5aOps", "true",
"Support ARM v9.5a instructions",
[HasV9_4aOps]>;
+// Armv9.6-A is a v9-only architecture.
+def HasV9_6aOps : Subt
https://github.com/usx95 approved this pull request.
Thanks. LGTM.
https://github.com/llvm/llvm-project/pull/110503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Viktoriia Bakalova
Date: 2024-10-02T15:40:10+02:00
New Revision: 91e3fb3e5b538360b6ede9ba17d376c2175a8dfd
URL:
https://github.com/llvm/llvm-project/commit/91e3fb3e5b538360b6ede9ba17d376c2175a8dfd
DIFF:
https://github.com/llvm/llvm-project/commit/91e3fb3e5b538360b6ede9ba17d376c2175a8dfd.
https://github.com/VitaNuo closed
https://github.com/llvm/llvm-project/pull/110503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/erichkeane commented:
So the problem with statement attributes is that we don't really have a good
way to do instantiation of them on a template, which is why we held off on this
in the first place. The infrastructure for instantiation DOES happen on decl
attributes automati
Author: Erich Keane
Date: 2024-10-02T07:10:53-07:00
New Revision: da4b972ef690b40344cbb366cc4bdebada260e57
URL:
https://github.com/llvm/llvm-project/commit/da4b972ef690b40344cbb366cc4bdebada260e57
DIFF:
https://github.com/llvm/llvm-project/commit/da4b972ef690b40344cbb366cc4bdebada260e57.diff
L
https://github.com/erichkeane closed
https://github.com/llvm/llvm-project/pull/110684
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-hip-vega20` running
on `hip-vega20-0` while building `clang` at step 3 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/123/builds/6839
Here is the relevant piece of the build log for
Sirraide wrote:
@erichkeane Since you’ve approved the pr, shall we merge it once CI is done or
do you still want to wait for Shafik to review the release note?
(I don’t have anything else to comment on either)
https://github.com/llvm/llvm-project/pull/99656
@@ -1660,7 +1660,7 @@ class Record {
// this record.
SmallVector Locs;
SmallVector ForwardDeclarationLocs;
- SmallVector ReferenceLocs;
+ mutable SmallVector ReferenceLocs;
jurahul wrote:
This was needed in `ParseIDValue`:
```
if (Init *I = Records.
https://github.com/jurahul edited
https://github.com/llvm/llvm-project/pull/110747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1660,7 +1660,7 @@ class Record {
// this record.
SmallVector Locs;
SmallVector ForwardDeclarationLocs;
- SmallVector ReferenceLocs;
+ mutable SmallVector ReferenceLocs;
jurahul wrote:
No, this is for another case. Essentially, `appendReferenceLoc`
erichkeane wrote:
> @erichkeane Since you’ve approved the pr, shall we merge it once CI is done
> or do you still want to wait for Shafik to review the release note?
>
> (I don’t have anything else to comment on either)
I'm OK just committing. Shafik did a run at the release note that wasn't
https://github.com/jvoung created
https://github.com/llvm/llvm-project/pull/110870
createStorageLocation used in transferCallReturningOptional:
https://github.com/llvm/llvm-project/blob/09ba83be0ac178851e3c9c9c8fefddbdd4d8353f/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.
https://github.com/jvoung updated
https://github.com/llvm/llvm-project/pull/110870
>From d148d4b3187d507fb1ba1735a3111c3eac2d2157 Mon Sep 17 00:00:00 2001
From: Jan Voung
Date: Wed, 2 Oct 2024 15:26:32 +
Subject: [PATCH 1/2] [clang][dataflow] Add a test demonstrating an issue in
unchecked-
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
@@ -0,0 +1,82 @@
+// RUN: %libomptarget-compile-generic -fprofile-generate-gpu
jdenny-ornl wrote:
When targeting a V100, this command fails for me in both pgo1.c and pgo2.c. In
the LTO case:
```
LLVM ERROR: Circular dependency found in global variable set
```
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -0,0 +1,82 @@
+// RUN: %libomptarget-compile-generic -fprofile-generate-gpu
jhuber6 wrote:
This is a limitation of the PTX target, globals cannot reference themselves.
Most likely whatever NVIDIA engineer wrote the PTX parser found it annoying to
reference s
dwblaikie wrote:
Thanks @jimingham - yeah, that makes sense. My original argument for being OK
with the de-canonicalization of typedefs was that they aren't load bearing
anyway. But if lldb puts load on them, that assumption doesn't hold.
Yeah, could check for angles or template parameter DIEs
@@ -980,3 +980,30 @@ namespace PR78381 {
}
}
}
+
+namespace GH109083 {
+void test() {
+ const int N = 6;
+ int Arr[N] = {1, 2, 3, 4, 5, 6};
+
+ for (int I = 0; I < N; ++I) {
+auto V = [T = Arr[I]]() {};
+ }
+ // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-
https://github.com/5chmidti edited
https://github.com/llvm/llvm-project/pull/109159
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/5chmidti approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/109159
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -339,11 +335,11 @@ just added using your new frontend option.
## CMake Support
As of [#7246](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7246)
-(and soon to be released CMake 3.24.0), `cmake` can detect `flang-new` as a
+(and soon to be released CMake 3.24.0), `
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
@@ -178,6 +266,9 @@ void SPIRVPassConfig::addIRPasses() {
addPass(createSPIRVStructurizerPass());
}
+ if (TM.getOptLevel() > CodeGenOptLevel::None)
+addPass(createInferAddressSpacesPass(AddressSpace::Generic));
AlexVlx wrote:
Because if one invokes
https://github.com/erichkeane created
https://github.com/llvm/llvm-project/pull/110906
The 'force' tag permits intervening code on the applicable 'loop' construct,
so this implements the restriction when the 'force' tag isn't present.
>From 2cf12f7d5e6ea7727ea40bfa229758f4d657f5e9 Mon Sep 17 0
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Erich Keane (erichkeane)
Changes
The 'force' tag permits intervening code on the applicable 'loop' construct,
so this implements the restriction when the 'force' tag isn't present.
---
Full diff: https://github.com/llvm/llvm-project/pull/
@@ -1784,6 +1784,12 @@ defm debug_info_for_profiling :
BoolFOption<"debug-info-for-profiling",
PosFlag,
NegFlag>;
+def fprofile_generate_cold_function_coverage : Flag<["-"],
"fprofile-generate-cold-function-coverage">,
mtrofin wrote:
Would `-Wl,-lclang_r
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/109804
From 23b27377e556085054621f27d97059618b416695 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 23 Sep 2024 15:42:20 +0200
Subject: [PATCH 1/7] [analyzer] Suppress out of bounds reports a
fsfod wrote:
@john-brawn-arm This may be hard to remember, but this a path you've tread
before could the LLVM_INSTANTIATE_REGISTRY just be changed to a fulll class
explicit template instantiation?
https://github.com/llvm/llvm-project/pull/109024
___
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/109804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hekota updated
https://github.com/llvm/llvm-project/pull/110327
>From 4f235c0e9c539cdaa2bab9a7f8228f33c0fea2b8 Mon Sep 17 00:00:00 2001
From: Helena Kotas
Date: Thu, 26 Sep 2024 14:34:16 -0700
Subject: [PATCH 1/6] Add codegen for existing resource types and make
HLSLAttribut
Artem-B wrote:
> I don't think we should rely on these on the host at all, the addition was a
> design mistake initially, we probably should not double down on it.
I agree with it in principle. However, removing things that already exist
should be done with consideration for the existing user
NagyDonat wrote:
@isuckatcs If I am not mistaken, I reacted to every comment in your first
review.
I'm sorry for the salty initial reactions -- after thinking about this topic
for months, I ended up feeling that everything is _so obvious_, while in fact
it's a really complicated topic and per
Artem-B wrote:
@ritter-x2a That's an outline of a strawman plan in case one does nave
nontrivial amount of existing code that depends on this macro, and assuming
that we still want to have a host-side macro for the wavefront size. If the end
goal is not to have the host-side macro at all, then
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/109804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
zeroomega wrote:
> This can be merged by whoever sees the CI green first.
There are 6 failing build so far but all due to the "runner received a shutdown
signal", not actually a build/test failure? Should I do another rebase to
trigger a rerun? Or we can just land it now?
https://github.com/l
@@ -4492,6 +4492,31 @@ void CXXNameMangler::mangleType(const ArrayParameterType
*T) {
mangleType(cast(T));
}
+void CXXNameMangler::mangleType(const HLSLAttributedResourceType *T) {
hekota wrote:
Updated to use `mangleVendorQualifier`.
https://github.com/l
https://github.com/hekota updated
https://github.com/llvm/llvm-project/pull/110327
>From 4f235c0e9c539cdaa2bab9a7f8228f33c0fea2b8 Mon Sep 17 00:00:00 2001
From: Helena Kotas
Date: Thu, 26 Sep 2024 14:34:16 -0700
Subject: [PATCH 1/5] Add codegen for existing resource types and make
HLSLAttribut
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
@@ -3753,6 +3754,32 @@ void MicrosoftCXXNameMangler::mangleType(const
DependentBitIntType *T,
Error(Range.getBegin(), "DependentBitInt type") << Range;
}
+void MicrosoftCXXNameMangler::mangleType(const HLSLAttributedResourceType *T,
+
4ast wrote:
> Since load_acquire and store_release are essentially atomic operations (e.g.
> __atomic_load_n() and __atomic_store_n()), > is it possible to add
> acquire/release support in BPF_ATOMIC?
We discussed it with Eduard as well and came to similar conclusion.
BPF_STX | BPF_ATOMIC and
@@ -339,11 +335,11 @@ just added using your new frontend option.
## CMake Support
As of [#7246](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7246)
-(and soon to be released CMake 3.24.0), `cmake` can detect `flang-new` as a
+(and soon to be released CMake 3.24.0), `
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/110767
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Michael137 wrote:
Test failure unrelated. Will merge to unblock libc++ and investigate a path
forward as a follow-up
https://github.com/llvm/llvm-project/pull/110767
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
201 - 300 of 462 matches
Mail list logo
