llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (llvmbot)
Changes
Backport 6dbdb84
Requested by: @philnik777
---
Full diff: https://github.com/llvm/llvm-project/pull/108147.diff
2 Files Affected:
- (modified) clang/lib/Sema/SemaExprCXX.cpp (+2-1)
- (modified) clang/test/SemaCX
llvmbot wrote:
@DimitryAndric What do you think about merging this PR to the release branch?
https://github.com/llvm/llvm-project/pull/108147
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
https://github.com/llvmbot milestoned
https://github.com/llvm/llvm-project/pull/108147
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/108147
Backport 6dbdb84
Requested by: @philnik777
>From 94ceefd28c894b52a760a8127c414e2f1b7d3165 Mon Sep 17 00:00:00 2001
From: Nikolas Klauser
Date: Wed, 11 Sep 2024 08:47:24 +0200
Subject: [PATCH] [Clang] Fix crash
Author: ChiaHungDuan
Date: 2024-09-10T18:55:12-07:00
New Revision: 00b2d78142495605c0c01f9228620a96b5b949d3
URL:
https://github.com/llvm/llvm-project/commit/00b2d78142495605c0c01f9228620a96b5b949d3
DIFF:
https://github.com/llvm/llvm-project/commit/00b2d78142495605c0c01f9228620a96b5b949d3.diff
Author: Vitaly Buka
Date: 2024-09-10T17:46:05-07:00
New Revision: eceac8e53357b8d91f047f7a5fe954d987e05e53
URL:
https://github.com/llvm/llvm-project/commit/eceac8e53357b8d91f047f7a5fe954d987e05e53
DIFF:
https://github.com/llvm/llvm-project/commit/eceac8e53357b8d91f047f7a5fe954d987e05e53.diff
L
Author: Florian Mayer
Date: 2024-09-10T16:12:46-07:00
New Revision: a7d156a7021ba9d72648a1c68668deb08a75a7ab
URL:
https://github.com/llvm/llvm-project/commit/a7d156a7021ba9d72648a1c68668deb08a75a7ab
DIFF:
https://github.com/llvm/llvm-project/commit/a7d156a7021ba9d72648a1c68668deb08a75a7ab.diff
Author: Henrik G. Olsson
Date: 2024-09-10T15:13:50-07:00
New Revision: 7ff656c48487213e52d9035f28877482d2cd86e2
URL:
https://github.com/llvm/llvm-project/commit/7ff656c48487213e52d9035f28877482d2cd86e2
DIFF:
https://github.com/llvm/llvm-project/commit/7ff656c48487213e52d9035f28877482d2cd86e2.di
Author: Daniel Thornburgh
Date: 2024-09-10T14:07:49-07:00
New Revision: 72cfc74a7c5cea78b174b668f6accaa955742a51
URL:
https://github.com/llvm/llvm-project/commit/72cfc74a7c5cea78b174b668f6accaa955742a51
DIFF:
https://github.com/llvm/llvm-project/commit/72cfc74a7c5cea78b174b668f6accaa955742a51.d
https://github.com/aaupov edited
https://github.com/llvm/llvm-project/pull/107970
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/aaupov updated
https://github.com/llvm/llvm-project/pull/107137
>From 50c021b09950cf7d6a8f25b1ac0dec246f2325f5 Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Tue, 3 Sep 2024 11:38:04 -0700
Subject: [PATCH 1/3] update pseudoprobe-decoding-inline.test
Created using spr 1.3.4
https://github.com/aaupov updated
https://github.com/llvm/llvm-project/pull/99891
>From 36197b175681d07b4704e576fb008cec3cc1e05e Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Wed, 28 Aug 2024 21:10:25 +0200
Subject: [PATCH 1/2] Reworked block probe matching
Use new probe ifaces
Get all func
https://github.com/aaupov updated
https://github.com/llvm/llvm-project/pull/99891
>From 36197b175681d07b4704e576fb008cec3cc1e05e Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Wed, 28 Aug 2024 21:10:25 +0200
Subject: [PATCH 1/2] Reworked block probe matching
Use new probe ifaces
Get all func
Author: Vitaly Buka
Date: 2024-09-10T09:52:01-07:00
New Revision: d92f149c714225128f2fcc4eac7cc8d5febfb0bf
URL:
https://github.com/llvm/llvm-project/commit/d92f149c714225128f2fcc4eac7cc8d5febfb0bf
DIFF:
https://github.com/llvm/llvm-project/commit/d92f149c714225128f2fcc4eac7cc8d5febfb0bf.diff
L
Author: Vitaly Buka
Date: 2024-09-10T09:49:58-07:00
New Revision: 55c2b8c9cb9ebf9308746226abb7110431367015
URL:
https://github.com/llvm/llvm-project/commit/55c2b8c9cb9ebf9308746226abb7110431367015
DIFF:
https://github.com/llvm/llvm-project/commit/55c2b8c9cb9ebf9308746226abb7110431367015.diff
L
https://github.com/aaupov edited
https://github.com/llvm/llvm-project/pull/107137
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
R-Goc wrote:
Indeed depending on specific optimizations sometimes there is a crash and
sometimes there isn't. There are cases where clang 17 won't compile but clang
18 will, or where clang 20 will compile but clang 18 won't. Or none will
compile at all.
https://github.com/llvm/llvm-project/p
https://github.com/jrtc27 approved this pull request.
This should be low risk. If the condition holds, it would previously
dereference an invalid iterator, and either crash immediately thanks to
assertions or use whatever junk's in memory. Now it will treat it the same as
if there's an immedia
huaatian wrote:
> this was merged - not sure why github shows it as closed instead.
Okay, I see that this PR has already been merged. Thank you！
https://github.com/llvm/llvm-project/pull/107338
___
llvm-branch-commits mailing list
llvm-branch-commits@
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/107659
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/aaupov edited
https://github.com/llvm/llvm-project/pull/107137
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
heiher wrote:
It seems that the patch created by the bot is incomplete. I'm not sure if it
will automatically update after #107945 is merged. If not, it may be necessary
to re-trigger the cherry-pick.
https://github.com/llvm/llvm-project/pull/107990
tru wrote:
this was merged - not sure why github shows it as closed instead.
https://github.com/llvm/llvm-project/pull/107338
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-b
github-actions[bot] wrote:
@owenca (or anyone else). If you would like to add a note about this fix in the
release notes (completely optional). Please reply to this comment with a one or
two sentence description of the fix. When you are done, please add the
release:note label to this PR.
ht
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/107531
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
Author: Owen Pan
Date: 2024-09-10T16:48:49+02:00
New Revision: 327ca6c02f0dbf13dd6f039d30d320a7ba1456b8
URL:
https://github.com/llvm/llvm-project/commit/327ca6c02f0dbf13dd6f039d30d320a7ba1456b8
DIFF:
https://github.com/llvm/llvm-project/commit/327ca6c02f0dbf13dd6f039d30d320a7ba1456b8.diff
LOG:
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/107531
>From 327ca6c02f0dbf13dd6f039d30d320a7ba1456b8 Mon Sep 17 00:00:00 2001
From: Owen Pan
Date: Thu, 5 Sep 2024 23:59:11 -0700
Subject: [PATCH] [clang-format] Correctly annotate braces in macro definition
(#107352)
Th
tru wrote:
I'll take it for 19 if we can get a reviewer to approve it.
https://github.com/llvm/llvm-project/pull/107466
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/107338
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/107338
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
Author: Hua Tian
Date: 2024-09-10T16:46:49+02:00
New Revision: 2651d09ec9c4d87d09ae72d8bf42fab566fb02d0
URL:
https://github.com/llvm/llvm-project/commit/2651d09ec9c4d87d09ae72d8bf42fab566fb02d0
DIFF:
https://github.com/llvm/llvm-project/commit/2651d09ec9c4d87d09ae72d8bf42fab566fb02d0.diff
LOG:
dtcxzyw wrote:
> In that case - does it make sense to wait for that change before merging this?
See https://github.com/llvm/llvm-project/pull/107990.
https://github.com/llvm/llvm-project/pull/107945
___
llvm-branch-commits mailing list
llvm-branch-co
wangpc-pp wrote:
> This is perhaps more of a comment for #107824 than for this one, but I think
> we'd benefit from some level of test coverage for OptForSize to demonstrate
> that we stick with the libcall in cases where expanding increases code size.
Thanks! Done!
https://github.com/llvm/ll
https://github.com/wangpc-pp updated
https://github.com/llvm/llvm-project/pull/107548
>From f21cfcfc90330ee3856746b6315a81a00313b0e0 Mon Sep 17 00:00:00 2001
From: Wang Pengcheng
Date: Fri, 6 Sep 2024 17:20:51 +0800
Subject: [PATCH 1/4] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=
https://github.com/wangpc-pp updated
https://github.com/llvm/llvm-project/pull/107548
>From f21cfcfc90330ee3856746b6315a81a00313b0e0 Mon Sep 17 00:00:00 2001
From: Wang Pengcheng
Date: Fri, 6 Sep 2024 17:20:51 +0800
Subject: [PATCH 1/4] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=
tblah wrote:
> I was wondering if there is some op that is like `scf.execute_region` but
> already used in flang.
Not that I am aware of.
I think adding `scf.execute_region` might be the easiest way to support this.
The alternative would be to go back and convert the if statement into CFG
be
ivanradanov wrote:
Ah yes, I meant `scf.execute_region`. But when I tried creating that and it was
not registered so I thought it was a deliberate decision to not pull in the scf
dialect so I opted not to go for that lowering. I was wondering if there is
some op that is like `scf.execute_regio
marekolsak wrote:
ROCm should consider it a critical issue because it fixes int64 multiplication
by a constant.
It's less critical for other LLVM users like Mesa.
https://github.com/llvm/llvm-project/pull/106977
___
llvm-branch-commits mailing list
l
AaronBallman wrote:
> This change has already been reverted on main because it breaks clang
> bootstrap and causes assertion failures. This was already known at the time
> it was accepted as "low risk" here. Please exercise at least a minimum amount
> of due diligence before approving backport
https://github.com/nikic requested changes to this pull request.
This change has already been reverted on main because it breaks clang bootstrap
and causes assertion failures. This was already known at the time it was
accepted as "low risk" here. Please exercise at least a minimum amount of due
https://github.com/AaronBallman approved this pull request.
LGTM -- I think this is important for 19.x given the behavior it's correcting.
https://github.com/llvm/llvm-project/pull/107886
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.l
tblah wrote:
> @kiranchandramohan @tblah @skatrak I have a question to people more familiar
> with Fortran and the Flang pipeline - is it possible that we would have CFG
> (multiple blocks) in the IR generated in the `omp.workshare` region at this
> point in the pipeline (immediately after low
R-Goc wrote:
This fixes compilation with clang-cl using /EHa. Some libraries (found this
trying to compile openCV, but it is not isolated, and other people also
reported this) use asynchronous exception handling. Currently the compiler will
either freeze or segfault and will hit an assert if a
asb wrote:
This is perhaps more of a comment for #107824 than for this one, but I think
we'd benefit from some level of test coverage for OptForSize to demonstrate
that we stick with the libcall in cases where expanding increases code size.
https://github.com/llvm/llvm-project/pull/107548
__
tru wrote:
Thanks for your detailed answer! I think this can go in 19.1.0
https://github.com/llvm/llvm-project/pull/106952
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bran
OCHyams wrote:
@tru just a note, I got confused about the release timelines and I mistakenly
said this wasn't a regression (it is a regression from LLVM 18 as it is in in
LLVM 19 that we turned on the feature that triggers the issue this patch
fixes). I've updated my initial reply.
https://gi
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/107990
Backport 0f47e3aebdd2a4a938468a272ea4224552dbf176
Requested by: @heiher
>From e27281dd8fdf476505f6faaa9f9c2eda8d023cbb Mon Sep 17 00:00:00 2001
From: hev
Date: Tue, 10 Sep 2024 16:52:21 +0800
Subject: [PATCH]
https://github.com/llvmbot milestoned
https://github.com/llvm/llvm-project/pull/107990
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
llvmbot wrote:
@llvm/pr-subscribers-backend-loongarch
Author: None (llvmbot)
Changes
Backport 0f47e3aebdd2a4a938468a272ea4224552dbf176
Requested by: @heiher
---
Full diff: https://github.com/llvm/llvm-project/pull/107990.diff
1 Files Affected:
- (modified) llvm/lib/Target/LoongArch/Lo
https://github.com/OCHyams edited
https://github.com/llvm/llvm-project/pull/106952
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
llvmbot wrote:
@SixWeining What do you think about merging this PR to the release branch?
https://github.com/llvm/llvm-project/pull/107990
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
SixWeining wrote:
> @heiher @SixWeining Do you guys have a plan to backport #107971?
Yes, I think #107971 should also be backported to 19.x.
https://github.com/llvm/llvm-project/pull/107945
___
llvm-branch-commits mailing list
llvm-branch-commits@list
dtcxzyw wrote:
> > It introduces a performance regression. I have filed an issue to track
> > this: #107946.
>
> Is this something you also expect to backport in this case? do we want to
> wait for this fix to be available before we merge? In that case - would it be
> better to wait and merge
sdesmalen-arm wrote:
> Hi, since we are wrapping up LLVM 19.1.0 we are very strict with the fixes we
> pick at this point. Can you please respond to the following questions to help
> me understand if this has to be included in the final release or not.
Sure, I appreciate your diligence!
> Is
owenca wrote:
> Hi, since we are wrapping up LLVM 19.1.0 we are very strict with the fixes we
> pick at this point. Can you please respond to the following questions to help
> me understand if this has to be included in the final release or not.
>
> Is this PR a fix for a regression or a criti
Author: Matthias Springer
Date: 2024-09-10T10:23:27+02:00
New Revision: 13fd7a28cd7bd0e06b61c3f56c563e28c6104c7e
URL:
https://github.com/llvm/llvm-project/commit/13fd7a28cd7bd0e06b61c3f56c563e28c6104c7e
DIFF:
https://github.com/llvm/llvm-project/commit/13fd7a28cd7bd0e06b61c3f56c563e28c6104c7e.d
grypp wrote:
It looks good the in general. Let's wait the main PR to land, and then you can
land this one as well.
https://github.com/llvm/llvm-project/pull/107659
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.l
@@ -209,7 +209,12 @@ struct GPULaneIdOpToNVVM :
ConvertOpToLLVMPattern {
ConversionPatternRewriter &rewriter) const override {
auto loc = op->getLoc();
MLIRContext *context = rewriter.getContext();
-Value newOp = rewriter.create(loc, rewriter.getI
cor3ntin wrote:
Yes, this is a 19 regression https://github.com/llvm/llvm-project/issues/104268
I think it's fairly low risk to accept - but if we don't clang will reject
fairly common c++ code (lookup of operator-> in template function)
https://github.com/llvm/llvm-project/pull/107886
__
cor3ntin wrote:
@tru thanks for noticing, fixed!
https://github.com/llvm/llvm-project/pull/107214
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/cor3ntin updated
https://github.com/llvm/llvm-project/pull/107214
>From 75af619d96d874d67dc142e9c09ffc2a61737d96 Mon Sep 17 00:00:00 2001
From: cor3ntin
Date: Tue, 3 Sep 2024 20:36:15 +0200
Subject: [PATCH] [Clang] Fix handling of placeholder variables name in init
captures
NagyDonat wrote:
> Is this PR a fix for a regression or a critical issue?
`#embed` support is a new feature introduced in Clang 19, so this is not a
regression. However, without this PR Clang Static Analyzer (and clang-tidy
which calls Clang Static Analyzer) will crash on any project that cont
https://github.com/OCHyams edited
https://github.com/llvm/llvm-project/pull/106952
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -975,8 +975,16 @@ void BasicBlock::spliceDebugInfoImpl(BasicBlock::iterator
Dest, BasicBlock *Src,
if (ReadFromTail && Src->getMarker(Last)) {
DbgMarker *FromLast = Src->getMarker(Last);
if (LastIsEnd) {
- Dest->adoptDbgRecords(Src, Last, true);
- // ado
@@ -975,8 +975,16 @@ void BasicBlock::spliceDebugInfoImpl(BasicBlock::iterator
Dest, BasicBlock *Src,
if (ReadFromTail && Src->getMarker(Last)) {
DbgMarker *FromLast = Src->getMarker(Last);
if (LastIsEnd) {
- Dest->adoptDbgRecords(Src, Last, true);
- // ado
@@ -975,8 +975,16 @@ void BasicBlock::spliceDebugInfoImpl(BasicBlock::iterator
Dest, BasicBlock *Src,
if (ReadFromTail && Src->getMarker(Last)) {
DbgMarker *FromLast = Src->getMarker(Last);
if (LastIsEnd) {
- Dest->adoptDbgRecords(Src, Last, true);
- // ado
@@ -975,8 +975,16 @@ void BasicBlock::spliceDebugInfoImpl(BasicBlock::iterator
Dest, BasicBlock *Src,
if (ReadFromTail && Src->getMarker(Last)) {
DbgMarker *FromLast = Src->getMarker(Last);
if (LastIsEnd) {
- Dest->adoptDbgRecords(Src, Last, true);
- // ado
https://github.com/OCHyams commented:
Hi @tru,
> Is this PR a fix for a regression or a critical issue?
Neither
> What is the risk of accepting this into the release branch?
If I've made a mistake in the patch we could get incorrect debug-info in an
edge case. I've added some comments inline
ivanradanov wrote:
@kiranchandramohan @tblah @skatrak I have a question to people more familiar
with Fortran and the entire Flang pipeline - is it possible that we would have
CFG (multiple blocks) in the IR generated in the workshare statement at this
point in the pipeline (immediately after l
jayfoad wrote:
> > Is this PR a fix for a regression or a critical issue?
>
> No, I believe it has been broken for about 3 years (since
> [d7e03df](https://github.com/llvm/llvm-project/commit/d7e03df719464354b20a845b7853be57da863924))
> but it was only reported to me recently.
>
> I guess thi
jayfoad wrote:
> Is this PR a fix for a regression or a critical issue?
No, I believe it has been broken for about 3 years (since
d7e03df719464354b20a845b7853be57da863924) but it was only reported to me
recently.
I guess this means it is not appropriate for 19.1.0.
https://github.com/llvm/ll
tru wrote:
> It introduces a performance regression. I have filed an issue to track this:
> https://github.com/llvm/llvm-project/issues/107946.
Is this something you also expect to backport in this case? do we want to wait
for this fix to be available before we merge? In that case - would it b
rorth wrote:
> Hi, since we are wrapping up LLVM 19.1.0 we are very strict with the fixes we
> pick at this point. Can you please respond to the following questions to help
> me understand if this has to be included in the final release or not.
I guess it's best for @petrhosek to make the fina
dtcxzyw wrote:
> Hi, since we are wrapping up LLVM 19.1.0 we are very strict with the fixes we
> pick at this point. Can you please respond to the following questions to help
> me understand if this has to be included in the final release or not.
>
> Is this PR a fix for a regression or a crit
DianQK wrote:
> Is this PR a fix for a regression or a critical issue?
Yes. It fixes a regression in f6e01b9ece1e73f6eda6e1dbff3aa72e917f4007.
> What is the risk of accepting this into the release branch?
This won't introduce a new regression for this.
> What is the risk of NOT accepting this
75 matches
Mail list logo
