[clang] [MS ABI]: Support preserve_none in MS ABI (PR #96487)
@@ -2986,6 +2989,9 @@ void
MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
case CC_Swift: Out << 'S'; break;
antangelo wrote:
Done
https://github.com/llvm/llvm-project/pull/96487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] [flang] Retry add basic -mtune support (PR #96688)
@@ -0,0 +1,7 @@ +// RUN: mlir-translate -mlir-to-llvmir %s | FileCheck %s gysit wrote: This may require x86-registered-target as well? https://github.com/llvm/llvm-project/pull/96688 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] [flang] Retry add basic -mtune support (PR #96688)
@@ -0,0 +1,9 @@ +; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s gysit wrote: Should this test also be guarded with `REQUIRES: x86-registered-target`? https://github.com/llvm/llvm-project/pull/96688 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 2ee2b6a - [Coroutines] Clear FirstVLALoc in time
Author: Chuanqi Xu
Date: 2024-06-26T13:25:06+08:00
New Revision: 2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823
URL:
https://github.com/llvm/llvm-project/commit/2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823
DIFF:
https://github.com/llvm/llvm-project/commit/2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823.diff
LOG: [Coroutines] Clear FirstVLALoc in time
Unlike other *Loc member in FunctionScopeInfo, we didn't clear
FirstVLALoc in 'FunctionScopeInfo::Clear()'. Then it will be
problematic for the following case:
```
void bar(int n) {
int array[n];
return;
}
coroutine foo(int n) {
co_return;
}
```
When we parse `foo`, the FirstVLALoc is still valid, then the compiler
will report `vla in coroutine` error in bar, which is super odd. After
this patch, we can fix this.
Added:
Modified:
clang/lib/Sema/ScopeInfo.cpp
clang/test/SemaCXX/coroutine-vla.cpp
Removed:
diff --git a/clang/lib/Sema/ScopeInfo.cpp b/clang/lib/Sema/ScopeInfo.cpp
index ce90451f2613b..12fb706072723 100644
--- a/clang/lib/Sema/ScopeInfo.cpp
+++ b/clang/lib/Sema/ScopeInfo.cpp
@@ -39,6 +39,7 @@ void FunctionScopeInfo::Clear() {
FirstReturnLoc = SourceLocation();
FirstCXXOrObjCTryLoc = SourceLocation();
FirstSEHTryLoc = SourceLocation();
+ FirstVLALoc = SourceLocation();
FoundImmediateEscalatingExpression = false;
// Coroutine state
diff --git a/clang/test/SemaCXX/coroutine-vla.cpp
b/clang/test/SemaCXX/coroutine-vla.cpp
index 176e35f346e2b..996c89025e2ad 100644
--- a/clang/test/SemaCXX/coroutine-vla.cpp
+++ b/clang/test/SemaCXX/coroutine-vla.cpp
@@ -16,6 +16,12 @@ struct promise
void unhandled_exception();
};
+// Test that we won't report the error incorrectly.
+void bar(int n) {
+ int array[n];
+ return;
+}
+
coroutine foo(int n) {
int array[n]; // expected-error {{variable length arrays in a coroutine are
not supported}}
co_return;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clang: Support minimumnum and maximumnum intrinsics (PR #96281)
https://github.com/wzssyqa updated
https://github.com/llvm/llvm-project/pull/96281
>From 1f357abed9d9e304b12ddd05a525557a8b0082c6 Mon Sep 17 00:00:00 2001
From: YunQiang Su
Date: Fri, 21 Jun 2024 14:28:42 +0800
Subject: [PATCH 1/2] Clang: Support minimumnum and maximumnum intrinsics
We just introduce llvm.minimumnum and llvm.maximumnum intrinsics
support to llvm. Let's support them in Clang.
See: #93033
---
clang/include/clang/Basic/Builtins.td | 28 +++
clang/lib/CodeGen/CGBuiltin.cpp | 24
.../Tooling/Inclusions/Stdlib/CSymbolMap.inc | 6
.../Inclusions/Stdlib/StdSymbolMap.inc| 18
clang/test/CodeGen/builtins.c | 18
clang/test/CodeGen/math-libcalls.c| 25 +
6 files changed, 119 insertions(+)
diff --git a/clang/include/clang/Basic/Builtins.td
b/clang/include/clang/Basic/Builtins.td
index f5b15cf90d1f8..f0b0521464f97 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -215,6 +215,18 @@ def FminF16F128 : Builtin, F16F128MathTemplate {
let Prototype = "T(T, T)";
}
+def FmaximumNumF16F128 : Builtin, F16F128MathTemplate {
+ let Spellings = ["__builtin_fmaximum_num"];
+ let Attributes = [FunctionWithBuiltinPrefix, NoThrow, Const, Constexpr];
+ let Prototype = "T(T, T)";
+}
+
+def FminimumNumF16F128 : Builtin, F16F128MathTemplate {
+ let Spellings = ["__builtin_fminimum_num"];
+ let Attributes = [FunctionWithBuiltinPrefix, NoThrow, Const, Constexpr];
+ let Prototype = "T(T, T)";
+}
+
def Atan2F128 : Builtin {
let Spellings = ["__builtin_atan2f128"];
let Attributes = [FunctionWithBuiltinPrefix, NoThrow,
ConstIgnoringErrnoAndExceptions];
@@ -3678,6 +3690,22 @@ def Fmin : FPMathTemplate, LibBuiltin<"math.h"> {
let OnlyBuiltinPrefixedAliasIsConstexpr = 1;
}
+def FmaximumNum : FPMathTemplate, LibBuiltin<"math.h"> {
+ let Spellings = ["fmaximum_num"];
+ let Attributes = [NoThrow, Const];
+ let Prototype = "T(T, T)";
+ let AddBuiltinPrefixedAlias = 1;
+ let OnlyBuiltinPrefixedAliasIsConstexpr = 1;
+}
+
+def FminimumNum : FPMathTemplate, LibBuiltin<"math.h"> {
+ let Spellings = ["fminimum_num"];
+ let Attributes = [NoThrow, Const];
+ let Prototype = "T(T, T)";
+ let AddBuiltinPrefixedAlias = 1;
+ let OnlyBuiltinPrefixedAliasIsConstexpr = 1;
+}
+
def Hypot : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["hypot"];
let Attributes = [NoThrow, ConstIgnoringErrnoAndExceptions];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 4edd8283aa03c..32f5d36067edf 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -2767,6 +2767,30 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
Intrinsic::minnum,
Intrinsic::experimental_constrained_minnum));
+case Builtin::BIfmaximum_num:
+case Builtin::BIfmaximum_numf:
+case Builtin::BIfmaximum_numl:
+case Builtin::BI__builtin_fmaximum_num:
+case Builtin::BI__builtin_fmaximum_numf:
+case Builtin::BI__builtin_fmaximum_numf16:
+case Builtin::BI__builtin_fmaximum_numl:
+case Builtin::BI__builtin_fmaximum_numf128:
+ return RValue::get(emitBinaryMaybeConstrainedFPBuiltin(
+ *this, E, Intrinsic::maximumnum,
+ Intrinsic::experimental_constrained_maximumnum));
+
+case Builtin::BIfminimum_num:
+case Builtin::BIfminimum_numf:
+case Builtin::BIfminimum_numl:
+case Builtin::BI__builtin_fminimum_num:
+case Builtin::BI__builtin_fminimum_numf:
+case Builtin::BI__builtin_fminimum_numf16:
+case Builtin::BI__builtin_fminimum_numl:
+case Builtin::BI__builtin_fminimum_numf128:
+ return RValue::get(emitBinaryMaybeConstrainedFPBuiltin(
+ *this, E, Intrinsic::minimumnum,
+ Intrinsic::experimental_constrained_minimumnum));
+
// fmod() is a special-case. It maps to the frem instruction rather than an
// LLVM intrinsic.
case Builtin::BIfmod:
diff --git a/clang/lib/Tooling/Inclusions/Stdlib/CSymbolMap.inc
b/clang/lib/Tooling/Inclusions/Stdlib/CSymbolMap.inc
index 463ce921f0672..af2dcb632fbb6 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/CSymbolMap.inc
+++ b/clang/lib/Tooling/Inclusions/Stdlib/CSymbolMap.inc
@@ -475,6 +475,12 @@ SYMBOL(fmaxl, None, )
SYMBOL(fmin, None, )
SYMBOL(fminf, None, )
SYMBOL(fminl, None, )
+SYMBOL(fmaximum_num, None, )
+SYMBOL(fmaximum_numf, None, )
+SYMBOL(fmaximum_numfl, None, )
+SYMBOL(fminimum_num, None, )
+SYMBOL(fminimum_numf, None, )
+SYMBOL(fminimum_numl, None, )
SYMBOL(fmod, None, )
SYMBOL(fmodf, None, )
SYMBOL(fmodl, None, )
diff --git a/clang/lib/Tooling/Inclusions/Stdlib/StdSymbolMap.inc
b/clang/lib/Tooling/Inclusions/Stdlib/StdSymbolMap.inc
index b46bd2e4d7a4b..442316ce8d4ff 100644
---
[clang] [MS ABI]: Support preserve_none in MS ABI (PR #96487)
https://github.com/antangelo updated
https://github.com/llvm/llvm-project/pull/96487
>From 1e95098e324860268d55e72a14090f9524c7dde1 Mon Sep 17 00:00:00 2001
From: Antonio Abbatangelo
Date: Mon, 24 Jun 2024 09:49:28 -0400
Subject: [PATCH 1/2] [MS ABI]: Support preserve_none in MS ABI
---
clang/lib/AST/MicrosoftMangle.cpp | 8 +-
clang/lib/Basic/Targets/AArch64.cpp | 1 +
.../CodeGenCXX/msabi-preserve-none-cc.cpp | 28 +++
clang/test/Sema/preserve-none-call-conv.c | 1 +
4 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 clang/test/CodeGenCXX/msabi-preserve-none-cc.cpp
diff --git a/clang/lib/AST/MicrosoftMangle.cpp
b/clang/lib/AST/MicrosoftMangle.cpp
index 3923d34274703..b49a96f105cfb 100644
--- a/clang/lib/AST/MicrosoftMangle.cpp
+++ b/clang/lib/AST/MicrosoftMangle.cpp
@@ -2962,7 +2962,10 @@ void
MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
// ::= J # __export __fastcall
// ::= Q # __vectorcall
// ::= S # __attribute__((__swiftcall__)) // Clang-only
- // ::= T # __attribute__((__swiftasynccall__))
+ // ::= W # __attribute__((__swiftasynccall__))
+ // ::= U # __attribute__((__preserve_most__))
+ // ::= V # __attribute__((__preserve_none__)) //
+ // Clang-only
//// Clang-only
// ::= w # __regcall
// ::= x # __regcall4
@@ -2986,6 +2989,9 @@ void
MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
case CC_Swift: Out << 'S'; break;
case CC_SwiftAsync: Out << 'W'; break;
case CC_PreserveMost: Out << 'U'; break;
+case CC_PreserveNone:
+ Out << 'V';
+ break;
case CC_X86RegCall:
if (getASTContext().getLangOpts().RegCall4)
Out << "x";
diff --git a/clang/lib/Basic/Targets/AArch64.cpp
b/clang/lib/Basic/Targets/AArch64.cpp
index 31d8121b91d10..2692ddec26ff4 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -1536,6 +1536,7 @@
WindowsARM64TargetInfo::checkCallingConvention(CallingConv CC) const {
case CC_OpenCLKernel:
case CC_PreserveMost:
case CC_PreserveAll:
+ case CC_PreserveNone:
case CC_Swift:
case CC_SwiftAsync:
case CC_Win64:
diff --git a/clang/test/CodeGenCXX/msabi-preserve-none-cc.cpp
b/clang/test/CodeGenCXX/msabi-preserve-none-cc.cpp
new file mode 100644
index 0..29df5e4d84a70
--- /dev/null
+++ b/clang/test/CodeGenCXX/msabi-preserve-none-cc.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec -emit-llvm
%s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple aarch64-unknown-windows-msvc -fdeclspec -emit-llvm
%s -o - | FileCheck %s
+
+void __attribute__((__preserve_none__)) f() {}
+// CHECK-DAG: @"?f@@YVXXZ"
+
+void (__attribute__((__preserve_none__)) *p)();
+// CHECK-DAG: @"?p@@3P6VXXZEA
+
+namespace {
+void __attribute__((__preserve_none__)) __attribute__((__used__)) f() { }
+}
+// CHECK-DAG: @"?f@?A0x{{[^@]*}}@@YVXXZ"
+
+namespace n {
+void __attribute__((__preserve_none__)) f() {}
+}
+// CHECK-DAG: @"?f@n@@YVXXZ"
+
+struct __declspec(dllexport) S {
+ S(const S &) = delete;
+ S & operator=(const S &) = delete;
+ void __attribute__((__preserve_none__)) m() { }
+};
+// CHECK-DAG: @"?m@S@@QEAVXXZ"
+
+void f(void (__attribute__((__preserve_none__))())) {}
+// CHECK-DAG: @"?f@@YAXP6VXXZ@Z"
diff --git a/clang/test/Sema/preserve-none-call-conv.c
b/clang/test/Sema/preserve-none-call-conv.c
index 4508095863de5..678fa7d5317e5 100644
--- a/clang/test/Sema/preserve-none-call-conv.c
+++ b/clang/test/Sema/preserve-none-call-conv.c
@@ -1,4 +1,5 @@
// RUN: %clang_cc1 %s -fsyntax-only -triple x86_64-unknown-unknown -verify
+// RUN: %clang_cc1 %s -fsyntax-only -triple aarch64-unknown-unknown -verify
typedef void typedef_fun_t(int);
>From 2f08dfbab5a2b92759a5a1d05a306dddbe5bdcf0 Mon Sep 17 00:00:00 2001
From: Antonio Abbatangelo
Date: Wed, 26 Jun 2024 01:30:09 -0400
Subject: [PATCH 2/2] Emit error instead of abort on unsupported calling
convention in MicrosoftMangle
---
clang/lib/AST/MicrosoftMangle.cpp | 64 ++-
1 file changed, 45 insertions(+), 19 deletions(-)
diff --git a/clang/lib/AST/MicrosoftMangle.cpp
b/clang/lib/AST/MicrosoftMangle.cpp
index b49a96f105cfb..8cbaad62bf9d7 100644
--- a/clang/lib/AST/MicrosoftMangle.cpp
+++ b/clang/lib/AST/MicrosoftMangle.cpp
@@ -447,8 +447,8 @@ class MicrosoftCXXNameMangler {
void mangleDecayedArrayType(const ArrayType *T);
void mangleArrayType(const ArrayType *T);
void mangleFunctionClass(const FunctionDecl *FD);
- void mangleCallingConvention(CallingConv CC);
- void mangleCallingConvention(const FunctionType *T);
+ void mangleCallingConvention(CallingConv CC, SourceRange Range);
+ void
[clang] [Clang][Sema] Tweak tryCaptureVariable for unevaluated lambdas (PR #93206)
zyn0217 wrote: > +1 to get this added to 18.1.9 if there ever is one - especially if the > Android NDK moves to it - the 27 betas fail for me too Sorry, I was unaware we had a scheduled release of 18.1.8 last week. @tstellar @cor3ntin do you think this is worth another 18.x release (presumably 18.1.9), though we're near the end of the 19 development cycle? I can issue one if the situation is warranted. https://github.com/llvm/llvm-project/pull/93206 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)
trcrsired wrote: @MaskRay https://github.com/llvm/llvm-project/pull/96417 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][dataflow] Teach `AnalysisASTVisitor` that `typeid()` can be evaluated. (PR #96731)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (martinboehme)
Changes
We were previously treating the operand of `typeid()` as being definitely
unevaluated, but it can be evaluated if it is a glvalue of polymorphic type.
This patch includes a test that fails without the fix.
---
Full diff: https://github.com/llvm/llvm-project/pull/96731.diff
2 Files Affected:
- (modified) clang/include/clang/Analysis/FlowSensitive/ASTOps.h (+5-1)
- (modified) clang/unittests/Analysis/FlowSensitive/TransferTest.cpp (+43)
``diff
diff --git a/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
b/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
index 925b99af9141a..f9c923a36ad22 100644
--- a/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
+++ b/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
@@ -113,7 +113,11 @@ class AnalysisASTVisitor : public
RecursiveASTVisitor {
// nevertheless it appears in the Clang CFG, so we don't exclude it here.
bool TraverseDecltypeTypeLoc(DecltypeTypeLoc) { return true; }
bool TraverseTypeOfExprTypeLoc(TypeOfExprTypeLoc) { return true; }
- bool TraverseCXXTypeidExpr(CXXTypeidExpr *) { return true; }
+ bool TraverseCXXTypeidExpr(CXXTypeidExpr *TIE) {
+if (TIE->isPotentiallyEvaluated())
+ return RecursiveASTVisitor::TraverseCXXTypeidExpr(TIE);
+return true;
+ }
bool TraverseUnaryExprOrTypeTraitExpr(UnaryExprOrTypeTraitExpr *) {
return true;
}
diff --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index 2a74d7fa63fd7..10d7ec9380ab8 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1637,6 +1637,49 @@ TEST(TransferTest, StructModeledFieldsWithAccessor) {
});
}
+TEST(TransferTest, StructModeledFieldsInTypeid) {
+ // Test that we model fields mentioned inside a `typeid()` expression only if
+ // that expression is potentially evaluated -- i.e. if the expression inside
+ // `typeid()` is a glvalue of polymorphic type (see
+ // `CXXTypeidExpr::isPotentiallyEvaluated()` and [expr.typeid]p3).
+ std::string Code = R"(
+// Definitions needed for `typeid`.
+namespace std {
+ class type_info {};
+ class bad_typeid {};
+} // namespace std
+
+struct NonPolymorphic {};
+
+struct Polymorphic {
+ virtual ~Polymorphic() = default;
+};
+
+struct S {
+ NonPolymorphic *NonPoly;
+ Polymorphic *Poly;
+};
+
+void target(S ) {
+ typeid(*s.NonPoly);
+ typeid(*s.Poly);
+ // [[p]]
+}
+ )";
+ runDataflow(
+ Code,
+ [](const llvm::StringMap> ,
+ ASTContext ) {
+const Environment = getEnvironmentAtAnnotation(Results, "p");
+auto = getLocForDecl(ASTCtx, Env, "s");
+std::vector Fields;
+for (auto [Field, _] : SLoc.children())
+ Fields.push_back(Field);
+EXPECT_THAT(Fields,
+UnorderedElementsAre(findValueDecl(ASTCtx, "Poly")));
+ });
+}
+
TEST(TransferTest, StructModeledFieldsWithComplicatedInheritance) {
std::string Code = R"(
struct Base1 {
``
https://github.com/llvm/llvm-project/pull/96731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][dataflow] Teach `AnalysisASTVisitor` that `typeid()` can be evaluated. (PR #96731)
https://github.com/martinboehme created
https://github.com/llvm/llvm-project/pull/96731
We were previously treating the operand of `typeid()` as being definitely
unevaluated, but it can be evaluated if it is a glvalue of polymorphic type.
This patch includes a test that fails without the fix.
>From 2e80e59fccc7ced7539fa2ee70e33545ce0e1441 Mon Sep 17 00:00:00 2001
From: Martin Braenne
Date: Wed, 26 Jun 2024 04:44:53 +
Subject: [PATCH] [clang][dataflow] Teach `AnalysisASTVisitor` that `typeid()`
can be evaluated.
We were previously treating the operand of `typeid()` as being definitely
unevaluated, but it can be evaluated if it is a glvalue of polymorphic type.
This patch includes a test that fails without the fix.
---
.../clang/Analysis/FlowSensitive/ASTOps.h | 6 ++-
.../Analysis/FlowSensitive/TransferTest.cpp | 43 +++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
b/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
index 925b99af9141a..f9c923a36ad22 100644
--- a/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
+++ b/clang/include/clang/Analysis/FlowSensitive/ASTOps.h
@@ -113,7 +113,11 @@ class AnalysisASTVisitor : public
RecursiveASTVisitor {
// nevertheless it appears in the Clang CFG, so we don't exclude it here.
bool TraverseDecltypeTypeLoc(DecltypeTypeLoc) { return true; }
bool TraverseTypeOfExprTypeLoc(TypeOfExprTypeLoc) { return true; }
- bool TraverseCXXTypeidExpr(CXXTypeidExpr *) { return true; }
+ bool TraverseCXXTypeidExpr(CXXTypeidExpr *TIE) {
+if (TIE->isPotentiallyEvaluated())
+ return RecursiveASTVisitor::TraverseCXXTypeidExpr(TIE);
+return true;
+ }
bool TraverseUnaryExprOrTypeTraitExpr(UnaryExprOrTypeTraitExpr *) {
return true;
}
diff --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index 2a74d7fa63fd7..10d7ec9380ab8 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1637,6 +1637,49 @@ TEST(TransferTest, StructModeledFieldsWithAccessor) {
});
}
+TEST(TransferTest, StructModeledFieldsInTypeid) {
+ // Test that we model fields mentioned inside a `typeid()` expression only if
+ // that expression is potentially evaluated -- i.e. if the expression inside
+ // `typeid()` is a glvalue of polymorphic type (see
+ // `CXXTypeidExpr::isPotentiallyEvaluated()` and [expr.typeid]p3).
+ std::string Code = R"(
+// Definitions needed for `typeid`.
+namespace std {
+ class type_info {};
+ class bad_typeid {};
+} // namespace std
+
+struct NonPolymorphic {};
+
+struct Polymorphic {
+ virtual ~Polymorphic() = default;
+};
+
+struct S {
+ NonPolymorphic *NonPoly;
+ Polymorphic *Poly;
+};
+
+void target(S ) {
+ typeid(*s.NonPoly);
+ typeid(*s.Poly);
+ // [[p]]
+}
+ )";
+ runDataflow(
+ Code,
+ [](const llvm::StringMap> ,
+ ASTContext ) {
+const Environment = getEnvironmentAtAnnotation(Results, "p");
+auto = getLocForDecl(ASTCtx, Env, "s");
+std::vector Fields;
+for (auto [Field, _] : SLoc.children())
+ Fields.push_back(Field);
+EXPECT_THAT(Fields,
+UnorderedElementsAre(findValueDecl(ASTCtx, "Poly")));
+ });
+}
+
TEST(TransferTest, StructModeledFieldsWithComplicatedInheritance) {
std::string Code = R"(
struct Base1 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [llvm] [runtimes] remove workaround for old CMake when setting `--unwindlib=none` (PR #93429)
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/93429
>From 8c1b899aa174b107fece1edbf99eaf261bdea516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 25 Apr 2022 09:45:22 +0300
Subject: [PATCH 1/4] [runtimes] [CMake] Use CMAKE_REQUIRED_LINK_OPTIONS to
simplify handling of the --unwindlib=none option
This avoids passing the option unnecessarily to compilation commands
(where it causes warnings).
This fails in practice with libunwind, where setting
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY breaks it, as
the option from CMAKE_REQUIRED_LINK_OPTIONS ends up passed to the "ar"
tool too.
---
libunwind/CMakeLists.txt | 3 +++
runtimes/CMakeLists.txt | 22 +-
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index b22ade0a7d71e..3d2fadca9d2ec 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -221,9 +221,12 @@ add_cxx_compile_flags_if_supported(-EHsc)
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
+set(_previous_CMAKE_REQUIRED_LINK_OPTIONS ${CMAKE_REQUIRED_LINK_OPTIONS})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
+set(CMAKE_REQUIRED_LINK_OPTIONS)
add_compile_flags_if_supported(-funwind-tables)
set(CMAKE_TRY_COMPILE_TARGET_TYPE ${_previous_CMAKE_TRY_COMPILE_TARGET_TYPE})
+set(CMAKE_REQUIRED_LINK_OPTIONS ${_previous_CMAKE_REQUIRED_LINK_OPTIONS})
if (LIBUNWIND_USES_ARM_EHABI AND NOT CXX_SUPPORTS_FUNWIND_TABLES_FLAG)
message(SEND_ERROR "The -funwind-tables flag must be supported "
diff --git a/runtimes/CMakeLists.txt b/runtimes/CMakeLists.txt
index 24f4851169591..8f909322c9a98 100644
--- a/runtimes/CMakeLists.txt
+++ b/runtimes/CMakeLists.txt
@@ -116,27 +116,7 @@
filter_prefixed("${CMAKE_ASM_IMPLICIT_INCLUDE_DIRECTORIES}" ${LLVM_BINARY_DIR} C
# brittle. We should ideally move this to runtimes/CMakeLists.txt.
llvm_check_compiler_linker_flag(C "--unwindlib=none"
CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
if (CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
- set(ORIG_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
- set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} --unwindlib=none")
- # TODO: When we can require CMake 3.14, we should use
- # CMAKE_REQUIRED_LINK_OPTIONS here. Until then, we need a workaround:
- # When using CMAKE_REQUIRED_FLAGS, this option gets added both to
- # compilation and linking commands. That causes warnings in the
- # compilation commands during cmake tests. This is normally benign, but
- # when testing whether -Werror works, that test fails (due to the
- # preexisting warning).
- #
- # Therefore, before we can use CMAKE_REQUIRED_LINK_OPTIONS, check if we
- # can use --start-no-unused-arguments to silence the warnings about
- # --unwindlib=none during compilation.
- #
- # We must first add --unwindlib=none to CMAKE_REQUIRED_FLAGS above, to
- # allow this subsequent test to succeed, then rewrite CMAKE_REQUIRED_FLAGS
- # below.
- check_c_compiler_flag("--start-no-unused-arguments"
C_SUPPORTS_START_NO_UNUSED_ARGUMENTS)
- if (C_SUPPORTS_START_NO_UNUSED_ARGUMENTS)
-set(CMAKE_REQUIRED_FLAGS "${ORIG_CMAKE_REQUIRED_FLAGS}
--start-no-unused-arguments --unwindlib=none --end-no-unused-arguments")
- endif()
+ list(APPEND CMAKE_REQUIRED_LINK_OPTIONS "--unwindlib=none")
endif()
# Disable use of the installed C++ standard library when building runtimes.
>From 816e9e6d81ac12537879406e0495fc80394a1a66 Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 23:18:51 +1100
Subject: [PATCH 2/4] add comment (and CMake issue reference) about
incompatible options
---
libunwind/CMakeLists.txt | 4
1 file changed, 4 insertions(+)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index 3d2fadca9d2ec..d84f8fa6ff954 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -220,6 +220,10 @@ add_cxx_compile_flags_if_supported(-EHsc)
#
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
+#
+# NOTE: we need to work around
https://gitlab.kitware.com/cmake/cmake/-/issues/23454
+# because CMAKE_REQUIRED_LINK_OPTIONS (c.f.
CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
+# is incompatible with CMAKE_TRY_COMPILE_TARGET_TYPE==STATIC_LIBRARY.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
set(_previous_CMAKE_REQUIRED_LINK_OPTIONS ${CMAKE_REQUIRED_LINK_OPTIONS})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
>From 3f917d22bdcd8b398cf7162563547418a056ecec Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 23:18:51 +1100
Subject: [PATCH 3/4] [cmake] move check for `-fno-exceptions` to "safe zone"
w.r.t. interference between CMAKE_REQUIRED_LINK_OPTIONS and static libraries
---
libunwind/CMakeLists.txt | 2 +-
[clang] [clang] add unnamed_addr function attribute (PR #92499)
efriedma-quic wrote: If you want to push this forward, start a Discourse thread (discourse.llvm.org) with a writeup of the proposal. Including an expanded rationale for why we want this. See also https://clang.llvm.org/get_involved.html https://github.com/llvm/llvm-project/pull/92499 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [libcxx] [libunwind] [llvm] [openmp] [cmake] switch to CMake's native `check_{compiler,linker}_flag` (PR #96171)
h-vetinari wrote: I think that was the last one. :) https://github.com/llvm/llvm-project/pull/96171 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
efriedma-quic wrote: I don't think I like this approach: - This seems like an easy way to unintentionally pass state between different compilations. - It seems very easy to try to use this API during LTO, and have it do nothing. - I'm pretty sure this breaks existing workflows involving AMDGPUCtorDtorLowering/NVPTXCtorDtorLowering. And please don't merge changes to core IR datastructures less than an hour after you post the patch. Please revert and start a Discourse discussion so we can discuss the right direction here. Off the top of my head, it might make sense to pass the relevant attributes as arguments to the constructor for the relevant IR passes. https://github.com/llvm/llvm-project/pull/96721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] add unnamed_addr function attribute (PR #92499)
yamt wrote: > If we're going to do this, it should probably also work for constants. > > Also, I think I'd prefer to sort out the situation with the C++ standard's > rules for constant merging before we start extending those rules. See #63628. may i update this to cover constants as well? or, it would be a waste of effort as it seems no chances to be merged? https://github.com/llvm/llvm-project/pull/92499 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AMDGPU] Extend permlane16, permlanex16 and permlane64 intrinsic lowering for generic types (PR #92725)
https://github.com/vikramRH closed https://github.com/llvm/llvm-project/pull/92725 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (PR #96540)
@@ -0,0 +1,29 @@ +USE_XMM= phoebewang wrote: How about we move these old implementations in to a seperate file (or leave them where they are if you like) and rename them to _dept, so that we don't rely on old compilers? We can then remove them as well as the tests in the next release. https://github.com/llvm/llvm-project/pull/96540 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
https://github.com/pcc closed https://github.com/llvm/llvm-project/pull/96721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 89d8df1 - CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr().
Author: pcc
Date: 2024-06-25T20:39:18-07:00
New Revision: 89d8df12015ac3440190d372a8d439614027dc2c
URL:
https://github.com/llvm/llvm-project/commit/89d8df12015ac3440190d372a8d439614027dc2c
DIFF:
https://github.com/llvm/llvm-project/commit/89d8df12015ac3440190d372a8d439614027dc2c.diff
LOG: CodeGen, IR: Add target-{cpu,features} attributes to functions created via
createWithDefaultAttr().
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature), clobbering registers specified via -ffixed-*
(missing reserve-* feature), and so on.
There's already a number of attributes copied from the module flags
onto functions created by createWithDefaultAttr(). I don't think
module flags are the right choice for the target attributes because
we don't need the conflict resolution logic between modules with
different target attributes, nor does it seem sensible to add it:
there's no unambiguously "correct" set of target attributes when
merging two modules with different attributes, and nor should there
be; it's perfectly valid for two modules to be compiled with different
target attributes, that's the whole reason why they are per-function.
This also implies that it's unnecessary to serialize the attributes in
bitcode, which implies that they shouldn't be stored on the module. We
can also observe that for the most part, createWithDefaultAttr()
is called from compiler passes such as sanitizers, coverage and
profiling passes that are part of the compile time pipeline, not
the LTO pipeline. This hints at a solution: we need to store the
attributes in a non-serialized location associated with the ambient
compilation context. Therefore in this patch I elected to store the
attributes on the LLVMContext.
There are calls to createWithDefaultAttr() in the NVPTX and AMDGPU
backends, and those calls would happen at LTO time. For those callers,
the bug still potentially exists and it would be necessary to refactor
them to create the functions at compile time if this issue is relevant
on those platforms.
Fixes #93633.
Reviewers: fmayer, MaskRay, eugenis
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/96721
Added:
clang/test/CodeGen/coverage-target-attr.c
Modified:
clang/lib/CodeGen/CodeGenAction.cpp
clang/test/CodeGen/asan-frame-pointer.cpp
clang/test/CodeGen/asan-globals.cpp
clang/test/CodeGen/sanitize-metadata-nosanitize.c
llvm/include/llvm/IR/Function.h
llvm/include/llvm/IR/LLVMContext.h
llvm/lib/IR/Function.cpp
llvm/lib/IR/LLVMContext.cpp
llvm/lib/IR/LLVMContextImpl.h
Removed:
diff --git a/clang/lib/CodeGen/CodeGenAction.cpp
b/clang/lib/CodeGen/CodeGenAction.cpp
index 6d3efdb5ffe34..7766383fdc890 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -299,6 +299,9 @@ void BackendConsumer::HandleTranslationUnit(ASTContext ) {
Ctx.setDiagnosticHandler(std::make_unique(
CodeGenOpts, this));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
@@ -1205,6 +1208,9 @@ void CodeGenAction::ExecuteAction() {
Ctx.setDiagnosticHandler(
std::make_unique(CodeGenOpts, ));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
diff --git a/clang/test/CodeGen/asan-frame-pointer.cpp
b/clang/test/CodeGen/asan-frame-pointer.cpp
index ed3624f3146eb..ecc1a18c11daa 100644
--- a/clang/test/CodeGen/asan-frame-pointer.cpp
+++ b/clang/test/CodeGen/asan-frame-pointer.cpp
@@ -8,12 +8,12 @@ int global;
// NONE: define internal void @asan.module_ctor() #[[#ATTR:]] {
// NONE: define internal void @asan.module_dtor() #[[#ATTR]] {
-// NONE: attributes #[[#ATTR]] = { nounwind }
+// NONE: attributes #[[#ATTR]] = { nounwind
// NONLEAF: define internal void @asan.module_ctor() #[[#ATTR:]] {
// NONLEAF: define internal void @asan.module_dtor() #[[#ATTR]] {
-// NONLEAF: attributes #[[#ATTR]] = { nounwind "frame-pointer"="non-leaf" }
+// NONLEAF: attributes #[[#ATTR]] = { nounwind "frame-pointer"="non-leaf"
// ALL: define internal void @asan.module_ctor() #[[#ATTR:]] {
// ALL: define internal void @asan.module_dtor() #[[#ATTR]] {
-// ALL: attributes #[[#ATTR]] = { nounwind "frame-pointer"="all" }
+// ALL: attributes #[[#ATTR]] = { nounwind "frame-pointer"="all"
diff --git a/clang/test/CodeGen/asan-globals.cpp
b/clang/test/CodeGen/asan-globals.cpp
index
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
@@ -327,6 +327,26 @@ class LLVMContext {
[[deprecated("Always returns false")]]
bool supportsTypedPointers() const;
+ /// Get the current "default" target CPU (target-cpu function attribute). The
+ /// intent is that compiler frontends will set this to a value that reflects
+ /// the attribute that a function would get "by default" without any specific
+ /// function attributes, and compiler passes will attach the attribute to
+ /// newly created functions that are not associated with a particular
+ /// function, such as global initializers. Function::createWithDefaultAttr()
+ /// will create functions with this attribute. This function should only be
+ /// called by passes that run at compile time and not by the backend or LTO
+ /// passes.
+ StringRef getDefaultTargetCPU();
+
+ /// See getDefaultTargetCPU().
+ void setDefaultTargetCPU(StringRef CPU);
+
+ /// Similar to getDefaultTargetCPU() but for default target-features instead.
+ StringRef getDefaultTargetFeatures();
+
+ /// See getDefaultTargetFeatures().
+ void setDefaultTargetFeatures(StringRef Features);
+
pcc wrote:
Done
https://github.com/llvm/llvm-project/pull/96721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
@@ -0,0 +1,17 @@ +// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30 -fsanitize=hwaddress %s -o %t pcc wrote: Done https://github.com/llvm/llvm-project/pull/96721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (PR #96540)
@@ -21,10 +21,29 @@ typedef int __v2si __attribute__((__vector_size__(8)));
typedef short __v4hi __attribute__((__vector_size__(8)));
typedef char __v8qi __attribute__((__vector_size__(8)));
+/* Unsigned types */
+typedef unsigned long long __v1du __attribute__ ((__vector_size__ (8)));
+typedef unsigned int __v2su __attribute__ ((__vector_size__ (8)));
+typedef unsigned short __v4hu __attribute__((__vector_size__(8)));
+typedef unsigned char __v8qu __attribute__((__vector_size__(8)));
+
+/* We need an explicitly signed variant for char. Note that this shouldn't
+ * appear in the interface though. */
+typedef signed char __v8qs __attribute__((__vector_size__(8)));
+
+/* SSE/SSE2 types */
+typedef long long __m128i __attribute__((__vector_size__(16),
__aligned__(16)));
+typedef long long __v2di __attribute__ ((__vector_size__ (16)));
+typedef int __v4si __attribute__((__vector_size__(16)));
+typedef short __v8hi __attribute__((__vector_size__(16)));
+typedef char __v16qi __attribute__((__vector_size__(16)));
+
/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS
\
- __attribute__((__always_inline__, __nodebug__, __target__("mmx,no-evex512"),
\
- __min_vector_width__(64)))
+#define __DEFAULT_FN_ATTRS_SSE2 __attribute__((__always_inline__, __nodebug__,
__target__("sse2,no-evex512"), __min_vector_width__(64)))
phoebewang wrote:
They are used to identify the maximum registers a function will use. The
backend doesn't distinguish the difference between scalar and 128-bit for now.
But we should make it comply the rule here.
https://github.com/llvm/llvm-project/pull/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
https://github.com/pcc updated https://github.com/llvm/llvm-project/pull/96721
>From 14e72c19daefd09b6cfe7e99865b89afa8c5a4d8 Mon Sep 17 00:00:00 2001
From: Peter Collingbourne
Date: Tue, 25 Jun 2024 19:16:01 -0700
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.6-beta.1
---
clang/lib/CodeGen/CodeGenAction.cpp | 6 ++
clang/test/CodeGen/coverage-target-attr.c | 17 +
llvm/include/llvm/IR/Function.h | 6 +-
llvm/include/llvm/IR/LLVMContext.h| 20
llvm/lib/IR/Function.cpp | 6 ++
llvm/lib/IR/LLVMContext.cpp | 16
llvm/lib/IR/LLVMContextImpl.h | 3 +++
7 files changed, 73 insertions(+), 1 deletion(-)
create mode 100644 clang/test/CodeGen/coverage-target-attr.c
diff --git a/clang/lib/CodeGen/CodeGenAction.cpp
b/clang/lib/CodeGen/CodeGenAction.cpp
index 6d3efdb5ffe34..7766383fdc890 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -299,6 +299,9 @@ void BackendConsumer::HandleTranslationUnit(ASTContext ) {
Ctx.setDiagnosticHandler(std::make_unique(
CodeGenOpts, this));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
@@ -1205,6 +1208,9 @@ void CodeGenAction::ExecuteAction() {
Ctx.setDiagnosticHandler(
std::make_unique(CodeGenOpts, ));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
diff --git a/clang/test/CodeGen/coverage-target-attr.c
b/clang/test/CodeGen/coverage-target-attr.c
new file mode 100644
index 0..3929d7b43df69
--- /dev/null
+++ b/clang/test/CodeGen/coverage-target-attr.c
@@ -0,0 +1,17 @@
+// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30
-fsanitize=hwaddress %s -o %t
+// RUN: FileCheck %s < %t
+
+// CHECK: define internal void @__llvm_gcov_writeout() unnamed_addr
[[ATTR:#[0-9]+]]
+// CHECK: define internal void @__llvm_gcov_reset() unnamed_addr [[ATTR]]
+// CHECK: define internal void @__llvm_gcov_init() unnamed_addr [[ATTR]]
+// CHECK: define internal void @hwasan.module_ctor() [[ATTR2:#[0-9]+]]
+// CHECK: attributes [[ATTR]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+// CHECK: attributes [[ATTR2]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+
+__attribute__((weak)) int foo = 0;
+
+__attribute__((weak)) void bar() {}
+
+int main() {
+ if (foo) bar();
+}
diff --git a/llvm/include/llvm/IR/Function.h b/llvm/include/llvm/IR/Function.h
index 5468cedb0815a..6bd997b7ac75a 100644
--- a/llvm/include/llvm/IR/Function.h
+++ b/llvm/include/llvm/IR/Function.h
@@ -181,10 +181,14 @@ class LLVM_EXTERNAL_VISIBILITY Function : public
GlobalObject,
const Twine , Module );
/// Creates a function with some attributes recorded in llvm.module.flags
- /// applied.
+ /// and the LLVMContext applied.
///
/// Use this when synthesizing new functions that need attributes that would
/// have been set by command line options.
+ ///
+ /// This function should not be called from backends or the LTO pipeline. If
+ /// it is called from one of those places, some default attributes will not
be
+ /// applied to the function.
static Function *createWithDefaultAttr(FunctionType *Ty, LinkageTypes
Linkage,
unsigned AddrSpace,
const Twine = "",
diff --git a/llvm/include/llvm/IR/LLVMContext.h
b/llvm/include/llvm/IR/LLVMContext.h
index 89ad6f1572c67..177d6e1817089 100644
--- a/llvm/include/llvm/IR/LLVMContext.h
+++ b/llvm/include/llvm/IR/LLVMContext.h
@@ -327,6 +327,26 @@ class LLVMContext {
[[deprecated("Always returns false")]]
bool supportsTypedPointers() const;
+ /// Get the current "default" target CPU (target-cpu function attribute). The
+ /// intent is that compiler frontends will set this to a value that reflects
+ /// the attribute that a function would get "by default" without any specific
+ /// function attributes, and compiler passes will attach the attribute to
+ /// newly created functions that are not associated with a particular
+ /// function, such as global initializers. Function::createWithDefaultAttr()
+ /// will create functions with this attribute. This function should only
[clang] [clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From c776e704294a0fc0db478aab9a6a15d8a39202f6 Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH] Support --sysroot= for ${arch}-windows-msvc targets
I think it is possible to use the same rule for msvc targets with
--target= and --sysroot=
See Repository:
https://github.com/trcrsired/windows-msvc-sysroot
Add sysroot support for msvc
MSVC.cpp needs getDriver before using D
add stl in parser for -stdlib=
Add Vcruntime to runtime list and unwind list
MSVC add default runtime lib type and default unwind lib type
add a msvc sysroot test
use %S instead of /foo
Fix test for msvc-sysroot
Also add a pesudo implementation for WebAssembly and
maybe Microsoft STL could be ported to more targets in the future
Fix the toggle of wasm that prevents -stdlib=stl passed into
---
clang/include/clang/Driver/ToolChain.h | 9 +-
clang/lib/Driver/ToolChain.cpp | 9 +
clang/lib/Driver/ToolChains/MSVC.cpp| 248 +++-
clang/lib/Driver/ToolChains/MSVC.h | 24 +-
clang/lib/Driver/ToolChains/WebAssembly.cpp | 29 +++
clang/lib/Driver/ToolChains/WebAssembly.h | 2 +
clang/test/Driver/msvc-sysroot.cpp | 81 +++
clang/test/Driver/wasm-toolchain.cpp| 12 +
8 files changed, 345 insertions(+), 69 deletions(-)
create mode 100644 clang/test/Driver/msvc-sysroot.cpp
diff --git a/clang/include/clang/Driver/ToolChain.h
b/clang/include/clang/Driver/ToolChain.h
index 1f93bd612e9b0..04535a98dd69c 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -95,18 +95,21 @@ class ToolChain {
enum CXXStdlibType {
CST_Libcxx,
-CST_Libstdcxx
+CST_Libstdcxx,
+CST_Stl,
};
enum RuntimeLibType {
RLT_CompilerRT,
-RLT_Libgcc
+RLT_Libgcc,
+RLT_Vcruntime
};
enum UnwindLibType {
UNW_None,
UNW_CompilerRT,
-UNW_Libgcc
+UNW_Libgcc,
+UNW_Vcruntime
};
enum class UnwindTableLevel {
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 40ab2e91125d1..b3ed8fc6de36d 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1091,6 +1091,8 @@ ToolChain::RuntimeLibType ToolChain::GetRuntimeLibType(
runtimeLibType = ToolChain::RLT_CompilerRT;
else if (LibName == "libgcc")
runtimeLibType = ToolChain::RLT_Libgcc;
+ else if (LibName == "vcruntime")
+runtimeLibType = ToolChain::RLT_Vcruntime;
else if (LibName == "platform")
runtimeLibType = GetDefaultRuntimeLibType();
else {
@@ -1129,6 +1131,8 @@ ToolChain::UnwindLibType ToolChain::GetUnwindLibType(
unwindLibType = ToolChain::UNW_CompilerRT;
} else if (LibName == "libgcc")
unwindLibType = ToolChain::UNW_Libgcc;
+ else if (LibName == "vcruntime")
+unwindLibType = ToolChain::UNW_Vcruntime;
else {
if (A)
getDriver().Diag(diag::err_drv_invalid_unwindlib_name)
@@ -1152,6 +1156,8 @@ ToolChain::CXXStdlibType
ToolChain::GetCXXStdlibType(const ArgList ) const{
cxxStdlibType = ToolChain::CST_Libcxx;
else if (LibName == "libstdc++")
cxxStdlibType = ToolChain::CST_Libstdcxx;
+ else if (LibName == "stl")
+cxxStdlibType = ToolChain::CST_Stl;
else if (LibName == "platform")
cxxStdlibType = GetDefaultCXXStdlibType();
else {
@@ -1290,6 +1296,9 @@ void ToolChain::AddCXXStdlibLibArgs(const ArgList ,
case ToolChain::CST_Libstdcxx:
CmdArgs.push_back("-lstdc++");
break;
+
+ default:
+break;
}
}
diff --git a/clang/lib/Driver/ToolChains/MSVC.cpp
b/clang/lib/Driver/ToolChains/MSVC.cpp
index ca266e3e1d1d3..bf1b6d3b9bc84 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -31,12 +31,12 @@
#include
#ifdef _WIN32
- #define WIN32_LEAN_AND_MEAN
- #define NOGDI
- #ifndef NOMINMAX
-#define NOMINMAX
- #endif
- #include
+#define WIN32_LEAN_AND_MEAN
+#define NOGDI
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+#include
#endif
using namespace clang::driver;
@@ -95,43 +95,52 @@ void visualstudio::Linker::ConstructJob(Compilation ,
const JobAction ,
// the environment variable is set however, assume the user knows what
// they're doing. If the user passes /vctoolsdir or /winsdkdir, trust that
// over env vars.
- if (const Arg *A = Args.getLastArg(options::OPT__SLASH_diasdkdir,
- options::OPT__SLASH_winsysroot)) {
-// cl.exe doesn't find the DIA SDK automatically, so this too requires
-// explicit flags and doesn't automatically look in "DIA SDK" relative
-// to the path we found for VCToolChainPath.
-llvm::SmallString<128> DIAPath(A->getValue());
-if (A->getOption().getID() == options::OPT__SLASH_winsysroot)
- llvm::sys::path::append(DIAPath, "DIA SDK");
-
-// The DIA SDK always uses the legacy vc arch, even in
[clang] [PAC][clang][Driver] Add signed GOT flag (PR #96160)
ahmedbougacha wrote: >> Do we want a lot of -fptrauth-xxx instead of -fptrauth-something=xxx,yyy,zzz? > > I would lean towards a single flag. Comma-separated flags generally seem less user-friendly (for, e.g., grepping, modifying, reading). To some extent we can mitigate that with the obvious cleverness (e.g., negatives, repetition), at the cost of a lot more driver logic, and even that would only go so far. Is there a compelling argument for them? > However, I do not know how this would affect Apple downstream and what are > preferences there. Yeah, we do already support the long spellings, but we can change these here if we have consensus, and it should be doable to support the long spellings on top of these. https://github.com/llvm/llvm-project/pull/96160 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/96084
>From 23844cd8b8fad07bce0c34f58430322090c5a793 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 19 Jun 2024 23:25:13 +0800
Subject: [PATCH 1/8] [Clang] Add diagnostic notes for implcitly generated
deduction guides
---
clang/docs/ReleaseNotes.rst | 3 ++
.../clang/Basic/DiagnosticSemaKinds.td| 1 +
clang/lib/Sema/SemaOverload.cpp | 30 +++
clang/test/CXX/drs/cwg26xx.cpp| 3 ++
.../CXX/expr/expr.post/expr.type.conv/p1.cpp | 2 +-
.../over.match.class.deduct/p2.cpp| 2 +-
.../temp.deduct/temp.deduct.call/p3-0x.cpp| 4 +--
clang/test/Modules/template_name_lookup.cpp | 2 ++
clang/test/PCH/cxx-explicit-specifier.cpp | 2 +-
clang/test/Sema/tls_alignment.cpp | 4 ++-
...xx1z-class-template-argument-deduction.cpp | 6 ++--
clang/test/SemaCXX/cxx20-ctad-type-alias.cpp | 17 +--
clang/test/SemaCXX/cxx2a-explicit-bool.cpp| 2 ++
clang/test/SemaCXX/gh65522.cpp| 3 +-
...deduction-guide-as-template-candidates.cpp | 4 ++-
.../lookup-template-name-extern-CXX.cpp | 6 ++--
.../aggregate-deduction-candidate.cpp | 24 ---
clang/test/SemaTemplate/class-template-id.cpp | 2 ++
clang/test/SemaTemplate/ctad.cpp | 6 ++--
clang/test/SemaTemplate/deduction-crash.cpp | 3 +-
clang/test/SemaTemplate/deduction-guide.cpp | 6 ++--
.../nested-implicit-deduction-guides.cpp | 3 ++
clang/test/SemaTemplate/temp_arg.cpp | 4 ++-
23 files changed, 108 insertions(+), 31 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 69aea6c21ad39..423f1e9198948 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -580,6 +580,9 @@ Improvements to Clang's diagnostics
- Clang no longer emits a "declared here" note for a builtin function that has
no declaration in source.
Fixes #GH93369.
+- Clang now emits implicit deduction guides corresponding to non-user-defined
constructors while at a failure
+ of overload resolution.
+
Improvements to Clang's time-trace
--
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index ab223f2b806d5..a65491b0c4399 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2405,6 +2405,7 @@ def err_selected_explicit_constructor : Error<
"chosen constructor is explicit in copy-initialization">;
def note_explicit_ctor_deduction_guide_here : Note<
"explicit %select{constructor|deduction guide}0 declared here">;
+def note_implicit_deduction_guide : Note<"implicit deduction guide declared as
'%0'">;
// C++11 auto
def warn_cxx98_compat_auto_type_specifier : Warning<
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index fb4ff72e42eb5..31b908eb3cc3c 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -40,6 +40,7 @@
#include "llvm/ADT/DenseSet.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/STLForwardCompat.h"
+#include "llvm/ADT/ScopeExit.h"
#include "llvm/ADT/SmallPtrSet.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/SmallVector.h"
@@ -12114,6 +12115,35 @@ static void NoteFunctionCandidate(Sema ,
OverloadCandidate *Cand,
return;
}
+ // If this is an implicit deduction guide against a non-user-defined
+ // constructor, add a note for it. These deduction guides nor their
+ // corresponding constructors are not explicitly spelled in the source code,
+ // and simply producing a deduction failure note around the heading of the
+ // enclosing RecordDecl is confusing.
+ //
+ // We prefer adding such notes at the end of the last deduction failure
+ // reason because duplicate code snippets appearing in the diagnostic
+ // are likely becoming noisy.
+ auto _ = llvm::make_scope_exit([&] {
+auto *DG = dyn_cast(Fn);
+if (!DG || !DG->isImplicit() || DG->getCorrespondingConstructor())
+ return;
+std::string FunctionProto;
+llvm::raw_string_ostream OS(FunctionProto);
+FunctionTemplateDecl *Template = DG->getDescribedFunctionTemplate();
+// This also could be an instantiation. Find out the primary template.
+if (!Template) {
+ FunctionDecl *Pattern = DG->getTemplateInstantiationPattern();
+ assert(Pattern && Pattern->getDescribedFunctionTemplate() &&
+ "Cannot find the associated function template of "
+ "CXXDeductionGuideDecl?");
+ Template = Pattern->getDescribedFunctionTemplate();
+}
+Template->print(OS);
+S.Diag(DG->getLocation(), diag::note_implicit_deduction_guide)
+<< FunctionProto;
+ });
+
switch (Cand->FailureKind) {
case ovl_fail_too_many_arguments:
case ovl_fail_too_few_arguments:
diff
[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/96084
>From 23844cd8b8fad07bce0c34f58430322090c5a793 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 19 Jun 2024 23:25:13 +0800
Subject: [PATCH 1/7] [Clang] Add diagnostic notes for implcitly generated
deduction guides
---
clang/docs/ReleaseNotes.rst | 3 ++
.../clang/Basic/DiagnosticSemaKinds.td| 1 +
clang/lib/Sema/SemaOverload.cpp | 30 +++
clang/test/CXX/drs/cwg26xx.cpp| 3 ++
.../CXX/expr/expr.post/expr.type.conv/p1.cpp | 2 +-
.../over.match.class.deduct/p2.cpp| 2 +-
.../temp.deduct/temp.deduct.call/p3-0x.cpp| 4 +--
clang/test/Modules/template_name_lookup.cpp | 2 ++
clang/test/PCH/cxx-explicit-specifier.cpp | 2 +-
clang/test/Sema/tls_alignment.cpp | 4 ++-
...xx1z-class-template-argument-deduction.cpp | 6 ++--
clang/test/SemaCXX/cxx20-ctad-type-alias.cpp | 17 +--
clang/test/SemaCXX/cxx2a-explicit-bool.cpp| 2 ++
clang/test/SemaCXX/gh65522.cpp| 3 +-
...deduction-guide-as-template-candidates.cpp | 4 ++-
.../lookup-template-name-extern-CXX.cpp | 6 ++--
.../aggregate-deduction-candidate.cpp | 24 ---
clang/test/SemaTemplate/class-template-id.cpp | 2 ++
clang/test/SemaTemplate/ctad.cpp | 6 ++--
clang/test/SemaTemplate/deduction-crash.cpp | 3 +-
clang/test/SemaTemplate/deduction-guide.cpp | 6 ++--
.../nested-implicit-deduction-guides.cpp | 3 ++
clang/test/SemaTemplate/temp_arg.cpp | 4 ++-
23 files changed, 108 insertions(+), 31 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 69aea6c21ad39..423f1e9198948 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -580,6 +580,9 @@ Improvements to Clang's diagnostics
- Clang no longer emits a "declared here" note for a builtin function that has
no declaration in source.
Fixes #GH93369.
+- Clang now emits implicit deduction guides corresponding to non-user-defined
constructors while at a failure
+ of overload resolution.
+
Improvements to Clang's time-trace
--
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index ab223f2b806d5..a65491b0c4399 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2405,6 +2405,7 @@ def err_selected_explicit_constructor : Error<
"chosen constructor is explicit in copy-initialization">;
def note_explicit_ctor_deduction_guide_here : Note<
"explicit %select{constructor|deduction guide}0 declared here">;
+def note_implicit_deduction_guide : Note<"implicit deduction guide declared as
'%0'">;
// C++11 auto
def warn_cxx98_compat_auto_type_specifier : Warning<
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index fb4ff72e42eb5..31b908eb3cc3c 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -40,6 +40,7 @@
#include "llvm/ADT/DenseSet.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/STLForwardCompat.h"
+#include "llvm/ADT/ScopeExit.h"
#include "llvm/ADT/SmallPtrSet.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/SmallVector.h"
@@ -12114,6 +12115,35 @@ static void NoteFunctionCandidate(Sema ,
OverloadCandidate *Cand,
return;
}
+ // If this is an implicit deduction guide against a non-user-defined
+ // constructor, add a note for it. These deduction guides nor their
+ // corresponding constructors are not explicitly spelled in the source code,
+ // and simply producing a deduction failure note around the heading of the
+ // enclosing RecordDecl is confusing.
+ //
+ // We prefer adding such notes at the end of the last deduction failure
+ // reason because duplicate code snippets appearing in the diagnostic
+ // are likely becoming noisy.
+ auto _ = llvm::make_scope_exit([&] {
+auto *DG = dyn_cast(Fn);
+if (!DG || !DG->isImplicit() || DG->getCorrespondingConstructor())
+ return;
+std::string FunctionProto;
+llvm::raw_string_ostream OS(FunctionProto);
+FunctionTemplateDecl *Template = DG->getDescribedFunctionTemplate();
+// This also could be an instantiation. Find out the primary template.
+if (!Template) {
+ FunctionDecl *Pattern = DG->getTemplateInstantiationPattern();
+ assert(Pattern && Pattern->getDescribedFunctionTemplate() &&
+ "Cannot find the associated function template of "
+ "CXXDeductionGuideDecl?");
+ Template = Pattern->getDescribedFunctionTemplate();
+}
+Template->print(OS);
+S.Diag(DG->getLocation(), diag::note_implicit_deduction_guide)
+<< FunctionProto;
+ });
+
switch (Cand->FailureKind) {
case ovl_fail_too_many_arguments:
case ovl_fail_too_few_arguments:
diff
[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/96084
>From 23844cd8b8fad07bce0c34f58430322090c5a793 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 19 Jun 2024 23:25:13 +0800
Subject: [PATCH 1/6] [Clang] Add diagnostic notes for implcitly generated
deduction guides
---
clang/docs/ReleaseNotes.rst | 3 ++
.../clang/Basic/DiagnosticSemaKinds.td| 1 +
clang/lib/Sema/SemaOverload.cpp | 30 +++
clang/test/CXX/drs/cwg26xx.cpp| 3 ++
.../CXX/expr/expr.post/expr.type.conv/p1.cpp | 2 +-
.../over.match.class.deduct/p2.cpp| 2 +-
.../temp.deduct/temp.deduct.call/p3-0x.cpp| 4 +--
clang/test/Modules/template_name_lookup.cpp | 2 ++
clang/test/PCH/cxx-explicit-specifier.cpp | 2 +-
clang/test/Sema/tls_alignment.cpp | 4 ++-
...xx1z-class-template-argument-deduction.cpp | 6 ++--
clang/test/SemaCXX/cxx20-ctad-type-alias.cpp | 17 +--
clang/test/SemaCXX/cxx2a-explicit-bool.cpp| 2 ++
clang/test/SemaCXX/gh65522.cpp| 3 +-
...deduction-guide-as-template-candidates.cpp | 4 ++-
.../lookup-template-name-extern-CXX.cpp | 6 ++--
.../aggregate-deduction-candidate.cpp | 24 ---
clang/test/SemaTemplate/class-template-id.cpp | 2 ++
clang/test/SemaTemplate/ctad.cpp | 6 ++--
clang/test/SemaTemplate/deduction-crash.cpp | 3 +-
clang/test/SemaTemplate/deduction-guide.cpp | 6 ++--
.../nested-implicit-deduction-guides.cpp | 3 ++
clang/test/SemaTemplate/temp_arg.cpp | 4 ++-
23 files changed, 108 insertions(+), 31 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 69aea6c21ad39..423f1e9198948 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -580,6 +580,9 @@ Improvements to Clang's diagnostics
- Clang no longer emits a "declared here" note for a builtin function that has
no declaration in source.
Fixes #GH93369.
+- Clang now emits implicit deduction guides corresponding to non-user-defined
constructors while at a failure
+ of overload resolution.
+
Improvements to Clang's time-trace
--
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index ab223f2b806d5..a65491b0c4399 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2405,6 +2405,7 @@ def err_selected_explicit_constructor : Error<
"chosen constructor is explicit in copy-initialization">;
def note_explicit_ctor_deduction_guide_here : Note<
"explicit %select{constructor|deduction guide}0 declared here">;
+def note_implicit_deduction_guide : Note<"implicit deduction guide declared as
'%0'">;
// C++11 auto
def warn_cxx98_compat_auto_type_specifier : Warning<
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index fb4ff72e42eb5..31b908eb3cc3c 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -40,6 +40,7 @@
#include "llvm/ADT/DenseSet.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/STLForwardCompat.h"
+#include "llvm/ADT/ScopeExit.h"
#include "llvm/ADT/SmallPtrSet.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/SmallVector.h"
@@ -12114,6 +12115,35 @@ static void NoteFunctionCandidate(Sema ,
OverloadCandidate *Cand,
return;
}
+ // If this is an implicit deduction guide against a non-user-defined
+ // constructor, add a note for it. These deduction guides nor their
+ // corresponding constructors are not explicitly spelled in the source code,
+ // and simply producing a deduction failure note around the heading of the
+ // enclosing RecordDecl is confusing.
+ //
+ // We prefer adding such notes at the end of the last deduction failure
+ // reason because duplicate code snippets appearing in the diagnostic
+ // are likely becoming noisy.
+ auto _ = llvm::make_scope_exit([&] {
+auto *DG = dyn_cast(Fn);
+if (!DG || !DG->isImplicit() || DG->getCorrespondingConstructor())
+ return;
+std::string FunctionProto;
+llvm::raw_string_ostream OS(FunctionProto);
+FunctionTemplateDecl *Template = DG->getDescribedFunctionTemplate();
+// This also could be an instantiation. Find out the primary template.
+if (!Template) {
+ FunctionDecl *Pattern = DG->getTemplateInstantiationPattern();
+ assert(Pattern && Pattern->getDescribedFunctionTemplate() &&
+ "Cannot find the associated function template of "
+ "CXXDeductionGuideDecl?");
+ Template = Pattern->getDescribedFunctionTemplate();
+}
+Template->print(OS);
+S.Diag(DG->getLocation(), diag::note_implicit_deduction_guide)
+<< FunctionProto;
+ });
+
switch (Cand->FailureKind) {
case ovl_fail_too_many_arguments:
case ovl_fail_too_few_arguments:
diff
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
+Consequently, if the build system bases recompilation decisions on directly
imported modules only,
+it becomes possible to skip the recompilation of Use.cc.
+It should be fine because the altered interfaces do not affect Use.cc in any
way.
+This concept is called as no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+into the currently written BMI. This ensures that build systems are not
required to consider
+transitively imported modules when deciding on recompilations.
+
+The definition for potential contributory BMIs is implementation defined. We
don't intend to
+display detailed rules for users. The contract is:
+
+1. It is a severe bug if a BMI remains unchanged erroneously following an
observable change
+ that affects its users.
+2. It is an potential improvement opportunity if a BMI changes after an
unobservable change
+ happens.
+
+We suggest build systems to support this feature as a configurable option for
a long time.
+So that users can go back to the transitive change mode safely at any time.
+
+Interactions with Reduced BMI
+~
+
+With reduced BMI, the no transitive change feature can be more powerful if the
change
+can be reduced. For example,
ChuanqiXu9 wrote:
For example,
```
// B.cppm
export module B;
import A;
export int b() { return a(); }
```
If reduced BMI is not enabled, we will record `a()` part in the BMI of `B`,
then we will think module A contributes to module B. Then the BMI of `B` should
change if module A changes like the example shows.
However, if reduced BMI enabled, we won't record the function body for `int
b()`, then module doesn't contributes to module B. So that we can avoid the
changes for B if module A changes like the example shows.
Maybe it will be better to remove the `if the change can be reduced` part. I'll
add a sentence to describe the above idea to make it clear.
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
+Consequently, if the build system bases recompilation decisions on directly
imported modules only,
+it becomes possible to skip the recompilation of Use.cc.
+It should be fine because the altered interfaces do not affect Use.cc in any
way.
+This concept is called as no transitive changes.
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
+Consequently, if the build system bases recompilation decisions on directly
imported modules only,
+it becomes possible to skip the recompilation of Use.cc.
+It should be fine because the altered interfaces do not affect Use.cc in any
way.
+This concept is called as no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+into the currently written BMI. This ensures that build systems are not
required to consider
+transitively imported modules when deciding on recompilations.
+
+The definition for potential contributory BMIs is implementation defined. We
don't intend to
+display detailed rules for users. The contract is:
+
+1. It is a severe bug if a BMI remains unchanged erroneously following an
observable change
+ that affects its users.
+2. It is an potential improvement opportunity if a BMI changes after an
unobservable change
+ happens.
+
+We suggest build systems to support this feature as a configurable option for
a long time.
+So that users can go back to the transitive change mode safely at any time.
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
+Consequently, if the build system bases recompilation decisions on directly
imported modules only,
+it becomes possible to skip the recompilation of Use.cc.
+It should be fine because the altered interfaces do not affect Use.cc in any
way.
+This concept is called as no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+into the currently written BMI. This ensures that build systems are not
required to consider
+transitively imported modules when deciding on recompilations.
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
ChuanqiXu9 wrote:
Done. The suggestion looks good. What do you mean for `an example`? There are a
following example. Do you mean a example that makes the BMI change but actually
it can avoid that?
An example may be:
```
// A.cppm
export module A;
export int a();
```
```
// B.cppm
export module B;
import A;
export inline int b() { return a(); }
```
and we add a unrelated function to A:
```
// A.cppm
export module A;
export int a0();
export int a();
```
Now the users may think the change is unrelated to B and the BMI of B should
keep unchanged. But we can't do that since the used DeclID for `a` in module B
become to `<1, 1>` instead of `<1, 0>` since the new declaration changes the
DeclID.
Is this the example you want? I didn't post this since I feel it has too many
implementation details.
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
+Consequently, if the build system bases recompilation decisions on directly
imported modules only,
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Transitive Change ChuanqiXu9 wrote: > Is it actually experimental if it's the default and there is no way to > disable it? This experiment can only be performed with the build systems. There shouldn't be any risk if the build systems implemented transitive changes model already. In another word, what I did actually provides an opportunity to the build systems to implement this feature. So ideally, the users should be able to disable it in the build system level. > I suggest saying "initial", would it better to capture what we intend to do > (I suspect we want to keep improving this and want feedback where it falls > short)? Yes that we want to keep improving this and want feedback where it falls short. I used `experimental` since I want to mention this feature may not be stable. It might be problematic that some recompilations got skipped but they shouldn't. So that users should go back to traditional mode in such cases. Then I feel `experimental` sounds good for such situations. https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Transitive Change ChuanqiXu9 wrote: > I'd like to find a better term than "no transitive change" -- this doesn't > work well as a noun phrase in English, so we say awkward things like "...the > no transitive change feature can be more powerful if ..." I think what > bothers me about is the "no" and "change" part -- "change" is a verb, so it > comes out sounding verb-like and we end up tacking on "feature" to try to > make it a noun again. While I respect the feelings from native speakers, Google told me that `change` can be a noun too. For the `no` part, may be we can use the term `less`? So that the feature name become to `less transitive change`, which may be more precise since there should always some changes are transitive. > "no-cascade" feature? I didn't know this word `cascade` before. I think it may be appropriate after I searched it. I can replace with it if we're happy with that. > "isolated BMI" `isolated` may not be accurate. Since the BMI still depends on other BMIs. https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Transitive Change +- + +Starting with clang19.x, we introduced an experimental feature: the non-transitive ChuanqiXu9 wrote: Done https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -229,6 +229,10 @@ C++20 Feature Support will now work. (#GH62925). +- Clang refactored the BMI format to make it possible to support no transitive changes ChuanqiXu9 wrote: Good suggestions. Applied. (Just change `should` to `can`. Since I feel `should` read like users can get this benefit directly. But it is not the case. They need helps from build systems). And I put this into the `What's New in Clang |release|?` section, which is highest except the `Potentially Breaking Change` section. https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/96453
>From a035ae25314f3168f73108988f2bb7671e7d9e7f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 24 Jun 2024 11:41:23 +0800
Subject: [PATCH 1/2] [Doc] Update documentation for no-transitive-change
---
clang/docs/ReleaseNotes.rst | 4 +
clang/docs/StandardCPlusPlusModules.rst | 128
2 files changed, 132 insertions(+)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 9c8f8c4a4fbaf..89e433870c9ff 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -229,6 +229,10 @@ C++20 Feature Support
will now work.
(#GH62925).
+- Clang refactored the BMI format to make it possible to support no transitive
changes
+ mode for modules. See `StandardCPlusPlusModules
`_ for
+ details.
+
C++23 Feature Support
^
diff --git a/clang/docs/StandardCPlusPlusModules.rst
b/clang/docs/StandardCPlusPlusModules.rst
index 1c3c4d319c0e1..68854636e617d 100644
--- a/clang/docs/StandardCPlusPlusModules.rst
+++ b/clang/docs/StandardCPlusPlusModules.rst
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+Starting with clang19.x, we introduced an experimental feature: the
non-transitive
+change for modules, aimed at reducing unnecessary recompilations. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+Now let's compile the project (For brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then let's change the interface of ``m-partA.cppm`` to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+Let's compile the BMI for `useBOnly` again:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+We observed that the contents of useBOnly.pcm remain unchanged.
+Consequently, if the build system bases recompilation decisions on directly
imported modules only,
+it becomes possible to skip the recompilation of Use.cc.
+It should be fine because the altered interfaces do not affect Use.cc in any
way.
+This concept is called as no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+into the currently written BMI. This ensures that build systems are not
required to consider
+transitively imported modules when deciding on recompilations.
+
+The definition for potential contributory BMIs is implementation defined. We
don't intend to
+display detailed rules for users. The contract is:
+
+1. It is a severe bug if a BMI remains unchanged erroneously following an
observable change
+ that affects its users.
+2. It is an potential improvement opportunity if a BMI changes after an
unobservable change
+ happens.
+
+We suggest build systems to support this feature as a configurable option for
a long time.
+So that users can go back to the transitive change mode safely at any time.
+
+Interactions with Reduced BMI
+~
+
+With reduced BMI, the no transitive change feature can be more powerful if the
change
+can be reduced. For example,
+
+.. code-block:: c++
+
+ // A.cppm
+ export module A;
+ export int a() { return 44; }
+
+ // B.cppm
+ export module B;
+ import A;
+ export int b() { return a(); }
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 A.cppm -c -fmodule-output=A.pcm
-fexperimental-modules-reduced-bmi -o A.o
+ $ clang++ -std=c++20 B.cppm -c -fmodule-output=B.pcm
-fexperimental-modules-reduced-bmi -o B.o -fmodule-file=A=A.pcm
+ $md5sum B.pcm
+ 6c2bd452ca32ab418bf35cd141b060b9
[clang] [compiler-rt] [libcxx] [libunwind] [llvm] [openmp] [cmake] switch to CMake's native `check_{compiler,linker}_flag` (PR #96171)
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/96171
>From 1df587efeb71fb1929667f008d7e9b251863d9d8 Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 21:43:31 +1100
Subject: [PATCH 1/4] [cmake] switch to CMake's native check_linker_flag,
delete LLVMCheckLinkerFlag.cmake
now that CMake baseline has moved past 3.18; see
https://cmake.org/cmake/help/latest/module/CheckLinkerFlag.html
---
clang/tools/driver/CMakeLists.txt| 4 +--
llvm/cmake/modules/AddLLVM.cmake | 4 +--
llvm/cmake/modules/HandleLLVMOptions.cmake | 8 +++---
llvm/cmake/modules/HandleLLVMStdlib.cmake| 6 ++---
llvm/cmake/modules/LLVMCheckLinkerFlag.cmake | 28
5 files changed, 11 insertions(+), 39 deletions(-)
delete mode 100644 llvm/cmake/modules/LLVMCheckLinkerFlag.cmake
diff --git a/clang/tools/driver/CMakeLists.txt
b/clang/tools/driver/CMakeLists.txt
index 290bf2a42536d..018605c2fd4f2 100644
--- a/clang/tools/driver/CMakeLists.txt
+++ b/clang/tools/driver/CMakeLists.txt
@@ -107,7 +107,7 @@ endif()
if(CLANG_ORDER_FILE AND
(LLVM_LINKER_IS_APPLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
- include(LLVMCheckLinkerFlag)
+ include(CheckLinkerFlag)
if (LLVM_LINKER_IS_APPLE OR (LLVM_LINKER_IS_LLD AND APPLE))
set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
@@ -118,7 +118,7 @@ if(CLANG_ORDER_FILE AND
endif()
# This is a test to ensure the actual order file works with the linker.
- llvm_check_linker_flag(CXX ${LINKER_ORDER_FILE_OPTION}
LINKER_ORDER_FILE_WORKS)
+ check_linker_flag(CXX ${LINKER_ORDER_FILE_OPTION} LINKER_ORDER_FILE_WORKS)
# Passing an empty order file disables some linker layout optimizations.
# To work around this and enable workflows for re-linking when the order file
diff --git a/llvm/cmake/modules/AddLLVM.cmake b/llvm/cmake/modules/AddLLVM.cmake
index 03f4e1f190fd9..cac5470435d91 100644
--- a/llvm/cmake/modules/AddLLVM.cmake
+++ b/llvm/cmake/modules/AddLLVM.cmake
@@ -327,8 +327,8 @@ function(add_link_opts target_name)
elseif(${CMAKE_SYSTEM_NAME} MATCHES "SunOS" AND LLVM_LINKER_IS_SOLARISLD)
# Support for ld -z discard-unused=sections was only added in
# Solaris 11.4. GNU ld ignores it, but warns every time.
-include(LLVMCheckLinkerFlag)
-llvm_check_linker_flag(CXX "-Wl,-z,discard-unused=sections"
LINKER_SUPPORTS_Z_DISCARD_UNUSED)
+include(CheckLinkerFlag)
+check_linker_flag(CXX "-Wl,-z,discard-unused=sections"
LINKER_SUPPORTS_Z_DISCARD_UNUSED)
if (LINKER_SUPPORTS_Z_DISCARD_UNUSED)
set_property(TARGET ${target_name} APPEND_STRING PROPERTY
LINK_FLAGS " -Wl,-z,discard-unused=sections")
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 5ca580fbb59c5..bdbd36174fc7a 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1061,8 +1061,8 @@ if (LLVM_USE_SPLIT_DWARF AND
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR
CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
add_compile_options($<$:-gsplit-dwarf>)
-include(LLVMCheckLinkerFlag)
-llvm_check_linker_flag(CXX "-Wl,--gdb-index" LINKER_SUPPORTS_GDB_INDEX)
+include(CheckLinkerFlag)
+check_linker_flag(CXX "-Wl,--gdb-index" LINKER_SUPPORTS_GDB_INDEX)
append_if(LINKER_SUPPORTS_GDB_INDEX "-Wl,--gdb-index"
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
@@ -1083,8 +1083,8 @@ endif()
# lld doesn't print colored diagnostics when invoked from Ninja
if (UNIX AND CMAKE_GENERATOR MATCHES "Ninja")
- include(LLVMCheckLinkerFlag)
- llvm_check_linker_flag(CXX "-Wl,--color-diagnostics"
LINKER_SUPPORTS_COLOR_DIAGNOSTICS)
+ include(CheckLinkerFlag)
+ check_linker_flag(CXX "-Wl,--color-diagnostics"
LINKER_SUPPORTS_COLOR_DIAGNOSTICS)
append_if(LINKER_SUPPORTS_COLOR_DIAGNOSTICS "-Wl,--color-diagnostics"
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()
diff --git a/llvm/cmake/modules/HandleLLVMStdlib.cmake
b/llvm/cmake/modules/HandleLLVMStdlib.cmake
index 7afc10cff74ff..a7e138aa0789b 100644
--- a/llvm/cmake/modules/HandleLLVMStdlib.cmake
+++ b/llvm/cmake/modules/HandleLLVMStdlib.cmake
@@ -13,12 +13,12 @@ if(NOT DEFINED LLVM_STDLIB_HANDLED)
endfunction()
include(CheckCXXCompilerFlag)
- include(LLVMCheckLinkerFlag)
+ include(CheckLinkerFlag)
set(LLVM_LIBCXX_USED 0)
if(LLVM_ENABLE_LIBCXX)
if(LLVM_COMPILER_IS_GCC_COMPATIBLE)
check_cxx_compiler_flag("-stdlib=libc++" CXX_COMPILER_SUPPORTS_STDLIB)
- llvm_check_linker_flag(CXX "-stdlib=libc++" CXX_LINKER_SUPPORTS_STDLIB)
+ check_linker_flag(CXX "-stdlib=libc++" CXX_LINKER_SUPPORTS_STDLIB)
if(CXX_COMPILER_SUPPORTS_STDLIB AND CXX_LINKER_SUPPORTS_STDLIB)
append("-stdlib=libc++"
CMAKE_CXX_FLAGS
[libunwind] [llvm] [runtimes] remove workaround for old CMake when setting `--unwindlib=none` (PR #93429)
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/93429
>From 8c1b899aa174b107fece1edbf99eaf261bdea516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 25 Apr 2022 09:45:22 +0300
Subject: [PATCH 1/3] [runtimes] [CMake] Use CMAKE_REQUIRED_LINK_OPTIONS to
simplify handling of the --unwindlib=none option
This avoids passing the option unnecessarily to compilation commands
(where it causes warnings).
This fails in practice with libunwind, where setting
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY breaks it, as
the option from CMAKE_REQUIRED_LINK_OPTIONS ends up passed to the "ar"
tool too.
---
libunwind/CMakeLists.txt | 3 +++
runtimes/CMakeLists.txt | 22 +-
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index b22ade0a7d71e..3d2fadca9d2ec 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -221,9 +221,12 @@ add_cxx_compile_flags_if_supported(-EHsc)
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
+set(_previous_CMAKE_REQUIRED_LINK_OPTIONS ${CMAKE_REQUIRED_LINK_OPTIONS})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
+set(CMAKE_REQUIRED_LINK_OPTIONS)
add_compile_flags_if_supported(-funwind-tables)
set(CMAKE_TRY_COMPILE_TARGET_TYPE ${_previous_CMAKE_TRY_COMPILE_TARGET_TYPE})
+set(CMAKE_REQUIRED_LINK_OPTIONS ${_previous_CMAKE_REQUIRED_LINK_OPTIONS})
if (LIBUNWIND_USES_ARM_EHABI AND NOT CXX_SUPPORTS_FUNWIND_TABLES_FLAG)
message(SEND_ERROR "The -funwind-tables flag must be supported "
diff --git a/runtimes/CMakeLists.txt b/runtimes/CMakeLists.txt
index 24f4851169591..8f909322c9a98 100644
--- a/runtimes/CMakeLists.txt
+++ b/runtimes/CMakeLists.txt
@@ -116,27 +116,7 @@
filter_prefixed("${CMAKE_ASM_IMPLICIT_INCLUDE_DIRECTORIES}" ${LLVM_BINARY_DIR} C
# brittle. We should ideally move this to runtimes/CMakeLists.txt.
llvm_check_compiler_linker_flag(C "--unwindlib=none"
CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
if (CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
- set(ORIG_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
- set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} --unwindlib=none")
- # TODO: When we can require CMake 3.14, we should use
- # CMAKE_REQUIRED_LINK_OPTIONS here. Until then, we need a workaround:
- # When using CMAKE_REQUIRED_FLAGS, this option gets added both to
- # compilation and linking commands. That causes warnings in the
- # compilation commands during cmake tests. This is normally benign, but
- # when testing whether -Werror works, that test fails (due to the
- # preexisting warning).
- #
- # Therefore, before we can use CMAKE_REQUIRED_LINK_OPTIONS, check if we
- # can use --start-no-unused-arguments to silence the warnings about
- # --unwindlib=none during compilation.
- #
- # We must first add --unwindlib=none to CMAKE_REQUIRED_FLAGS above, to
- # allow this subsequent test to succeed, then rewrite CMAKE_REQUIRED_FLAGS
- # below.
- check_c_compiler_flag("--start-no-unused-arguments"
C_SUPPORTS_START_NO_UNUSED_ARGUMENTS)
- if (C_SUPPORTS_START_NO_UNUSED_ARGUMENTS)
-set(CMAKE_REQUIRED_FLAGS "${ORIG_CMAKE_REQUIRED_FLAGS}
--start-no-unused-arguments --unwindlib=none --end-no-unused-arguments")
- endif()
+ list(APPEND CMAKE_REQUIRED_LINK_OPTIONS "--unwindlib=none")
endif()
# Disable use of the installed C++ standard library when building runtimes.
>From 816e9e6d81ac12537879406e0495fc80394a1a66 Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 23:18:51 +1100
Subject: [PATCH 2/3] add comment (and CMake issue reference) about
incompatible options
---
libunwind/CMakeLists.txt | 4
1 file changed, 4 insertions(+)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index 3d2fadca9d2ec..d84f8fa6ff954 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -220,6 +220,10 @@ add_cxx_compile_flags_if_supported(-EHsc)
#
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
+#
+# NOTE: we need to work around
https://gitlab.kitware.com/cmake/cmake/-/issues/23454
+# because CMAKE_REQUIRED_LINK_OPTIONS (c.f.
CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
+# is incompatible with CMAKE_TRY_COMPILE_TARGET_TYPE==STATIC_LIBRARY.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
set(_previous_CMAKE_REQUIRED_LINK_OPTIONS ${CMAKE_REQUIRED_LINK_OPTIONS})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
>From 3f917d22bdcd8b398cf7162563547418a056ecec Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 23:18:51 +1100
Subject: [PATCH 3/3] [cmake] move check for `-fno-exceptions` to "safe zone"
w.r.t. interference between CMAKE_REQUIRED_LINK_OPTIONS and static libraries
---
libunwind/CMakeLists.txt | 2 +-
[libunwind] [llvm] [runtimes] remove workaround for old CMake when setting `--unwindlib=none` (PR #93429)
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/93429
>From 8c1b899aa174b107fece1edbf99eaf261bdea516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 25 Apr 2022 09:45:22 +0300
Subject: [PATCH 1/3] [runtimes] [CMake] Use CMAKE_REQUIRED_LINK_OPTIONS to
simplify handling of the --unwindlib=none option
This avoids passing the option unnecessarily to compilation commands
(where it causes warnings).
This fails in practice with libunwind, where setting
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY breaks it, as
the option from CMAKE_REQUIRED_LINK_OPTIONS ends up passed to the "ar"
tool too.
---
libunwind/CMakeLists.txt | 3 +++
runtimes/CMakeLists.txt | 22 +-
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index b22ade0a7d71e..3d2fadca9d2ec 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -221,9 +221,12 @@ add_cxx_compile_flags_if_supported(-EHsc)
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
+set(_previous_CMAKE_REQUIRED_LINK_OPTIONS ${CMAKE_REQUIRED_LINK_OPTIONS})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
+set(CMAKE_REQUIRED_LINK_OPTIONS)
add_compile_flags_if_supported(-funwind-tables)
set(CMAKE_TRY_COMPILE_TARGET_TYPE ${_previous_CMAKE_TRY_COMPILE_TARGET_TYPE})
+set(CMAKE_REQUIRED_LINK_OPTIONS ${_previous_CMAKE_REQUIRED_LINK_OPTIONS})
if (LIBUNWIND_USES_ARM_EHABI AND NOT CXX_SUPPORTS_FUNWIND_TABLES_FLAG)
message(SEND_ERROR "The -funwind-tables flag must be supported "
diff --git a/runtimes/CMakeLists.txt b/runtimes/CMakeLists.txt
index 24f4851169591..8f909322c9a98 100644
--- a/runtimes/CMakeLists.txt
+++ b/runtimes/CMakeLists.txt
@@ -116,27 +116,7 @@
filter_prefixed("${CMAKE_ASM_IMPLICIT_INCLUDE_DIRECTORIES}" ${LLVM_BINARY_DIR} C
# brittle. We should ideally move this to runtimes/CMakeLists.txt.
llvm_check_compiler_linker_flag(C "--unwindlib=none"
CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
if (CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
- set(ORIG_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
- set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} --unwindlib=none")
- # TODO: When we can require CMake 3.14, we should use
- # CMAKE_REQUIRED_LINK_OPTIONS here. Until then, we need a workaround:
- # When using CMAKE_REQUIRED_FLAGS, this option gets added both to
- # compilation and linking commands. That causes warnings in the
- # compilation commands during cmake tests. This is normally benign, but
- # when testing whether -Werror works, that test fails (due to the
- # preexisting warning).
- #
- # Therefore, before we can use CMAKE_REQUIRED_LINK_OPTIONS, check if we
- # can use --start-no-unused-arguments to silence the warnings about
- # --unwindlib=none during compilation.
- #
- # We must first add --unwindlib=none to CMAKE_REQUIRED_FLAGS above, to
- # allow this subsequent test to succeed, then rewrite CMAKE_REQUIRED_FLAGS
- # below.
- check_c_compiler_flag("--start-no-unused-arguments"
C_SUPPORTS_START_NO_UNUSED_ARGUMENTS)
- if (C_SUPPORTS_START_NO_UNUSED_ARGUMENTS)
-set(CMAKE_REQUIRED_FLAGS "${ORIG_CMAKE_REQUIRED_FLAGS}
--start-no-unused-arguments --unwindlib=none --end-no-unused-arguments")
- endif()
+ list(APPEND CMAKE_REQUIRED_LINK_OPTIONS "--unwindlib=none")
endif()
# Disable use of the installed C++ standard library when building runtimes.
>From 816e9e6d81ac12537879406e0495fc80394a1a66 Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 23:18:51 +1100
Subject: [PATCH 2/3] add comment (and CMake issue reference) about
incompatible options
---
libunwind/CMakeLists.txt | 4
1 file changed, 4 insertions(+)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index 3d2fadca9d2ec..d84f8fa6ff954 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -220,6 +220,10 @@ add_cxx_compile_flags_if_supported(-EHsc)
#
# This leads to libunwind not being built with this flag, which makes
# libunwind quite useless in this setup.
+#
+# NOTE: we need to work around
https://gitlab.kitware.com/cmake/cmake/-/issues/23454
+# because CMAKE_REQUIRED_LINK_OPTIONS (c.f.
CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG)
+# is incompatible with CMAKE_TRY_COMPILE_TARGET_TYPE==STATIC_LIBRARY.
set(_previous_CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
set(_previous_CMAKE_REQUIRED_LINK_OPTIONS ${CMAKE_REQUIRED_LINK_OPTIONS})
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
>From 48764a8434e66ba0c48ea062522720ff886c748e Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 23:18:51 +1100
Subject: [PATCH 3/3] [cmake] add comment (and CMake issue reference) about
incompatible options
w.r.t. interference between CMAKE_REQUIRED_LINK_OPTIONS and static libraries
---
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
@@ -327,6 +327,26 @@ class LLVMContext {
[[deprecated("Always returns false")]]
bool supportsTypedPointers() const;
+ /// Get the current "default" target CPU (target-cpu function attribute). The
+ /// intent is that compiler frontends will set this to a value that reflects
+ /// the attribute that a function would get "by default" without any specific
+ /// function attributes, and compiler passes will attach the attribute to
+ /// newly created functions that are not associated with a particular
+ /// function, such as global initializers. Function::createWithDefaultAttr()
+ /// will create functions with this attribute. This function should only be
+ /// called by passes that run at compile time and not by the backend or LTO
+ /// passes.
+ StringRef getDefaultTargetCPU();
+
+ /// See getDefaultTargetCPU().
+ void setDefaultTargetCPU(StringRef CPU);
+
+ /// Similar to getDefaultTargetCPU() but for default target-features instead.
+ StringRef getDefaultTargetFeatures();
+
+ /// See getDefaultTargetFeatures().
+ void setDefaultTargetFeatures(StringRef Features);
+
MaskRay wrote:
I agree with your analysis about "no serialization". I think we may have a lot
of getters/setters.
Perhaps make a pair of getter/setter share the same comment so that it will
look conciser?
```
// xxx
StringRef getDefaultTargetFeatures();
void setDefaultTargetFeatures(StringRef Features);
// yyy
StringRef getDefaultTargetFeatures();
void setDefaultTargetFeatures(StringRef Features);
```
https://github.com/llvm/llvm-project/pull/96721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
https://github.com/MaskRay approved this pull request. https://github.com/llvm/llvm-project/pull/96721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
https://github.com/MaskRay edited https://github.com/llvm/llvm-project/pull/96721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
@@ -0,0 +1,17 @@ +// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30 -fsanitize=hwaddress %s -o %t MaskRay wrote: Prefer %clang_cc1 in non-driver tests https://github.com/llvm/llvm-project/pull/96721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
llvmbot wrote:
@llvm/pr-subscribers-llvm-ir
Author: None (pcc)
Changes
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature), clobbering registers specified via -ffixed-*
(missing reserve-* feature), and so on.
There's already a number of attributes copied from the module flags
onto functions created by createWithDefaultAttr(). I don't think
module flags are the right choice for the target attributes because
we don't need the conflict resolution logic between modules with
different target attributes, nor does it seem sensible to add it:
there's no unambiguously "correct" set of target attributes when
merging two modules with different attributes, and nor should there
be; it's perfectly valid for two modules to be compiled with different
target attributes, that's the whole reason why they are per-function.
This also implies that it's unnecessary to serialize the attributes in
bitcode, which implies that they shouldn't be stored on the module. We
can also observe that for the most part, createWithDefaultAttr()
is called from compiler passes such as sanitizers, coverage and
profiling passes that are part of the compile time pipeline, not
the LTO pipeline. This hints at a solution: we need to store the
attributes in a non-serialized location associated with the ambient
compilation context. Therefore in this patch I elected to store the
attributes on the LLVMContext.
There are calls to createWithDefaultAttr() in the NVPTX and AMDGPU
backends, and those calls would happen at LTO time. For those callers,
the bug still potentially exists and it would be necessary to refactor
them to create the functions at compile time if this issue is relevant
on those platforms.
Fixes #93633.
---
Full diff: https://github.com/llvm/llvm-project/pull/96721.diff
7 Files Affected:
- (modified) clang/lib/CodeGen/CodeGenAction.cpp (+6)
- (added) clang/test/CodeGen/coverage-target-attr.c (+17)
- (modified) llvm/include/llvm/IR/Function.h (+5-1)
- (modified) llvm/include/llvm/IR/LLVMContext.h (+20)
- (modified) llvm/lib/IR/Function.cpp (+6)
- (modified) llvm/lib/IR/LLVMContext.cpp (+16)
- (modified) llvm/lib/IR/LLVMContextImpl.h (+3)
``diff
diff --git a/clang/lib/CodeGen/CodeGenAction.cpp
b/clang/lib/CodeGen/CodeGenAction.cpp
index 6d3efdb5ffe34..7766383fdc890 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -299,6 +299,9 @@ void BackendConsumer::HandleTranslationUnit(ASTContext ) {
Ctx.setDiagnosticHandler(std::make_unique(
CodeGenOpts, this));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
@@ -1205,6 +1208,9 @@ void CodeGenAction::ExecuteAction() {
Ctx.setDiagnosticHandler(
std::make_unique(CodeGenOpts, ));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
diff --git a/clang/test/CodeGen/coverage-target-attr.c
b/clang/test/CodeGen/coverage-target-attr.c
new file mode 100644
index 0..3929d7b43df69
--- /dev/null
+++ b/clang/test/CodeGen/coverage-target-attr.c
@@ -0,0 +1,17 @@
+// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30
-fsanitize=hwaddress %s -o %t
+// RUN: FileCheck %s < %t
+
+// CHECK: define internal void @__llvm_gcov_writeout() unnamed_addr
[[ATTR:#[0-9]+]]
+// CHECK: define internal void @__llvm_gcov_reset() unnamed_addr [[ATTR]]
+// CHECK: define internal void @__llvm_gcov_init() unnamed_addr [[ATTR]]
+// CHECK: define internal void @hwasan.module_ctor() [[ATTR2:#[0-9]+]]
+// CHECK: attributes [[ATTR]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+// CHECK: attributes [[ATTR2]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+
+__attribute__((weak)) int foo = 0;
+
+__attribute__((weak)) void bar() {}
+
+int main() {
+ if (foo) bar();
+}
diff --git a/llvm/include/llvm/IR/Function.h b/llvm/include/llvm/IR/Function.h
index 5468cedb0815a..6bd997b7ac75a 100644
--- a/llvm/include/llvm/IR/Function.h
+++ b/llvm/include/llvm/IR/Function.h
@@ -181,10 +181,14 @@ class LLVM_EXTERNAL_VISIBILITY Function : public
GlobalObject,
const Twine , Module );
/// Creates a function with some attributes recorded in llvm.module.flags
- /// applied.
+ /// and the LLVMContext applied.
///
/// Use this when synthesizing new
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (pcc)
Changes
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature), clobbering registers specified via -ffixed-*
(missing reserve-* feature), and so on.
There's already a number of attributes copied from the module flags
onto functions created by createWithDefaultAttr(). I don't think
module flags are the right choice for the target attributes because
we don't need the conflict resolution logic between modules with
different target attributes, nor does it seem sensible to add it:
there's no unambiguously "correct" set of target attributes when
merging two modules with different attributes, and nor should there
be; it's perfectly valid for two modules to be compiled with different
target attributes, that's the whole reason why they are per-function.
This also implies that it's unnecessary to serialize the attributes in
bitcode, which implies that they shouldn't be stored on the module. We
can also observe that for the most part, createWithDefaultAttr()
is called from compiler passes such as sanitizers, coverage and
profiling passes that are part of the compile time pipeline, not
the LTO pipeline. This hints at a solution: we need to store the
attributes in a non-serialized location associated with the ambient
compilation context. Therefore in this patch I elected to store the
attributes on the LLVMContext.
There are calls to createWithDefaultAttr() in the NVPTX and AMDGPU
backends, and those calls would happen at LTO time. For those callers,
the bug still potentially exists and it would be necessary to refactor
them to create the functions at compile time if this issue is relevant
on those platforms.
Fixes #93633.
---
Full diff: https://github.com/llvm/llvm-project/pull/96721.diff
7 Files Affected:
- (modified) clang/lib/CodeGen/CodeGenAction.cpp (+6)
- (added) clang/test/CodeGen/coverage-target-attr.c (+17)
- (modified) llvm/include/llvm/IR/Function.h (+5-1)
- (modified) llvm/include/llvm/IR/LLVMContext.h (+20)
- (modified) llvm/lib/IR/Function.cpp (+6)
- (modified) llvm/lib/IR/LLVMContext.cpp (+16)
- (modified) llvm/lib/IR/LLVMContextImpl.h (+3)
``diff
diff --git a/clang/lib/CodeGen/CodeGenAction.cpp
b/clang/lib/CodeGen/CodeGenAction.cpp
index 6d3efdb5ffe34..7766383fdc890 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -299,6 +299,9 @@ void BackendConsumer::HandleTranslationUnit(ASTContext ) {
Ctx.setDiagnosticHandler(std::make_unique(
CodeGenOpts, this));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
@@ -1205,6 +1208,9 @@ void CodeGenAction::ExecuteAction() {
Ctx.setDiagnosticHandler(
std::make_unique(CodeGenOpts, ));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
diff --git a/clang/test/CodeGen/coverage-target-attr.c
b/clang/test/CodeGen/coverage-target-attr.c
new file mode 100644
index 0..3929d7b43df69
--- /dev/null
+++ b/clang/test/CodeGen/coverage-target-attr.c
@@ -0,0 +1,17 @@
+// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30
-fsanitize=hwaddress %s -o %t
+// RUN: FileCheck %s < %t
+
+// CHECK: define internal void @__llvm_gcov_writeout() unnamed_addr
[[ATTR:#[0-9]+]]
+// CHECK: define internal void @__llvm_gcov_reset() unnamed_addr [[ATTR]]
+// CHECK: define internal void @__llvm_gcov_init() unnamed_addr [[ATTR]]
+// CHECK: define internal void @hwasan.module_ctor() [[ATTR2:#[0-9]+]]
+// CHECK: attributes [[ATTR]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+// CHECK: attributes [[ATTR2]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+
+__attribute__((weak)) int foo = 0;
+
+__attribute__((weak)) void bar() {}
+
+int main() {
+ if (foo) bar();
+}
diff --git a/llvm/include/llvm/IR/Function.h b/llvm/include/llvm/IR/Function.h
index 5468cedb0815a..6bd997b7ac75a 100644
--- a/llvm/include/llvm/IR/Function.h
+++ b/llvm/include/llvm/IR/Function.h
@@ -181,10 +181,14 @@ class LLVM_EXTERNAL_VISIBILITY Function : public
GlobalObject,
const Twine , Module );
/// Creates a function with some attributes recorded in llvm.module.flags
- /// applied.
+ /// and the LLVMContext applied.
///
/// Use this when synthesizing new functions
[clang] [llvm] CodeGen, IR: Add target-{cpu,features} attributes to functions created via createWithDefaultAttr(). (PR #96721)
https://github.com/pcc created https://github.com/llvm/llvm-project/pull/96721
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature), clobbering registers specified via -ffixed-*
(missing reserve-* feature), and so on.
There's already a number of attributes copied from the module flags
onto functions created by createWithDefaultAttr(). I don't think
module flags are the right choice for the target attributes because
we don't need the conflict resolution logic between modules with
different target attributes, nor does it seem sensible to add it:
there's no unambiguously "correct" set of target attributes when
merging two modules with different attributes, and nor should there
be; it's perfectly valid for two modules to be compiled with different
target attributes, that's the whole reason why they are per-function.
This also implies that it's unnecessary to serialize the attributes in
bitcode, which implies that they shouldn't be stored on the module. We
can also observe that for the most part, createWithDefaultAttr()
is called from compiler passes such as sanitizers, coverage and
profiling passes that are part of the compile time pipeline, not
the LTO pipeline. This hints at a solution: we need to store the
attributes in a non-serialized location associated with the ambient
compilation context. Therefore in this patch I elected to store the
attributes on the LLVMContext.
There are calls to createWithDefaultAttr() in the NVPTX and AMDGPU
backends, and those calls would happen at LTO time. For those callers,
the bug still potentially exists and it would be necessary to refactor
them to create the functions at compile time if this issue is relevant
on those platforms.
Fixes #93633.
>From 14e72c19daefd09b6cfe7e99865b89afa8c5a4d8 Mon Sep 17 00:00:00 2001
From: Peter Collingbourne
Date: Tue, 25 Jun 2024 19:16:01 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.6-beta.1
---
clang/lib/CodeGen/CodeGenAction.cpp | 6 ++
clang/test/CodeGen/coverage-target-attr.c | 17 +
llvm/include/llvm/IR/Function.h | 6 +-
llvm/include/llvm/IR/LLVMContext.h| 20
llvm/lib/IR/Function.cpp | 6 ++
llvm/lib/IR/LLVMContext.cpp | 16
llvm/lib/IR/LLVMContextImpl.h | 3 +++
7 files changed, 73 insertions(+), 1 deletion(-)
create mode 100644 clang/test/CodeGen/coverage-target-attr.c
diff --git a/clang/lib/CodeGen/CodeGenAction.cpp
b/clang/lib/CodeGen/CodeGenAction.cpp
index 6d3efdb5ffe34..7766383fdc890 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -299,6 +299,9 @@ void BackendConsumer::HandleTranslationUnit(ASTContext ) {
Ctx.setDiagnosticHandler(std::make_unique(
CodeGenOpts, this));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
@@ -1205,6 +1208,9 @@ void CodeGenAction::ExecuteAction() {
Ctx.setDiagnosticHandler(
std::make_unique(CodeGenOpts, ));
+ Ctx.setDefaultTargetCPU(TargetOpts.CPU);
+ Ctx.setDefaultTargetFeatures(llvm::join(TargetOpts.Features, ","));
+
Expected> OptRecordFileOrErr =
setupLLVMOptimizationRemarks(
Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
diff --git a/clang/test/CodeGen/coverage-target-attr.c
b/clang/test/CodeGen/coverage-target-attr.c
new file mode 100644
index 0..3929d7b43df69
--- /dev/null
+++ b/clang/test/CodeGen/coverage-target-attr.c
@@ -0,0 +1,17 @@
+// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30
-fsanitize=hwaddress %s -o %t
+// RUN: FileCheck %s < %t
+
+// CHECK: define internal void @__llvm_gcov_writeout() unnamed_addr
[[ATTR:#[0-9]+]]
+// CHECK: define internal void @__llvm_gcov_reset() unnamed_addr [[ATTR]]
+// CHECK: define internal void @__llvm_gcov_init() unnamed_addr [[ATTR]]
+// CHECK: define internal void @hwasan.module_ctor() [[ATTR2:#[0-9]+]]
+// CHECK: attributes [[ATTR]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+// CHECK: attributes [[ATTR2]] = {{.*}} "target-cpu"="generic"
"target-features"="+fix-cortex-a53-835769,+fp-armv8,+neon,+outline-atomics,+tagged-globals,+v8a"
+
+__attribute__((weak)) int foo = 0;
+
+__attribute__((weak)) void bar() {}
+
+int main() {
+ if (foo) bar();
+}
diff --git a/llvm/include/llvm/IR/Function.h b/llvm/include/llvm/IR/Function.h
index
[clang] Add documentation for `__builtin_object_size`. (PR #96573)
bwendling wrote:
This LGTM as well. I have a question about the "sub-object" part. Do we attempt
to discover the sub-object past any casting? A motivating example:
```c
char mux[10][10][10];
printf("%ld\n", __builtin_dynamic_object_size(&((char *)[1][1])[var], 1));
```
GCC prints `89` (when `var` is 1). In the changes I'm making to the sub-object
calculations, I want to say that this should print `9`, because the sub-object
is `mux[1][1]` and not a one-dimensional array. There could be arguments made
for both options, so I'd like to get everyone's opinions.
https://github.com/llvm/llvm-project/pull/96573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] CTAD: Generate deduction guides for alias templates from non-template explicit deduction guides (PR #96686)
https://github.com/zyn0217 edited https://github.com/llvm/llvm-project/pull/96686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] CTAD: Generate deduction guides for alias templates from non-template explicit deduction guides (PR #96686)
@@ -3216,6 +3226,44 @@ void DeclareImplicitDeductionGuidesForTypeAlias(
Guides.suppressDiagnostics();
for (auto *G : Guides) {
+if (auto *DG = dyn_cast(G)) {
+ // The deduction guide is a non-template function decl, we just clone it.
+ auto *FunctionType =
+ SemaRef.Context.getTrivialTypeSourceInfo(DG->getType());
+ FunctionProtoTypeLoc FPTL =
+ FunctionType->getTypeLoc().castAs();
+
+ // Clone the parameters.
+ unsigned ProcessedParamIndex = 0;
+ for (auto *P : DG->parameters()) {
+auto *TSI = SemaRef.Context.getTrivialTypeSourceInfo(P->getType());
+ParmVarDecl *NewParam = ParmVarDecl::Create(
+SemaRef.Context, G->getDeclContext(), P->getBeginLoc(),
+P->getLocation(), nullptr, TSI->getType(), TSI, SC_None, nullptr);
+NewParam->setScopeInfo(0, ProcessedParamIndex);
+FPTL.setParam(ProcessedParamIndex, NewParam);
+ProcessedParamIndex++;
zyn0217 wrote:
Do we need to inject the `NewParam` into the new `DeductionGuide` later? i.e.
call `NewParam->setOwningFunction()` somewhere below.
https://github.com/llvm/llvm-project/pull/96686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] CTAD: Generate deduction guides for alias templates from non-template explicit deduction guides (PR #96686)
https://github.com/zyn0217 commented: Thanks for the patch! I think the overall approach looks good, and with this patch, I also need to remove the assumption in my https://github.com/llvm/llvm-project/pull/96084 that there's always a template decl associated with the deduction guide. https://github.com/llvm/llvm-project/pull/96686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] CTAD: Generate deduction guides for alias templates from non-template explicit deduction guides (PR #96686)
https://github.com/zyn0217 edited https://github.com/llvm/llvm-project/pull/96686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)
@@ -1059,9 +1059,10 @@
CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
if (Guard.isValid()) {
// If we have a guard variable, check whether we've already performed
// these initializations. This happens for TLS initialization functions.
- llvm::Value *GuardVal = Builder.CreateLoad(Guard);
- llvm::Value *Uninit = Builder.CreateIsNull(GuardVal,
- "guard.uninitialized");
+ llvm::Value *GuardVal = EmitLoadOfScalar(
+ MakeAddrLValue(Guard, getContext().IntTy), SourceLocation());
ChuanqiXu9 wrote:
I am slightly not happy with the use of `MakeAddrLValue` since the term
`LValue` is a language concept in my mind and here are some codes for
implementing details for the language to me. I may feel better to implement
this with the `CreateThreadLocalAddress` API directly.
https://github.com/llvm/llvm-project/pull/96633
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang-tidy]: Use correct term for user-provided constructor (PR #96617)
https://github.com/HerrCai0907 approved this pull request. LGTM. Thanks for your contribution. https://github.com/llvm/llvm-project/pull/96617 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema] Tweak tryCaptureVariable for unevaluated lambdas (PR #93206)
FireBurn wrote: I've just bisected to the faulty commit and eventaully to this fix +1 to get this added to 18.1.9 if there ever is one - especially if the Android NDK moves to it - the 27 betas fail for me too https://github.com/llvm/llvm-project/pull/93206 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang-tidy] add fixhint for misc-use-internal-linkage (PR #96203)
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/96203
>From 669205c0f659239c58a3bde3ddadabb0a8ecbad8 Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Thu, 20 Jun 2024 15:05:57 +
Subject: [PATCH 1/4] [clang-tidy] add fixhint for misc-use-internal-linkage
---
.../clang-tidy/misc/UseInternalLinkageCheck.cpp | 12 ++--
.../checkers/misc/use-internal-linkage-func.cpp | 1 +
.../checkers/misc/use-internal-linkage-var.cpp | 1 +
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
b/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
index 70d0281df28fa..e36ccdba42ef1 100644
--- a/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
+++ b/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
@@ -82,11 +82,19 @@ static constexpr StringRef Message =
void UseInternalLinkageCheck::check(const MatchFinder::MatchResult ) {
if (const auto *FD = Result.Nodes.getNodeAs("fn")) {
-diag(FD->getLocation(), Message) << "function" << FD;
+DiagnosticBuilder DB = diag(FD->getLocation(), Message) << "function" <<
FD;
+SourceLocation FixLoc = FD->getTypeSpecStartLoc();
+if (FixLoc.isInvalid() || FixLoc.isMacroID())
+ return;
+DB << FixItHint::CreateInsertion(FixLoc, "static ");
return;
}
if (const auto *VD = Result.Nodes.getNodeAs("var")) {
-diag(VD->getLocation(), Message) << "variable" << VD;
+DiagnosticBuilder DB = diag(VD->getLocation(), Message) << "variable" <<
VD;
+SourceLocation FixLoc = VD->getTypeSpecStartLoc();
+if (FixLoc.isInvalid() || FixLoc.isMacroID())
+ return;
+DB << FixItHint::CreateInsertion(FixLoc, "static ");
return;
}
llvm_unreachable("");
diff --git
a/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-func.cpp
b/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-func.cpp
index c6c513fe0b0c0..c244f32db8e96 100644
---
a/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-func.cpp
+++
b/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-func.cpp
@@ -4,6 +4,7 @@
void func() {}
// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'func'
+// CHECK-FIXES: static void func() {}
template
void func_template() {}
diff --git
a/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-var.cpp
b/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-var.cpp
index bd5ef5431de6c..b076e9125fc35 100644
---
a/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-var.cpp
+++
b/clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-var.cpp
@@ -4,6 +4,7 @@
int global;
// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: variable 'global'
+// CHECK-FIXES: static int global;
template
T global_template;
>From d5bb05e2af683a2dcb08c6e8cabc448001c07414 Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Mon, 24 Jun 2024 21:58:56 +0800
Subject: [PATCH 2/4] add FixMode option
---
.../misc/UseInternalLinkageCheck.cpp | 36 +--
.../clang-tidy/misc/UseInternalLinkageCheck.h | 11 --
.../checks/misc/use-internal-linkage.rst | 13 +++
.../use-internal-linkage-fix-mode-none.cpp| 10 ++
.../misc/use-internal-linkage-func.cpp| 2 ++
.../misc/use-internal-linkage-var.cpp | 2 ++
6 files changed, 69 insertions(+), 5 deletions(-)
create mode 100644
clang-tools-extra/test/clang-tidy/checkers/misc/use-internal-linkage-fix-mode-none.cpp
diff --git a/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
b/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
index e36ccdba42ef1..44ccc2bc906a5 100644
--- a/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
+++ b/clang-tools-extra/clang-tidy/misc/UseInternalLinkageCheck.cpp
@@ -18,6 +18,26 @@
using namespace clang::ast_matchers;
+namespace clang::tidy {
+
+template <>
+struct OptionEnumMapping {
+ static llvm::ArrayRef<
+ std::pair>
+ getEnumMapping() {
+static constexpr std::pair
+Mapping[] = {
+{misc::UseInternalLinkageCheck::FixModeKind::None, "None"},
+{misc::UseInternalLinkageCheck::FixModeKind::UseStatic,
+ "UseStatic"},
+};
+return {Mapping};
+ }
+};
+
+} // namespace clang::tidy
+
namespace clang::tidy::misc {
namespace {
@@ -57,6 +77,16 @@ AST_POLYMORPHIC_MATCHER(isExternStorageClass,
} // namespace
+UseInternalLinkageCheck::UseInternalLinkageCheck(StringRef Name,
+ ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+ HeaderFileExtensions(Context->getHeaderFileExtensions()),
+ FixMode(Options.get("FixMode", FixModeKind::UseStatic)) {}
+
+void UseInternalLinkageCheck::storeOptions(ClangTidyOptions::OptionMap ) {
+ Options.store(Opts, "FixMode", FixMode);
+}
+
void
[clang-tools-extra] [clang-tidy] add fixhint for misc-use-internal-linkage (PR #96203)
@@ -25,3 +25,16 @@ Example: } // already declared as extern extern int v2; + +Options +--- + +.. option:: FixMode + + Selects the fix mode when fixing automatically. HerrCai0907 wrote: ```suggestion Selects what kind of a fix the check should provide. ``` https://github.com/llvm/llvm-project/pull/96203 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Serialization] Storing DeclID separately (PR #95897)
ChuanqiXu9 wrote: > Thanks for this patch, I will try it on our codebase to see the effects of it > and report back to you. I am also trying to understand in which cases this > would be a win and when not. IIUC, this is always a win when `ModuleFileIndex > != 0` and a pessimization otherwise. Yes, I think. > > When is `ModuleFileIndex == 0`? Does this only happen for predefined decls > (that we never deserialize) or also for the declarations owned by the > currently written module? Yes, this is what I thought. https://github.com/llvm/llvm-project/pull/95897 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)
https://github.com/trcrsired edited https://github.com/llvm/llvm-project/pull/96417 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
jdenny-ornl wrote: > I think this looks good overall, Thanks for the fast reviews. > though I'd like to hear some other clang maintainers chime in on the LIT > config changes. For reference, I mostly copied that from the llvm test suite config. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From 049f249f0f5ff769224cf53b4d7be47bdac6196a Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH] Support --sysroot= for ${arch}-windows-msvc targets
I think it is possible to use the same rule for msvc targets with
--target= and --sysroot=
See Repository:
https://github.com/trcrsired/windows-msvc-sysroot
Add sysroot support for msvc
MSVC.cpp needs getDriver before using D
add stl in parser for -stdlib=
Add Vcruntime to runtime list and unwind list
MSVC add default runtime lib type and default unwind lib type
add a msvc sysroot test
use %S instead of /foo
Fix test for msvc-sysroot
Also add a pesudo implementation for WebAssembly and
maybe Microsoft STL could be ported to more targets in the future
---
clang/include/clang/Driver/ToolChain.h | 9 +-
clang/lib/Driver/ToolChain.cpp | 9 +
clang/lib/Driver/ToolChains/MSVC.cpp| 248 +++-
clang/lib/Driver/ToolChains/MSVC.h | 24 +-
clang/lib/Driver/ToolChains/WebAssembly.cpp | 27 +++
clang/lib/Driver/ToolChains/WebAssembly.h | 2 +
clang/test/Driver/msvc-sysroot.cpp | 81 +++
clang/test/Driver/wasm-toolchain.cpp| 12 +
8 files changed, 343 insertions(+), 69 deletions(-)
create mode 100644 clang/test/Driver/msvc-sysroot.cpp
diff --git a/clang/include/clang/Driver/ToolChain.h
b/clang/include/clang/Driver/ToolChain.h
index 1f93bd612e9b0..04535a98dd69c 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -95,18 +95,21 @@ class ToolChain {
enum CXXStdlibType {
CST_Libcxx,
-CST_Libstdcxx
+CST_Libstdcxx,
+CST_Stl,
};
enum RuntimeLibType {
RLT_CompilerRT,
-RLT_Libgcc
+RLT_Libgcc,
+RLT_Vcruntime
};
enum UnwindLibType {
UNW_None,
UNW_CompilerRT,
-UNW_Libgcc
+UNW_Libgcc,
+UNW_Vcruntime
};
enum class UnwindTableLevel {
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 40ab2e91125d1..b3ed8fc6de36d 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1091,6 +1091,8 @@ ToolChain::RuntimeLibType ToolChain::GetRuntimeLibType(
runtimeLibType = ToolChain::RLT_CompilerRT;
else if (LibName == "libgcc")
runtimeLibType = ToolChain::RLT_Libgcc;
+ else if (LibName == "vcruntime")
+runtimeLibType = ToolChain::RLT_Vcruntime;
else if (LibName == "platform")
runtimeLibType = GetDefaultRuntimeLibType();
else {
@@ -1129,6 +1131,8 @@ ToolChain::UnwindLibType ToolChain::GetUnwindLibType(
unwindLibType = ToolChain::UNW_CompilerRT;
} else if (LibName == "libgcc")
unwindLibType = ToolChain::UNW_Libgcc;
+ else if (LibName == "vcruntime")
+unwindLibType = ToolChain::UNW_Vcruntime;
else {
if (A)
getDriver().Diag(diag::err_drv_invalid_unwindlib_name)
@@ -1152,6 +1156,8 @@ ToolChain::CXXStdlibType
ToolChain::GetCXXStdlibType(const ArgList ) const{
cxxStdlibType = ToolChain::CST_Libcxx;
else if (LibName == "libstdc++")
cxxStdlibType = ToolChain::CST_Libstdcxx;
+ else if (LibName == "stl")
+cxxStdlibType = ToolChain::CST_Stl;
else if (LibName == "platform")
cxxStdlibType = GetDefaultCXXStdlibType();
else {
@@ -1290,6 +1296,9 @@ void ToolChain::AddCXXStdlibLibArgs(const ArgList ,
case ToolChain::CST_Libstdcxx:
CmdArgs.push_back("-lstdc++");
break;
+
+ default:
+break;
}
}
diff --git a/clang/lib/Driver/ToolChains/MSVC.cpp
b/clang/lib/Driver/ToolChains/MSVC.cpp
index ca266e3e1d1d3..bf1b6d3b9bc84 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -31,12 +31,12 @@
#include
#ifdef _WIN32
- #define WIN32_LEAN_AND_MEAN
- #define NOGDI
- #ifndef NOMINMAX
-#define NOMINMAX
- #endif
- #include
+#define WIN32_LEAN_AND_MEAN
+#define NOGDI
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+#include
#endif
using namespace clang::driver;
@@ -95,43 +95,52 @@ void visualstudio::Linker::ConstructJob(Compilation ,
const JobAction ,
// the environment variable is set however, assume the user knows what
// they're doing. If the user passes /vctoolsdir or /winsdkdir, trust that
// over env vars.
- if (const Arg *A = Args.getLastArg(options::OPT__SLASH_diasdkdir,
- options::OPT__SLASH_winsysroot)) {
-// cl.exe doesn't find the DIA SDK automatically, so this too requires
-// explicit flags and doesn't automatically look in "DIA SDK" relative
-// to the path we found for VCToolChainPath.
-llvm::SmallString<128> DIAPath(A->getValue());
-if (A->getOption().getID() == options::OPT__SLASH_winsysroot)
- llvm::sys::path::append(DIAPath, "DIA SDK");
-
-// The DIA SDK always uses the legacy vc arch, even in new MSVC versions.
-llvm::sys::path::append(DIAPath,
[clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From 70823f780dc0748446c752f27b52b0f6061bc7e1 Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH 1/2] Support --sysroot= for ${arch}-windows-msvc targets
I think it is possible to use the same rule for msvc targets with
--target= and --sysroot=
See Repository:
https://github.com/trcrsired/windows-msvc-sysroot
Add sysroot support for msvc
MSVC.cpp needs getDriver before using D
add stl in parser for -stdlib=
Add Vcruntime to runtime list and unwind list
MSVC add default runtime lib type and default unwind lib type
add a msvc sysroot test
use %S instead of /foo
---
clang/include/clang/Driver/ToolChain.h | 9 +-
clang/lib/Driver/ToolChain.cpp | 9 +
clang/lib/Driver/ToolChains/MSVC.cpp | 248 +++--
clang/lib/Driver/ToolChains/MSVC.h | 24 ++-
clang/test/Driver/msvc-sysroot.cpp | 11 ++
5 files changed, 232 insertions(+), 69 deletions(-)
create mode 100644 clang/test/Driver/msvc-sysroot.cpp
diff --git a/clang/include/clang/Driver/ToolChain.h
b/clang/include/clang/Driver/ToolChain.h
index 1f93bd612e9b0..04535a98dd69c 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -95,18 +95,21 @@ class ToolChain {
enum CXXStdlibType {
CST_Libcxx,
-CST_Libstdcxx
+CST_Libstdcxx,
+CST_Stl,
};
enum RuntimeLibType {
RLT_CompilerRT,
-RLT_Libgcc
+RLT_Libgcc,
+RLT_Vcruntime
};
enum UnwindLibType {
UNW_None,
UNW_CompilerRT,
-UNW_Libgcc
+UNW_Libgcc,
+UNW_Vcruntime
};
enum class UnwindTableLevel {
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 40ab2e91125d1..b3ed8fc6de36d 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1091,6 +1091,8 @@ ToolChain::RuntimeLibType ToolChain::GetRuntimeLibType(
runtimeLibType = ToolChain::RLT_CompilerRT;
else if (LibName == "libgcc")
runtimeLibType = ToolChain::RLT_Libgcc;
+ else if (LibName == "vcruntime")
+runtimeLibType = ToolChain::RLT_Vcruntime;
else if (LibName == "platform")
runtimeLibType = GetDefaultRuntimeLibType();
else {
@@ -1129,6 +1131,8 @@ ToolChain::UnwindLibType ToolChain::GetUnwindLibType(
unwindLibType = ToolChain::UNW_CompilerRT;
} else if (LibName == "libgcc")
unwindLibType = ToolChain::UNW_Libgcc;
+ else if (LibName == "vcruntime")
+unwindLibType = ToolChain::UNW_Vcruntime;
else {
if (A)
getDriver().Diag(diag::err_drv_invalid_unwindlib_name)
@@ -1152,6 +1156,8 @@ ToolChain::CXXStdlibType
ToolChain::GetCXXStdlibType(const ArgList ) const{
cxxStdlibType = ToolChain::CST_Libcxx;
else if (LibName == "libstdc++")
cxxStdlibType = ToolChain::CST_Libstdcxx;
+ else if (LibName == "stl")
+cxxStdlibType = ToolChain::CST_Stl;
else if (LibName == "platform")
cxxStdlibType = GetDefaultCXXStdlibType();
else {
@@ -1290,6 +1296,9 @@ void ToolChain::AddCXXStdlibLibArgs(const ArgList ,
case ToolChain::CST_Libstdcxx:
CmdArgs.push_back("-lstdc++");
break;
+
+ default:
+break;
}
}
diff --git a/clang/lib/Driver/ToolChains/MSVC.cpp
b/clang/lib/Driver/ToolChains/MSVC.cpp
index ca266e3e1d1d3..bf1b6d3b9bc84 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -31,12 +31,12 @@
#include
#ifdef _WIN32
- #define WIN32_LEAN_AND_MEAN
- #define NOGDI
- #ifndef NOMINMAX
-#define NOMINMAX
- #endif
- #include
+#define WIN32_LEAN_AND_MEAN
+#define NOGDI
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+#include
#endif
using namespace clang::driver;
@@ -95,43 +95,52 @@ void visualstudio::Linker::ConstructJob(Compilation ,
const JobAction ,
// the environment variable is set however, assume the user knows what
// they're doing. If the user passes /vctoolsdir or /winsdkdir, trust that
// over env vars.
- if (const Arg *A = Args.getLastArg(options::OPT__SLASH_diasdkdir,
- options::OPT__SLASH_winsysroot)) {
-// cl.exe doesn't find the DIA SDK automatically, so this too requires
-// explicit flags and doesn't automatically look in "DIA SDK" relative
-// to the path we found for VCToolChainPath.
-llvm::SmallString<128> DIAPath(A->getValue());
-if (A->getOption().getID() == options::OPT__SLASH_winsysroot)
- llvm::sys::path::append(DIAPath, "DIA SDK");
-
-// The DIA SDK always uses the legacy vc arch, even in new MSVC versions.
-llvm::sys::path::append(DIAPath, "lib",
-llvm::archToLegacyVCArch(TC.getArch()));
-CmdArgs.push_back(Args.MakeArgString(Twine("-libpath:") + DIAPath));
- }
- if (!llvm::sys::Process::GetEnv("LIB") ||
- Args.getLastArg(options::OPT__SLASH_vctoolsdir,
- options::OPT__SLASH_winsysroot)) {
-
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
https://github.com/jhuber6 approved this pull request. I think this looks good overall, though I'd like to hear some other clang maintainers chime in on the LIT config changes. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,77 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. jhuber6 wrote: I see, probably fine then. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
https://github.com/jdenny-ornl edited https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,77 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. jdenny-ornl wrote: noinline prevents the inline pass in the test from running. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,77 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. jhuber6 wrote: -disable-O0-optnone handles the optnone, don't think `noinline` affects that much. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (PR #96540)
efriedma-quic wrote: > Or, if we do need to preserve bitcode compat, how to best achieve it? Perhaps > we convert them into inline-asm in the bitcode upgrader? Really, the question is whether we plan to completely drop support for the x86_mmx type (including inline asm operands/results). If we don't, then there's not much reason to touch the LLVM IR builtins; there isn't any actual "code" outside of TableGen, so there's basically zero maintenance work. If we do drop it, then autoupgrade becomes very complicated and not really useful. https://github.com/llvm/llvm-project/pull/96540 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
https://github.com/jdenny-ornl edited https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
https://github.com/h-vetinari edited https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,77 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. jdenny-ornl wrote: OK, I did that. I used opt to discard the inline attribute that clang introduces. If you know of a better way that doesn't perform inlining before the clang-linker-wrapper call, let me know. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
https://github.com/jdenny-ornl updated https://github.com/llvm/llvm-project/pull/96704 >From 98e04dd372b82c2c5309a6148bb49eb1012a97ee Mon Sep 17 00:00:00 2001 From: "Joel E. Denny" Date: Tue, 25 Jun 2024 17:29:49 -0400 Subject: [PATCH 1/4] [LinkerWrapper] Extend with usual pass options The goal of this patch is to enable utilizing LLVM plugin passes and remarks for GPU offload code at link time. Specifically, this patch extends clang-linker-wrapper's `--offload-opt` (and consequently `-mllvm`) to accept the various LLVM pass options that tools like opt usually accept. Those options include `--passes`, `--load-pass-plugin`, and various remarks options. Unlike many other LLVM options that are inherited from linked code by clang-linker-wrapper (e.g., `-pass-remarks` is already implemented in `llvm/lib/IR/DiagnosticHandler.cpp`), these options are implemented separately as needed by each tool (e.g., opt, llc). Fortunately, this patch is able to handle most of the implementation by passing the option values to `lto::Config`. For testing plugin support, this patch uses the simple `Bye` plugin from LLVM core, but that requires several small Clang test suite config extensions. --- clang/test/CMakeLists.txt | 3 + clang/test/Driver/linker-wrapper-llvm-help.c | 10 +++ clang/test/Driver/linker-wrapper-passes.ll| 86 +++ clang/test/Driver/lit.local.cfg | 1 + clang/test/lit.cfg.py | 12 +++ clang/test/lit.site.cfg.py.in | 4 + .../tools/clang-linker-wrapper/CMakeLists.txt | 2 + .../ClangLinkerWrapper.cpp| 74 .../clang-linker-wrapper/LinkerWrapperOpts.td | 8 +- 9 files changed, 198 insertions(+), 2 deletions(-) create mode 100644 clang/test/Driver/linker-wrapper-llvm-help.c create mode 100644 clang/test/Driver/linker-wrapper-passes.ll diff --git a/clang/test/CMakeLists.txt b/clang/test/CMakeLists.txt index 5fceb1d710334..8303269a9ad07 100644 --- a/clang/test/CMakeLists.txt +++ b/clang/test/CMakeLists.txt @@ -11,6 +11,9 @@ llvm_canonicalize_cmake_booleans( CLANG_SPAWN_CC1 CLANG_ENABLE_CIR ENABLE_BACKTRACES + LLVM_BUILD_EXAMPLES + LLVM_BYE_LINK_INTO_TOOLS + LLVM_ENABLE_PLUGINS LLVM_ENABLE_ZLIB LLVM_ENABLE_ZSTD LLVM_ENABLE_PER_TARGET_RUNTIME_DIR diff --git a/clang/test/Driver/linker-wrapper-llvm-help.c b/clang/test/Driver/linker-wrapper-llvm-help.c new file mode 100644 index 0..ffd1cf78bcd9a --- /dev/null +++ b/clang/test/Driver/linker-wrapper-llvm-help.c @@ -0,0 +1,10 @@ +// Check that these simple command lines for listing LLVM options are supported, +// as claimed by 'clang-linker-wrapper --help'. + +// RUN: clang-linker-wrapper -mllvm --help 2>&1 | FileCheck %s +// RUN: clang-linker-wrapper --offload-opt=--help 2>&1 | FileCheck %s + +// Look for a few options supported only after -mllvm and --offload-opt. +// CHECK: OPTIONS: +// CHECK-DAG: --passes= +// CHECK-DAG: --load-pass-plugin= diff --git a/clang/test/Driver/linker-wrapper-passes.ll b/clang/test/Driver/linker-wrapper-passes.ll new file mode 100644 index 0..28493b9a88eb1 --- /dev/null +++ b/clang/test/Driver/linker-wrapper-passes.ll @@ -0,0 +1,86 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. + +; REQUIRES: llvm-plugins, llvm-examples +; REQUIRES: x86-registered-target +; REQUIRES: amdgpu-registered-target + +; Setup. +; RUN: split-file %s %t +; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \ +; RUN: %t/host-x86_64-unknown-linux-gnu.ll +; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \ +; RUN: %t/openmp-amdgcn-amd-amdhsa.ll +; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \ +; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa +; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \ +; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \ +; RUN: %t/host-x86_64-unknown-linux-gnu.bc +; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \ +; RUN: %t/host-x86_64-unknown-linux-gnu.s + +; Check plugin, -passes, and no remarks. +; RUN: clang-linker-wrapper -o a.out --embed-bitcode \ +; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \ +; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \ +; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s + +; Check plugin, -p, and remarks. +; RUN: clang-linker-wrapper -o a.out --embed-bitcode \ +; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \ +; RUN: --offload-opt=-p="function(goodbye),module(inline)" \ +; RUN: --offload-opt=-pass-remarks=inline \ +; RUN:
[clang] [clang] Implement pointer authentication for C++ virtual functions, v-tables, and VTTs (PR #94056)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/94056 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clang: Add warning flag for storage class specifiers on explicit specializations (PR #96699)
dwblaikie wrote: > Should we add a test for this flag? Something around existing tests in > clang/test/CXX/temp/temp.spec/temp.expl.spec/p2-20.cpp and > clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp. Oh, right, I did have a new test I meant to add, but that's a better place for it - so I've added that test coverage in https://github.com/llvm/llvm-project/pull/96699/commits/b3facc9dffc762e3cef93886df23026d502afcae (I'm out for the day, so if anyone happens to approve this and feel like pressing the "squash and merge" button that'd be swell, otherwise I'll get to it when I have a chance/tomorrow) https://github.com/llvm/llvm-project/pull/96699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Transitive Change h-vetinari wrote: * "no-cascade" feature? * "isolated BMI" (not sure if this is a great idea given how there's already full/reduced BMI) * "BMI isolation" * + variations with synonyms for isolated/secluded/confined/... https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clang: Add warning flag for storage class specifiers on explicit specializations (PR #96699)
https://github.com/dwblaikie updated
https://github.com/llvm/llvm-project/pull/96699
>From a539afc7b81502ffcab7028bfe8266b8e32951d9 Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Tue, 25 Jun 2024 21:02:50 +
Subject: [PATCH 1/2] Clang: Add warning flag for storage class specifiers on
explicit specializations
With the recent fix for this situation in class members (#93873) (for
which the fixed code is invalid prior to this patch - making migrating
code difficult as it must be in lock-step with the compiler migration,
if building with -Werror) it'd be really useful to be able to disable
this warning during the compiler migration/decouple the compiler
migration from the source fixes.
In theory this approach will regress the codebase to the previous
non-member cases of this issue that were already being held back by the
warning (as opposed to if we carved out the new cases into a separate
warning from the existing cases) but I think this'll be so rare and the
cleanup so simple, that the extra regressions of disabling the warning
broadly won't be too much of a problem. (but if folks disagree, I'm open
to making the warning more fine-grained)
---
clang/include/clang/Basic/DiagnosticGroups.td| 4
clang/include/clang/Basic/DiagnosticSemaKinds.td | 2 +-
clang/test/Misc/warning-flags.c | 3 +--
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/clang/include/clang/Basic/DiagnosticGroups.td
b/clang/include/clang/Basic/DiagnosticGroups.td
index 9b37d4bd3205b..8c5cbbc160ba1 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -1535,3 +1535,7 @@ def BitIntExtension : DiagGroup<"bit-int-extension">;
// Warnings about misuse of ExtractAPI options.
def ExtractAPIMisuse : DiagGroup<"extractapi-misuse">;
+
+// Warnings about using the non-standard extension having an explicit
specialization
+// with a storage class specifier.
+def ExplicitSpecializationStorageClass :
DiagGroup<"explicit-specialization-storage-class">;
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 25a87078a5709..f12121f065783 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -5366,7 +5366,7 @@ def err_not_class_template_specialization : Error<
"cannot specialize a %select{dependent template|template template "
"parameter}0">;
def ext_explicit_specialization_storage_class : ExtWarn<
- "explicit specialization cannot have a storage class">;
+ "explicit specialization cannot have a storage class">,
InGroup;
def err_dependent_function_template_spec_no_match : Error<
"no candidate function template was found for dependent"
" %select{member|friend}0 function template specialization">;
diff --git a/clang/test/Misc/warning-flags.c b/clang/test/Misc/warning-flags.c
index dd73331913c6f..ae14720959a0e 100644
--- a/clang/test/Misc/warning-flags.c
+++ b/clang/test/Misc/warning-flags.c
@@ -18,10 +18,9 @@ This test serves two purposes:
The list of warnings below should NEVER grow. It should gradually shrink to 0.
-CHECK: Warnings without flags (66):
+CHECK: Warnings without flags (65):
CHECK-NEXT: ext_expected_semi_decl_list
-CHECK-NEXT: ext_explicit_specialization_storage_class
CHECK-NEXT: ext_missing_whitespace_after_macro_name
CHECK-NEXT: ext_new_paren_array_nonconst
CHECK-NEXT: ext_plain_complex
>From b3facc9dffc762e3cef93886df23026d502afcae Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Wed, 26 Jun 2024 00:01:46 +
Subject: [PATCH 2/2] Add test
---
clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp | 16
...n-explicit-specialization-storage-class.cpp | 18 ++
2 files changed, 30 insertions(+), 4 deletions(-)
create mode 100644
clang/test/SemaCXX/warn-explicit-specialization-storage-class.cpp
diff --git a/clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp
b/clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp
index f6b5d2487e73d..9efa7b67f5bdb 100644
--- a/clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp
+++ b/clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,spec %s
+// RUN: %clang_cc1 -fsyntax-only -verify
-Wno-explicit-specialization-storage-class %s
// A storage-class-specifier shall not be specified in an explicit
// specialization (14.7.3) or an explicit instantiation (14.7.2)
@@ -7,13 +8,13 @@ template void f(T) {}
template static void g(T) {}
-template<> static void f(int); // expected-warning{{explicit
specialization cannot have a storage class}}
+template<> static void f(int); // spec-warning{{explicit specialization
cannot have a storage class}}
template static void f(float); // expected-error{{explicit
instantiation cannot have a storage class}}
template<> void f(double);
template void f(long);
[clang-tools-extra] [clang-tidy] align all help message in run-clang-tidy (PR #96199)
https://github.com/HerrCai0907 closed https://github.com/llvm/llvm-project/pull/96199 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] 6b29965 - [clang-tidy] align all help message in run-clang-tidy (#96199)
Author: Congcong Cai
Date: 2024-06-26T08:05:00+08:00
New Revision: 6b29965fd9355243f23a83a590a70ac7744f0e0f
URL:
https://github.com/llvm/llvm-project/commit/6b29965fd9355243f23a83a590a70ac7744f0e0f
DIFF:
https://github.com/llvm/llvm-project/commit/6b29965fd9355243f23a83a590a70ac7744f0e0f.diff
LOG: [clang-tidy] align all help message in run-clang-tidy (#96199)
Added:
Modified:
clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
Removed:
diff --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
index 4dd20bec81d3b..6e7cc8a873a22 100755
--- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -261,20 +261,20 @@ def main():
parser.add_argument(
"-allow-enabling-alpha-checkers",
action="store_true",
-help="allow alpha checkers from clang-analyzer.",
+help="Allow alpha checkers from clang-analyzer.",
)
parser.add_argument(
-"-clang-tidy-binary", metavar="PATH", help="path to clang-tidy binary"
+"-clang-tidy-binary", metavar="PATH", help="Path to clang-tidy binary."
)
parser.add_argument(
"-clang-apply-replacements-binary",
metavar="PATH",
-help="path to clang-apply-replacements binary",
+help="Path to clang-apply-replacements binary.",
)
parser.add_argument(
"-checks",
default=None,
-help="checks filter, when not specified, use clang-tidy default",
+help="Checks filter, when not specified, use clang-tidy default.",
)
config_group = parser.add_mutually_exclusive_group()
config_group.add_argument(
@@ -307,7 +307,7 @@ def main():
parser.add_argument(
"-header-filter",
default=None,
-help="regular expression matching the names of the "
+help="Regular expression matching the names of the "
"headers to output diagnostics from. Diagnostics from "
"the main file of each translation unit are always "
"displayed.",
@@ -347,19 +347,22 @@ def main():
"-j",
type=int,
default=0,
-help="number of tidy instances to be run in parallel.",
+help="Number of tidy instances to be run in parallel.",
)
parser.add_argument(
-"files", nargs="*", default=[".*"], help="files to be processed (regex
on path)"
+"files",
+nargs="*",
+default=[".*"],
+help="Files to be processed (regex on path).",
)
-parser.add_argument("-fix", action="store_true", help="apply fix-its")
+parser.add_argument("-fix", action="store_true", help="apply fix-its.")
parser.add_argument(
-"-format", action="store_true", help="Reformat code after applying
fixes"
+"-format", action="store_true", help="Reformat code after applying
fixes."
)
parser.add_argument(
"-style",
default="file",
-help="The style of reformat code after applying fixes",
+help="The style of reformat code after applying fixes.",
)
parser.add_argument(
"-use-color",
@@ -388,7 +391,7 @@ def main():
help="Additional argument to prepend to the compiler command line.",
)
parser.add_argument(
-"-quiet", action="store_true", help="Run clang-tidy in quiet mode"
+"-quiet", action="store_true", help="Run clang-tidy in quiet mode."
)
parser.add_argument(
"-load",
@@ -400,7 +403,7 @@ def main():
parser.add_argument(
"-warnings-as-errors",
default=None,
-help="Upgrades warnings to errors. Same format as '-checks'",
+help="Upgrades warnings to errors. Same format as '-checks'.",
)
args = parser.parse_args()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix codegen of consteval functions returning an empty class, and related issues (PR #93115)
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
-// fast-isel.
-// FIXME: Do we need to recurse here?
-void CodeGenFunction::EmitAggregateStore(llvm::Value *Val, Address Dest,
- bool DestIsVolatile) {
- // Prefer scalar stores to first-class aggregate stores.
- if (llvm::StructType *STy = dyn_cast(Val->getType())) {
-for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
- Address EltPtr = Builder.CreateStructGEP(Dest, i);
- llvm::Value *Elt = Builder.CreateExtractValue(Val, i);
- Builder.CreateStore(Elt, EltPtr, DestIsVolatile);
-}
- } else {
-Builder.CreateStore(Val, Dest, DestIsVolatile);
- }
-}
-
/// CreateCoercedStore - Create a store to \arg DstPtr from \arg Src,
/// where the source and destination may have different types. The
/// destination is known to be aligned to \arg DstAlign bytes.
///
/// This safely handles the case when the src type is larger than the
/// destination type; the upper bits of the src will be lost.
-static void CreateCoercedStore(llvm::Value *Src,
- Address Dst,
- bool DstIsVolatile,
- CodeGenFunction ) {
- llvm::Type *SrcTy = Src->getType();
- llvm::Type *DstTy = Dst.getElementType();
- if (SrcTy == DstTy) {
-CGF.Builder.CreateStore(Src, Dst, DstIsVolatile);
-return;
- }
-
- llvm::TypeSize SrcSize = CGF.CGM.getDataLayout().getTypeAllocSize(SrcTy);
-
- if (llvm::StructType *DstSTy = dyn_cast(DstTy)) {
-Dst = EnterStructPointerForCoercedAccess(Dst, DstSTy,
- SrcSize.getFixedValue(), CGF);
-DstTy = Dst.getElementType();
- }
-
- llvm::PointerType *SrcPtrTy = llvm::dyn_cast(SrcTy);
- llvm::PointerType *DstPtrTy = llvm::dyn_cast(DstTy);
- if (SrcPtrTy && DstPtrTy &&
- SrcPtrTy->getAddressSpace() != DstPtrTy->getAddressSpace()) {
-Src = CGF.Builder.CreateAddrSpaceCast(Src, DstTy);
-CGF.Builder.CreateStore(Src, Dst, DstIsVolatile);
+void CodeGenFunction::CreateCoercedStore(llvm::Value *Src, Address Dst,
+ llvm::TypeSize DstSize,
+ bool DstIsVolatile) {
+ if (!DstSize)
return;
- }
- // If the source and destination are integer or pointer types, just do an
- // extension or truncation to the desired type.
- if ((isa(SrcTy) || isa(SrcTy)) &&
- (isa(DstTy) || isa(DstTy))) {
-Src = CoerceIntOrPtrToIntOrPtr(Src, DstTy, CGF);
-CGF.Builder.CreateStore(Src, Dst, DstIsVolatile);
-return;
+ llvm::Type *SrcTy = Src->getType();
+ llvm::TypeSize SrcSize = CGM.getDataLayout().getTypeAllocSize(SrcTy);
+
+ // GEP into structs to try to make types match.
+ // FIXME: This isn't really that useful with opaque types, but it impacts a
+ // lot of regression tests.
+ if (SrcTy != Dst.getElementType()) {
+if (llvm::StructType *DstSTy =
+dyn_cast(Dst.getElementType())) {
+ assert(!SrcSize.isScalable());
+ Dst = EnterStructPointerForCoercedAccess(Dst, DstSTy,
+ SrcSize.getFixedValue(), *this);
+}
}
- llvm::TypeSize DstSize = CGF.CGM.getDataLayout().getTypeAllocSize(DstTy);
-
- // If store is legal, just bitcast the src pointer.
- if (isa(SrcTy) ||
- isa(DstTy) ||
- SrcSize.getFixedValue() <= DstSize.getFixedValue()) {
-Dst = Dst.withElementType(SrcTy);
-CGF.EmitAggregateStore(Src, Dst, DstIsVolatile);
+ if (SrcSize.isScalable() || SrcSize <= DstSize) {
+if (SrcTy->isIntegerTy() && Dst.getElementType()->isPointerTy() &&
+SrcSize == CGM.getDataLayout().getTypeAllocSize(Dst.getElementType()))
{
+ // If the value is supposed to be a pointer, convert it before storing
it.
+ Src = CoerceIntOrPtrToIntOrPtr(Src, Dst.getElementType(), *this);
zygoloid wrote:
Yeah, it definitely seems like it'd be a pretty big surprise to need this. OK.
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,77 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. jdenny-ornl wrote: Yeah, I suppose that's just as good. I do wonder if this is really the right directory for these tests at all. Its lit.local.cfg has a %clang_cc1 substitution that expands to a complaint that it shouldn't be used in Driver tests, so existing tests just use `%clang -cc1` instead. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,77 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. jhuber6 wrote: Hm, is this really the only LLVM-IR file in the Driver directory? I guess it makes sense, though you could probably just do what the other linker wrapper tests do and use `clang-cc1` to directly get some random IR to use. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From 70823f780dc0748446c752f27b52b0f6061bc7e1 Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH] Support --sysroot= for ${arch}-windows-msvc targets
I think it is possible to use the same rule for msvc targets with
--target= and --sysroot=
See Repository:
https://github.com/trcrsired/windows-msvc-sysroot
Add sysroot support for msvc
MSVC.cpp needs getDriver before using D
add stl in parser for -stdlib=
Add Vcruntime to runtime list and unwind list
MSVC add default runtime lib type and default unwind lib type
add a msvc sysroot test
use %S instead of /foo
---
clang/include/clang/Driver/ToolChain.h | 9 +-
clang/lib/Driver/ToolChain.cpp | 9 +
clang/lib/Driver/ToolChains/MSVC.cpp | 248 +++--
clang/lib/Driver/ToolChains/MSVC.h | 24 ++-
clang/test/Driver/msvc-sysroot.cpp | 11 ++
5 files changed, 232 insertions(+), 69 deletions(-)
create mode 100644 clang/test/Driver/msvc-sysroot.cpp
diff --git a/clang/include/clang/Driver/ToolChain.h
b/clang/include/clang/Driver/ToolChain.h
index 1f93bd612e9b0..04535a98dd69c 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -95,18 +95,21 @@ class ToolChain {
enum CXXStdlibType {
CST_Libcxx,
-CST_Libstdcxx
+CST_Libstdcxx,
+CST_Stl,
};
enum RuntimeLibType {
RLT_CompilerRT,
-RLT_Libgcc
+RLT_Libgcc,
+RLT_Vcruntime
};
enum UnwindLibType {
UNW_None,
UNW_CompilerRT,
-UNW_Libgcc
+UNW_Libgcc,
+UNW_Vcruntime
};
enum class UnwindTableLevel {
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 40ab2e91125d1..b3ed8fc6de36d 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1091,6 +1091,8 @@ ToolChain::RuntimeLibType ToolChain::GetRuntimeLibType(
runtimeLibType = ToolChain::RLT_CompilerRT;
else if (LibName == "libgcc")
runtimeLibType = ToolChain::RLT_Libgcc;
+ else if (LibName == "vcruntime")
+runtimeLibType = ToolChain::RLT_Vcruntime;
else if (LibName == "platform")
runtimeLibType = GetDefaultRuntimeLibType();
else {
@@ -1129,6 +1131,8 @@ ToolChain::UnwindLibType ToolChain::GetUnwindLibType(
unwindLibType = ToolChain::UNW_CompilerRT;
} else if (LibName == "libgcc")
unwindLibType = ToolChain::UNW_Libgcc;
+ else if (LibName == "vcruntime")
+unwindLibType = ToolChain::UNW_Vcruntime;
else {
if (A)
getDriver().Diag(diag::err_drv_invalid_unwindlib_name)
@@ -1152,6 +1156,8 @@ ToolChain::CXXStdlibType
ToolChain::GetCXXStdlibType(const ArgList ) const{
cxxStdlibType = ToolChain::CST_Libcxx;
else if (LibName == "libstdc++")
cxxStdlibType = ToolChain::CST_Libstdcxx;
+ else if (LibName == "stl")
+cxxStdlibType = ToolChain::CST_Stl;
else if (LibName == "platform")
cxxStdlibType = GetDefaultCXXStdlibType();
else {
@@ -1290,6 +1296,9 @@ void ToolChain::AddCXXStdlibLibArgs(const ArgList ,
case ToolChain::CST_Libstdcxx:
CmdArgs.push_back("-lstdc++");
break;
+
+ default:
+break;
}
}
diff --git a/clang/lib/Driver/ToolChains/MSVC.cpp
b/clang/lib/Driver/ToolChains/MSVC.cpp
index ca266e3e1d1d3..bf1b6d3b9bc84 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -31,12 +31,12 @@
#include
#ifdef _WIN32
- #define WIN32_LEAN_AND_MEAN
- #define NOGDI
- #ifndef NOMINMAX
-#define NOMINMAX
- #endif
- #include
+#define WIN32_LEAN_AND_MEAN
+#define NOGDI
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+#include
#endif
using namespace clang::driver;
@@ -95,43 +95,52 @@ void visualstudio::Linker::ConstructJob(Compilation ,
const JobAction ,
// the environment variable is set however, assume the user knows what
// they're doing. If the user passes /vctoolsdir or /winsdkdir, trust that
// over env vars.
- if (const Arg *A = Args.getLastArg(options::OPT__SLASH_diasdkdir,
- options::OPT__SLASH_winsysroot)) {
-// cl.exe doesn't find the DIA SDK automatically, so this too requires
-// explicit flags and doesn't automatically look in "DIA SDK" relative
-// to the path we found for VCToolChainPath.
-llvm::SmallString<128> DIAPath(A->getValue());
-if (A->getOption().getID() == options::OPT__SLASH_winsysroot)
- llvm::sys::path::append(DIAPath, "DIA SDK");
-
-// The DIA SDK always uses the legacy vc arch, even in new MSVC versions.
-llvm::sys::path::append(DIAPath, "lib",
-llvm::archToLegacyVCArch(TC.getArch()));
-CmdArgs.push_back(Args.MakeArgString(Twine("-libpath:") + DIAPath));
- }
- if (!llvm::sys::Process::GetEnv("LIB") ||
- Args.getLastArg(options::OPT__SLASH_vctoolsdir,
- options::OPT__SLASH_winsysroot)) {
-
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,86 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
+
+; REQUIRES: llvm-plugins, llvm-examples
+; REQUIRES: x86-registered-target
+; REQUIRES: amdgpu-registered-target
+
+; Setup.
+; RUN: split-file %s %t
+; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \
+; RUN: %t/host-x86_64-unknown-linux-gnu.ll
+; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \
+; RUN: %t/openmp-amdgcn-amd-amdhsa.ll
+; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa
+; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \
+; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \
+; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: %t/host-x86_64-unknown-linux-gnu.bc
+; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \
+; RUN: %t/host-x86_64-unknown-linux-gnu.s
+
+; Check plugin, -passes, and no remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s
+
+; Check plugin, -p, and remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-p="function(goodbye),module(inline)" \
+; RUN: --offload-opt=-pass-remarks=inline \
+; RUN: --offload-opt=-pass-remarks-output=%t/remarks.yml \
+; RUN: --offload-opt=-pass-remarks-filter=inline \
+; RUN: --offload-opt=-pass-remarks-format=yaml 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT,REM %s
+; RUN: FileCheck -input-file=%t/remarks.yml -match-full-lines \
+; RUN: -check-prefixes=YML %s
+
+; Check handling of bad plugin.
+; RUN: not clang-linker-wrapper \
+; RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
+
+; OUT-NOT: {{.}}
+; OUT: Bye: f
+; OUT-NEXT: Bye: test
+; REM-NEXT: remark: {{.*}} 'f' inlined into 'test' {{.*}}
+; OUT-NOT: {{.}}
+
+; YML-NOT: {{.}}
+; YML: --- !Passed
+; YML-NEXT: Pass: inline
+; YML-NEXT: Name: Inlined
+; YML-NEXT: Function: test
+; YML-NEXT: Args:
+; YML: - Callee: f
+; YML: - Caller: test
+; YML: ...
+; YML-NOT: {{.}}
+
+; BAD-PLUGIN-NOT: {{.}}
+; BAD-PLUGIN: {{.*}}Could not load library {{.*}}nonexistent.so{{.*}}
+; BAD-PLUGIN-NOT: {{.}}
+
+;--- host-x86_64-unknown-linux-gnu.ll
+target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+;--- openmp-amdgcn-amd-amdhsa.ll
+target datalayout =
"e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
+target triple = "amdgcn-amd-amdhsa"
+
+define void @f() {
+entry:
+ ret void
+}
+
+define amdgpu_kernel void @test() {
jdenny-ornl wrote:
I pushed another commit. Let know if that's what you had in mind.
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
https://github.com/jdenny-ornl updated https://github.com/llvm/llvm-project/pull/96704 >From 98e04dd372b82c2c5309a6148bb49eb1012a97ee Mon Sep 17 00:00:00 2001 From: "Joel E. Denny" Date: Tue, 25 Jun 2024 17:29:49 -0400 Subject: [PATCH 1/3] [LinkerWrapper] Extend with usual pass options The goal of this patch is to enable utilizing LLVM plugin passes and remarks for GPU offload code at link time. Specifically, this patch extends clang-linker-wrapper's `--offload-opt` (and consequently `-mllvm`) to accept the various LLVM pass options that tools like opt usually accept. Those options include `--passes`, `--load-pass-plugin`, and various remarks options. Unlike many other LLVM options that are inherited from linked code by clang-linker-wrapper (e.g., `-pass-remarks` is already implemented in `llvm/lib/IR/DiagnosticHandler.cpp`), these options are implemented separately as needed by each tool (e.g., opt, llc). Fortunately, this patch is able to handle most of the implementation by passing the option values to `lto::Config`. For testing plugin support, this patch uses the simple `Bye` plugin from LLVM core, but that requires several small Clang test suite config extensions. --- clang/test/CMakeLists.txt | 3 + clang/test/Driver/linker-wrapper-llvm-help.c | 10 +++ clang/test/Driver/linker-wrapper-passes.ll| 86 +++ clang/test/Driver/lit.local.cfg | 1 + clang/test/lit.cfg.py | 12 +++ clang/test/lit.site.cfg.py.in | 4 + .../tools/clang-linker-wrapper/CMakeLists.txt | 2 + .../ClangLinkerWrapper.cpp| 74 .../clang-linker-wrapper/LinkerWrapperOpts.td | 8 +- 9 files changed, 198 insertions(+), 2 deletions(-) create mode 100644 clang/test/Driver/linker-wrapper-llvm-help.c create mode 100644 clang/test/Driver/linker-wrapper-passes.ll diff --git a/clang/test/CMakeLists.txt b/clang/test/CMakeLists.txt index 5fceb1d710334..8303269a9ad07 100644 --- a/clang/test/CMakeLists.txt +++ b/clang/test/CMakeLists.txt @@ -11,6 +11,9 @@ llvm_canonicalize_cmake_booleans( CLANG_SPAWN_CC1 CLANG_ENABLE_CIR ENABLE_BACKTRACES + LLVM_BUILD_EXAMPLES + LLVM_BYE_LINK_INTO_TOOLS + LLVM_ENABLE_PLUGINS LLVM_ENABLE_ZLIB LLVM_ENABLE_ZSTD LLVM_ENABLE_PER_TARGET_RUNTIME_DIR diff --git a/clang/test/Driver/linker-wrapper-llvm-help.c b/clang/test/Driver/linker-wrapper-llvm-help.c new file mode 100644 index 0..ffd1cf78bcd9a --- /dev/null +++ b/clang/test/Driver/linker-wrapper-llvm-help.c @@ -0,0 +1,10 @@ +// Check that these simple command lines for listing LLVM options are supported, +// as claimed by 'clang-linker-wrapper --help'. + +// RUN: clang-linker-wrapper -mllvm --help 2>&1 | FileCheck %s +// RUN: clang-linker-wrapper --offload-opt=--help 2>&1 | FileCheck %s + +// Look for a few options supported only after -mllvm and --offload-opt. +// CHECK: OPTIONS: +// CHECK-DAG: --passes= +// CHECK-DAG: --load-pass-plugin= diff --git a/clang/test/Driver/linker-wrapper-passes.ll b/clang/test/Driver/linker-wrapper-passes.ll new file mode 100644 index 0..28493b9a88eb1 --- /dev/null +++ b/clang/test/Driver/linker-wrapper-passes.ll @@ -0,0 +1,86 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. + +; REQUIRES: llvm-plugins, llvm-examples +; REQUIRES: x86-registered-target +; REQUIRES: amdgpu-registered-target + +; Setup. +; RUN: split-file %s %t +; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \ +; RUN: %t/host-x86_64-unknown-linux-gnu.ll +; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \ +; RUN: %t/openmp-amdgcn-amd-amdhsa.ll +; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \ +; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa +; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \ +; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \ +; RUN: %t/host-x86_64-unknown-linux-gnu.bc +; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \ +; RUN: %t/host-x86_64-unknown-linux-gnu.s + +; Check plugin, -passes, and no remarks. +; RUN: clang-linker-wrapper -o a.out --embed-bitcode \ +; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \ +; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \ +; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s + +; Check plugin, -p, and remarks. +; RUN: clang-linker-wrapper -o a.out --embed-bitcode \ +; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \ +; RUN: --offload-opt=-p="function(goodbye),module(inline)" \ +; RUN: --offload-opt=-pass-remarks=inline \ +; RUN:
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
jdenny-ornl wrote: > Makes sense overall. However in the future I'm looking to move away from the > home-baked LTO pipeline in favor of giving it to the linker. That allows me > to set up libraries as a part of the target toolchain in the driver. I guess > for that I'll just need to forward `-mllvm` to the internal clang invocation. As long as there's some way to inject an LLVM pass plugin at link time (even if it requires -flto or -foffload-lto), that's fine. I don't know that a stable command-line interface is critical at this point. Of course, please ping me if it changes. https://github.com/llvm/llvm-project/pull/96704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (PR #96540)
jyknight wrote: > I guess the clang calling convention code never uses MMX types for > passing/returning values? Correct, Clang never uses MMX types in its calling convention. This is actually _wrong_ for the 32-bit x86 psABI. You're supposed to pass the first 3 MMX args in mm0-2, and return the first MMX value in mm0. Yet...conflicting with those statements, it also states that all functions MUST be entered in x87 mode, and that you must call emms before returning. _shrug_. We did attempt to implement the arg/return-passing rules for MMX in llvm/lib/Target/X86/X86CallingConv.td, but it doesn't actually apply to the IR Clang emits, since Clang never uses the `x87mmx` type, except as needed around the MMX LLVM-builtins, and inline-asm. Anyhow, I propose that we _do not_ attempt to fix Clang's ABI to conform with the 32-bit psABI. We've gotten it wrong for a decade, and at this point, "fixing" it to use MMX registers it would be worse than not doing so. > Have you looked at the code quality? #41665 mentions potential issues with > widening vectors. I've glanced at it. In optimized code, the codegen looks pretty good. Unoptimized code looks pretty bad _before_ my changes, and looks about the same after. I have not attempted to measure performance of any MMX-intrinsics-using code. > This doesn't touch inline asm or _mm_empty; I guess you're leaving that for a > followup? Correct. That needs additional work, which I have not done. I do plan to add to this PR another commit that deletes all the `__builtin_*` MMX functions, which are no longer used, after the header changes here. However, that will leave all those MMX intrinsics existing still on the LLVM side, and I'm not sure how to go about removing those. Should we just do it, and break bitcode backwards-compatibility for those files? Or, if we do need to preserve bitcode compat, how to best achieve it? Perhaps we convert them into inline-asm in the bitcode upgrader? https://github.com/llvm/llvm-project/pull/96540 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,86 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
+
+; REQUIRES: llvm-plugins, llvm-examples
+; REQUIRES: x86-registered-target
+; REQUIRES: amdgpu-registered-target
+
+; Setup.
+; RUN: split-file %s %t
+; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \
+; RUN: %t/host-x86_64-unknown-linux-gnu.ll
+; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \
+; RUN: %t/openmp-amdgcn-amd-amdhsa.ll
+; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa
+; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \
+; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \
+; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: %t/host-x86_64-unknown-linux-gnu.bc
+; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \
+; RUN: %t/host-x86_64-unknown-linux-gnu.s
+
+; Check plugin, -passes, and no remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s
+
+; Check plugin, -p, and remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-p="function(goodbye),module(inline)" \
+; RUN: --offload-opt=-pass-remarks=inline \
+; RUN: --offload-opt=-pass-remarks-output=%t/remarks.yml \
+; RUN: --offload-opt=-pass-remarks-filter=inline \
+; RUN: --offload-opt=-pass-remarks-format=yaml 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT,REM %s
+; RUN: FileCheck -input-file=%t/remarks.yml -match-full-lines \
+; RUN: -check-prefixes=YML %s
+
+; Check handling of bad plugin.
+; RUN: not clang-linker-wrapper \
+; RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
+
+; OUT-NOT: {{.}}
+; OUT: Bye: f
+; OUT-NEXT: Bye: test
+; REM-NEXT: remark: {{.*}} 'f' inlined into 'test' {{.*}}
+; OUT-NOT: {{.}}
+
+; YML-NOT: {{.}}
+; YML: --- !Passed
+; YML-NEXT: Pass: inline
+; YML-NEXT: Name: Inlined
+; YML-NEXT: Function: test
+; YML-NEXT: Args:
+; YML: - Callee: f
+; YML: - Caller: test
+; YML: ...
+; YML-NOT: {{.}}
+
+; BAD-PLUGIN-NOT: {{.}}
+; BAD-PLUGIN: {{.*}}Could not load library {{.*}}nonexistent.so{{.*}}
+; BAD-PLUGIN-NOT: {{.}}
+
+;--- host-x86_64-unknown-linux-gnu.ll
+target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+;--- openmp-amdgcn-amd-amdhsa.ll
+target datalayout =
"e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
+target triple = "amdgcn-amd-amdhsa"
+
+define void @f() {
+entry:
+ ret void
+}
+
+define amdgpu_kernel void @test() {
jhuber6 wrote:
I mean, we have this kernel-split thing when we could just have some generic
LLVM-IR and set `-mtriple` in `opt` to just get the triple and default data
layout instead.
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,86 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
+
+; REQUIRES: llvm-plugins, llvm-examples
+; REQUIRES: x86-registered-target
+; REQUIRES: amdgpu-registered-target
+
+; Setup.
+; RUN: split-file %s %t
+; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \
+; RUN: %t/host-x86_64-unknown-linux-gnu.ll
+; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \
+; RUN: %t/openmp-amdgcn-amd-amdhsa.ll
+; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa
+; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \
+; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \
+; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: %t/host-x86_64-unknown-linux-gnu.bc
+; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \
+; RUN: %t/host-x86_64-unknown-linux-gnu.s
+
+; Check plugin, -passes, and no remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s
+
+; Check plugin, -p, and remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-p="function(goodbye),module(inline)" \
+; RUN: --offload-opt=-pass-remarks=inline \
+; RUN: --offload-opt=-pass-remarks-output=%t/remarks.yml \
+; RUN: --offload-opt=-pass-remarks-filter=inline \
+; RUN: --offload-opt=-pass-remarks-format=yaml 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT,REM %s
+; RUN: FileCheck -input-file=%t/remarks.yml -match-full-lines \
+; RUN: -check-prefixes=YML %s
+
+; Check handling of bad plugin.
+; RUN: not clang-linker-wrapper \
+; RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
+
+; OUT-NOT: {{.}}
+; OUT: Bye: f
+; OUT-NEXT: Bye: test
+; REM-NEXT: remark: {{.*}} 'f' inlined into 'test' {{.*}}
+; OUT-NOT: {{.}}
+
+; YML-NOT: {{.}}
+; YML: --- !Passed
+; YML-NEXT: Pass: inline
+; YML-NEXT: Name: Inlined
+; YML-NEXT: Function: test
+; YML-NEXT: Args:
+; YML: - Callee: f
+; YML: - Caller: test
+; YML: ...
+; YML-NOT: {{.}}
+
+; BAD-PLUGIN-NOT: {{.}}
+; BAD-PLUGIN: {{.*}}Could not load library {{.*}}nonexistent.so{{.*}}
+; BAD-PLUGIN-NOT: {{.}}
+
+;--- host-x86_64-unknown-linux-gnu.ll
+target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+;--- openmp-amdgcn-amd-amdhsa.ll
+target datalayout =
"e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
+target triple = "amdgcn-amd-amdhsa"
+
+define void @f() {
+entry:
+ ret void
+}
+
+define amdgpu_kernel void @test() {
jdenny-ornl wrote:
> Is the kernel really necessary?
OK, I removed it and the test still passed.
> Otherwise I'd just compile with `-mtriple=amdgcn--` or something.
Not sure what you're asking for here. Which command line do you want me to
change?
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
https://github.com/jdenny-ornl updated https://github.com/llvm/llvm-project/pull/96704 >From 98e04dd372b82c2c5309a6148bb49eb1012a97ee Mon Sep 17 00:00:00 2001 From: "Joel E. Denny" Date: Tue, 25 Jun 2024 17:29:49 -0400 Subject: [PATCH 1/2] [LinkerWrapper] Extend with usual pass options The goal of this patch is to enable utilizing LLVM plugin passes and remarks for GPU offload code at link time. Specifically, this patch extends clang-linker-wrapper's `--offload-opt` (and consequently `-mllvm`) to accept the various LLVM pass options that tools like opt usually accept. Those options include `--passes`, `--load-pass-plugin`, and various remarks options. Unlike many other LLVM options that are inherited from linked code by clang-linker-wrapper (e.g., `-pass-remarks` is already implemented in `llvm/lib/IR/DiagnosticHandler.cpp`), these options are implemented separately as needed by each tool (e.g., opt, llc). Fortunately, this patch is able to handle most of the implementation by passing the option values to `lto::Config`. For testing plugin support, this patch uses the simple `Bye` plugin from LLVM core, but that requires several small Clang test suite config extensions. --- clang/test/CMakeLists.txt | 3 + clang/test/Driver/linker-wrapper-llvm-help.c | 10 +++ clang/test/Driver/linker-wrapper-passes.ll| 86 +++ clang/test/Driver/lit.local.cfg | 1 + clang/test/lit.cfg.py | 12 +++ clang/test/lit.site.cfg.py.in | 4 + .../tools/clang-linker-wrapper/CMakeLists.txt | 2 + .../ClangLinkerWrapper.cpp| 74 .../clang-linker-wrapper/LinkerWrapperOpts.td | 8 +- 9 files changed, 198 insertions(+), 2 deletions(-) create mode 100644 clang/test/Driver/linker-wrapper-llvm-help.c create mode 100644 clang/test/Driver/linker-wrapper-passes.ll diff --git a/clang/test/CMakeLists.txt b/clang/test/CMakeLists.txt index 5fceb1d710334..8303269a9ad07 100644 --- a/clang/test/CMakeLists.txt +++ b/clang/test/CMakeLists.txt @@ -11,6 +11,9 @@ llvm_canonicalize_cmake_booleans( CLANG_SPAWN_CC1 CLANG_ENABLE_CIR ENABLE_BACKTRACES + LLVM_BUILD_EXAMPLES + LLVM_BYE_LINK_INTO_TOOLS + LLVM_ENABLE_PLUGINS LLVM_ENABLE_ZLIB LLVM_ENABLE_ZSTD LLVM_ENABLE_PER_TARGET_RUNTIME_DIR diff --git a/clang/test/Driver/linker-wrapper-llvm-help.c b/clang/test/Driver/linker-wrapper-llvm-help.c new file mode 100644 index 0..ffd1cf78bcd9a --- /dev/null +++ b/clang/test/Driver/linker-wrapper-llvm-help.c @@ -0,0 +1,10 @@ +// Check that these simple command lines for listing LLVM options are supported, +// as claimed by 'clang-linker-wrapper --help'. + +// RUN: clang-linker-wrapper -mllvm --help 2>&1 | FileCheck %s +// RUN: clang-linker-wrapper --offload-opt=--help 2>&1 | FileCheck %s + +// Look for a few options supported only after -mllvm and --offload-opt. +// CHECK: OPTIONS: +// CHECK-DAG: --passes= +// CHECK-DAG: --load-pass-plugin= diff --git a/clang/test/Driver/linker-wrapper-passes.ll b/clang/test/Driver/linker-wrapper-passes.ll new file mode 100644 index 0..28493b9a88eb1 --- /dev/null +++ b/clang/test/Driver/linker-wrapper-passes.ll @@ -0,0 +1,86 @@ +; Check various clang-linker-wrapper pass options after -offload-opt. + +; REQUIRES: llvm-plugins, llvm-examples +; REQUIRES: x86-registered-target +; REQUIRES: amdgpu-registered-target + +; Setup. +; RUN: split-file %s %t +; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \ +; RUN: %t/host-x86_64-unknown-linux-gnu.ll +; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \ +; RUN: %t/openmp-amdgcn-amd-amdhsa.ll +; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \ +; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa +; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \ +; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \ +; RUN: %t/host-x86_64-unknown-linux-gnu.bc +; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \ +; RUN: %t/host-x86_64-unknown-linux-gnu.s + +; Check plugin, -passes, and no remarks. +; RUN: clang-linker-wrapper -o a.out --embed-bitcode \ +; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \ +; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \ +; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s + +; Check plugin, -p, and remarks. +; RUN: clang-linker-wrapper -o a.out --embed-bitcode \ +; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \ +; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \ +; RUN: --offload-opt=-p="function(goodbye),module(inline)" \ +; RUN: --offload-opt=-pass-remarks=inline \ +; RUN:
[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
@@ -86,6 +86,8 @@ DYNAMIC_TAG(RELRSZ, 35) // Size of Relr relocation table. DYNAMIC_TAG(RELR, 36)// Address of relocation table (Relr entries). DYNAMIC_TAG(RELRENT, 37) // Size of a Relr relocation entry. +DYNAMIC_TAG(CREL, 38) // CREL relocation table + dwblaikie wrote: > I think we need to avoid generic numbers for dynamic tags/section types etc, > except possibly generic numbers that are a long way from the "normal" range. +1. I've tried to pushback on using any standard range before it's been standardized (eg: https://github.com/llvm/llvm-project/pull/91280#issuecomment-2099201183 https://github.com/llvm/llvm-project/pull/91280#issuecomment-2101019352 ) but I haven't looked through the change completely to see all the enumerations used and how they're reserved, whether they use an extension space or what the argument is for them not using one. Perhaps someone could summarize this aspect of the patch? https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Clang: Add warning flag for storage class specifiers on explicit specializations (PR #96699)
https://github.com/alexfh commented: Should we add a test for this flag? Something around existing tests in clang/test/CXX/temp/temp.spec/temp.expl.spec/p2-20.cpp and clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp. https://github.com/llvm/llvm-project/pull/96699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP][Clang][Sema] Fix crash when calling builtins with pointer arguments (PR #95957)
https://github.com/rymdtian updated
https://github.com/llvm/llvm-project/pull/95957
>From f001ebc8b2670240930de82bb5b4692a0376248e Mon Sep 17 00:00:00 2001
From: Raymond Tian
Date: Tue, 18 Jun 2024 09:58:32 -0700
Subject: [PATCH] [HIP][Clang][Sema] Fix crash when calling builtins with
pointer arguments
Crashed when the number of args passed was less than
number of parameters in builtin definition, because we were indexing the
list of args while iterating through the entire number of parameters.
---
clang/lib/Sema/SemaExpr.cpp | 3 +-
.../SemaCUDA/amdgpu-builtins-pointer-args.cu | 28 +++
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 clang/test/SemaCUDA/amdgpu-builtins-pointer-args.cu
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index acaff304be193..83c3d094c496f 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -6628,7 +6628,8 @@ ExprResult Sema::BuildCallExpr(Scope *Scope, Expr *Fn,
SourceLocation LParenLoc,
// the parameter type.
if (getLangOpts().HIP && getLangOpts().CUDAIsDevice && FD &&
FD->getBuiltinID()) {
- for (unsigned Idx = 0; Idx < FD->param_size(); ++Idx) {
+ for (unsigned Idx = 0; Idx < ArgExprs.size() && Idx < FD->param_size();
+ ++Idx) {
ParmVarDecl *Param = FD->getParamDecl(Idx);
if (!ArgExprs[Idx] || !Param || !Param->getType()->isPointerType() ||
!ArgExprs[Idx]->getType()->isPointerType())
diff --git a/clang/test/SemaCUDA/amdgpu-builtins-pointer-args.cu
b/clang/test/SemaCUDA/amdgpu-builtins-pointer-args.cu
new file mode 100644
index 0..034bfaec25cfd
--- /dev/null
+++ b/clang/test/SemaCUDA/amdgpu-builtins-pointer-args.cu
@@ -0,0 +1,28 @@
+// REQUIRES: amdgpu-registered-target
+// REQUIRES: x86-registered-target
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -aux-triple
x86_64-unknown-linux-gnu -fcuda-is-device -fsyntax-only -verify %s
+
+void call_amdgpu_builtins() {
+ __builtin_amdgcn_fence(); // expected-error {{too few arguments to function
call, expected at least 2, have 0}}
+ __builtin_amdgcn_atomic_inc32(); // expected-error {{too few arguments to
function call, expected 4, have 0}}
+ __builtin_amdgcn_atomic_inc32(0); // expected-error {{too few arguments to
function call, expected 4, have 1}}
+ __builtin_amdgcn_atomic_inc32(0, 0); // expected-error {{too few arguments
to function call, expected 4, have 2}}
+ __builtin_amdgcn_atomic_inc32(0, 0, 0); // expected-error {{too few
arguments to function call, expected 4, have 3}}
+ __builtin_amdgcn_atomic_inc64(); // expected-error {{too few arguments to
function call, expected 4, have 0}}
+ __builtin_amdgcn_atomic_dec32(); // expected-error {{too few arguments to
function call, expected 4, have 0}}
+ __builtin_amdgcn_atomic_dec64(); // expected-error {{too few arguments to
function call, expected 4, have 0}}
+ __builtin_amdgcn_div_scale(); // expected-error {{too few arguments to
function call, expected 4, have 0}}
+ __builtin_amdgcn_div_scale(0); // expected-error {{too few arguments to
function call, expected 4, have 1}}
+ __builtin_amdgcn_div_scale(0, 0); // expected-error {{too few arguments to
function call, expected 4, have 2}}
+ __builtin_amdgcn_div_scale(0, 0, 0); // expected-error {{too few arguments
to function call, expected 4, have 3}}
+ __builtin_amdgcn_div_scalef(); // expected-error {{too few arguments to
function call, expected 4, have 0}}
+ __builtin_amdgcn_ds_faddf(); // expected-error {{too few arguments to
function call, expected 5, have 0}}
+ __builtin_amdgcn_ds_fminf(); // expected-error {{too few arguments to
function call, expected 5, have 0}}
+ __builtin_amdgcn_ds_fmaxf(); // expected-error {{too few arguments to
function call, expected 5, have 0}}
+ __builtin_amdgcn_ds_append(); // expected-error {{too few arguments to
function call, expected 1, have 0}}
+ __builtin_amdgcn_ds_consume(); // expected-error {{too few arguments to
function call, expected 1, have 0}}
+ __builtin_amdgcn_is_shared(); // expected-error {{too few arguments to
function call, expected 1, have 0}}
+ __builtin_amdgcn_is_private(); // expected-error {{too few arguments to
function call, expected 1, have 0}}
+}
+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [LinkerWrapper] Extend with usual pass options (PR #96704)
@@ -0,0 +1,86 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
+
+; REQUIRES: llvm-plugins, llvm-examples
+; REQUIRES: x86-registered-target
+; REQUIRES: amdgpu-registered-target
+
+; Setup.
+; RUN: split-file %s %t
+; RUN: opt -o %t/host-x86_64-unknown-linux-gnu.bc \
+; RUN: %t/host-x86_64-unknown-linux-gnu.ll
+; RUN: opt -o %t/openmp-amdgcn-amd-amdhsa.bc \
+; RUN: %t/openmp-amdgcn-amd-amdhsa.ll
+; RUN: clang-offload-packager -o %t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: --image=file=%t/openmp-amdgcn-amd-amdhsa.bc,triple=amdgcn-amd-amdhsa
+; RUN: %clang -cc1 -S -o %t/host-x86_64-unknown-linux-gnu.s \
+; RUN: -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \
+; RUN: -fembed-offload-object=%t/openmp-x86_64-unknown-linux-gnu.out \
+; RUN: %t/host-x86_64-unknown-linux-gnu.bc
+; RUN: %clang -cc1as -o %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64 \
+; RUN: %t/host-x86_64-unknown-linux-gnu.s
+
+; Check plugin, -passes, and no remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT %s
+
+; Check plugin, -p, and remarks.
+; RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+; RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
+; RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
+; RUN: --offload-opt=-p="function(goodbye),module(inline)" \
+; RUN: --offload-opt=-pass-remarks=inline \
+; RUN: --offload-opt=-pass-remarks-output=%t/remarks.yml \
+; RUN: --offload-opt=-pass-remarks-filter=inline \
+; RUN: --offload-opt=-pass-remarks-format=yaml 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=OUT,REM %s
+; RUN: FileCheck -input-file=%t/remarks.yml -match-full-lines \
+; RUN: -check-prefixes=YML %s
+
+; Check handling of bad plugin.
+; RUN: not clang-linker-wrapper \
+; RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
+; RUN: FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
+
+; OUT-NOT: {{.}}
+; OUT: Bye: f
+; OUT-NEXT: Bye: test
+; REM-NEXT: remark: {{.*}} 'f' inlined into 'test' {{.*}}
+; OUT-NOT: {{.}}
+
+; YML-NOT: {{.}}
+; YML: --- !Passed
+; YML-NEXT: Pass: inline
+; YML-NEXT: Name: Inlined
+; YML-NEXT: Function: test
+; YML-NEXT: Args:
+; YML: - Callee: f
+; YML: - Caller: test
+; YML: ...
+; YML-NOT: {{.}}
+
+; BAD-PLUGIN-NOT: {{.}}
+; BAD-PLUGIN: {{.*}}Could not load library {{.*}}nonexistent.so{{.*}}
+; BAD-PLUGIN-NOT: {{.}}
+
+;--- host-x86_64-unknown-linux-gnu.ll
+target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+;--- openmp-amdgcn-amd-amdhsa.ll
+target datalayout =
"e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
+target triple = "amdgcn-amd-amdhsa"
+
+define void @f() {
+entry:
+ ret void
+}
+
+define amdgpu_kernel void @test() {
jdenny-ornl wrote:
That came from clang followed by llvm-reduce. I'll look into refactoring it.
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
