llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Amr Hesham (AmrDeveloper)
Changes
Upstream support for SubstNonTypeTemplateParmExpr
---
Full diff: https://github.com/llvm/llvm-project/pull/146751.diff
2 Files Affected:
- (modified) clang/lib/CIR/CodeGen/CIRGenExprScalar.cpp (+5)
- (
https://github.com/AmrDeveloper created
https://github.com/llvm/llvm-project/pull/146751
Upstream support for SubstNonTypeTemplateParmExpr
>From 09eb48db09711dd0a88d37b07eb0873c939c9176 Mon Sep 17 00:00:00 2001
From: AmrDeveloper
Date: Wed, 2 Jul 2025 20:02:35 +0200
Subject: [PATCH] [CIR] Upst
benlangmuir wrote:
> Would you have a different opinion if I told you that the next PR in my
> queue re-introduces AFFECTING_*_CODEGENOPT to represent the affecting
> ENUM_LANGOPT(ExceptionHandling, ...?
I think it helps a bit, but the core problem is that we don't have
`BENIGN_CODEGENOPT`.
rjmccall wrote:
I think Eli is suggesting something like the rule for
[@available](https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available):
- If a builtin is unconditionally available, you can always use it without any
diagnostics.
- If a builtin is only available on specific
@@ -5354,6 +5368,22 @@ AMDGPURegisterBankInfo::getInstrMapping(const
MachineInstr &MI) const {
}
case Intrinsic::amdgcn_pops_exiting_wave_id:
return getDefaultMappingSOP(MI);
+case Intrinsic::amdgcn_tensor_load_to_lds_d2:
+case Intrinsic::amdgcn_tensor_st
@@ -15,18 +15,19 @@ void f(int n) {
return;
}
case 2:
+// FIXME: Should we emit an error {{fallthrough annotation does not
directly precede switch label}}?
yronglin wrote:
Hmm, this because I originally set the new diagnostic's severity to `Er
https://github.com/yronglin updated
https://github.com/llvm/llvm-project/pull/146224
>From 43e2dc670d7c9ed5e23b5d26dff1e273c84b5a53 Mon Sep 17 00:00:00 2001
From: yronglin
Date: Thu, 3 Jul 2025 02:15:22 +0800
Subject: [PATCH 1/2] [C23][Parser] Diagnostic for attribute declaration where
stateme
Author: Joshua Batista
Date: 2025-07-02T11:22:42-07:00
New Revision: 2ed7b22f0c9e91cf2565aafe1b0bdf387c5a366a
URL:
https://github.com/llvm/llvm-project/commit/2ed7b22f0c9e91cf2565aafe1b0bdf387c5a366a
DIFF:
https://github.com/llvm/llvm-project/commit/2ed7b22f0c9e91cf2565aafe1b0bdf387c5a366a.diff
https://github.com/bob80905 closed
https://github.com/llvm/llvm-project/pull/146448
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -35,7 +36,7 @@ void f(int n) {
[[fallthrough]];
}
case 8:
-[[fallthrough]]; // expected-error {{does not directly precede switch
label}}
+[[fallthrough]]; // FIXME: The error {{does not directly precede switch
label}} cannot reproduce in this translate
yronglin wrote:
Thanks for your review!
https://github.com/llvm/llvm-project/pull/146224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nilanjana87 updated
https://github.com/llvm/llvm-project/pull/145957
>From f0893f3b64661fc5a6ab39e7bdcc86a9142221a1 Mon Sep 17 00:00:00 2001
From: Nilanjana Basu
Date: Thu, 26 Jun 2025 11:54:14 -0700
Subject: [PATCH 1/3] [Clang][Driver][SamplePGO] Enable
-fsample-profile-use
https://github.com/anchuraj updated
https://github.com/llvm/llvm-project/pull/143441
>From 4816fb9bc0761d8761798300bb419db0072c9d04 Mon Sep 17 00:00:00 2001
From: Anchu Rajendran
Date: Wed, 4 Jun 2025 15:12:49 -0500
Subject: [PATCH 1/5] [flang][flang-driver] atomic control support
---
clang/i
https://github.com/tJener updated
https://github.com/llvm/llvm-project/pull/146761
>From 61e2f8e1d79563ad9bd9478e97ee1d597518f305 Mon Sep 17 00:00:00 2001
From: Eric Li
Date: Wed, 2 Jul 2025 14:46:45 -0400
Subject: [PATCH 1/2] [clang-format] Propagate `LeadingEmptyLinesAffected` when
joining l
mstorsjo wrote:
I'll go ahead and land this now to unbreak my builds.
https://github.com/llvm/llvm-project/pull/146643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Matt Arsenault
Date: 2025-07-02T23:21:47+03:00
New Revision: 7fc50e92a59c764eb6b1897fcdd506aacb92629c
URL:
https://github.com/llvm/llvm-project/commit/7fc50e92a59c764eb6b1897fcdd506aacb92629c
DIFF:
https://github.com/llvm/llvm-project/commit/7fc50e92a59c764eb6b1897fcdd506aacb92629c.diff
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/146643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Andres-Salamanca updated
https://github.com/llvm/llvm-project/pull/145971
>From f1f1d8c8db9d3c976e2baa50ac70bfa88b905434 Mon Sep 17 00:00:00 2001
From: Andres Salamanca
Date: Thu, 26 Jun 2025 15:51:02 -0500
Subject: [PATCH 1/7] Get Lvalue for bit-field
---
clang/include/cla
https://github.com/HighCommander4 updated
https://github.com/llvm/llvm-project/pull/143345
>From 2211dbf5b3167797ec2e5bf4db5adc13427d3e7b Mon Sep 17 00:00:00 2001
From: Nathan Ridge
Date: Mon, 9 Jun 2025 00:58:47 -0400
Subject: [PATCH] [clang][Sema] Unify getPrototypeLoc helpers in
SemaCodeCom
https://github.com/HighCommander4 ready_for_review
https://github.com/llvm/llvm-project/pull/143345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
Updated patch to add dedicated `HeuristicResolver` tests. And I did catch a bug
in the unified implementation in the process, so thank you for suggesting it:)
https://github.com/llvm/llvm-project/pull/143345
___
cfe-commits maili
rjmccall wrote:
So your users today are building for generic AMDGPU but using builtins that are
only available on a specific processor release? Presumably that code is
protected *somehow* and their programs are not simply crashing at runtime. Is
that something you'd be able to leverage at all,
https://github.com/xgupta created
https://github.com/llvm/llvm-project/pull/146772
Previously, implicit variable like `__begin3` used in range-based OpenMP
for-loops were not being properly privatized, leading to missing entries in
LocalDeclMap and crashes.
This patch ensures such implicit
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
@llvm/pr-subscribers-clang
Author: Shivam Gupta (xgupta)
Changes
Previously, implicit variable like `__begin3` used in range-based OpenMP
for-loops were not being properly privatized, leading to missing entries in
LocalDeclMap and cras
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-aarch64-quick`
running on `linaro-clang-aarch64-quick` while building `clang` at step 5 "ninja
check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/65/builds/18970
Here is the relevant pie
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-clang-aarch64-darwin`
running on `doug-worker-4` while building `clang` at step 6
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/190/builds/22666
Here is th
jhuber6 wrote:
> So your users today are building for generic AMDGPU but using builtins that
> are only available on a specific processor release? Presumably that code is
> protected _somehow_ and their programs are not simply crashing at runtime. Is
> that something you'd be able to leverage
benlangmuir wrote:
> Ok, so what do you suggest? Change all CODEGENOPT to BENIGN_CODEGENOPT before
> this PR lands?
This would be fine with me.
> (Or alternatively/equivalently go all the way and add an explicit benign
> effect on AST argument to CODEGENOPT, similar to what I linked above for
@@ -5354,6 +5368,22 @@ AMDGPURegisterBankInfo::getInstrMapping(const
MachineInstr &MI) const {
}
case Intrinsic::amdgcn_pops_exiting_wave_id:
return getDefaultMappingSOP(MI);
+case Intrinsic::amdgcn_tensor_load_to_lds_d2:
+case Intrinsic::amdgcn_tensor_st
seanm wrote:
Another interesting case:
```c++
static int testToWindowsExtendedPath()
{
#ifdef _WIN32
// lots of real, non constant work
return ret;
#else
return 0;
#endif
}
```
For some platforms this can be constexpr; for other platforms (Windows), it
cannot. It was transformed to `cons
rjmccall wrote:
Right, but the code still contains some kind of check to decide which version
of the library function to call. Maybe it's implicit by multiversioned
functions or something, but there's *something* in the source code, because if
the user just writes a kernel that does nothing bu
https://github.com/xgupta edited
https://github.com/llvm/llvm-project/pull/146772
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/144970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/144970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/yronglin updated
https://github.com/llvm/llvm-project/pull/146224
>From 43e2dc670d7c9ed5e23b5d26dff1e273c84b5a53 Mon Sep 17 00:00:00 2001
From: yronglin
Date: Thu, 3 Jul 2025 02:15:22 +0800
Subject: [PATCH] [C23][Parser] Diagnostic for attribute declaration where
statement i
Lukas =?utf-8?q?Döllerer?= ,
Lukas =?utf-8?q?Döllerer?= ,
Lukas =?utf-8?q?Döllerer?=
Message-ID:
In-Reply-To:
kripken wrote:
@Lukasdoe You may be interested in this Binaryen PR which adds passes for
branch hint debugging:
https://github.com/WebAssembly/binaryen/pull/7695
For example you cou
https://github.com/jkorous-apple edited
https://github.com/llvm/llvm-project/pull/145784
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Sirraide commented:
One more thing I thought of: What about C++ edge cases, e.g. both Clang and GCC
accept this... which doesn’t quite seem right to me
(https://godbolt.org/z/K58eEvG9P):
```c++
typeof(int){} x; // Probably parsed as typeof(int{})
```
https://github.com/llvm/
@@ -1000,8 +1001,10 @@ ExprResult Parser::ParseCastExpression(CastParseKind
ParseKind,
Token Replacement;
CastExpressionIdValidator Validator(
/*Next=*/Tok,
-/*AllowTypes=*/isTypeCast != TypeCastState::NotTypeCast,
-/*AllowNonTypes=*/isTypeCast
@@ -3580,6 +3580,37 @@ def int_amdgcn_fdiv_fast : DefaultAttrsIntrinsic<
[IntrNoMem, IntrSpeculatable]
>;
+class AMDGPUTensorLoadStore:
+ Intrinsic<
+[],
+[llvm_v4i32_ty, // D# group 0
+ llvm_v8i32_ty, // D# group 1
+ llvm_v4i32_ty, // D# group 2
+ llvm_
https://github.com/AmrDeveloper updated
https://github.com/llvm/llvm-project/pull/146755
>From ba1109f6c42bc902d9dc1f0613ce0b4959e8233e Mon Sep 17 00:00:00 2001
From: AmrDeveloper
Date: Wed, 2 Jul 2025 20:26:39 +0200
Subject: [PATCH] [CIR] Upstream SubstNonTypeTemplateParmExpr support for
Comp
@@ -621,6 +621,32 @@ Value *CodeGenFunction::EmitAMDGPUBuiltinExpr(unsigned
BuiltinID,
llvm::Function *F = CGM.getIntrinsic(IID, {LoadTy});
return Builder.CreateCall(F, {Addr});
}
+ case AMDGPU::BI__builtin_amdgcn_tensor_load_to_lds:
+ case AMDGPU::BI__builtin_amdg
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/3] [C23] Fix typeof handling in enum declarations
We have
sivadeilra wrote:
@arsenm, @efriedma-quic, @namazso , do you have more feedback on this PR? I'd
like to get this merged and move on to the next pieces for supporting Windows
hot-patching.
https://github.com/llvm/llvm-project/pull/144745
___
cfe-comm
@@ -4210,6 +4215,7 @@ class Parser : public CodeCompletionHandler {
/// \endverbatim
ExprResult ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr, bool isTypeCast,
+ bool ParenKnownToBeNon
@@ -2850,7 +2870,8 @@ Parser::ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr,
isFoldOperator(NextToken().getKind())) {
ExprType = ParenParseOption::FoldExpr;
return ParseFoldExpression(ExprResult(), T);
- } else if (isTypeCast) {
+
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 HEAD~1 HEAD --extensions h,cpp,c --
clang/include/clang/Parse/Parser.h clang/lib/Pars
seanm wrote:
> > This actually compiles, though with a `-Wduplicate-decl-specifier` warning.
>
> I failed to reproduce this...
I don't have a minimal repro case, I was building
[VTK](https://gitlab.kitware.com/vtk/vtk). It's pretty simple to build it
yourself if you're familiar with CMake. I
@@ -292,6 +292,21 @@ class ClangTidyDiagnosticConsumer : public
DiagnosticConsumer {
void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
const Diagnostic &Info) override;
+ void BeginSourceFile(const LangOptions &LangOpts,
vbv
@@ -5354,6 +5368,22 @@ AMDGPURegisterBankInfo::getInstrMapping(const
MachineInstr &MI) const {
}
case Intrinsic::amdgcn_pops_exiting_wave_id:
return getDefaultMappingSOP(MI);
+case Intrinsic::amdgcn_tensor_load_to_lds_d2:
+case Intrinsic::amdgcn_tensor_st
https://github.com/tgymnich edited
https://github.com/llvm/llvm-project/pull/146636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HazardyKnusperkeks wrote:
> > While it is less code, I find a bit harder to understand and the code gen
> > is far worse: https://gcc.godbolt.org/z/KzG4YnTh3
>
> `IsBlank` is misleading because of `std::isblank` whereas `Blanks.contains`
> is not, so the latter has better readability for me. A
@@ -2332,6 +2332,12 @@ void CodeGenFunction::EmitOMPPrivateLoopCounters(
for (const Expr *E : S.counters()) {
const auto *VD = cast(cast(E)->getDecl());
const auto *PrivateVD = cast(cast(*I)->getDecl());
+// Privatize original counter variable (e.g., __beginN, __e
@@ -0,0 +1,419 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --clang-args ['-fopenmp', '-std=c++20'] --function-signature
--include-generated-funcs --replace-value-regex
"__omp_offloading_[0-9a-z]+_[0-9a-z]+" "reduction_size[.].+[.]
lenary wrote:
What is your intention here around the LLVM 21 release cycle, knowing this is a
big feature and we are 1 week from the branch date
https://github.com/llvm/llvm-project/pull/146534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
AlexVlx wrote:
> So your users today are building for generic AMDGPU but using builtins that
> are only available on a specific processor release? Presumably that code is
> protected _somehow_ and their programs are not simply crashing at runtime. Is
> that something you'd be able to leverage
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/144970
>From b1f7402423af22b0ea8cdf0b3d3734bcce68a636 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 19 Jun 2025 18:29:49 -0700
Subject: [PATCH 1/2] [clang] Consistently handle consteval constructors for
https://github.com/jkorous-apple approved this pull request.
I want to check that my mental model of InSourceFile is correct but otherwise
LGTM.
https://github.com/llvm/llvm-project/pull/145784
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
@@ -292,6 +292,21 @@ class ClangTidyDiagnosticConsumer : public
DiagnosticConsumer {
void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
const Diagnostic &Info) override;
+ void BeginSourceFile(const LangOptions &LangOpts,
+
https://github.com/tJener created
https://github.com/llvm/llvm-project/pull/146761
Before this commit, when `LineJoiner` joins a line with affected leading
whitespace, it would drop the knowledge of this entirely. However, when the
`AffectedRangeManager` is computing the affected lines, the le
https://github.com/Sirraide edited
https://github.com/llvm/llvm-project/pull/146394
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Sirraide wrote:
> > ```c++
> > typeof(int){} x; // Probably parsed as typeof(int{})
> > ```
>
> Actually, I’m not sure what we think this is supposed to be; I haven’t
> checked.
Actually, that’s just a compound literal; I forgot we supported those in C++.
https://github.com/llvm/llvm-project/
https://github.com/dbartol updated
https://github.com/llvm/llvm-project/pull/145784
>From 0be65986e1e2adf973a032936afa9cf48841055b Mon Sep 17 00:00:00 2001
From: Dave Bartolomeo
Date: Wed, 25 Jun 2025 17:45:50 -0400
Subject: [PATCH 1/3] EndSourceFile() for preprocessor before diagnostic client
https://github.com/Bigcheese approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/146766
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Martin Storsjö
Date: 2025-07-02T23:58:22+03:00
New Revision: 551d6ddaa3810749ecae33f65759870b78b9a86a
URL:
https://github.com/llvm/llvm-project/commit/551d6ddaa3810749ecae33f65759870b78b9a86a
DIFF:
https://github.com/llvm/llvm-project/commit/551d6ddaa3810749ecae33f65759870b78b9a86a.diff
mstorsjo wrote:
I pushed a fix to add `REQUIRES: x86-registered-target` in
551d6ddaa3810749ecae33f65759870b78b9a86a.
https://github.com/llvm/llvm-project/pull/146643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
efriedma-quic wrote:
> we only know the concrete target when we are finalising, which happens at a
> completely different time-point, on possibly a different machine;
This is precisely why we want the frontend diagnostic: if we diagnose the bad
cases in the frontend, later stages are guarantee
@@ -9125,9 +9126,25 @@ bool
LValueExprEvaluator::VisitCompoundLiteralExpr(const CompoundLiteralExpr *E) {
assert((!Info.getLangOpts().CPlusPlus || E->isFileScope()) &&
"lvalue compound literal in c++?");
- // Defer visiting the literal until the lvalue-to-rvalue con
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/137163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/cristianassaiante updated
https://github.com/llvm/llvm-project/pull/145059
>From ab6063493744ef5a1ee92fd249bf8d86b7299fad Mon Sep 17 00:00:00 2001
From: Cristian Assaiante
Date: Fri, 20 Jun 2025 16:56:23 +0200
Subject: [PATCH 1/7] Adding -opt-disable and a test for it
---
c
Author: KAWASHIMA Takahiro
Date: 2025-07-03T14:38:45+09:00
New Revision: d67013a2b44295e7558b6678f07c7f3a7ef9601c
URL:
https://github.com/llvm/llvm-project/commit/d67013a2b44295e7558b6678f07c7f3a7ef9601c
DIFF:
https://github.com/llvm/llvm-project/commit/d67013a2b44295e7558b6678f07c7f3a7ef9601c.
https://github.com/kawashima-fj closed
https://github.com/llvm/llvm-project/pull/146453
___
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,flang` at step 3 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/123/builds/22559
Here is the relevant piece of the build
https://github.com/yronglin deleted
https://github.com/llvm/llvm-project/pull/146394
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -651,8 +651,19 @@ void AVR::Linker::ConstructJob(Compilation &C, const
JobAction &JA,
// This is almost always required because otherwise avr-ld
// will assume 'avr2' and warn about the program being larger
// than the bare minimum supports.
- if (Linker.find("avr-ld
Author: Jim Lin
Date: 2025-07-03T09:06:01+08:00
New Revision: 44bed1af0fb641ce169262ab9fdb15ad76fe72a1
URL:
https://github.com/llvm/llvm-project/commit/44bed1af0fb641ce169262ab9fdb15ad76fe72a1
DIFF:
https://github.com/llvm/llvm-project/commit/44bed1af0fb641ce169262ab9fdb15ad76fe72a1.diff
LOG:
https://github.com/naveen-seth edited
https://github.com/llvm/llvm-project/pull/146645
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/kazutakahirata created
https://github.com/llvm/llvm-project/pull/146811
Note that LLVM Coding Standards discourages std::for_each and
llvm::for_each unless the callable object already exists.
>From b8285abad935fd37196719b7f3b81cf0af0767b5 Mon Sep 17 00:00:00 2001
From: Kazu
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Kazu Hirata (kazutakahirata)
Changes
The only use of BW is to initialize BitWidth. This patch renames BW
to BitWdith while removing the cast statement.
---
Full diff: https://github.com/llvm/llvm-project/pull/146808.diff
1 Files Affect
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Kazu Hirata (kazutakahirata)
Changes
Note that LLVM Coding Standards discourages std::for_each and
llvm::for_each unless the callable object already exists.
---
Full diff: https://github.com/llvm/llvm-project/pull/146811.diff
5 Files Af
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Kazu Hirata (kazutakahirata)
Changes
Note that LLVM Coding Standards discourages std::for_each and
llvm::for_each unless the callable object already exists.
---
Full diff: https://github.com/llvm/llvm-project/pull/146811.diff
5 F
llvmbot wrote:
@llvm/pr-subscribers-clangir
Author: Kazu Hirata (kazutakahirata)
Changes
Note that LLVM Coding Standards discourages std::for_each and
llvm::for_each unless the callable object already exists.
---
Full diff: https://github.com/llvm/llvm-project/pull/146811.diff
5 Files
LegalizeAdulthood wrote:
My expectation would be that if I specify a header filter I'm not going to use
weird paths like a/b/../foo.h, but just a/foo.h because that is where foo.h
lives.
https://github.com/llvm/llvm-project/pull/143520
___
cfe-commit
https://github.com/AlexVlx created
https://github.com/llvm/llvm-project/pull/146813
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
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Alex Voicu (AlexVlx)
Changes
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
https://github.com/kazutakahirata created
https://github.com/llvm/llvm-project/pull/146808
The only use of BW is to initialize BitWidth. This patch renames BW
to BitWdith while removing the cast statement.
>From 27461a27118922c384e6bd97b9d0a9d6848960dc Mon Sep 17 00:00:00 2001
From: Kazu Hira
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 HEAD~1 HEAD --extensions cpp --
llvm/lib/Transforms/HipStdPar/HipStdPar.cpp
`
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/146813
>From d98e3785a144ada9881cdbe24c86f273850eca20 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Thu, 3 Jul 2025 02:02:04 +0100
Subject: [PATCH 1/3] Add support for true globals.
---
llvm/lib/Transforms/HipStdPa
MythreyaK wrote:
Seems to be working as expected. I'll add a test case for this as well.
https://github.com/llvm/
ChuanqiXu9 wrote:
> I'm not suggesting to treat CodeGenOptions as incompatible by default. For
> now I'm just trying to remove the duplication and improve the
> infrastructure.CodeGenOptions are still benign by default, and can only be
> marked as compatible, which doesn't have any impact on e
https://github.com/mtrofin edited
https://github.com/llvm/llvm-project/pull/145059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: David Green
Date: 2025-07-03T07:41:13+01:00
New Revision: 1f8f477bd03869a9b5b2e7ff0c24c74397aba486
URL:
https://github.com/llvm/llvm-project/commit/1f8f477bd03869a9b5b2e7ff0c24c74397aba486
DIFF:
https://github.com/llvm/llvm-project/commit/1f8f477bd03869a9b5b2e7ff0c24c74397aba486.diff
L
https://github.com/steakhal approved this pull request.
https://github.com/llvm/llvm-project/pull/145066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ravurvi20 wrote:
@alexey-bataev I have updated Release notes. Since it's just a deprecation it
is not there in support file.
https://github.com/llvm/llvm-project/pull/145854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/lhames created
https://github.com/llvm/llvm-project/pull/146819
This removes ThreadSafeContext::Lock, ThreadSafeContext::getLock, and
ThreadSafeContext::getContext, and replaces them with a
ThreadSafeContext::withContextDo method (and const override).
The new method can be
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Lang Hames (lhames)
Changes
This removes ThreadSafeContext::Lock, ThreadSafeContext::getLock, and
ThreadSafeContext::getContext, and replaces them with a
ThreadSafeContext::withContextDo method (and const override).
The new method can be
https://github.com/ravurvi20 updated
https://github.com/llvm/llvm-project/pull/145854
>From 15935b92827c26a7697084201980f23305f3b348 Mon Sep 17 00:00:00 2001
From: urvi-rav
Date: Thu, 26 Jun 2025 03:19:50 -0500
Subject: [PATCH 1/2] deprecate delimited form of 'declare target'
---
.../clang/Ba
jansvoboda11 wrote:
> > I'm not suggesting to treat CodeGenOptions as incompatible by default.
>
> I think the naming might be adding to the confusion here. We now have
> `COMPATIBLE_..._CODEGENOPT`, but it's the "compatible" ones that are
> impacting the AST and not being cleared in `resetNon
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Amr Hesham (AmrDeveloper)
Changes
Upstream SubstNonTypeTemplateParmExpr support for ComplexType
https://github.com/llvm/llvm-project/issues/141365
---
Full diff: https://github.com/llvm/llvm-project/pull/146755.diff
2 Files Affected:
-
1 - 100 of 443 matches
Mail list logo
