Author: Aaron Ballman
Date: 2025-05-01T07:31:48-04:00
New Revision: bc9aa0f4c4c6ad9dd6207097478f4e461a8fe5cb
URL:
https://github.com/llvm/llvm-project/commit/bc9aa0f4c4c6ad9dd6207097478f4e461a8fe5cb
DIFF:
https://github.com/llvm/llvm-project/commit/bc9aa0f4c4c6ad9dd6207097478f4e461a8fe5cb.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/137967
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Mohamed Emad
Date: 2025-05-01T07:21:50-04:00
New Revision: 212f2456fcde822fad37bfa4e69ced1a51a4c19d
URL:
https://github.com/llvm/llvm-project/commit/212f2456fcde822fad37bfa4e69ced1a51a4c19d
DIFF:
https://github.com/llvm/llvm-project/commit/212f2456fcde822fad37bfa4e69ced1a51a4c19d.diff
chandraghale wrote:
Refactored code to look up the expression and handle UDR, emitting it as is.
updated the lit test.
https://github.com/llvm/llvm-project/pull/134709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/132991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mati865 updated
https://github.com/llvm/llvm-project/pull/134494
From b7a5fab29b810f72f2ffa65fb0945abd302c2411 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mateusz=20Miku=C5=82a?=
Date: Sat, 5 Apr 2025 13:18:35 +0200
Subject: [PATCH 1/4] [LLVM][Cygwin] Fix Signals compatibility w
Author: Aaron Ballman
Date: 2025-05-01T07:25:28-04:00
New Revision: 75d1cceb948666af9b2cb26fc3933d4176a2806d
URL:
https://github.com/llvm/llvm-project/commit/75d1cceb948666af9b2cb26fc3933d4176a2806d
DIFF:
https://github.com/llvm/llvm-project/commit/75d1cceb948666af9b2cb26fc3933d4176a2806d.diff
https://github.com/mati865 converted_to_draft
https://github.com/llvm/llvm-project/pull/134494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -23,4 +23,20 @@
#define _CLC_DEF __attribute__((always_inline))
#endif
+#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 ||
\
+(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 &&
\
+ defined(__opencl_c_generic_addr
https://github.com/mati865 created
https://github.com/llvm/llvm-project/pull/138118
Currently building for Cygwin hits this error:
```
In file included from
/h/projects/llvm-project/clang/lib/Basic/Attributes.cpp:17:
/h/projects/llvm-project/clang/include/clang/Basic/ParsedAttrInfo.h:180:73:
e
https://github.com/jofrn updated
https://github.com/llvm/llvm-project/pull/123609
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-ser
https://github.com/xlauko approved this pull request.
lgtm, besides Erich's comments
https://github.com/llvm/llvm-project/pull/138041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/xlauko edited
https://github.com/llvm/llvm-project/pull/138041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -185,6 +185,15 @@ class CIRGenBuilderTy : public cir::CIRBaseBuilderTy {
}
bool isInt(mlir::Type i) { return mlir::isa(i); }
+ //
+ // Constant creation helpers
+ // -
+ //
+ cir::ConstantOp getSInt32(int32_t c, mlir::Location loc) {
+au
https://github.com/jmmartinez closed
https://github.com/llvm/llvm-project/pull/137306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmmartinez wrote:
Thanks !
https://github.com/llvm/llvm-project/pull/137306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Juan Manuel Martinez Caamaño
Date: 2025-05-01T09:55:46+02:00
New Revision: 0d3d2f639c42b22fc1b9453c7b834dbb0f16c0dc
URL:
https://github.com/llvm/llvm-project/commit/0d3d2f639c42b22fc1b9453c7b834dbb0f16c0dc
DIFF:
https://github.com/llvm/llvm-project/commit/0d3d2f639c42b22fc1b9453c7b834db
https://github.com/cor3ntin approved this pull request.
https://github.com/llvm/llvm-project/pull/138073
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zyn0217 approved this pull request.
Okay, let's go ahead as is. Though I feel it's unfortunate that the warnings
for left fold and right fold are scattered - maybe we could clean them up in
future
Thanks for working on this.
https://github.com/llvm/llvm-project/pull/136836
DeinAlptraum wrote:
Which parts do you mean? The `__eq__` operators for other objects?
https://github.com/llvm/llvm-project/pull/138074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Mateusz Mikuła (mati865)
Changes
Currently building for Cygwin hits this error:
```
In file included from
/h/projects/llvm-project/clang/lib/Basic/Attributes.cpp:17:
/h/projects/llvm-project/clang/include/clang/Basic/ParsedAttrInfo.h:180:7
https://github.com/efriedma-quic approved this pull request.
Please add a test for the new indirect goto diagnostic. Otherwise LGTM
https://github.com/llvm/llvm-project/pull/138009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
krzysz00 wrote:
> It does, we should have a consistent set of buffer builtins
To specify what I _think_ the proposed rewrite is, it's auto-upgrading or
otherwise transforming
```llvm
%r = call T llvm.amdgcn.{raw,struct}.buffer.*(<4 x i32> %rsrc, ...)
```
into
```llvm
%rsrc.int = bitcast <4 x i3
ilovepi wrote:
@PeterChou1 I've uploaded a patch set w/ the relevant changes from this patch.
Some of the details were split into standalone patches, but I'd appreciate if
you could help both review and test those patches. It would also be nice if you
could share any testing corpus or lit test
arsenm wrote:
Apparently the inliner has an arbitrary size threshold even for single uses. I
don't see the point of that, we should probably remove that
https://github.com/llvm/llvm-project/pull/137769
___
cfe-commits mailing list
cfe-commits@lists.l
krzysz00 wrote:
Side note, if we're cleaning up the API, we really should add
s.buffer.load.real that actually models the memory effects correctly
https://github.com/llvm/llvm-project/pull/137678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/138162
>From 7b139b3a06e45f7429e1e0f15eb16d0c3aed5718 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Thu, 1 May 2025 12:08:05 -0400
Subject: [PATCH] [CUDA][HIP] Fix implicit attribute of builtin
When a builti
@@ -6174,6 +6174,19 @@ void
CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
CodeGenFunction(*this).GenerateCode(GD, Fn, FI);
setNonAliasAttributes(GD, Fn);
+
+ bool ShouldAddOptNone = !CodeGenOpts.DisableO0ImplyOptNone &&
+ (CodeGenOpt
@@ -6174,6 +6174,19 @@ void
CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
CodeGenFunction(*this).GenerateCode(GD, Fn, FI);
setNonAliasAttributes(GD, Fn);
+
+ bool ShouldAddOptNone = !CodeGenOpts.DisableO0ImplyOptNone &&
+ (CodeGenOpt
@@ -6174,6 +6174,19 @@ void
CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
CodeGenFunction(*this).GenerateCode(GD, Fn, FI);
setNonAliasAttributes(GD, Fn);
+
+ bool ShouldAddOptNone = !CodeGenOpts.DisableO0ImplyOptNone &&
+ (CodeGenOpt
https://github.com/andykaylor approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/138106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Lancern updated
https://github.com/llvm/llvm-project/pull/136810
>From e9334137d0d1b968ac4d0e59af9f1b04e6b639ac Mon Sep 17 00:00:00 2001
From: Sirui Mu
Date: Fri, 2 May 2025 00:31:08 +0800
Subject: [PATCH] [CIR] Upstream cir.call with scalar arguments
---
.../CIR/Dialect/Bu
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Erich Keane (erichkeane)
Changes
These just add a standard 'device_type' flag to the acc.loop, so
implement that lowering. This also modifies the dialect to add helpers
for these as well, to be consistent with the previous ones.
---
Full d
llvmbot wrote:
@llvm/pr-subscribers-openacc
@llvm/pr-subscribers-clangir
Author: Erich Keane (erichkeane)
Changes
These just add a standard 'device_type' flag to the acc.loop, so
implement that lowering. This also modifies the dialect to add helpers
for these as well, to be consistent with
https://github.com/erichkeane created
https://github.com/llvm/llvm-project/pull/138164
These just add a standard 'device_type' flag to the acc.loop, so
implement that lowering. This also modifies the dialect to add helpers
for these as well, to be consistent with the previous ones.
>From 2047e1
llvmbot wrote:
@llvm/pr-subscribers-mlir-openacc
Author: Erich Keane (erichkeane)
Changes
These just add a standard 'device_type' flag to the acc.loop, so
implement that lowering. This also modifies the dialect to add helpers
for these as well, to be consistent with the previous ones.
---
https://github.com/andykaylor approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/138110
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/anchuraj updated
https://github.com/llvm/llvm-project/pull/137996
>From bb486c5e7cbe7b1c4a87469e06ca51bf49ddd081 Mon Sep 17 00:00:00 2001
From: Anchu Rajendran
Date: Tue, 29 Apr 2025 14:41:55 -0500
Subject: [PATCH 1/4] [flang] Support flag -finstrument-functions
---
clang/
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/sweiglbosker created
https://github.com/llvm/llvm-project/pull/138165
fixes: https://github.com/llvm/llvm-project/issues/138094
this patch fixes a crash triggered by Lexing past eof when emitting a
diagnostic for a malformed `_Pragma` directive within an `include` directive.
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Stefan (sweiglbosker)
Changes
fixes: https://github.com/llvm/llvm-project/issues/138094
this patch fixes a crash triggered by Lexing past eof when emitting a
diagnostic for a malformed `_Pragma` directive within an `include` directive.
Fix
https://github.com/razvanlupusoru approved this pull request.
Awesome. Thank you for continuing to contribute the builders to the dialect.
https://github.com/llvm/llvm-project/pull/138164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
https://github.com/sweiglbosker edited
https://github.com/llvm/llvm-project/pull/138165
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -81,6 +81,8 @@ class CodeGenOptions : public CodeGenOptionsBase {
/// Options to add to the linker for the object file
std::vector DependentLibs;
+ bool InstrumentFunctions{false};
anchuraj wrote:
Thank you for the review @tblah . Updated.
https://gi
https://github.com/sweiglbosker edited
https://github.com/llvm/llvm-project/pull/138165
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -252,6 +252,32 @@ TEST_F(ParseHLSLRootSignatureTest, ValidSamplerFlagsTest) {
ASSERT_TRUE(Consumer->isSatisfied());
}
+TEST_F(ParseHLSLRootSignatureTest, ValidParseRootConsantsTest) {
joaosaffran wrote:
```suggestion
TEST_F(ParseHLSLRootSignatureTest, Va
https://github.com/joaosaffran approved this pull request.
LGTM, just a typo and a nit
https://github.com/llvm/llvm-project/pull/137999
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Amr Hesham
Date: 2025-05-01T08:51:55+02:00
New Revision: 93ff19c27a0ad21068f431c0380f5a6dd5c4abc3
URL:
https://github.com/llvm/llvm-project/commit/93ff19c27a0ad21068f431c0380f5a6dd5c4abc3
DIFF:
https://github.com/llvm/llvm-project/commit/93ff19c27a0ad21068f431c0380f5a6dd5c4abc3.diff
LO
https://github.com/owenca edited
https://github.com/llvm/llvm-project/pull/108332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
anutosh491 wrote:
The cuda tests for the negation case should now work (not segfault because
libcudart.so is not found but simply get skipped).
```
1: Test command:
/build/anutosh491/CppInterOp/build1/unittests/CppInterOp/CppInterOpTests/unittests/bin/Release/CppInterOpTests
1: Working Director
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Anutosh Bhat (anutosh491)
Changes
Check this error for more context
(https://github.com/compiler-research/CppInterOp/actions/runs/14749797085/job/41407625681?pr=491#step:10:531)
This fails with
```
* thread #1, name = 'CppInterOpTests',
https://github.com/anutosh491 created
https://github.com/llvm/llvm-project/pull/138091
Check this error for more context
(https://github.com/compiler-research/CppInterOp/actions/runs/14749797085/job/41407625681?pr=491#step:10:531)
This fails with
```
* thread #1, name = 'CppInterOpTests', sto
owenca wrote:
I don't like new options for bug fixes. WDYT @mydeveloperday?
https://github.com/llvm/llvm-project/pull/137544
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Thomas Du Plessis
Date: 2025-05-01T03:11:30-04:00
New Revision: ac9e1df3efcaa80b8e0fc8a16a929c0f0dc2e161
URL:
https://github.com/llvm/llvm-project/commit/ac9e1df3efcaa80b8e0fc8a16a929c0f0dc2e161
DIFF:
https://github.com/llvm/llvm-project/commit/ac9e1df3efcaa80b8e0fc8a16a929c0f0dc2e161.d
owenca wrote:
IMO, unless it's a bug, we need a new option to ensure it's a non-breaking
change.
https://github.com/llvm/llvm-project/pull/137840
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
@@ -62,6 +62,22 @@ struct FormatStyle {
/// \version 3.3
int AccessModifierOffset;
+ /// Different styles for breaking the parenthesis after a control statement
+ /// (``if/switch/while/for ...``).
+ /// \version 21
+ enum BreakAfterControlStatementStyle : int8_t {
+
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu`
running on `linaro-lldb-aarch64-ubuntu` while building `clang` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/59/builds/16971
Here is the relevant piece of the
https://github.com/anutosh491 updated
https://github.com/llvm/llvm-project/pull/138091
>From 8783ea05d2d7f4504978427764da7e78c088aa39 Mon Sep 17 00:00:00 2001
From: anutosh491
Date: Thu, 1 May 2025 12:16:06 +0530
Subject: [PATCH 1/2] Fix destructor for interpreter for the cuda negation case
--
https://github.com/anutosh491 updated
https://github.com/llvm/llvm-project/pull/138091
>From aba1800393455fd99feeb9017a4ead4fd582 Mon Sep 17 00:00:00 2001
From: anutosh491
Date: Thu, 1 May 2025 12:16:06 +0530
Subject: [PATCH] Fix destructor for interpreter for the cuda negation case
---
c
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,h --
clang/include/clang/Interpreter/Interpreter.h
clan
@@ -9694,6 +9694,304 @@ TEST_F(FormatTest, ParenthesesAndOperandAlignment) {
Style);
}
+TEST_F(FormatTest, AlignAfterConditionalStatements) {
owenca wrote:
```suggestion
TEST_F(FormatTest, AlignAfterControlStatements) {
```
Can you move this to
HighCommander4 wrote:
Thanks! I'll go ahead and merge.
https://github.com/llvm/llvm-project/pull/71605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
owenca wrote:
> > > > I prefer that we limit this to breaking after the left parenthesis of a
> > > > control statement, with true/false or Always, Never, Multiline,
> > > > BlockIndent, etc.
> > >
> > >
> > > if I understand you correctly, you would like a new style option added
> > > for s
owenca wrote:
Please add a description so that we'll understand why you need this new option.
https://github.com/llvm/llvm-project/pull/137609
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/71605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/owenca commented:
You need to run `ninja clang-format-style` to update the documentation.
https://github.com/llvm/llvm-project/pull/108332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`llvm-clang-x86_64-gcc-ubuntu` running on `sie-linux-worker3` while building
`clang-tools-extra` at step 6 "test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/174/builds
https://github.com/jurahul created
https://github.com/llvm/llvm-project/pull/138174
None
>From d6f69414e3ac5c1a22f6509149609258ef980c13 Mon Sep 17 00:00:00 2001
From: Rahul Joshi
Date: Wed, 30 Apr 2025 23:47:37 -0700
Subject: [PATCH] [NFC][Support] Add llvm::uninitialized_copy
---
clang/incl
https://github.com/jurahul updated
https://github.com/llvm/llvm-project/pull/138174
>From b34e9b6c708dfbe097504804a0a85e1169518911 Mon Sep 17 00:00:00 2001
From: Rahul Joshi
Date: Wed, 30 Apr 2025 23:47:37 -0700
Subject: [PATCH] [NFC][Support] Add llvm::uninitialized_copy
---
clang/include/cl
@@ -428,6 +429,52 @@ mlir::LogicalResult CIRGenFunction::emitBreakStmt(const
clang::BreakStmt &s) {
return mlir::success();
}
+const CaseStmt *CIRGenFunction::foldCaseStmt(const clang::CaseStmt &s,
+ mlir::Type condType,
+
@@ -215,17 +342,115 @@ void sw9(int a) {
// OGCG: entry:
// OGCG: %[[A_ADDR:.*]] = alloca i32, align 4
// OGCG: %[[A_VAL:.*]] = load i32, ptr %[[A_ADDR]], align 4
-// OGCG: switch i32 %[[A_VAL]], label %[[EPILOG:.*]] [
+// OGCG: switch i32 %[[A_VAL]], label %[[DEFAULT:.
@@ -91,12 +92,40 @@ void sw2(int a) {
// OGCG: [[SW_EPILOG]]:
// OGCG: ret void
+void sw3(int a) {
andykaylor wrote:
Please add tests for the GNU range case, including one where it would be in the
same group with other cases, like this:
```
void f(int x)
@@ -428,6 +429,52 @@ mlir::LogicalResult CIRGenFunction::emitBreakStmt(const
clang::BreakStmt &s) {
return mlir::success();
}
+const CaseStmt *CIRGenFunction::foldCaseStmt(const clang::CaseStmt &s,
+ mlir::Type condType,
+
Author: Andy Kaylor
Date: 2025-05-01T11:11:02-07:00
New Revision: 5209668e357e0a1d295d9e9aa9dbca8f41132c0c
URL:
https://github.com/llvm/llvm-project/commit/5209668e357e0a1d295d9e9aa9dbca8f41132c0c
DIFF:
https://github.com/llvm/llvm-project/commit/5209668e357e0a1d295d9e9aa9dbca8f41132c0c.diff
L
https://github.com/andykaylor closed
https://github.com/llvm/llvm-project/pull/138041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
evodius96 wrote:
Hello, I'm seeing ProgramStackTest fail when running on our downstream
toolchain on Linux:
```
2 | | FAIL: llvm_regressions ::
LLVM-Unit/Support/SupportTests/ProgramStackTest/runOnNewStack
3 | |
--
@@ -428,6 +429,52 @@ mlir::LogicalResult CIRGenFunction::emitBreakStmt(const
clang::BreakStmt &s) {
return mlir::success();
}
+const CaseStmt *CIRGenFunction::foldCaseStmt(const clang::CaseStmt &s,
+ mlir::Type condType,
+
@@ -428,6 +429,52 @@ mlir::LogicalResult CIRGenFunction::emitBreakStmt(const
clang::BreakStmt &s) {
return mlir::success();
}
+const CaseStmt *CIRGenFunction::foldCaseStmt(const clang::CaseStmt &s,
+ mlir::Type condType,
+
@@ -428,6 +429,52 @@ mlir::LogicalResult CIRGenFunction::emitBreakStmt(const
clang::BreakStmt &s) {
return mlir::success();
}
+const CaseStmt *CIRGenFunction::foldCaseStmt(const clang::CaseStmt &s,
+ mlir::Type condType,
+
@@ -794,12 +794,14 @@ AArch64TargetInfo::getTargetBuiltins() const {
std::optional>
AArch64TargetInfo::getVScaleRange(const LangOptions &LangOpts,
- bool IsArmStreamingFunction) const {
+ bool IsArmStreamingFunc
@@ -8197,6 +8197,16 @@ def err_address_space_qualified_new : Error<
def err_address_space_qualified_delete : Error<
"'delete' cannot delete objects of type %0 in address space '%1'">;
+def note_default_init_const_member : Note<
+ "member %0 declared 'const' here">;
+def war
@@ -4238,7 +4238,8 @@ static Value *emitPointerArithmetic(CodeGenFunction &CGF,
else
elemTy = CGF.ConvertTypeForMem(elementType);
- if (CGF.getLangOpts().PointerOverflowDefined)
+ if (CGF.getLangOpts().PointerOverflowDefined ||
+ CGF.isUnderlyingBasePointerConstan
@@ -428,6 +429,52 @@ mlir::LogicalResult CIRGenFunction::emitBreakStmt(const
clang::BreakStmt &s) {
return mlir::success();
}
+const CaseStmt *CIRGenFunction::foldCaseStmt(const clang::CaseStmt &s,
+ mlir::Type condType,
+
@@ -0,0 +1,23 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -aux-triple
amdgcn-amd-amdhsa -fsyntax-only -verify -xhip %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fsyntax-only -fcuda-is-device
-verify -xhip %s
+
+#include "Inputs/cuda
fmayer wrote:
Could we make sure this gets called out in the Release Notes? Even if it's a
fix, this is a change of ABI which could break stuff.
https://github.com/llvm/llvm-project/pull/126774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
https://github.com/cor3ntin updated
https://github.com/llvm/llvm-project/pull/138121
>From 34011def1ec643701a84424f0813484efa39a1d1 Mon Sep 17 00:00:00 2001
From: Corentin Jabot
Date: Thu, 1 May 2025 13:32:00 +0200
Subject: [PATCH 1/2] [Clang] incorrect assertion when checking template
templat
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lld-x86_64-win` running on
`as-worker-93` while building `clang,llvm` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/146/builds/2823
Here is the releva
https://github.com/erichkeane approved this pull request.
I'm concerned about the static-invoker ending up just being an assert, but I
guess that is no behavioral change (just 1 assert to another).
https://github.com/llvm/llvm-project/pull/138121
___
Endilll wrote:
#138134 seems to stick. I'll close this PR later if everything goes well
https://github.com/llvm/llvm-project/pull/138139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonChesterfield wrote:
There's some existing builtin stuff going on in this area, e.g.
https://github.com/llvm/llvm-project/pull/138141/commits/96e94b5662c613fd80f712080751076254a73524
The use case in CK is behind a hip header file, so could become static inline
functions renaming a builtin, o
@@ -0,0 +1,39 @@
+! Tests for -fprofile-generate and -fprofile-use flag compatibility. These two
+! flags behave similarly to their GCC counterparts:
+!
+! -fprofile-generate Generates the profile file ./default.profraw
+! -fprofile-use=/file Uses the profile file /file
AaronBallman wrote:
> > Do we need yet another calling convention or is there a way we can start to
> > combine some of these for all the offloading languages? It seems we keep
> > re-implementing the same concepts multiple times for each language and it
> > would be nice to share as much of t
AaronBallman wrote:
> > Perhaps silly initial question: why do we need a whole different qualifier
> > for this? Why can you not write `__ptrauth uintptr_t foo`?
>
> Not a silly question, back when first implemented we spent time thinking
> about this.
>
> The concern was basically `T* __ptra
@@ -13,6 +13,7 @@
#ifndef LLVM_FRONTEND_DRIVER_CODEGENOPTIONS_H
#define LLVM_FRONTEND_DRIVER_CODEGENOPTIONS_H
+#include
fanju110 wrote:
Ok，I have adjusted it as you suggested
https://github.com/llvm/llvm-project/pull/136098
_
@@ -8,8 +8,14 @@
#include "llvm/Frontend/Driver/CodeGenOptions.h"
#include "llvm/Analysis/TargetLibraryInfo.h"
+#include "llvm/ProfileData/InstrProfCorrelator.h"
#include "llvm/TargetParser/Triple.h"
+namespace llvm {
+extern llvm::cl::opt DebugInfoCorrelate;
+extern llvm::
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `premerge-monolithic-linux`
running on `premerge-linux-1` while building `clang,llvm` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/153/builds/30468
He
https://github.com/sarnex converted_to_draft
https://github.com/llvm/llvm-project/pull/137882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sarnex wrote:
> I was thinking that orthogonal calling conventions could be combined so that
> we need fewer of them. e.g., if spir_kernel cannot be mixed with nvptx_kernel
> in the same TU, then there's no need for two distinct internal
> representations for the attributes, just two distinct
@@ -0,0 +1,60 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -cl-std=CL2.0 -O0 -triple amdgcn-unknown-unknown
-target-cpu gfx900 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -O0 -triple amdgcn-unknown-u
earnol wrote:
Could you please take a look into the issue
https://github.com/llvm/llvm-project/issues/138145 i created and provide an
input from your side if possible.
https://github.com/llvm/llvm-project/pull/136855
___
cfe-commits mailing list
cfe-
1 - 100 of 527 matches
Mail list logo
