https://github.com/mcbarton updated
https://github.com/llvm/llvm-project/pull/146786
>From d528fe6474cf233ed024a1479ede12545e59b4c2 Mon Sep 17 00:00:00 2001
From: mcbarton <150042563+mcbar...@users.noreply.github.com>
Date: Wed, 2 Jul 2025 22:17:30 +0100
Subject: [PATCH] Add __attribute__((visib
@@ -2122,8 +2122,21 @@ SVal
RegionStoreManager::getBindingForField(RegionBindingsConstRef B,
if (const std::optional &V = B.getDirectBinding(R))
return *V;
- // If the containing record was initialized, try to get its constant value.
+ // UnnamedBitField is always Und
github-actions[bot] wrote:
@Tedlion 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 build,
https://github.com/steakhal closed
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
Author: Tedlion
Date: 2025-07-03T08:42:10+02:00
New Revision: 6504c96b1d865c69888a2a17aa8fe479987c00f0
URL:
https://github.com/llvm/llvm-project/commit/6504c96b1d865c69888a2a17aa8fe479987c00f0
DIFF:
https://github.com/llvm/llvm-project/commit/6504c96b1d865c69888a2a17aa8fe479987c00f0.diff
LOG:
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
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/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
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
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/3] deprecate delimited form of 'declare target'
---
.../clang/Ba
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/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
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/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
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/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
https://github.com/snehasish approved this pull request.
LGTM, please give downstream users ~1w to add the opt out flag to build configs
before landing this.
CC @llvm/pr-subscribers-pgo for visibility.
https://github.com/llvm/llvm-project/pull/146795
__
https://github.com/brevzin updated
https://github.com/llvm/llvm-project/pull/146815
>From 40290a957b6f349a9b670193c8bc699d8eb7d373 Mon Sep 17 00:00:00 2001
From: Barry Revzin
Date: Fri, 27 Jun 2025 17:29:45 -0500
Subject: [PATCH 1/2] [P3074] Implementing part of trivial unions
---
clang/lib/A
brevzin wrote:
Oh. Actually I didn't quite properly implement the destructor rule, since that
changed since I originally implemented this. The new rule is that the default
destructor for a union `X` [is deleted
if](http://eel.is/c++draft/class.dtor#7.2)
* default constructing an `X` either fa
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Barry Revzin (brevzin)
Changes
This commit makes union construction/destruction trivial by default, but does
not add the lifetime aspects of the paper — am holding out until P3726R0 will
be discussed which alters that approach somewhat ba
https://github.com/brevzin edited
https://github.com/llvm/llvm-project/pull/146815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/brevzin created
https://github.com/llvm/llvm-project/pull/146815
This commit makes union construction/destruction trivial by default, but does
not add the lifetime aspects of the paper — am holding out until P3726R0 will
be discussed which alters that approach somewhat based
https://github.com/MaskRay commented:
Driver change looks reasonable if samplepgo maintainers decide to proceed.
https://github.com/llvm/llvm-project/pull/146795
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
wenju-he wrote:
> I am seeing unresolved CLC functions in `nvptx--.bc` and `nvptx64--.bc`. I
> think it's because we're now building things like `get_num_groups` for
> `nvptx`/`nvptx64`, whereas previously they were not being built for those
> targets. We're also not building `__clc_get_num_gr
https://github.com/wenju-he edited
https://github.com/llvm/llvm-project/pull/144333
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
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
MythreyaK wrote:
Seems to be working as expected. I'll add a test case for this as well.
https://github.com/llvm/
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
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
`
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/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
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
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
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
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
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
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:
@@ -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
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/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
@@ -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/mcbarton updated
https://github.com/llvm/llvm-project/pull/146786
>From ef5f9e92dca662c7de4dd6cc2ef8c02ec3aaad60 Mon Sep 17 00:00:00 2001
From: mcbarton <150042563+mcbar...@users.noreply.github.com>
Date: Wed, 2 Jul 2025 22:17:30 +0100
Subject: [PATCH 1/3] Add __attribute__((v
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `sanitizer-x86_64-linux`
running on `sanitizer-buildbot2` while building `.github,clang` at step 2
"annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/66/builds/16152
Here is the relevant piec
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `fuchsia-x86_64-linux`
running on `fuchsia-debian-64-us-central1-a-1` while building `clang,llvm` at
step 4 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/11/builds/18644
Here is the rele
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
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
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
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
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
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
@@ -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[.].+[.]
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
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
@@ -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
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
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
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
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
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
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
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,
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
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 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
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/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
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
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
seanm wrote:
I've tried another project: [opencv](https://github.com/opencv/opencv) and the
result also fails to compile.
One case I think is because two variables are declared together. i.e.:
```
int foo, bar;
```
instead of:
```
int foo;
int bar;
```
Concretely:
```c++
const char * c
tigbr wrote:
@steakhal As we have discussed in person, unfortunately, I could not reproduce
the big improvements for the three problematic translation units.
On the bright side, however, I was able to reproduce an average improvement
between 0.5% and 1%. This is in the ballpark that I have mea
https://github.com/shafik approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/146604
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
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/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
@@ -988,6 +988,8 @@ class LineJoiner {
assert(!B.First->Previous);
if (B.Affected)
A.Affected = true;
+else if (B.LeadingEmptyLinesAffected && A.Last->Children.empty())
tJener wrote:
Done.
https://github.com/llvm/llvm-project/pull/146761
___
@@ -1,4 +1,19 @@
-/// Test if profi flat is enabled in frontend as user-facing feature.
-// RUN: %clang --target=x86_64 -c -fsample-profile-use-profi
-fprofile-sample-use=/dev/null -### %s 2>&1 | FileCheck %s
+/// Ensure that profi flag is enabled by default in frontend for Sampl
AlexVlx 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
@@ -127,6 +127,7 @@ TEST_F(ParseHLSLRootSignatureTest, ValidParseEmptyTest) {
}
TEST_F(ParseHLSLRootSignatureTest, ValidParseDTClausesTest) {
+ using FlagT = llvm::dxbc::DescriptorRangeFlags;
bogner wrote:
I wouldn't rename this to `FlagT`, but instead just
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
@@ -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
@@ -292,6 +292,21 @@ class ClangTidyDiagnosticConsumer : public
DiagnosticConsumer {
void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
const Diagnostic &Info) override;
+ void BeginSourceFile(const LangOptions &LangOpts,
vbv
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
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
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
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/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
@@ -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/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
llvmbot wrote:
@llvm/pr-subscribers-clang-format
Author: Eric Li (tJener)
Changes
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, t
1 - 100 of 443 matches
Mail list logo
