[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
- // FIXME: We should enable RelaxedTemplateTemplateArgs by default as it is a
- // defect report resolution from C++17 and shouldn't be introduced by
- // concepts.
- if (getLangOpts().RelaxedTemplateTemplateArgs) {
erichkeane wrote:
>How about for starters we just change the default, but still deprecate the
>flag both ways anyway?
If the transition is a concern, I think it would be a problem that we don't
start to warn the users of the flags as soon as possible. Otherwise, I think
this will be specially problematic if there are current users of the negative
spelling -fno-relaxed-template-template-args.
Seems reasonable to me.
I had missed the impact of the CWG issue, if @zygoloid thinks we're Ok with
just deprecating the flags (or removing them? I think I'd prefer the
deprecate-but-do-nothing over removal), I'm Ok too.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][HLSL] Add environment parameter to availability attribute (PR #89809)
https://github.com/hekota updated
https://github.com/llvm/llvm-project/pull/89809
>From 22b67d30ca087d6a912183039c87fd1790eedfe4 Mon Sep 17 00:00:00 2001
From: Helena Kotas
Date: Tue, 23 Apr 2024 00:49:28 -0700
Subject: [PATCH 1/2] Add environment parameter to clang availability attribute
---
clang/include/clang/Basic/Attr.td | 33 +-
clang/include/clang/Basic/AttrDocs.td | 2 +
.../clang/Basic/DiagnosticParseKinds.td | 2 +
.../clang/Basic/DiagnosticSemaKinds.td| 5 +-
clang/include/clang/Parse/Parser.h| 3 +
clang/include/clang/Sema/ParsedAttr.h | 40 ---
clang/include/clang/Sema/Sema.h | 5 +-
clang/lib/AST/DeclBase.cpp| 27 -
clang/lib/Headers/hlsl/hlsl_intrinsics.h | 13 ++-
clang/lib/Index/CommentToXML.cpp | 3 +
clang/lib/Parse/ParseDecl.cpp | 20 +++-
clang/lib/Sema/SemaAPINotes.cpp | 3 +-
clang/lib/Sema/SemaAvailability.cpp | 109 +-
clang/lib/Sema/SemaDecl.cpp | 2 +-
clang/lib/Sema/SemaDeclAttr.cpp | 34 --
15 files changed, 232 insertions(+), 69 deletions(-)
diff --git a/clang/include/clang/Basic/Attr.td
b/clang/include/clang/Basic/Attr.td
index dc87a8c6f022dc..1b07f4eb408093 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -956,7 +956,7 @@ def Availability : InheritableAttr {
VersionArgument<"deprecated">, VersionArgument<"obsoleted">,
BoolArgument<"unavailable">, StringArgument<"message">,
BoolArgument<"strict">, StringArgument<"replacement">,
- IntArgument<"priority">];
+ IntArgument<"priority">, IdentifierArgument<"environment">];
let AdditionalMembers =
[{static llvm::StringRef getPrettyPlatformName(llvm::StringRef Platform) {
return llvm::StringSwitch(Platform)
@@ -976,7 +976,7 @@ def Availability : InheritableAttr {
.Case("xros", "visionOS")
.Case("xros_app_extension", "visionOS (App Extension)")
.Case("swift", "Swift")
- .Case("shadermodel", "HLSL ShaderModel")
+ .Case("shadermodel", "HLSL Shader Model")
.Case("ohos", "OpenHarmony OS")
.Default(llvm::StringRef());
}
@@ -1016,7 +1016,34 @@ static llvm::StringRef
canonicalizePlatformName(llvm::StringRef Platform) {
.Case("visionos_app_extension", "xros_app_extension")
.Case("ShaderModel", "shadermodel")
.Default(Platform);
-} }];
+}
+static llvm::StringRef getPrettyEnviromentName(llvm::StringRef Environment) {
+return llvm::StringSwitch(Environment)
+ .Case("pixel", "pixel shader")
+ .Case("vertex", "vertex shader")
+ .Case("geometry", "geometry shader")
+ .Case("hull", "hull shader")
+ .Case("domain", "domain shader")
+ .Case("compute", "compute shader")
+ .Case("mesh", "mesh shader")
+ .Case("amplification", "amplification shader")
+ .Case("library", "shader library")
+ .Default(Environment);
+}
+static llvm::Triple::EnvironmentType getEnvironmentType(llvm::StringRef
Environment) {
+return llvm::StringSwitch(Environment)
+ .Case("pixel", llvm::Triple::Pixel)
+ .Case("vertex", llvm::Triple::Vertex)
+ .Case("geometry", llvm::Triple::Geometry)
+ .Case("hull", llvm::Triple::Hull)
+ .Case("domain", llvm::Triple::Domain)
+ .Case("compute", llvm::Triple::Compute)
+ .Case("mesh", llvm::Triple::Mesh)
+ .Case("amplification", llvm::Triple::Amplification)
+ .Case("library", llvm::Triple::Library)
+ .Default(llvm::Triple::UnknownEnvironment);
+}
+}];
let HasCustomParsing = 1;
let InheritEvenIfAlreadyPresent = 1;
let Subjects = SubjectList<[Named]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td
b/clang/include/clang/Basic/AttrDocs.td
index a0bbe5861c5722..a81163df35ca8b 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -1593,6 +1593,8 @@ replacement=\ *string-literal*
a warning about use of a deprecated declaration. The Fix-It will replace
the deprecated declaration with the new declaration specified.
+// HEKOTA TODO add docs here
+
Multiple availability attributes can be placed on a declaration, which may
correspond to different platforms. For most platforms, the availability
attribute with the platform corresponding to the target platform will be used;
diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 66405095d51de8..631dc8880fcfc8 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1103,6 +1103,8 @@
[clang] [clang] Refactor `IdentifierInfo::ObjcOrBuiltinID` (PR #71709)
@@ -3597,8 +3597,13 @@ class ASTIdentifierTableTrait {
/// doesn't check whether the name has macros defined; use
PublicMacroIterator
/// to check that.
bool isInterestingIdentifier(const IdentifierInfo *II, uint64_t MacroOffset)
{
-if (MacroOffset || II->isPoisoned() ||
-(!IsModule && II->getObjCOrBuiltinID()) ||
+II->getObjCOrBuiltinID();
mikerice1969 wrote:
Hi @Endilll, Does this call to getObjCOrBuiltinID do anything? Static verifiers
report it 'useless' since it only returns a value and the value is not used.
https://github.com/llvm/llvm-project/pull/71709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
https://github.com/dschuff approved this pull request. (also LGTM FTR) https://github.com/llvm/llvm-project/pull/80923 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
https://github.com/dschuff edited https://github.com/llvm/llvm-project/pull/80923 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
@@ -147,19 +147,25 @@ void
WebAssemblyTargetInfo::setFeatureEnabled(llvm::StringMap &Features,
bool WebAssemblyTargetInfo::initFeatureMap(
llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector &FeaturesVec) const {
- if (CPU == "bleeding-edge") {
-Features["nontrapping-fptoint"] = true;
+ auto addGenericFeatures = [&]() {
Features["sign-ext"] = true;
+Features["mutable-globals"] = true;
+Features["reference-types"] = true;
+Features["multivalue"] = true;
+ };
+ auto addBleedingEdgeFeatures = [&]() {
+addGenericFeatures();
+Features["nontrapping-fptoint"] = true;
dschuff wrote:
MV and reftypes are required to use exnref, that's the thing that's on the
critical path here. So yes, we definitely want to land these two without
blocking on nontrapping-fptoint.
Relatedly (to nontrapping-fptoint, but unrelatedly to this PR), I prototyped a
Binaryen pass to lower away LLVM's use of nontrapping-fptoint* which is what
would allow us to improve codegen. I think it works, but I discovered that some
of emscripten's tests fail when we enable nontrapping fptoint, and I haven't
yet looked at why that's the case (either a bug in emscripten's tests, or a bug
in V8's implementation of nontrapping fptoint). We'd need to also fix that to
unblock enabling this.
* (This isn't exactly the same as a full lowering of nontrapping-fptoint as
spec'ed, because it takes advantage of knowledge of the semantics of LLVM's
fptosi intrinsics)
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][SPIR-V] Add support for AMDGCN flavoured SPIRV (PR #89796)
@@ -54,3 +56,289 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
&Opts,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static constexpr Builtin::Info BuiltinInfo[] = {
+#define BUILTIN(ID, TYPE, ATTRS)
\
+ {#ID, TYPE, ATTRS, nullptr, HeaderDesc::NO_HEADER, ALL_LANGUAGES},
+#define TARGET_BUILTIN(ID, TYPE, ATTRS, FEATURE)
\
+ {#ID, TYPE, ATTRS, FEATURE, HeaderDesc::NO_HEADER, ALL_LANGUAGES},
+#include "clang/Basic/BuiltinsAMDGPU.def"
+};
+
+namespace {
+const char *AMDGPUGCCRegNames[] = {
+ "v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", "v8",
+ "v9", "v10", "v11", "v12", "v13", "v14", "v15", "v16", "v17",
+ "v18", "v19", "v20", "v21", "v22", "v23", "v24", "v25", "v26",
+ "v27", "v28", "v29", "v30", "v31", "v32", "v33", "v34", "v35",
+ "v36", "v37", "v38", "v39", "v40", "v41", "v42", "v43", "v44",
+ "v45", "v46", "v47", "v48", "v49", "v50", "v51", "v52", "v53",
+ "v54", "v55", "v56", "v57", "v58", "v59", "v60", "v61", "v62",
+ "v63", "v64", "v65", "v66", "v67", "v68", "v69", "v70", "v71",
+ "v72", "v73", "v74", "v75", "v76", "v77", "v78", "v79", "v80",
+ "v81", "v82", "v83", "v84", "v85", "v86", "v87", "v88", "v89",
+ "v90", "v91", "v92", "v93", "v94", "v95", "v96", "v97", "v98",
+ "v99", "v100", "v101", "v102", "v103", "v104", "v105", "v106", "v107",
+ "v108", "v109", "v110", "v111", "v112", "v113", "v114", "v115", "v116",
+ "v117", "v118", "v119", "v120", "v121", "v122", "v123", "v124", "v125",
+ "v126", "v127", "v128", "v129", "v130", "v131", "v132", "v133", "v134",
+ "v135", "v136", "v137", "v138", "v139", "v140", "v141", "v142", "v143",
+ "v144", "v145", "v146", "v147", "v148", "v149", "v150", "v151", "v152",
+ "v153", "v154", "v155", "v156", "v157", "v158", "v159", "v160", "v161",
+ "v162", "v163", "v164", "v165", "v166", "v167", "v168", "v169", "v170",
+ "v171", "v172", "v173", "v174", "v175", "v176", "v177", "v178", "v179",
+ "v180", "v181", "v182", "v183", "v184", "v185", "v186", "v187", "v188",
+ "v189", "v190", "v191", "v192", "v193", "v194", "v195", "v196", "v197",
+ "v198", "v199", "v200", "v201", "v202", "v203", "v204", "v205", "v206",
+ "v207", "v208", "v209", "v210", "v211", "v212", "v213", "v214", "v215",
+ "v216", "v217", "v218", "v219", "v220", "v221", "v222", "v223", "v224",
+ "v225", "v226", "v227", "v228", "v229", "v230", "v231", "v232", "v233",
+ "v234", "v235", "v236", "v237", "v238", "v239", "v240", "v241", "v242",
+ "v243", "v244", "v245", "v246", "v247", "v248", "v249", "v250", "v251",
+ "v252", "v253", "v254", "v255", "s0", "s1", "s2", "s3", "s4",
+ "s5", "s6", "s7", "s8", "s9", "s10", "s11", "s12", "s13",
+ "s14", "s15", "s16", "s17", "s18", "s19", "s20", "s21", "s22",
+ "s23", "s24", "s25", "s26", "s27", "s28", "s29", "s30", "s31",
+ "s32", "s33", "s34", "s35", "s36", "s37", "s38", "s39", "s40",
+ "s41", "s42", "s43", "s44", "s45", "s46", "s47", "s48", "s49",
+ "s50", "s51", "s52", "s53", "s54", "s55", "s56", "s57", "s58",
+ "s59", "s60", "s61", "s62", "s63", "s64", "s65", "s66", "s67",
+ "s68", "s69", "s70", "s71", "s72", "s73", "s74", "s75", "s76",
+ "s77", "s78", "s79", "s80", "s81", "s82", "s83", "s84", "s85",
+ "s86", "s87", "s88", "s89", "s90", "s91", "s92", "s93", "s94",
+ "s95", "s96", "s97", "s98", "s99", "s100", "s101", "s102", "s103",
+ "s104", "s105", "s106", "s107", "s108", "s109", "s110", "s111", "s112",
+ "s113", "s114", "s115", "s116", "s117", "s118", "s119", "s120", "s121",
+ "s122", "s123", "s124", "s125", "s126", "s127", "exec", "vcc", "scc",
+ "m0", "flat_scratch", "exec_lo", "exec_hi", "vcc_lo", "vcc_hi",
+ "flat_scratch_lo", "flat_scratch_hi",
+ "a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7", "a8",
+ "a9", "a10", "a11", "a12", "a13", "a14", "a15", "a16", "a17",
+ "a18", "a19", "a20", "a21", "a22", "a23", "a24", "a25", "a26",
+ "a27", "a28", "a29", "a30", "a31", "a32", "a33", "a34", "a35",
+ "a36", "a37", "a38", "a39", "a40", "a41", "a42", "a43", "a44",
+ "a45", "a46", "a47", "a48", "a49", "a50", "a51", "a52", "a53",
+ "a54", "a55", "a56", "a57", "a58", "a59", "a60", "a61", "a62",
+ "a63", "a64", "a65", "a66", "a67", "a68", "a69", "a70", "a71",
+ "a72", "a73", "a74", "a75", "a76", "a77", "a78", "a79", "a80",
+ "a81", "a82", "a83", "a84", "a85", "a86", "a87", "a88", "a89",
+ "a90", "a91", "a92", "a93", "a94", "a95", "a96", "a97", "a98",
+ "a99", "a100", "a101", "a102", "a103", "a104", "a105", "a106", "a107",
+ "a108", "a109", "a110", "a111", "a112", "a113", "a114", "a115", "a116",
+ "a117", "a118", "a119", "a120", "a121", "a122", "a123", "a124", "a125",
+ "a126", "a127", "a128", "a129", "a130", "a131", "a132", "a133", "a134",
+ "a135", "a136", "a137", "a138", "a139", "a140", "a141", "a142", "a143",
+ "a144", "a145", "a146", "a147", "a148", "a149", "a150", "a151", "a152",
+ "a153", "a154", "a155", "a156", "a157", "a158", "a159", "a
[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)
https://github.com/jansvoboda11 updated
https://github.com/llvm/llvm-project/pull/89441
>From 9165d6086e2570198fba1c333d0c9cb9c09037c7 Mon Sep 17 00:00:00 2001
From: Jan Svoboda
Date: Fri, 19 Apr 2024 12:13:06 -0700
Subject: [PATCH 1/4] [clang][modules] Allow module map files with textual
header be non-affecting
---
clang/lib/Serialization/ASTWriter.cpp | 10 ---
...e-non-affecting-module-map-files-textual.c | 26 +++
2 files changed, 32 insertions(+), 4 deletions(-)
create mode 100644
clang/test/Modules/prune-non-affecting-module-map-files-textual.c
diff --git a/clang/lib/Serialization/ASTWriter.cpp
b/clang/lib/Serialization/ASTWriter.cpp
index 8a4b36207c4734..4825c245a4b846 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -187,7 +187,8 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module
*RootModule) {
continue;
const HeaderFileInfo *HFI = HS.getExistingLocalFileInfo(*File);
-if (!HFI || (HFI->isModuleHeader && !HFI->isCompilingModuleHeader))
+if (!HFI || ((HFI->isModuleHeader || HFI->isTextualModuleHeader) &&
+ !HFI->isCompilingModuleHeader))
continue;
for (const auto &KH : HS.findResolvedModulesForHeader(*File)) {
@@ -2055,11 +2056,12 @@ void ASTWriter::WriteHeaderSearch(const HeaderSearch
&HS) {
// Get the file info. Skip emitting this file if we have no information on
// it as a header file (in which case HFI will be null) or if it hasn't
-// changed since it was loaded. Also skip it if it's for a modular header
-// from a different module; in that case, we rely on the module(s)
+// changed since it was loaded. Also skip it if it's for a non-excluded
+// header from a different module; in that case, we rely on the module(s)
// containing the header to provide this information.
const HeaderFileInfo *HFI = HS.getExistingLocalFileInfo(*File);
-if (!HFI || (HFI->isModuleHeader && !HFI->isCompilingModuleHeader))
+if (!HFI || ((HFI->isModuleHeader || HFI->isTextualModuleHeader) &&
+ !HFI->isCompilingModuleHeader))
continue;
// Massage the file path into an appropriate form.
diff --git a/clang/test/Modules/prune-non-affecting-module-map-files-textual.c
b/clang/test/Modules/prune-non-affecting-module-map-files-textual.c
new file mode 100644
index 00..8f8f00560b1834
--- /dev/null
+++ b/clang/test/Modules/prune-non-affecting-module-map-files-textual.c
@@ -0,0 +1,26 @@
+// This test checks that a module map with a textual header can be marked as
+// non-affecting.
+
+// RUN: rm -rf %t && mkdir %t
+// RUN: split-file %s %t
+
+//--- A.modulemap
+module A { textual header "A.h" }
+//--- B.modulemap
+module B { header "B.h" export * }
+//--- A.h
+typedef int A_int;
+//--- B.h
+#include "A.h"
+typedef A_int B_int;
+
+// RUN: %clang_cc1 -fmodules -emit-module %t/A.modulemap -fmodule-name=A -o
%t/A.pcm \
+// RUN: -fmodule-map-file=%t/A.modulemap -fmodule-map-file=%t/B.modulemap
+
+// RUN: %clang_cc1 -fmodules -emit-module %t/B.modulemap -fmodule-name=B -o
%t/B0.pcm \
+// RUN: -fmodule-map-file=%t/A.modulemap -fmodule-map-file=%t/B.modulemap
-fmodule-file=%t/A.pcm
+
+// RUN: %clang_cc1 -fmodules -emit-module %t/B.modulemap -fmodule-name=B -o
%t/B1.pcm \
+// RUN:-fmodule-map-file=%t/B.modulemap
-fmodule-file=%t/A.pcm
+
+// RUN: diff %t/B0.pcm %t/B1.pcm
>From 17b1860b25de99f8b2b2e047ef1590b8ede6648b Mon Sep 17 00:00:00 2001
From: Jan Svoboda
Date: Mon, 22 Apr 2024 09:28:26 -0700
Subject: [PATCH 2/4] [clang][modules] Mark 'use'd modules as affecting
---
clang/lib/Serialization/ASTWriter.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/clang/lib/Serialization/ASTWriter.cpp
b/clang/lib/Serialization/ASTWriter.cpp
index 4825c245a4b846..8c303fa67e3023 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -238,6 +238,8 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module
*RootModule) {
CollectIncludingMapsFromAncestors(CurrentModule);
for (const Module *ImportedModule : CurrentModule->Imports)
CollectIncludingMapsFromAncestors(ImportedModule);
+for (const Module *UsedModule : CurrentModule->DirectUses)
+ CollectIncludingMapsFromAncestors(UsedModule);
for (const Module *UndeclaredModule : CurrentModule->UndeclaredUses)
CollectIncludingMapsFromAncestors(UndeclaredModule);
}
>From 9eeea3f468432ec810a9e09696cf6a527c7db233 Mon Sep 17 00:00:00 2001
From: Jan Svoboda
Date: Tue, 23 Apr 2024 07:51:17 -0700
Subject: [PATCH 3/4] [clang][modules] Do consider module maps of included
textual headers affecting
---
clang/lib/Serialization/ASTWriter.cpp| 16 +---
...rune-non-affecting-module-map-files-textual.c | 14 --
2 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/clang/lib/Serialization/ASTWriter.cpp
b/cl
[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)
kovdan01 wrote: @AaronBallman @rjmccall Please see 53485b1e7f7c60253b8734e95ae9b9a04e9e7a95 commit which makes `Mask` 64-bit and removes separate `PtrAuth` field in `Qualifiers`. The performance becomes better: - before https://llvm-compile-time-tracker.com/compare.php?from=3ae10fde39419d7c985b9fff210ed44b699e438c&to=ed334d7dba24c53d39c8994d51440e34f6d3b375 - after https://llvm-compile-time-tracker.com/compare.php?from=3ae10fde39419d7c985b9fff210ed44b699e438c&to=7c4ee3fd79a0cda33e60b4681ec327055d5f5c20 https://github.com/llvm/llvm-project/pull/84384 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][SPIR-V] Add support for AMDGCN flavoured SPIRV (PR #89796)
AlexVlx wrote: > How much of this is actually different from the existing target info for > AMDGCN? Seems like we're doing a lot of redundant stuff like defining macros > or features. That's part of the point, it's not actually supposed to differ in those particular regards, up to the point where things fork into specific GFXIPs. At the same time, there's no feasible way to re-use any of that, at least not one that I can see with how targets currently work. If you're suggesting that this should actually be based on AMDGPUTargetInfo, that's probably not the right way to go since that sets additional things that do not work with SPIRV at all. https://github.com/llvm/llvm-project/pull/89796 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)
https://github.com/kovdan01 updated
https://github.com/llvm/llvm-project/pull/84384
>From ef23d427b48687b62da9e1062886ddfcc1649b6a Mon Sep 17 00:00:00 2001
From: John McCall
Date: Mon, 16 Dec 2019 20:31:25 -0500
Subject: [PATCH 1/9] Abstract serialization fixes for the Apple Clang changes.
---
clang/include/clang/AST/AbstractBasicReader.h | 4 ++--
clang/include/clang/AST/AbstractBasicWriter.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/clang/include/clang/AST/AbstractBasicReader.h
b/clang/include/clang/AST/AbstractBasicReader.h
index 1f2797cc701458..ab036f1d445acc 100644
--- a/clang/include/clang/AST/AbstractBasicReader.h
+++ b/clang/include/clang/AST/AbstractBasicReader.h
@@ -213,9 +213,9 @@ class DataStreamBasicReader : public BasicReaderBase {
}
Qualifiers readQualifiers() {
-static_assert(sizeof(Qualifiers().getAsOpaqueValue()) <= sizeof(uint32_t),
+static_assert(sizeof(Qualifiers().getAsOpaqueValue()) <= sizeof(uint64_t),
"update this if the value size changes");
-uint32_t value = asImpl().readUInt32();
+uint64_t value = asImpl().readUInt64();
return Qualifiers::fromOpaqueValue(value);
}
diff --git a/clang/include/clang/AST/AbstractBasicWriter.h
b/clang/include/clang/AST/AbstractBasicWriter.h
index 07afa388de2c17..8e42fcaad1d388 100644
--- a/clang/include/clang/AST/AbstractBasicWriter.h
+++ b/clang/include/clang/AST/AbstractBasicWriter.h
@@ -196,9 +196,9 @@ class DataStreamBasicWriter : public BasicWriterBase {
}
void writeQualifiers(Qualifiers value) {
-static_assert(sizeof(value.getAsOpaqueValue()) <= sizeof(uint32_t),
+static_assert(sizeof(value.getAsOpaqueValue()) <= sizeof(uint64_t),
"update this if the value size changes");
-asImpl().writeUInt32(value.getAsOpaqueValue());
+asImpl().writeUInt64(value.getAsOpaqueValue());
}
void writeExceptionSpecInfo(
>From 9e296a1a69158419960c265f12f52523db0c8e2a Mon Sep 17 00:00:00 2001
From: Daniil Kovalev
Date: Thu, 7 Mar 2024 15:34:24 +0300
Subject: [PATCH 2/9] [clang] Define `PointerAuthenticationMode` enum
---
clang/include/clang/Basic/LangOptions.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/clang/include/clang/Basic/LangOptions.h
b/clang/include/clang/Basic/LangOptions.h
index 862952d336ef31..6fe7472d8ad0ca 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -57,6 +57,13 @@ enum class ShaderStage {
Invalid,
};
+enum class PointerAuthenticationMode : unsigned {
+ None,
+ Strip,
+ SignAndStrip,
+ SignAndAuth
+};
+
/// Bitfields of LangOptions, split out from LangOptions in order to ensure
that
/// this large collection of bitfields is a trivial class type.
class LangOptionsBase {
>From 71d7760aa9cc459d7bc0365fa079f64cb5704c96 Mon Sep 17 00:00:00 2001
From: Daniil Kovalev
Date: Thu, 7 Mar 2024 15:31:03 +0300
Subject: [PATCH 3/9] [clang] Define `PointerAuthQualifier` class
Includes changes from the following commits from the branch
https://github.com/ahmedbougacha/llvm-project/tree/eng/arm64e-upstream-llvmorg
- Initial support
https://github.com/ahmedbougacha/llvm-project/commit/cc7ba7eb1814e9b254c7d94aa0b78cb0e21acfc5
- ObjC isa signing
https://github.com/ahmedbougacha/llvm-project/commit/c9ce0d408f1d9aeffc7b86256334220aec6de5a3
Also applies a fix from https://github.com/access-softek/llvm-project/pull/75
Co-authored-by: Ahmed Bougacha
---
clang/include/clang/AST/Type.h| 215 +-
.../include/clang/Basic/PointerAuthOptions.h | 23 ++
2 files changed, 227 insertions(+), 11 deletions(-)
create mode 100644 clang/include/clang/Basic/PointerAuthOptions.h
diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 1942b0e67f65a3..1741a3017f7280 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -25,8 +25,10 @@
#include "clang/Basic/Diagnostic.h"
#include "clang/Basic/ExceptionSpecificationType.h"
#include "clang/Basic/LLVM.h"
+#include "clang/Basic/LangOptions.h"
#include "clang/Basic/Linkage.h"
#include "clang/Basic/PartialDiagnostic.h"
+#include "clang/Basic/PointerAuthOptions.h"
#include "clang/Basic/SourceLocation.h"
#include "clang/Basic/Specifiers.h"
#include "clang/Basic/Visibility.h"
@@ -138,6 +140,165 @@ using CanQualType = CanQual;
#define TYPE(Class, Base) class Class##Type;
#include "clang/AST/TypeNodes.inc"
+/// Pointer-authentication qualifiers.
+class PointerAuthQualifier {
+ enum : uint32_t {
+EnabledShift = 0,
+EnabledBits = 1,
+EnabledMask = 1 << EnabledShift,
+AddressDiscriminatedShift = EnabledShift + EnabledBits,
+AddressDiscriminatedBits = 1,
+AddressDiscriminatedMask = 1 << AddressDiscriminatedShift,
+AuthenticationModeShift =
+AddressDiscriminatedShift + AddressDiscriminatedBits,
+AuthenticationModeBits = 2,
+AuthenticationModeMask = ((1 << AuthenticationModeBits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
https://github.com/jcranmer-intel commented: Other side notes: fmin and frexp can signal exceptions if the input is an sNaN, which causes [library.c]p3 to kick in. (That's the only time these operations can signal an exception.) https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr();
+
+ return false;
+}
+
Decl *Parser::ParseDeclarationAfterDeclaratorAndAttributes(
Declarator &D, const ParsedTemplateInfo &TemplateInfo, ForRangeInit *FRI) {
// RAII type used to track whether we're inside an initializer.
struct InitializerScopeRAII {
Parser &P;
Declarator &D;
Decl *ThisDecl;
+EnterExpressionEvaluationContext EC;
InitializerScopeRAII(Parser &P, Declarator &D, Decl *ThisDecl)
-: P(P), D(D), ThisDecl(ThisDecl) {
+: P(P), D(D), ThisDecl(ThisDecl),
+ EC(P.Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated,
+ ThisDecl, Sema::ExpressionEvaluationContextRecord::EK_Other,
+ isConstexprVariable(ThisDecl)) {
katzdm wrote:
@efriedma-quic I see your point - we need to handle a broader class of
variables in this case than just `constexpr`. Let me see what I can do, thanks
for the feedback.
https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr();
+
+ return false;
+}
+
Decl *Parser::ParseDeclarationAfterDeclaratorAndAttributes(
Declarator &D, const ParsedTemplateInfo &TemplateInfo, ForRangeInit *FRI) {
// RAII type used to track whether we're inside an initializer.
struct InitializerScopeRAII {
Parser &P;
Declarator &D;
Decl *ThisDecl;
+EnterExpressionEvaluationContext EC;
InitializerScopeRAII(Parser &P, Declarator &D, Decl *ThisDecl)
-: P(P), D(D), ThisDecl(ThisDecl) {
+: P(P), D(D), ThisDecl(ThisDecl),
+ EC(P.Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated,
+ ThisDecl, Sema::ExpressionEvaluationContextRecord::EK_Other,
+ isConstexprVariable(ThisDecl)) {
katzdm wrote:
> if I'm understanding the rule, it's not supposed to be valid.
Agreed; MSVC appears to get this right:
```
(8): error C7595: 'fn': call to immediate function is not a constant
expression
```
Since `int a` is not usable in a constant expression, its initializer isn't
manifestly constant-evaluated. Thus only the call to `fn()` is manifestly
constant-evaluated, so the access to the heap-allocated memory is ill-formed.
...as far as I can tell 😅
https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo &Info, const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to IEEE 754 here.
- if (LHS.isNaN()) {
+ if (!Info.getLangOpts().CPlusPlus23 && LHS.isNaN()) {
jcranmer-intel wrote:
https://eel.is/c++draft/library.c#3 says that
>A call to a C standard library function is a non-constant library call
>([defns.nonconst.libcall]) if it raises a floating-point exception other than
>FE_INEXACT.)"
which suggests that floating-point exceptions should generally cause things to
fall out of constant expressions. C's Annex F suggests that warnings be emitted
for constant expressions that cause floating-point exceptions other than
FE_INEXACT (see F.8.2p2).
As for wording, [expr.pre]p4 requires that things be "mathematically defined",
except IEEE 754 specifically says (in section 3.2)
> The mathematical structure underpinning the arithmetic in this standard is
> the extended reals, that is, the set
of real numbers together with positive and negative infinity.
The C++ specification actually does define "mathematically defined" somewhere,
in a footnote of https://eel.is/c++draft/sf.cmath.general:
> A mathematical function is mathematically defined for a given set of argument
> values (a) if it is explicitly defined for that set of argument values, or
> (b) if its limiting value exists and does not depend on the direction of
> approach.
(which, as pendants will note, only defines it for functions, not the base
operations of C++, and sidesteps the question of what the set of argument
values actually is).
It does seem pretty clear from all the standards that a result of infinity is
clearly part of the representable types, and it seems a reasonable inference
that the result being infinity is "mathematically defined" (division by 0 is
permissible in the extended real numbers).
The role of NaNs is... clear as mud. You have to go into the definition of
to find out that NaN is a representable value. IEEE 754 gives multiple
specification levels for floating-point, where NaN is a part of some of them,
and proceeds to ignore the fact that it did so in the rest of the
specification; the definition of operations involving NaN is deferred into an
entire separate section. Section 7.2 goes so far as to say that
> The invalid operation exception is signaled if and only if there is no
> usefully definable result. In these cases
the operands are invalid for the operation to be performed.
Is `0.0 / 0.0` "mathematically defined" per IEEE 754? It's definitely
*defined*, but I don't think I can entirely endorse saying that it's
"mathematically defined." The rule of thumb that FE_INVALID is signaled when
the inputs are non-qNaN but the output is NaN, combined with the above text,
makes it suspect that it should be considered a "mathematical" definition. But
this also doesn't help with `NaN / NaN`, which is `NaN` but doesn't throw a
FE_INVALID.
As noted in the CWG issue Aaron linked to, someone needs to write a paper to
clarify this, and... that's going to be me isn't it?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
https://github.com/mizvekov edited https://github.com/llvm/llvm-project/pull/89807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes +C++17 Feature Support +^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros to support standard library implementations of + ``std::hardware_destructive_interference_size`` and + ``std::hardware_constructive_interference_size``, respectively. These macros + are predefined in all C and C++ language modes. These macros can be + overridden on the command line with ``-D``, if desired. The values the macros jyknight wrote: > My comment was only to not encourage using -D. The fact it's defined through > a macro is really an implementation details, the macro is not meant to be > user facing. There should to be a user-facing way to set this, in order to pin it to a particular value. If not -D, then e.g. copy GCC's `--param hardware_destructive_interference_size=N` command-line. > we don't really make special cases for all the other potentially ABI-terrible > ideas people can come up with in a header file IMO, the special thing about this is that it's exposed by the standard library in a way that invites and suggests the _precise usage_ which is ABI-unstable. The purpose of `hardware_destructive_interference_size` is to put `alignas(std::hardware_destructive_interference_size)` on a struct. Yet, putting that into a header is a terrible idea almost all of the time -- it should be affected by -mtune, and may be changed by compiler upgrades. This is quite non-obvious issue for users, since the C++ stdlib generally goes to a huge amount of effort to remain ABI-stable for users. How do they know that _this_ constant is not ABI-stable, unlike the entire rest of the library? The way GCC handles it is to warn for _any_ use of `std::hardware_destructive_interference_size` in a header -- but only that one, not `hardware_constructive_interference_size`. I think the rationale is that the documented/expected usage of `destructive` is to use to add padding and/or alignment, while the documented/expected usage of `constructive` is to static_assert that a struct is smaller than it. It actually doesn't bother to warn on the internal __GCC_* macros at all. That may not be ideal, but it's a relatively simple solution that seems likely to be good enough. I think Clang could quite reasonably do the same thing. https://github.com/llvm/llvm-project/pull/89446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][SPIR-V] Add support for AMDGCN flavoured SPIRV (PR #89796)
@@ -0,0 +1,294 @@ +// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py +// RUN: %clang_cc1 -triple spirv64-amd-amdhsa -x hip \ +// RUN: -aux-triple x86_64-unknown-linux-gnu -fcuda-is-device -emit-llvm %s \ +// RUN: -o - | FileCheck %s + +// RUN: %clang_cc1 -triple spirv64-amd-amdhsa -x hip \ +// RUN: -aux-triple x86_64-pc-windows-msvc -fcuda-is-device -emit-llvm %s \ +// RUN: -o - | FileCheck %s + +#include "Inputs/cuda.h" + arsenm wrote: Should also have a test somewhere that __has_builtin works https://github.com/llvm/llvm-project/pull/89796 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][SPIR-V] Add support for AMDGCN flavoured SPIRV (PR #89796)
https://github.com/jhuber6 commented: How much of this is actually different from the existing target info for AMDGCN? Seems like we're doing a lot of redundant stuff like defining macros or features. https://github.com/llvm/llvm-project/pull/89796 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][SPIR-V] Add support for AMDGCN flavoured SPIRV (PR #89796)
@@ -54,3 +56,289 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
&Opts,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static constexpr Builtin::Info BuiltinInfo[] = {
+#define BUILTIN(ID, TYPE, ATTRS)
\
+ {#ID, TYPE, ATTRS, nullptr, HeaderDesc::NO_HEADER, ALL_LANGUAGES},
+#define TARGET_BUILTIN(ID, TYPE, ATTRS, FEATURE)
\
+ {#ID, TYPE, ATTRS, FEATURE, HeaderDesc::NO_HEADER, ALL_LANGUAGES},
+#include "clang/Basic/BuiltinsAMDGPU.def"
+};
+
+namespace {
+const char *AMDGPUGCCRegNames[] = {
+ "v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", "v8",
+ "v9", "v10", "v11", "v12", "v13", "v14", "v15", "v16", "v17",
+ "v18", "v19", "v20", "v21", "v22", "v23", "v24", "v25", "v26",
+ "v27", "v28", "v29", "v30", "v31", "v32", "v33", "v34", "v35",
+ "v36", "v37", "v38", "v39", "v40", "v41", "v42", "v43", "v44",
+ "v45", "v46", "v47", "v48", "v49", "v50", "v51", "v52", "v53",
+ "v54", "v55", "v56", "v57", "v58", "v59", "v60", "v61", "v62",
+ "v63", "v64", "v65", "v66", "v67", "v68", "v69", "v70", "v71",
+ "v72", "v73", "v74", "v75", "v76", "v77", "v78", "v79", "v80",
+ "v81", "v82", "v83", "v84", "v85", "v86", "v87", "v88", "v89",
+ "v90", "v91", "v92", "v93", "v94", "v95", "v96", "v97", "v98",
+ "v99", "v100", "v101", "v102", "v103", "v104", "v105", "v106", "v107",
+ "v108", "v109", "v110", "v111", "v112", "v113", "v114", "v115", "v116",
+ "v117", "v118", "v119", "v120", "v121", "v122", "v123", "v124", "v125",
+ "v126", "v127", "v128", "v129", "v130", "v131", "v132", "v133", "v134",
+ "v135", "v136", "v137", "v138", "v139", "v140", "v141", "v142", "v143",
+ "v144", "v145", "v146", "v147", "v148", "v149", "v150", "v151", "v152",
+ "v153", "v154", "v155", "v156", "v157", "v158", "v159", "v160", "v161",
+ "v162", "v163", "v164", "v165", "v166", "v167", "v168", "v169", "v170",
+ "v171", "v172", "v173", "v174", "v175", "v176", "v177", "v178", "v179",
+ "v180", "v181", "v182", "v183", "v184", "v185", "v186", "v187", "v188",
+ "v189", "v190", "v191", "v192", "v193", "v194", "v195", "v196", "v197",
+ "v198", "v199", "v200", "v201", "v202", "v203", "v204", "v205", "v206",
+ "v207", "v208", "v209", "v210", "v211", "v212", "v213", "v214", "v215",
+ "v216", "v217", "v218", "v219", "v220", "v221", "v222", "v223", "v224",
+ "v225", "v226", "v227", "v228", "v229", "v230", "v231", "v232", "v233",
+ "v234", "v235", "v236", "v237", "v238", "v239", "v240", "v241", "v242",
+ "v243", "v244", "v245", "v246", "v247", "v248", "v249", "v250", "v251",
+ "v252", "v253", "v254", "v255", "s0", "s1", "s2", "s3", "s4",
+ "s5", "s6", "s7", "s8", "s9", "s10", "s11", "s12", "s13",
+ "s14", "s15", "s16", "s17", "s18", "s19", "s20", "s21", "s22",
+ "s23", "s24", "s25", "s26", "s27", "s28", "s29", "s30", "s31",
+ "s32", "s33", "s34", "s35", "s36", "s37", "s38", "s39", "s40",
+ "s41", "s42", "s43", "s44", "s45", "s46", "s47", "s48", "s49",
+ "s50", "s51", "s52", "s53", "s54", "s55", "s56", "s57", "s58",
+ "s59", "s60", "s61", "s62", "s63", "s64", "s65", "s66", "s67",
+ "s68", "s69", "s70", "s71", "s72", "s73", "s74", "s75", "s76",
+ "s77", "s78", "s79", "s80", "s81", "s82", "s83", "s84", "s85",
+ "s86", "s87", "s88", "s89", "s90", "s91", "s92", "s93", "s94",
+ "s95", "s96", "s97", "s98", "s99", "s100", "s101", "s102", "s103",
+ "s104", "s105", "s106", "s107", "s108", "s109", "s110", "s111", "s112",
+ "s113", "s114", "s115", "s116", "s117", "s118", "s119", "s120", "s121",
+ "s122", "s123", "s124", "s125", "s126", "s127", "exec", "vcc", "scc",
+ "m0", "flat_scratch", "exec_lo", "exec_hi", "vcc_lo", "vcc_hi",
+ "flat_scratch_lo", "flat_scratch_hi",
+ "a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7", "a8",
+ "a9", "a10", "a11", "a12", "a13", "a14", "a15", "a16", "a17",
+ "a18", "a19", "a20", "a21", "a22", "a23", "a24", "a25", "a26",
+ "a27", "a28", "a29", "a30", "a31", "a32", "a33", "a34", "a35",
+ "a36", "a37", "a38", "a39", "a40", "a41", "a42", "a43", "a44",
+ "a45", "a46", "a47", "a48", "a49", "a50", "a51", "a52", "a53",
+ "a54", "a55", "a56", "a57", "a58", "a59", "a60", "a61", "a62",
+ "a63", "a64", "a65", "a66", "a67", "a68", "a69", "a70", "a71",
+ "a72", "a73", "a74", "a75", "a76", "a77", "a78", "a79", "a80",
+ "a81", "a82", "a83", "a84", "a85", "a86", "a87", "a88", "a89",
+ "a90", "a91", "a92", "a93", "a94", "a95", "a96", "a97", "a98",
+ "a99", "a100", "a101", "a102", "a103", "a104", "a105", "a106", "a107",
+ "a108", "a109", "a110", "a111", "a112", "a113", "a114", "a115", "a116",
+ "a117", "a118", "a119", "a120", "a121", "a122", "a123", "a124", "a125",
+ "a126", "a127", "a128", "a129", "a130", "a131", "a132", "a133", "a134",
+ "a135", "a136", "a137", "a138", "a139", "a140", "a141", "a142", "a143",
+ "a144", "a145", "a146", "a147", "a148", "a149", "a150", "a151", "a152",
+ "a153", "a154", "a155", "a156", "a157", "a158", "a159", "a
[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr();
+
+ return false;
+}
+
Decl *Parser::ParseDeclarationAfterDeclaratorAndAttributes(
Declarator &D, const ParsedTemplateInfo &TemplateInfo, ForRangeInit *FRI) {
// RAII type used to track whether we're inside an initializer.
struct InitializerScopeRAII {
Parser &P;
Declarator &D;
Decl *ThisDecl;
+EnterExpressionEvaluationContext EC;
InitializerScopeRAII(Parser &P, Declarator &D, Decl *ThisDecl)
-: P(P), D(D), ThisDecl(ThisDecl) {
+: P(P), D(D), ThisDecl(ThisDecl),
+ EC(P.Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated,
+ ThisDecl, Sema::ExpressionEvaluationContextRecord::EK_Other,
+ isConstexprVariable(ThisDecl)) {
efriedma-quic wrote:
On a side-note, gcc currently accepts the following; if I'm understanding the
rule, it's not supposed to be valid.
```
struct S {
int *value;
constexpr S(int v) : value(new int {v}) {}
constexpr ~S() { delete value; }
};
consteval S fn() { return S(5); }
int g();
void f() {
int a = *fn().value;
}
```
https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
- // FIXME: We should enable RelaxedTemplateTemplateArgs by default as it is a
- // defect report resolution from C++17 and shouldn't be introduced by
- // concepts.
- if (getLangOpts().RelaxedTemplateTemplateArgs) {
mizvekov wrote:
It's a removal of the flag's behavior, with the addition of provisional wording
changes, in order to moot the original reason the flag existed.
I see where the confusion comes from. The original patch did not remove the
flag completely, just changed the default, but still deprecated it. After some
offline discussion with @zygoloid, we decided to remove the flag as well, but I
forgot to update the title.
@zygoloid thoughts on that?
How about for starters we just change the default, but still deprecate the flag
both ways anyway?
If the transition is a concern, I think it would be a problem that we don't
start to warn the users of the flags as soon as possible. Otherwise, I think
this will be specially problematic if there are current users of the negative
spelling `-fno-relaxed-template-template-args`.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AMDGPU] Correctly determine the toolchain linker (PR #89803)
https://github.com/arsenm approved this pull request. https://github.com/llvm/llvm-project/pull/89803 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Implement a subset of builtin_cpu_supports() features (PR #82809)
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix7.2.0.0 -emit-llvm -o - %s |
FileCheck %s
+
+int main() {
+ int ret = 0;
+ ret += __builtin_cpu_supports("vsx");
+ ret += __builtin_cpu_supports("htm");
+ ret += __builtin_cpu_supports("cellbe");
+ ret += __builtin_cpu_supports("power4");
+ return ret;
lei137 wrote:
would be good to add a call that will directly return true, another call to
syscfg and doc which is which within the src here.
https://github.com/llvm/llvm-project/pull/82809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Implement a subset of builtin_cpu_supports() features (PR #82809)
@@ -141,46 +149,98 @@ PPC_LNX_CPU("power10",47)
#define AIX_BUILTIN_PPC_TRUE 1
#define AIX_BUILTIN_PPC_FALSE 0
#define USE_SYS_CONF 2
-
- // Supported COMPARE_OP values.
- #define COMP_EQ 0
-
+ #define SYS_CALL 3
#endif
// The value of SUPPORT_METHOD can be AIX_BUILTIN_PPC_TRUE,
-// AIX_BUILTIN_PPC_FALSE, or USE_SYS_CONF.
-// When the value of SUPPORT_METHOD is USE_SYS_CONF, the return value
-// depends on the result of comparing the data member of
-// _system_configuration specified by INDEX with a certain value.
+// AIX_BUILTIN_PPC_FALSE, USE_SYS_CONF, SYS_CALL.
+// When the value of SUPPORT_METHOD is set to USE_SYS_CONF, the return value
+// depends on comparing VALUE with the specified data member of
+// _system_configuration at INDEX, where the data member is masked by Mask.
+// When the SUPPORT_METHOD value is set to SYS_CALL, the return value depends
+// on comparing a VALUE with the return value of calling `getsystemcfg`
+// with the parameter INDEX, which is then masked by Mask.
+// AIX_BUILTIN_PPC_TRUE and AIX_BUILTIN_PPC_FALSE are for features
+// that are supported or unsupported on all systems respectively.
lei137 wrote:
Maybe this will be more clear:
```suggestion
// The value of SUPPORT_METHOD can be:
//AIX_BUILTIN_PPC_TRUE : feature supported
//AIX_BUILTIN_PPC_FALSE : feature not supported
//USE_SYS_CONF : return value depends on comparing VALUE with the specified
// data member of _system_configuration at INDEX, where the
// data member is masked by Mask.
//SYS_CALL : return value depends on comparing a VALUE with the return value
// of calling `getsystemcfg` with the parameter INDEX, which is
// then masked by Mask.
```
https://github.com/llvm/llvm-project/pull/82809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr();
+
+ return false;
+}
+
Decl *Parser::ParseDeclarationAfterDeclaratorAndAttributes(
Declarator &D, const ParsedTemplateInfo &TemplateInfo, ForRangeInit *FRI) {
// RAII type used to track whether we're inside an initializer.
struct InitializerScopeRAII {
Parser &P;
Declarator &D;
Decl *ThisDecl;
+EnterExpressionEvaluationContext EC;
InitializerScopeRAII(Parser &P, Declarator &D, Decl *ThisDecl)
-: P(P), D(D), ThisDecl(ThisDecl) {
+: P(P), D(D), ThisDecl(ThisDecl),
+ EC(P.Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated,
+ ThisDecl, Sema::ExpressionEvaluationContextRecord::EK_Other,
+ isConstexprVariable(ThisDecl)) {
efriedma-quic wrote:
This doesn't look right. The relevant standard text says:
- "An expression or conversion is in an immediate function context if it is
potentially evaluated and [...] it is a subexpression of a manifestly
constant-evaluated expression or conversion [...]"
- "An expression or conversion is manifestly constant-evaluated if it is [...]
the initializer of a variable that is usable in constant expressions or has
constant initialization"
So we need to handle:
- constexpr variables
- variables of type `const int`
- constant-initialized variables (global/static)
https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Tom Stellard (tstellar)
Changes
Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds now use
two stages, so `ninja -C build stage2-package` can be used with both PGO and
non-PGO builds.
---
Full diff: https://github.com/llvm/llvm-project/pull/89812.diff
1 Files Affected:
- (modified) clang/cmake/caches/Release.cmake (+67-67)
``diff
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index bd1f688d61a7ea..c164d5497275f3 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -1,93 +1,93 @@
# Plain options configure the first build.
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# PGO Builds have 3 stages (stage1, stage2-instrumented, stage2)
+# non-PGO Builds have 2 stages (stage1, stage2)
-# General Options
+
+function (set_final_stage_var name value type)
+ if (LLVM_RELEASE_ENABLE_PGO)
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ else()
+set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+function (set_instrument_and_final_stage_var name value type)
+ # This sets the varaible for the final stage in non-PGO builds and in
+ # the stage2-instrumented stage for PGO builds.
+ set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ if (LLVM_RELEASE_ENABLE_PGO)
+# Set the variable in the final stage for PGO builds.
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+# General Options:
+# If you want to override any of the LLVM_RELEASE_* variables you can set them
+# on the command line via -D, but you need to do this before you pass this
+# cache file to CMake via -C. e.g.
+#
+# cmake -D LLVM_RELEASE_ENABLE_PGO=ON -C Release.cmake
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
set(LLVM_RELEASE_ENABLE_PGO OFF CACHE BOOL "")
-
+set(LLVM_RELEASE_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind"
CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+# Note we don't need to add install here, since it is one of the pre-defined
+# steps.
+set(LLVM_RELEASE_FINAL_STAGE_TARGETS
"clang;package;check-all;check-llvm;check-clang" CACHE STRING "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
-# Stage 1 Bootstrap Setup
+# Stage 1 Options
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
set(CLANG_BOOTSTRAP_TARGETS
generate-profdata
-stage2
+stage2-package
stage2-clang
-stage2-distribution
stage2-install
-stage2-install-distribution
-stage2-install-distribution-toolchain
stage2-check-all
stage2-check-llvm
-stage2-check-clang
-stage2-test-suite CACHE STRING "")
-else()
- set(CLANG_BOOTSTRAP_TARGETS
-clang
-check-all
-check-llvm
-check-clang
-test-suite
-stage3
-stage3-clang
-stage3-check-all
-stage3-check-llvm
-stage3-check-clang
-stage3-install
-stage3-test-suite CACHE STRING "")
-endif()
+stage2-check-clang CACHE STRING "")
-# Stage 1 Options
-set(STAGE1_PROJECTS "clang")
-set(STAGE1_RUNTIMES "")
+ # Configuration for stage2-instrumented
+ set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "")
+ # This enables the build targets for the final stage which is called stage2.
+ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS}
CACHE STRING "")
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED IR CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES "compiler-rt" CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-if (LLVM_RELEASE_ENABLE_PGO)
- list(APPEND STAGE1_PROJECTS "lld")
- list(APPEND STAGE1_RUNTIMES "compiler-rt")
+else()
+ if (LLVM_RELEASE_ENABLE_LTO)
+list(APPEND STAGE1_PROJECTS "lld")
+ endif()
+ # Any targets added here will be given the target name stage2-${target}, so
+ # if you want to run them you can just use:
+ # ninja -C $BUILDDIR stage2-${target}
+ set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING
"")
endif()
+# Stage 1 Common Config
set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "")
set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
-set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
-
-# Stage 2 Bootstrap Setup
-set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "")
-set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
- clang
- check-all
- check-llvm
- check-clang CACHE STRING "")
-
-# Stage 2 Options
-set(STAGE2_PROJECTS "clang")
-set(STAGE2_RUNTIMES "")
-
-if (LLVM_RELEASE_ENABLE_LTO OR LLVM_RELE
[clang] [clang-repl] Lay the foundation of pretty printing for C. (PR #89811)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Vassil Vassilev (vgvassilev)
Changes
Depends on #89804.
---
Full diff: https://github.com/llvm/llvm-project/pull/89811.diff
6 Files Affected:
- (modified) clang/lib/Interpreter/IncrementalParser.cpp (+11-2)
- (modified) clang/lib/Interpreter/Interpreter.cpp (+92-76)
- (modified) clang/lib/Parse/ParseStmt.cpp (+1-4)
- (modified) clang/lib/Sema/SemaDecl.cpp (+2-1)
- (added) clang/test/Interpreter/execute.c (+21)
- (added) clang/test/Interpreter/pretty-print.c (+8)
``diff
diff --git a/clang/lib/Interpreter/IncrementalParser.cpp
b/clang/lib/Interpreter/IncrementalParser.cpp
index ef90fe9e6f5451..f1cb5fc870eb94 100644
--- a/clang/lib/Interpreter/IncrementalParser.cpp
+++ b/clang/lib/Interpreter/IncrementalParser.cpp
@@ -387,8 +387,7 @@ std::unique_ptr
IncrementalParser::GenModule() {
void IncrementalParser::CleanUpPTU(PartialTranslationUnit &PTU) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
- TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
- if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
+ if (StoredDeclsMap *Map = MostRecentTU->getPrimaryContext()->getLookupPtr())
{
for (auto &&[Key, List] : *Map) {
DeclContextLookupResult R = List.getLookupResult();
std::vector NamedDeclsToRemove;
@@ -407,6 +406,16 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
&PTU) {
}
}
}
+
+ // FIXME: We should de-allocate MostRecentTU
+ for (Decl *D : MostRecentTU->decls()) {
+if (!isa(D))
+ continue;
+// Check if we need to clean up the IdResolver chain.
+NamedDecl *ND = cast(D);
+if (ND->getDeclName().getFETokenInfo())
+ getCI()->getSema().IdResolver.RemoveDecl(ND);
+ }
}
llvm::StringRef IncrementalParser::GetMangledName(GlobalDecl GD) const {
diff --git a/clang/lib/Interpreter/Interpreter.cpp
b/clang/lib/Interpreter/Interpreter.cpp
index b20e6efcebfd10..96abf4bc53ef4b 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -42,6 +42,9 @@
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
+
+#include
+
using namespace clang;
// FIXME: Figure out how to unify with namespace init_convenience from
@@ -250,14 +253,9 @@ Interpreter::~Interpreter() {
// can't find the precise resource directory in unittests so we have to hard
// code them.
const char *const Runtimes = R"(
+#define __CLANG_REPL__ 1
#ifdef __cplusplus
void *__clang_Interpreter_SetValueWithAlloc(void*, void*, void*);
-void __clang_Interpreter_SetValueNoAlloc(void*, void*, void*);
-void __clang_Interpreter_SetValueNoAlloc(void*, void*, void*, void*);
-void __clang_Interpreter_SetValueNoAlloc(void*, void*, void*, float);
-void __clang_Interpreter_SetValueNoAlloc(void*, void*, void*, double);
-void __clang_Interpreter_SetValueNoAlloc(void*, void*, void*, long double);
-void __clang_Interpreter_SetValueNoAlloc(void*,void*,void*,unsigned long
long);
struct __clang_Interpreter_NewTag{} __ci_newtag;
void* operator new(__SIZE_TYPE__, void* __p, __clang_Interpreter_NewTag)
noexcept;
template
@@ -269,7 +267,10 @@ const char *const Runtimes = R"(
void __clang_Interpreter_SetValueCopyArr(const T (*Src)[N], void*
Placement, unsigned long Size) {
__clang_Interpreter_SetValueCopyArr(Src[0], Placement, Size);
}
+extern "C"
#endif // __cplusplus
+
+ void __clang_Interpreter_SetValueNoAlloc(void *This, void *OutVal, void
*OpaqueType, ...);
)";
llvm::Expected>
@@ -564,15 +565,17 @@ std::unique_ptr
Interpreter::FindRuntimeInterface() {
if (!LookupInterface(ValuePrintingInfo[NoAlloc],
MagicRuntimeInterface[NoAlloc]))
return nullptr;
- if (!LookupInterface(ValuePrintingInfo[WithAlloc],
- MagicRuntimeInterface[WithAlloc]))
-return nullptr;
- if (!LookupInterface(ValuePrintingInfo[CopyArray],
- MagicRuntimeInterface[CopyArray]))
-return nullptr;
- if (!LookupInterface(ValuePrintingInfo[NewTag],
- MagicRuntimeInterface[NewTag]))
-return nullptr;
+ if (Ctx.getLangOpts().CPlusPlus) {
+if (!LookupInterface(ValuePrintingInfo[WithAlloc],
+ MagicRuntimeInterface[WithAlloc]))
+ return nullptr;
+if (!LookupInterface(ValuePrintingInfo[CopyArray],
+ MagicRuntimeInterface[CopyArray]))
+ return nullptr;
+if (!LookupInterface(ValuePrintingInfo[NewTag],
+ MagicRuntimeInterface[NewTag]))
+ return nullptr;
+ }
return createInProcessRuntimeInterfaceBuilder(*this, Ctx, S);
}
@@ -831,69 +834,82 @@ __clang_Interpreter_SetValueWithAlloc(void *This, void
*OutVal,
return VRef.getPtr();
}
-// Pointers, lvalue struct that can take as a reference.
-REPL_EXTERNAL_VISIBILITY void
-__clang_Interpret
[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/89812
Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds now use
two stages, so `ninja -C build stage2-package` can be used with both PGO and
non-PGO builds.
>From 275979816a1de8b16a6c45b5ee2ef4e73c8828ba Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Tue, 23 Apr 2024 19:29:04 +
Subject: [PATCH] [CMake][Release] Refactor cache file and use two stages for
non-PGO builds
Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds now
use two stages, so `ninja -C build stage2-package` can be used with both
PGO and non-PGO builds.
---
clang/cmake/caches/Release.cmake | 134 +++
1 file changed, 67 insertions(+), 67 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index bd1f688d61a7ea..c164d5497275f3 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -1,93 +1,93 @@
# Plain options configure the first build.
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# PGO Builds have 3 stages (stage1, stage2-instrumented, stage2)
+# non-PGO Builds have 2 stages (stage1, stage2)
-# General Options
+
+function (set_final_stage_var name value type)
+ if (LLVM_RELEASE_ENABLE_PGO)
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ else()
+set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+function (set_instrument_and_final_stage_var name value type)
+ # This sets the varaible for the final stage in non-PGO builds and in
+ # the stage2-instrumented stage for PGO builds.
+ set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ if (LLVM_RELEASE_ENABLE_PGO)
+# Set the variable in the final stage for PGO builds.
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+# General Options:
+# If you want to override any of the LLVM_RELEASE_* variables you can set them
+# on the command line via -D, but you need to do this before you pass this
+# cache file to CMake via -C. e.g.
+#
+# cmake -D LLVM_RELEASE_ENABLE_PGO=ON -C Release.cmake
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
set(LLVM_RELEASE_ENABLE_PGO OFF CACHE BOOL "")
-
+set(LLVM_RELEASE_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind"
CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+# Note we don't need to add install here, since it is one of the pre-defined
+# steps.
+set(LLVM_RELEASE_FINAL_STAGE_TARGETS
"clang;package;check-all;check-llvm;check-clang" CACHE STRING "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
-# Stage 1 Bootstrap Setup
+# Stage 1 Options
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
set(CLANG_BOOTSTRAP_TARGETS
generate-profdata
-stage2
+stage2-package
stage2-clang
-stage2-distribution
stage2-install
-stage2-install-distribution
-stage2-install-distribution-toolchain
stage2-check-all
stage2-check-llvm
-stage2-check-clang
-stage2-test-suite CACHE STRING "")
-else()
- set(CLANG_BOOTSTRAP_TARGETS
-clang
-check-all
-check-llvm
-check-clang
-test-suite
-stage3
-stage3-clang
-stage3-check-all
-stage3-check-llvm
-stage3-check-clang
-stage3-install
-stage3-test-suite CACHE STRING "")
-endif()
+stage2-check-clang CACHE STRING "")
-# Stage 1 Options
-set(STAGE1_PROJECTS "clang")
-set(STAGE1_RUNTIMES "")
+ # Configuration for stage2-instrumented
+ set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "")
+ # This enables the build targets for the final stage which is called stage2.
+ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS}
CACHE STRING "")
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED IR CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES "compiler-rt" CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-if (LLVM_RELEASE_ENABLE_PGO)
- list(APPEND STAGE1_PROJECTS "lld")
- list(APPEND STAGE1_RUNTIMES "compiler-rt")
+else()
+ if (LLVM_RELEASE_ENABLE_LTO)
+list(APPEND STAGE1_PROJECTS "lld")
+ endif()
+ # Any targets added here will be given the target name stage2-${target}, so
+ # if you want to run them you can just use:
+ # ninja -C $BUILDDIR stage2-${target}
+ set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING
"")
endif()
+# Stage 1 Common Config
set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "
[clang] [clang-repl] Lay the foundation of pretty printing for C. (PR #89811)
https://github.com/vgvassilev created
https://github.com/llvm/llvm-project/pull/89811
Depends on #89804.
>From 8317ce33d07d0986e314de0b39aa977f784e0619 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 18:07:06 +
Subject: [PATCH 1/2] [clang-repl] Extend the C support.
The IdResolver chain is the main way for C to implement lookup rules. Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.
This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
---
clang/lib/Interpreter/IncrementalParser.cpp | 13 +++--
clang/lib/Sema/SemaDecl.cpp | 3 ++-
clang/test/Interpreter/execute.c| 21 +
3 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 clang/test/Interpreter/execute.c
diff --git a/clang/lib/Interpreter/IncrementalParser.cpp
b/clang/lib/Interpreter/IncrementalParser.cpp
index ef90fe9e6f5451..f1cb5fc870eb94 100644
--- a/clang/lib/Interpreter/IncrementalParser.cpp
+++ b/clang/lib/Interpreter/IncrementalParser.cpp
@@ -387,8 +387,7 @@ std::unique_ptr
IncrementalParser::GenModule() {
void IncrementalParser::CleanUpPTU(PartialTranslationUnit &PTU) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
- TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
- if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
+ if (StoredDeclsMap *Map = MostRecentTU->getPrimaryContext()->getLookupPtr())
{
for (auto &&[Key, List] : *Map) {
DeclContextLookupResult R = List.getLookupResult();
std::vector NamedDeclsToRemove;
@@ -407,6 +406,16 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
&PTU) {
}
}
}
+
+ // FIXME: We should de-allocate MostRecentTU
+ for (Decl *D : MostRecentTU->decls()) {
+if (!isa(D))
+ continue;
+// Check if we need to clean up the IdResolver chain.
+NamedDecl *ND = cast(D);
+if (ND->getDeclName().getFETokenInfo())
+ getCI()->getSema().IdResolver.RemoveDecl(ND);
+ }
}
llvm::StringRef IncrementalParser::GetMangledName(GlobalDecl GD) const {
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 452e00fa32b102..2a0f73b42d3088 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -2282,7 +2282,8 @@ void Sema::ActOnPopScope(SourceLocation Loc, Scope *S) {
// Remove this name from our lexical scope, and warn on it if we haven't
// already.
-IdResolver.RemoveDecl(D);
+if (!PP.isIncrementalProcessingEnabled())
+ IdResolver.RemoveDecl(D);
auto ShadowI = ShadowingDecls.find(D);
if (ShadowI != ShadowingDecls.end()) {
if (const auto *FD = dyn_cast(ShadowI->second)) {
diff --git a/clang/test/Interpreter/execute.c b/clang/test/Interpreter/execute.c
new file mode 100644
index 00..44a3a32c930112
--- /dev/null
+++ b/clang/test/Interpreter/execute.c
@@ -0,0 +1,21 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -Xclang -Xcc -verify | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -O2 -Xcc -Xclang -Xcc -verify|
FileCheck %s
+int printf(const char *, ...);
+int i = 42; err // expected-error{{use of undeclared identifier}}
+int i = 42;
+struct S { float f; struct S *m;} s = {1.0, 0};
+// FIXME: Making foo inline fails to emit the function.
+int foo() { return 42; }
+void run() {\
+ printf("i = %d\n", i);\
+ printf("S[f=%f, m=0x%llx]\n", s.f, (unsigned long long)s.m); \
+ int r3 = foo(); \
+}
+run();
+// CHECK: i = 42
+// CHECK-NEXT: S[f=1.00, m=0x0]
+
+%quit
>From fa864fb5926a87596b8a6ccd998d5c2f123be1f7 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH 2/2] [clang-repl] Lay the foundation of pretty printing for C.
---
clang/lib/Interpreter/Interpreter.cpp | 168 ++
clang/lib/Parse/ParseStmt.cpp | 5 +-
clang/test/Interpreter/pretty-print.c | 8 ++
3 files changed, 101 insertions(+), 80 deletions(-)
create mode 100644 clang/test/Interpreter/pretty-print.c
diff --git a/clang/lib/Interpreter/Interpreter.cpp
b/clang/lib/Interpreter/Interpreter.cpp
index b20e6efcebfd10..96abf4bc53ef4b 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -42,6 +42,9 @@
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
+
+#include
+
using namespace clang;
// FIXME: Figure out how to unify with namespace init_convenience from
@@ -250,14 +253,9 @@ Interpreter::~Interpreter() {
// can't find th
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
@@ -147,19 +147,25 @@ void
WebAssemblyTargetInfo::setFeatureEnabled(llvm::StringMap &Features,
bool WebAssemblyTargetInfo::initFeatureMap(
llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector &FeaturesVec) const {
- if (CPU == "bleeding-edge") {
-Features["nontrapping-fptoint"] = true;
+ auto addGenericFeatures = [&]() {
Features["sign-ext"] = true;
+Features["mutable-globals"] = true;
+Features["reference-types"] = true;
+Features["multivalue"] = true;
+ };
+ auto addBleedingEdgeFeatures = [&]() {
+addGenericFeatures();
+Features["nontrapping-fptoint"] = true;
sbc100 wrote:
I'm a bit sad not to see this added, since this is the one that can actually
improve codegen. If we know we want to enable to this, is there any downside
to doing two different rounds (i.e. are there advantages to waiting on this
until we have the lowering pass in place?)
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [mlir] Fix mismatches between function parameter definitions and declarations (PR #89512)
https://github.com/Troy-Butler updated
https://github.com/llvm/llvm-project/pull/89512
>From f03466fa44a3c7210e7590e6305bc0c9f9aeb446 Mon Sep 17 00:00:00 2001
From: Troy-Butler
Date: Sat, 20 Apr 2024 15:13:09 -0400
Subject: [PATCH 1/6] Fix Definition-Declaration Mismatches
Signed-off-by: Troy-Butler
---
.../include/clang/StaticAnalyzer/Core/PathSensitive/Store.h | 4 ++--
llvm/lib/Transforms/InstCombine/InstCombineInternal.h | 2 +-
llvm/lib/Transforms/Vectorize/VPlan.h | 4 ++--
.../SparseTensor/Transforms/Utils/SparseTensorIterator.h| 6 +++---
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
index fac0c04ae2caab..e60a49f68b7a0d 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
@@ -227,12 +227,12 @@ class StoreManager {
/// information will not be used.
virtual StoreRef invalidateRegions(Store store,
ArrayRef Values,
- const Expr *E, unsigned Count,
+ const Expr *Ex, unsigned Count,
const LocationContext *LCtx,
const CallEvent *Call,
InvalidatedSymbols &IS,
RegionAndSymbolInvalidationTraits &ITraits,
- InvalidatedRegions *InvalidatedTopLevel,
+ InvalidatedRegions *TopLevelRegions,
InvalidatedRegions *Invalidated) = 0;
/// enterStackFrame - Let the StoreManager to do something when execution
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
b/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
index 4479afbd09afde..4ec5f417998273 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
+++ b/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
@@ -433,7 +433,7 @@ class LLVM_LIBRARY_VISIBILITY InstCombinerImpl final
Value *foldAndOrOfICmpsOfAndWithPow2(ICmpInst *LHS, ICmpInst *RHS,
Instruction *CxtI, bool IsAnd,
bool IsLogical = false);
- Value *matchSelectFromAndOr(Value *A, Value *B, Value *C, Value *D,
+ Value *matchSelectFromAndOr(Value *A, Value *C, Value *B, Value *D,
bool InvertFalseVal = false);
Value *getSelectCondition(Value *A, Value *B, bool ABIsTheSame);
diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h
b/llvm/lib/Transforms/Vectorize/VPlan.h
index c74329a0bcc4ac..21b088cd238660 100644
--- a/llvm/lib/Transforms/Vectorize/VPlan.h
+++ b/llvm/lib/Transforms/Vectorize/VPlan.h
@@ -3278,8 +3278,8 @@ class VPlan {
private:
/// Add to the given dominator tree the header block and every new basic
block
/// that was created between it and the latch block, inclusive.
- static void updateDominatorTree(DominatorTree *DT, BasicBlock *LoopLatchBB,
- BasicBlock *LoopPreHeaderBB,
+ static void updateDominatorTree(DominatorTree *DT, BasicBlock *LoopHeaderBB,
+ BasicBlock *LoopLatchBB,
BasicBlock *LoopExitBB);
};
diff --git
a/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
b/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
index 9d69a233555986..38f8c8423fd16f 100644
--- a/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
+++ b/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
@@ -284,9 +284,9 @@ class SparseIterator {
};
/// Helper function to create a TensorLevel object from given `tensor`.
-std::unique_ptr makeSparseTensorLevel(OpBuilder &builder,
- Location loc, Value t,
- unsigned tid, Level
l);
+std::unique_ptr makeSparseTensorLevel(OpBuilder &b,
+ Location l, Value t,
+ unsigned tid, Level
lvl);
/// Helper function to create a simple SparseIterator object that iterate over
/// the SparseTensorLevel.
>From 4fe63ddecc056bc521d439952fb2b7fc5d83d9b6 Mon Sep 17 00:00:00 2001
From: Troy-Butler
Date: Sat, 20 Apr 2024 15:33:43 -0400
Subject: [PATCH 2/6] Fix Code Formatting Issues
Signed-off-by: Troy-Butler
---
.../StaticAnalyzer/Core/PathSensitive/Store.h | 14 +-
.../Transforms/Utils/SparseTensorIterator.h| 3 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
b/clang/include/clang/StaticAnalyzer/Core/PathSensiti
[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)
mstorsjo wrote: > > The recent changes, #81037 and #87866, were (as far as I know) only > > intended to change what is printed as error messages, when neither is > > found, to help users correct their setup for the new style layout. But > > those changes also seem to have unexpected effects in changing e.g. what > > gets emitted as embedded directive, when the compiler doesn't see either of > > them at compile time (with e.g. distributed build systems), while they > > might be available at link time. > > This matches my understanding. I am not aware of the embedded directive? Do > you embed a path to a compiler-rt library to the generated object files? Clang does this, in a number of cases. In the MSVC ecosystem, one usually invokes `link` or `lld-link` directly, instead of using `clang` to drive the link - therefore, in order to pass implicit libraries to link, like asan/profile, directives are embedded into the generated object files, that tells the linker to link in those libraries. > I think while technically a new clang can use an old compiler-rt file > hierarchy, technically it is unsupported: kinda like that a very old libc++ > may not be built with a new Clang. I don't think anybody is arguing that a new clang should use an old compiler-rt install, but it should be able to use a new install with the layout according to `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` disabled. > If we avoid hard-coded library names in compiler-generated relocatable files > (just called "object files" on Windows?). there should be no distributed > build system concern. We can't avoid this - we already have this situation. See https://github.com/llvm/llvm-project/pull/87866#issuecomment-2072626122 - #87866 changed the output of the embedded directives when building with a distributed build system, where the compiler doesn't have access to inspect the lib directory that is going to be used to link things in the end. https://github.com/llvm/llvm-project/pull/89775 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
https://github.com/tahonermann approved this pull request. Looks good to me, thanks @smanna12! https://github.com/llvm/llvm-project/pull/89801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)
@@ -237,6 +238,8 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module
*RootModule) {
CollectIncludingMapsFromAncestors(CurrentModule);
for (const Module *ImportedModule : CurrentModule->Imports)
CollectIncludingMapsFromAncestors(ImportedModule);
+for (const Module *UsedModule : CurrentModule->DirectUses)
sam-mccall wrote:
I don't really understand what this change does, and all the tests pass without
it. Is it related to the rest of this patch?
(Looking at the other collections that happen here, it does seem to "fit". But
I don't have a really clear idea about this piece).
https://github.com/llvm/llvm-project/pull/89441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)
@@ -187,7 +187,8 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module
*RootModule) {
continue;
const HeaderFileInfo *HFI = HS.getExistingLocalFileInfo(*File);
-if (!HFI || (HFI->isModuleHeader && !HFI->isCompilingModuleHeader))
+if (!HFI || (HFI->isModuleHeader && !HFI->isCompilingModuleHeader) ||
+(HFI->isTextualModuleHeader && !PP.alreadyIncluded(*File)))
sam-mccall wrote:
That makes sense, I don't have any intuition for whether it's necessary or not.
Shortcutting this analysis seems like a useful change of possible, but I think
restoring the previous behavior is a helpful starting point.
https://github.com/llvm/llvm-project/pull/89441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)
@@ -0,0 +1,20 @@ +// This test checks that a module map with a textual header can be marked as sam-mccall wrote: This is a useful test, I think there are a couple of other affecting-ness properties that are important to test: - that a textual header that *is* included means its module is affecting (i.e. the include matters) - that this textual-affecting-ness doesn't leak outside the module (a module depending on B isn't affected by A.modulemap) I tried to cover these in https://github.com/llvm/llvm-project/pull/89729/files#diff-2eed05f9a85bc5a79b9651ee0f23e5f1494e94a2f32e093847aa6dae5ce5d839 - it might be nice to add these as a second test here (I can do it as a followup if you prefer) https://github.com/llvm/llvm-project/pull/89441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)
https://github.com/sam-mccall approved this pull request. Thanks! This looks good, much neater than my approach. I'm interested in whether the DirectUses change is related to this, and would like to slap on a couple of tests. But either way, this looks good and it would be great to have it landed! https://github.com/llvm/llvm-project/pull/89441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)
https://github.com/sam-mccall edited https://github.com/llvm/llvm-project/pull/89441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [mlir] Fix mismatches between function parameter definitions and declarations (PR #89512)
https://github.com/Troy-Butler updated
https://github.com/llvm/llvm-project/pull/89512
>From f03466fa44a3c7210e7590e6305bc0c9f9aeb446 Mon Sep 17 00:00:00 2001
From: Troy-Butler
Date: Sat, 20 Apr 2024 15:13:09 -0400
Subject: [PATCH 1/5] Fix Definition-Declaration Mismatches
Signed-off-by: Troy-Butler
---
.../include/clang/StaticAnalyzer/Core/PathSensitive/Store.h | 4 ++--
llvm/lib/Transforms/InstCombine/InstCombineInternal.h | 2 +-
llvm/lib/Transforms/Vectorize/VPlan.h | 4 ++--
.../SparseTensor/Transforms/Utils/SparseTensorIterator.h| 6 +++---
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
index fac0c04ae2caab..e60a49f68b7a0d 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
@@ -227,12 +227,12 @@ class StoreManager {
/// information will not be used.
virtual StoreRef invalidateRegions(Store store,
ArrayRef Values,
- const Expr *E, unsigned Count,
+ const Expr *Ex, unsigned Count,
const LocationContext *LCtx,
const CallEvent *Call,
InvalidatedSymbols &IS,
RegionAndSymbolInvalidationTraits &ITraits,
- InvalidatedRegions *InvalidatedTopLevel,
+ InvalidatedRegions *TopLevelRegions,
InvalidatedRegions *Invalidated) = 0;
/// enterStackFrame - Let the StoreManager to do something when execution
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
b/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
index 4479afbd09afde..4ec5f417998273 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
+++ b/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
@@ -433,7 +433,7 @@ class LLVM_LIBRARY_VISIBILITY InstCombinerImpl final
Value *foldAndOrOfICmpsOfAndWithPow2(ICmpInst *LHS, ICmpInst *RHS,
Instruction *CxtI, bool IsAnd,
bool IsLogical = false);
- Value *matchSelectFromAndOr(Value *A, Value *B, Value *C, Value *D,
+ Value *matchSelectFromAndOr(Value *A, Value *C, Value *B, Value *D,
bool InvertFalseVal = false);
Value *getSelectCondition(Value *A, Value *B, bool ABIsTheSame);
diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h
b/llvm/lib/Transforms/Vectorize/VPlan.h
index c74329a0bcc4ac..21b088cd238660 100644
--- a/llvm/lib/Transforms/Vectorize/VPlan.h
+++ b/llvm/lib/Transforms/Vectorize/VPlan.h
@@ -3278,8 +3278,8 @@ class VPlan {
private:
/// Add to the given dominator tree the header block and every new basic
block
/// that was created between it and the latch block, inclusive.
- static void updateDominatorTree(DominatorTree *DT, BasicBlock *LoopLatchBB,
- BasicBlock *LoopPreHeaderBB,
+ static void updateDominatorTree(DominatorTree *DT, BasicBlock *LoopHeaderBB,
+ BasicBlock *LoopLatchBB,
BasicBlock *LoopExitBB);
};
diff --git
a/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
b/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
index 9d69a233555986..38f8c8423fd16f 100644
--- a/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
+++ b/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
@@ -284,9 +284,9 @@ class SparseIterator {
};
/// Helper function to create a TensorLevel object from given `tensor`.
-std::unique_ptr makeSparseTensorLevel(OpBuilder &builder,
- Location loc, Value t,
- unsigned tid, Level
l);
+std::unique_ptr makeSparseTensorLevel(OpBuilder &b,
+ Location l, Value t,
+ unsigned tid, Level
lvl);
/// Helper function to create a simple SparseIterator object that iterate over
/// the SparseTensorLevel.
>From 4fe63ddecc056bc521d439952fb2b7fc5d83d9b6 Mon Sep 17 00:00:00 2001
From: Troy-Butler
Date: Sat, 20 Apr 2024 15:33:43 -0400
Subject: [PATCH 2/5] Fix Code Formatting Issues
Signed-off-by: Troy-Butler
---
.../StaticAnalyzer/Core/PathSensitive/Store.h | 14 +-
.../Transforms/Utils/SparseTensorIterator.h| 3 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
b/clang/include/clang/StaticAnalyzer/Core/PathSensiti
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
- // FIXME: We should enable RelaxedTemplateTemplateArgs by default as it is a
- // defect report resolution from C++17 and shouldn't be introduced by
- // concepts.
- if (getLangOpts().RelaxedTemplateTemplateArgs) {
erichkeane wrote:
Ah, so this isn't just a 'deprecate', this is a complete removal of the flag's
behavior. I don't think that is something I'm comfortable with. We should do
a release cycle with this as 'default true', a cycle with 'deprecated', and
then a removal if we care to.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
- // FIXME: We should enable RelaxedTemplateTemplateArgs by default as it is a
- // defect report resolution from C++17 and shouldn't be introduced by
- // concepts.
- if (getLangOpts().RelaxedTemplateTemplateArgs) {
mizvekov wrote:
The code following this removal contains the exact same code, but outside the
if-block and de-indented.
It's a shame the GitHub diff viewer is not very good at showing this, phab was
much better.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/8] Start migrating away from the embedded assumption that
the default AS **must** be 0.
---
clang/lib/CodeGen/CGExprCXX.cpp | 2 +-
clang/lib/CodeGen/CodeGenModule.cpp | 10 ++
clang/lib/CodeGen/CodeGenTypeCache.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/clang/lib/CodeGen/CGExprCXX.cpp b/clang/lib/CodeGen/CGExprCXX.cpp
index 2adbef6d55122c..b9c920a81d79c9 100644
--- a/clang/lib/CodeGen/CGExprCXX.cpp
+++ b/clang/lib/CodeGen/CGExprCXX.cpp
@@ -,7 +,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
&CGF, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy = Int8PtrTy;
LangAS GlobAS = CGM.GetGlobalVarAddressSpace(nullptr);
auto MaybeASCast = [=](auto &&TypeInfo) {
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp
b/clang/lib/CodeGen/CodeGenModule.cpp
index 8ceecff28cbc63..7dd14d32aa2d03 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -364,7 +364,8 @@ CodeGenModule::CodeGenModule(ASTContext &C,
IntTy = llvm::IntegerType::get(LLVMContext, C.getTargetInfo().getIntWidth());
IntPtrTy = llvm::IntegerType::get(LLVMContext,
C.getTargetInfo().getMaxPointerWidth());
- Int8PtrTy = llvm::PointerType::get(LLVMContext, 0);
+ Int8PtrTy = llvm::PointerType::get(
+ LLVMContext, C.getTargetInfo().getTargetAddressSpace(LangAS::Default));
const llvm::DataLayout &DL = M.getDataLayout();
AllocaInt8PtrTy =
llvm::PointerType::get(LLVMContext, DL.getAllocaAddrSpace());
@@ -4512,9 +4513,10 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
IsIncompleteFunction = true;
}
- llvm::Function *F =
- llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
- Entry ? StringRef() : MangledName, &getModule());
+ llvm::Function *F = llvm::Function::Create(
+ FTy, llvm::Function::ExternalLinkage,
+ getDataLayout().getProgramAddressSpace(),
+ Entry ? StringRef() : MangledName, &getModule());
// Store the declaration associated with this function so it is potentially
// updated by further declarations or definitions and emitted at the end.
diff --git a/clang/lib/CodeGen/CodeGenTypeCache.h
b/clang/lib/CodeGen/CodeGenTypeCache.h
index 083d69214fb3c2..e273ebe3b060f2 100644
--- a/clang/lib/CodeGen/CodeGenTypeCache.h
+++ b/clang/lib/CodeGen/CodeGenTypeCache.h
@@ -51,7 +51,7 @@ struct CodeGenTypeCache {
llvm::IntegerType *PtrDiffTy;
};
- /// void*, void** in address space 0
+ /// void*, void** in the target's default address space (often 0)
union {
llvm::PointerType *UnqualPtrTy;
llvm::PointerType *VoidPtrTy;
>From 74ae6f52a5f84f8fc92135df3ff93a4a89b914ed Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 25 Mar 2024 10:55:22 +0200
Subject: [PATCH 2/8] Make querying the Global AS more robust, add 1 new test
(WiP).
---
clang/lib/CodeGen/CodeGenModule.cpp | 10 ---
clang/lib/CodeGen/ItaniumCXXABI.cpp | 4 ++-
...x11-with-nonzero-default-address-space.cpp | 29 +++
3 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644
clang/test/CodeGenCXX/typeid-cxx11-with-nonzero-default-address-space.cpp
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp
b/clang/lib/CodeGen/CodeGenModule.cpp
index 63d54f9b1c0b60..39ccd40bf1adbb 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -371,8 +371,8 @@ CodeGenModule::CodeGenModule(ASTContext &C,
const llvm::DataLayout &DL = M.getDataLayout();
AllocaInt8PtrTy =
llvm::PointerType::get(LLVMContext, DL.getAllocaAddrSpace());
- GlobalsInt8PtrTy =
- llvm::PointerType::get(LLVMContext, DL.getDefaultGlobalsAddressSpace());
+ GlobalsInt8PtrTy = llvm::PointerType::get(
+ LLVMContext, C.getTargetAddressSpace(GetGlobalVarAddressSpace(nullptr)));
ConstGlobalsPtrTy = llvm::PointerType::get(
LLVMContext, C.getTargetAddressSpace(GetGlobalConstantAddressSpace()));
ASTAllocaAddressSpace = getTargetCodeGenInfo().getASTAllocaAddressSpace();
@@ -5018,7 +5018,9 @@ llvm::GlobalVariable
*CodeGenModule::CreateOrReplaceCXXRuntimeVariable(
// Create a new variable.
GV = new llvm::GlobalVariable(getModule(), Ty, /*isConstant=*/true,
-Linkage, nullptr, Name);
+Linkage, nullptr, Name, nullptr,
+llvm::GlobalValue::NotThreadLocal,
+GlobalsInt8PtrTy->getAddressSpace());
if (OldGV) {
// Replace occurrences of the old variable if needed.
@@ -5133,7 +5135,7 @@ La
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
- // FIXME: We should enable RelaxedTemplateTemplateArgs by default as it is a
- // defect report resolution from C++17 and shouldn't be introduced by
- // concepts.
- if (getLangOpts().RelaxedTemplateTemplateArgs) {
mizvekov wrote:
Only the flag is deprecated, we want the new 'on' behavior to stay.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [mlir] Fix mismatches between function parameter definitions and declarations (PR #89512)
https://github.com/Troy-Butler updated
https://github.com/llvm/llvm-project/pull/89512
>From f03466fa44a3c7210e7590e6305bc0c9f9aeb446 Mon Sep 17 00:00:00 2001
From: Troy-Butler
Date: Sat, 20 Apr 2024 15:13:09 -0400
Subject: [PATCH 1/4] Fix Definition-Declaration Mismatches
Signed-off-by: Troy-Butler
---
.../include/clang/StaticAnalyzer/Core/PathSensitive/Store.h | 4 ++--
llvm/lib/Transforms/InstCombine/InstCombineInternal.h | 2 +-
llvm/lib/Transforms/Vectorize/VPlan.h | 4 ++--
.../SparseTensor/Transforms/Utils/SparseTensorIterator.h| 6 +++---
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
index fac0c04ae2caab..e60a49f68b7a0d 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
@@ -227,12 +227,12 @@ class StoreManager {
/// information will not be used.
virtual StoreRef invalidateRegions(Store store,
ArrayRef Values,
- const Expr *E, unsigned Count,
+ const Expr *Ex, unsigned Count,
const LocationContext *LCtx,
const CallEvent *Call,
InvalidatedSymbols &IS,
RegionAndSymbolInvalidationTraits &ITraits,
- InvalidatedRegions *InvalidatedTopLevel,
+ InvalidatedRegions *TopLevelRegions,
InvalidatedRegions *Invalidated) = 0;
/// enterStackFrame - Let the StoreManager to do something when execution
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
b/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
index 4479afbd09afde..4ec5f417998273 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
+++ b/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
@@ -433,7 +433,7 @@ class LLVM_LIBRARY_VISIBILITY InstCombinerImpl final
Value *foldAndOrOfICmpsOfAndWithPow2(ICmpInst *LHS, ICmpInst *RHS,
Instruction *CxtI, bool IsAnd,
bool IsLogical = false);
- Value *matchSelectFromAndOr(Value *A, Value *B, Value *C, Value *D,
+ Value *matchSelectFromAndOr(Value *A, Value *C, Value *B, Value *D,
bool InvertFalseVal = false);
Value *getSelectCondition(Value *A, Value *B, bool ABIsTheSame);
diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h
b/llvm/lib/Transforms/Vectorize/VPlan.h
index c74329a0bcc4ac..21b088cd238660 100644
--- a/llvm/lib/Transforms/Vectorize/VPlan.h
+++ b/llvm/lib/Transforms/Vectorize/VPlan.h
@@ -3278,8 +3278,8 @@ class VPlan {
private:
/// Add to the given dominator tree the header block and every new basic
block
/// that was created between it and the latch block, inclusive.
- static void updateDominatorTree(DominatorTree *DT, BasicBlock *LoopLatchBB,
- BasicBlock *LoopPreHeaderBB,
+ static void updateDominatorTree(DominatorTree *DT, BasicBlock *LoopHeaderBB,
+ BasicBlock *LoopLatchBB,
BasicBlock *LoopExitBB);
};
diff --git
a/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
b/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
index 9d69a233555986..38f8c8423fd16f 100644
--- a/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
+++ b/mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorIterator.h
@@ -284,9 +284,9 @@ class SparseIterator {
};
/// Helper function to create a TensorLevel object from given `tensor`.
-std::unique_ptr makeSparseTensorLevel(OpBuilder &builder,
- Location loc, Value t,
- unsigned tid, Level
l);
+std::unique_ptr makeSparseTensorLevel(OpBuilder &b,
+ Location l, Value t,
+ unsigned tid, Level
lvl);
/// Helper function to create a simple SparseIterator object that iterate over
/// the SparseTensorLevel.
>From 4fe63ddecc056bc521d439952fb2b7fc5d83d9b6 Mon Sep 17 00:00:00 2001
From: Troy-Butler
Date: Sat, 20 Apr 2024 15:33:43 -0400
Subject: [PATCH 2/4] Fix Code Formatting Issues
Signed-off-by: Troy-Butler
---
.../StaticAnalyzer/Core/PathSensitive/Store.h | 14 +-
.../Transforms/Utils/SparseTensorIterator.h| 3 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
b/clang/include/clang/StaticAnalyzer/Core/PathSensiti
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
https://github.com/erichkeane commented: Also needs a release note, entry into breaking changes, and a post on mailing list or whatever for the 'breaking change' subscribers to pay attention to. https://github.com/llvm/llvm-project/pull/89807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][HLSL] Add environment parameter to availability attribute (PR #89809)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 78eb2c2cba5ad0f9a36ec1959371527313a76bbe
22b67d30ca087d6a912183039c87fd1790eedfe4 -- clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/ParsedAttr.h clang/include/clang/Sema/Sema.h
clang/lib/AST/DeclBase.cpp clang/lib/Headers/hlsl/hlsl_intrinsics.h
clang/lib/Index/CommentToXML.cpp clang/lib/Parse/ParseDecl.cpp
clang/lib/Sema/SemaAPINotes.cpp clang/lib/Sema/SemaAvailability.cpp
clang/lib/Sema/SemaDecl.cpp clang/lib/Sema/SemaDeclAttr.cpp
``
View the diff from clang-format here.
``diff
diff --git a/clang/include/clang/Sema/ParsedAttr.h
b/clang/include/clang/Sema/ParsedAttr.h
index 7ad39d1a49..a2b35e7179 100644
--- a/clang/include/clang/Sema/ParsedAttr.h
+++ b/clang/include/clang/Sema/ParsedAttr.h
@@ -73,10 +73,10 @@ struct AvailabilityData {
AvailabilityData(const AvailabilityChange &Introduced,
const AvailabilityChange &Deprecated,
- const AvailabilityChange &Obsoleted,
- SourceLocation Strict, const Expr *ReplaceExpr,
- const IdentifierLoc *EnvironmentLoc)
-: StrictLoc(Strict), Replacement(ReplaceExpr),
EnvironmentLoc(EnvironmentLoc) {
+ const AvailabilityChange &Obsoleted, SourceLocation Strict,
+ const Expr *ReplaceExpr, const IdentifierLoc
*EnvironmentLoc)
+ : StrictLoc(Strict), Replacement(ReplaceExpr),
+EnvironmentLoc(EnvironmentLoc) {
Changes[IntroducedSlot] = Introduced;
Changes[DeprecatedSlot] = Deprecated;
Changes[ObsoletedSlot] = Obsoleted;
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index d2686e9f8b..b7baa68919 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3618,15 +3618,13 @@ public:
bool CheckAttrTarget(const ParsedAttr &CurrAttr);
bool CheckAttrNoArgs(const ParsedAttr &CurrAttr);
- AvailabilityAttr *
- mergeAvailabilityAttr(NamedDecl *D, const AttributeCommonInfo &CI,
-IdentifierInfo *Platform, bool Implicit,
-VersionTuple Introduced, VersionTuple Deprecated,
-VersionTuple Obsoleted, bool IsUnavailable,
-StringRef Message, bool IsStrict, StringRef
Replacement,
-AvailabilityMergeKind AMK, int Priority,
-IdentifierInfo *IIEnvironment);
-
+ AvailabilityAttr *mergeAvailabilityAttr(
+ NamedDecl *D, const AttributeCommonInfo &CI, IdentifierInfo *Platform,
+ bool Implicit, VersionTuple Introduced, VersionTuple Deprecated,
+ VersionTuple Obsoleted, bool IsUnavailable, StringRef Message,
+ bool IsStrict, StringRef Replacement, AvailabilityMergeKind AMK,
+ int Priority, IdentifierInfo *IIEnvironment);
+
TypeVisibilityAttr *
mergeTypeVisibilityAttr(Decl *D, const AttributeCommonInfo &CI,
TypeVisibilityAttr::VisibilityType Vis);
diff --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index 87177d00c8..a720f996f1 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -667,7 +667,8 @@ static AvailabilityResult CheckAvailability(ASTContext
&Context,
if (!A->getIntroduced().empty() &&
EnclosingVersion < A->getIntroduced()) {
IdentifierInfo *IIEnv = A->getEnvironment();
-StringRef TargetEnv =
Context.getTargetInfo().getTriple().getEnvironmentName();
+StringRef TargetEnv =
+Context.getTargetInfo().getTriple().getEnvironmentName();
StringRef EnvName = AvailabilityAttr::getPrettyEnviromentName(TargetEnv);
// Matching environment or no environment on attribute
if (!IIEnv || (!TargetEnv.empty() && IIEnv->getName() == TargetEnv)) {
@@ -675,8 +676,8 @@ static AvailabilityResult CheckAvailability(ASTContext
&Context,
Message->clear();
llvm::raw_string_ostream Out(*Message);
VersionTuple VTI(A->getIntroduced());
-Out << "introduced in " << PrettyPlatformName << " "
-<< VTI << EnvName << HintMessage;
+Out << "introduced in " << PrettyPlatformName << " " << VTI << EnvName
+<< HintMessage;
}
}
// Non-matching environment or no environment on target
@@ -684,8 +685,8 @@ static AvailabilityResult CheckAvailability(ASTContext
&Context,
if (Message) {
Message->clear();
llvm::raw_string_ostream Out(*Message);
-Out << "not available on " << PrettyPlatformName << " "
-<< EnvName << HintMessage;
+Out << "not available on " << PrettyPlatformName << " " << EnvName
+<< HintMessage;
}
}
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index ca0582ef39..6880e26600 10
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
- // FIXME: We should enable RelaxedTemplateTemplateArgs by default as it is a
- // defect report resolution from C++17 and shouldn't be introduced by
- // concepts.
- if (getLangOpts().RelaxedTemplateTemplateArgs) {
erichkeane wrote:
This is just being deprecated, right? Don't we still need this?
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
@@ -6561,7 +6561,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
if (const Arg *A =
Args.getLastArg(options::OPT_fvisibility_global_new_delete_hidden)) {
D.Diag(diag::warn_drv_deprecated_arg)
-<< A->getAsString(Args)
+<< A->getAsString(Args) << true
erichkeane wrote:
Add a comment on the 'true' to show what it means. Elsewher etoo.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
https://github.com/erichkeane edited https://github.com/llvm/llvm-project/pull/89807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
https://github.com/erichkeane commented: We probably need to attach this to ClangABI as well, this is an ABI breaking change. https://github.com/llvm/llvm-project/pull/89807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][HLSL] Add environment parameter to availability attribute (PR #89809)
https://github.com/hekota created
https://github.com/llvm/llvm-project/pull/89809
Fixes #89802
>From 22b67d30ca087d6a912183039c87fd1790eedfe4 Mon Sep 17 00:00:00 2001
From: Helena Kotas
Date: Tue, 23 Apr 2024 00:49:28 -0700
Subject: [PATCH] Add environment parameter to clang availability attribute
---
clang/include/clang/Basic/Attr.td | 33 +-
clang/include/clang/Basic/AttrDocs.td | 2 +
.../clang/Basic/DiagnosticParseKinds.td | 2 +
.../clang/Basic/DiagnosticSemaKinds.td| 5 +-
clang/include/clang/Parse/Parser.h| 3 +
clang/include/clang/Sema/ParsedAttr.h | 40 ---
clang/include/clang/Sema/Sema.h | 5 +-
clang/lib/AST/DeclBase.cpp| 27 -
clang/lib/Headers/hlsl/hlsl_intrinsics.h | 13 ++-
clang/lib/Index/CommentToXML.cpp | 3 +
clang/lib/Parse/ParseDecl.cpp | 20 +++-
clang/lib/Sema/SemaAPINotes.cpp | 3 +-
clang/lib/Sema/SemaAvailability.cpp | 109 +-
clang/lib/Sema/SemaDecl.cpp | 2 +-
clang/lib/Sema/SemaDeclAttr.cpp | 34 --
15 files changed, 232 insertions(+), 69 deletions(-)
diff --git a/clang/include/clang/Basic/Attr.td
b/clang/include/clang/Basic/Attr.td
index dc87a8c6f022dc..1b07f4eb408093 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -956,7 +956,7 @@ def Availability : InheritableAttr {
VersionArgument<"deprecated">, VersionArgument<"obsoleted">,
BoolArgument<"unavailable">, StringArgument<"message">,
BoolArgument<"strict">, StringArgument<"replacement">,
- IntArgument<"priority">];
+ IntArgument<"priority">, IdentifierArgument<"environment">];
let AdditionalMembers =
[{static llvm::StringRef getPrettyPlatformName(llvm::StringRef Platform) {
return llvm::StringSwitch(Platform)
@@ -976,7 +976,7 @@ def Availability : InheritableAttr {
.Case("xros", "visionOS")
.Case("xros_app_extension", "visionOS (App Extension)")
.Case("swift", "Swift")
- .Case("shadermodel", "HLSL ShaderModel")
+ .Case("shadermodel", "HLSL Shader Model")
.Case("ohos", "OpenHarmony OS")
.Default(llvm::StringRef());
}
@@ -1016,7 +1016,34 @@ static llvm::StringRef
canonicalizePlatformName(llvm::StringRef Platform) {
.Case("visionos_app_extension", "xros_app_extension")
.Case("ShaderModel", "shadermodel")
.Default(Platform);
-} }];
+}
+static llvm::StringRef getPrettyEnviromentName(llvm::StringRef Environment) {
+return llvm::StringSwitch(Environment)
+ .Case("pixel", "pixel shader")
+ .Case("vertex", "vertex shader")
+ .Case("geometry", "geometry shader")
+ .Case("hull", "hull shader")
+ .Case("domain", "domain shader")
+ .Case("compute", "compute shader")
+ .Case("mesh", "mesh shader")
+ .Case("amplification", "amplification shader")
+ .Case("library", "shader library")
+ .Default(Environment);
+}
+static llvm::Triple::EnvironmentType getEnvironmentType(llvm::StringRef
Environment) {
+return llvm::StringSwitch(Environment)
+ .Case("pixel", llvm::Triple::Pixel)
+ .Case("vertex", llvm::Triple::Vertex)
+ .Case("geometry", llvm::Triple::Geometry)
+ .Case("hull", llvm::Triple::Hull)
+ .Case("domain", llvm::Triple::Domain)
+ .Case("compute", llvm::Triple::Compute)
+ .Case("mesh", llvm::Triple::Mesh)
+ .Case("amplification", llvm::Triple::Amplification)
+ .Case("library", llvm::Triple::Library)
+ .Default(llvm::Triple::UnknownEnvironment);
+}
+}];
let HasCustomParsing = 1;
let InheritEvenIfAlreadyPresent = 1;
let Subjects = SubjectList<[Named]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td
b/clang/include/clang/Basic/AttrDocs.td
index a0bbe5861c5722..a81163df35ca8b 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -1593,6 +1593,8 @@ replacement=\ *string-literal*
a warning about use of a deprecated declaration. The Fix-It will replace
the deprecated declaration with the new declaration specified.
+// HEKOTA TODO add docs here
+
Multiple availability attributes can be placed on a declaration, which may
correspond to different platforms. For most platforms, the availability
attribute with the platform corresponding to the target platform will be used;
diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 66405095d51de8..631dc8880fcfc8 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1103,6
[clang] [Driver] Ensure ToolChain::LibraryPaths is not empty for non-Darwin (PR #87866)
mstorsjo wrote: > > I would suggest we revert this - and at least collect all the observed side > > effects and declare them before considering relanding it. > > That sounds good to me. Do you have a list of PRs to revert? Not sure if there are follow-up fixes, sorry, but the discussed PRs are this one, and #81037 (where #89775 says the latter one changed functional behaviour, but it sounds mostly like your issue, i.e. caused by this one). > > ... then we do still get the old name embedded. > > Sure. The motivation on our side is a distributed compile service where the > library doesn't exist on the remote end. This patch means we'll have to add > knowledge about path layouts at link time to the remote setup at compile > time. That's certainly doable, but kind of janky. Right, I see. FWIW, with the embedding of directives, which kind of depends on knowing the runtime layout style, I guess this is an issue that needs to be tackled at one point or another, for distributed builds (especially as long as the intent is to change default towards the per-triple directories instead of per-os directories). > (What we'll actually do is use the flag from #89642 to disable all this > guessing of libs and just explicitly pass the path to the lib at link time. > So this won't actually affect us then, but reverting and relanding in one > commit with a list of side effects still sounds like a good thing independent > of that.) Ah, that probably sounds like a good flag to have in any case, for that kind of distributed setup! https://github.com/llvm/llvm-project/pull/87866 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo &Info, const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to IEEE 754 here.
- if (LHS.isNaN()) {
+ if (!Info.getLangOpts().CPlusPlus23 && LHS.isNaN()) {
zahiraam wrote:
So, the comment in the code above is not quite correct right? Should that
entire condition be removed?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Matheus Izvekov (mizvekov)
Changes
This patch will finally allow us to mark C++17 support in clang as complete.
This is a continuation of the review process from an [old PR in
phab](https://reviews.llvm.org/D109496).
Recap: The original patch from phab initially contained no workarounds /
provisional resolutions for core defects,
Though testing by @yxsamliu
[here](https://reviews.llvm.org/D109496#3101839) showed problems with
some important libraries used in GPU applications, and we ended up reverting it.
In order to implement this as a DR and avoid breaking reasonable code that
worked before P0522, this patch implements a provisional resolution for
CWG2398: When deducing template template parameters against each other, and the
argument side names a template specialization, instead of just deducing A, we
instead deduce a synthesized template template parameter based on A, but with
it's parameters using the template specialization's arguments as defaults.
This does not fix all possible regressions introduced by P0522, but it does
seem to match in effect an undocumented workaround implemented by GCC. Though
it's unconfirmed how closely we match, as I have not received official word
regarding this yet.
Fixing other regressions will require more extensive changes, some of them
would require possibly controversial wording changes, and so is left for future
work.
The driver flag is deprecated with a warning, and it will not have any effect.
@yxsamliu Can you confirm this version avoids any breakages in your
setup?
CC: @yuanfang-chen @MaskRay @chandlerc @jicama
@lichray @AaronBallman
---
Patch is 30.33 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/89807.diff
18 Files Affected:
- (modified) clang/include/clang/Basic/DiagnosticDriverKinds.td (+1-1)
- (modified) clang/include/clang/Basic/LangOptions.def (-1)
- (modified) clang/include/clang/Driver/Options.td (+2-5)
- (modified) clang/lib/Driver/SanitizerArgs.cpp (+5-4)
- (modified) clang/lib/Driver/ToolChains/Clang.cpp (+5-6)
- (modified) clang/lib/Frontend/InitPreprocessor.cpp (+2-2)
- (modified) clang/lib/Sema/SemaTemplate.cpp (+41-47)
- (modified) clang/lib/Sema/SemaTemplateDeduction.cpp (+93-6)
- (modified) clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp (+1-1)
- (modified) clang/test/CodeGenCXX/mangle-concept.cpp (+2-2)
- (added) clang/test/Driver/frelaxed-template-template-args.cpp (+5)
- (modified) clang/test/Lexer/cxx-features.cpp (+1-4)
- (modified) clang/test/SemaTemplate/default-arguments.cpp (+3-4)
- (modified) clang/test/SemaTemplate/instantiate-template-template-parm.cpp
(+8-9)
- (modified) clang/test/SemaTemplate/nested-template.cpp (+3-5)
- (modified) clang/test/SemaTemplate/temp_arg_template.cpp (+3-3)
- (modified) clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp (+1-1)
- (modified) clang/www/cxx_status.html (+7-10)
``diff
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index ed3fd9b1c4a55b..9781fcaa4ff5e9 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -435,7 +435,7 @@ def warn_drv_diagnostics_misexpect_requires_pgo : Warning<
def warn_drv_clang_unsupported : Warning<
"the clang compiler does not support '%0'">;
def warn_drv_deprecated_arg : Warning<
- "argument '%0' is deprecated, use '%1' instead">, InGroup;
+ "argument '%0' is deprecated%select{|, use '%2' instead}1">,
InGroup;
def warn_drv_deprecated_custom : Warning<
"argument '%0' is deprecated, %1">, InGroup;
def warn_drv_assuming_mfloat_abi_is : Warning<
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index 8ef6700ecdc78e..2dfe70f29d7c85 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -158,7 +158,6 @@ LANGOPT(GNUAsm, 1, 1, "GNU-style inline
assembly")
LANGOPT(Coroutines, 1, 0, "C++20 coroutines")
LANGOPT(CoroAlignedAllocation, 1, 0, "prefer Aligned Allocation according to
P2014 Option 2")
LANGOPT(DllExportInlines , 1, 1, "dllexported classes dllexport inline
methods")
-LANGOPT(RelaxedTemplateTemplateArgs, 1, 0, "C++17 relaxed matching of template
template arguments")
LANGOPT(ExperimentalLibrary, 1, 0, "enable unstable and experimental library
features")
LANGOPT(PointerAuthIntrinsics, 1, 0, "pointer authentication intrinsics")
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 922bda721dc780..f907102f7f813b 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3359,11 +3359,8 @@ defm application_extension :
BoolFOption<"application-extension",
PosFlag,
NegFlag>;
-defm relaxed_template_template_args :
BoolFOption<"relaxed-temp
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
https://github.com/mizvekov created
https://github.com/llvm/llvm-project/pull/89807
This patch will finally allow us to mark C++17 support in clang as complete.
This is a continuation of the review process from an [old PR in
phab](https://reviews.llvm.org/D109496).
Recap: The original patch from phab initially contained no workarounds /
provisional resolutions for core defects,
Though testing by @yxsamliu [here](https://reviews.llvm.org/D109496#3101839)
showed problems with some important libraries used in GPU applications, and we
ended up reverting it.
In order to implement this as a DR and avoid breaking reasonable code that
worked before P0522, this patch implements a provisional resolution for
CWG2398: When deducing template template parameters against each other, and the
argument side names a template specialization, instead of just deducing A, we
instead deduce a synthesized template template parameter based on A, but with
it's parameters using the template specialization's arguments as defaults.
This does not fix all possible regressions introduced by P0522, but it does
seem to match in effect an undocumented workaround implemented by GCC. Though
it's unconfirmed how closely we match, as I have not received official word
regarding this yet.
Fixing other regressions will require more extensive changes, some of them
would require possibly controversial wording changes, and so is left for future
work.
The driver flag is deprecated with a warning, and it will not have any effect.
@yxsamliu Can you confirm this version avoids any breakages in your setup?
CC: @yuanfang-chen @MaskRay @chandlerc @jicama @lichray @AaronBallman
>From 873043f6ea08b8828a5e061cf67c70e39b66b8b8 Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Tue, 9 Apr 2024 01:14:28 -0300
Subject: [PATCH] [clang] deprecate frelaxed-template-template-args, make it on
by default
In order to implement this as a DR and avoid breaking reasonable code
that worked before P0522, this patch implements a provisional resolution
for CWG2398: When deducing template template parameters against each other,
and the argument side names a template specialization, instead of just
deducing A, we instead deduce a synthesized template template parameter based
on A, but with it's parameters using the template specialization's arguments
as defaults.
The driver flag is deprecated with a warning, and it will not have any effect.
---
.../clang/Basic/DiagnosticDriverKinds.td | 2 +-
clang/include/clang/Basic/LangOptions.def | 1 -
clang/include/clang/Driver/Options.td | 7 +-
clang/lib/Driver/SanitizerArgs.cpp| 9 +-
clang/lib/Driver/ToolChains/Clang.cpp | 11 +--
clang/lib/Frontend/InitPreprocessor.cpp | 4 +-
clang/lib/Sema/SemaTemplate.cpp | 88 -
clang/lib/Sema/SemaTemplateDeduction.cpp | 99 +--
.../temp/temp.arg/temp.arg.template/p3-2a.cpp | 2 +-
clang/test/CodeGenCXX/mangle-concept.cpp | 4 +-
.../frelaxed-template-template-args.cpp | 5 +
clang/test/Lexer/cxx-features.cpp | 5 +-
clang/test/SemaTemplate/default-arguments.cpp | 7 +-
.../instantiate-template-template-parm.cpp| 17 ++--
clang/test/SemaTemplate/nested-template.cpp | 8 +-
clang/test/SemaTemplate/temp_arg_template.cpp | 6 +-
.../SemaTemplate/temp_arg_template_cxx1z.cpp | 2 +-
clang/www/cxx_status.html | 17 ++--
18 files changed, 183 insertions(+), 111 deletions(-)
create mode 100644 clang/test/Driver/frelaxed-template-template-args.cpp
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index ed3fd9b1c4a55b..9781fcaa4ff5e9 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -435,7 +435,7 @@ def warn_drv_diagnostics_misexpect_requires_pgo : Warning<
def warn_drv_clang_unsupported : Warning<
"the clang compiler does not support '%0'">;
def warn_drv_deprecated_arg : Warning<
- "argument '%0' is deprecated, use '%1' instead">, InGroup;
+ "argument '%0' is deprecated%select{|, use '%2' instead}1">,
InGroup;
def warn_drv_deprecated_custom : Warning<
"argument '%0' is deprecated, %1">, InGroup;
def warn_drv_assuming_mfloat_abi_is : Warning<
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index 8ef6700ecdc78e..2dfe70f29d7c85 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -158,7 +158,6 @@ LANGOPT(GNUAsm, 1, 1, "GNU-style inline
assembly")
LANGOPT(Coroutines, 1, 0, "C++20 coroutines")
LANGOPT(CoroAlignedAllocation, 1, 0, "prefer Aligned Allocation according to
P2014 Option 2")
LANGOPT(DllExportInlines , 1, 1, "dllexported classes dllexport inline
methods")
-LANGOPT(RelaxedTemplateTemplateArgs, 1, 0, "C++17 relaxed matching of template
[clang] [clang] coroutine: generate valid mangled name in CodeGenFunction::generateAwaitSuspendWrapper (PR #89731)
https://github.com/hokein closed https://github.com/llvm/llvm-project/pull/89731 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] dc8f6a8 - [clang] coroutine: generate valid mangled name in CodeGenFunction::generateAwaitSuspendWrapper (#89731)
Author: Haojian Wu
Date: 2024-04-23T21:09:36+02:00
New Revision: dc8f6a8cdad427345a60f5142411617df521c303
URL:
https://github.com/llvm/llvm-project/commit/dc8f6a8cdad427345a60f5142411617df521c303
DIFF:
https://github.com/llvm/llvm-project/commit/dc8f6a8cdad427345a60f5142411617df521c303.diff
LOG: [clang] coroutine: generate valid mangled name in
CodeGenFunction::generateAwaitSuspendWrapper (#89731)
Fixes https://github.com/llvm/llvm-project/issues/89723
Added:
Modified:
clang/lib/CodeGen/CGCoroutine.cpp
clang/test/CodeGenCoroutines/coro-await.cpp
clang/test/CodeGenCoroutines/coro-dwarf.cpp
clang/test/CodeGenCoroutines/pr65054.cpp
Removed:
diff --git a/clang/lib/CodeGen/CGCoroutine.cpp
b/clang/lib/CodeGen/CGCoroutine.cpp
index 93ca711f716fce..567e85a02dc612 100644
--- a/clang/lib/CodeGen/CGCoroutine.cpp
+++ b/clang/lib/CodeGen/CGCoroutine.cpp
@@ -413,10 +413,8 @@ llvm::Function *
CodeGenFunction::generateAwaitSuspendWrapper(Twine const &CoroName,
Twine const &SuspendPointName,
CoroutineSuspendExpr const &S) {
- std::string FuncName = "__await_suspend_wrapper_";
- FuncName += CoroName.str();
- FuncName += '_';
- FuncName += SuspendPointName.str();
+ std::string FuncName =
+ (CoroName + ".__await_suspend_wrapper__" + SuspendPointName).str();
ASTContext &C = getContext();
diff --git a/clang/test/CodeGenCoroutines/coro-await.cpp
b/clang/test/CodeGenCoroutines/coro-await.cpp
index 75851d8805bb6e..65bfb099468817 100644
--- a/clang/test/CodeGenCoroutines/coro-await.cpp
+++ b/clang/test/CodeGenCoroutines/coro-await.cpp
@@ -73,7 +73,7 @@ extern "C" void f0() {
// ---
// Call coro.await.suspend
// ---
- // CHECK-NEXT: call void @llvm.coro.await.suspend.void(ptr %[[AWAITABLE]],
ptr %[[FRAME]], ptr @__await_suspend_wrapper_f0_await)
+ // CHECK-NEXT: call void @llvm.coro.await.suspend.void(ptr %[[AWAITABLE]],
ptr %[[FRAME]], ptr @f0.__await_suspend_wrapper__await)
// -
// Generate a suspend point:
// -
@@ -100,7 +100,7 @@ extern "C" void f0() {
// CHECK: call i8 @llvm.coro.suspend(token %[[FINALSP_ID]], i1 true)
// Await suspend wrapper
- // CHECK: define{{.*}} @__await_suspend_wrapper_f0_await(ptr {{[^,]*}}
%[[AWAITABLE_ARG:.+]], ptr {{[^,]*}} %[[FRAME_ARG:.+]])
+ // CHECK: define{{.*}} @f0.__await_suspend_wrapper__await(ptr {{[^,]*}}
%[[AWAITABLE_ARG:.+]], ptr {{[^,]*}} %[[FRAME_ARG:.+]])
// CHECK: store ptr %[[AWAITABLE_ARG]], ptr %[[AWAITABLE_TMP:.+]],
// CHECK: store ptr %[[FRAME_ARG]], ptr %[[FRAME_TMP:.+]],
// CHECK: %[[AWAITABLE:.+]] = load ptr, ptr %[[AWAITABLE_TMP]]
@@ -149,7 +149,7 @@ extern "C" void f1(int) {
// ---
// Call coro.await.suspend
// ---
- // CHECK-NEXT: %[[YES:.+]] = call i1 @llvm.coro.await.suspend.bool(ptr
%[[AWAITABLE]], ptr %[[FRAME]], ptr @__await_suspend_wrapper_f1_yield)
+ // CHECK-NEXT: %[[YES:.+]] = call i1 @llvm.coro.await.suspend.bool(ptr
%[[AWAITABLE]], ptr %[[FRAME]], ptr @f1.__await_suspend_wrapper__yield)
// ---
// See if await_suspend decided not to suspend
// ---
@@ -162,7 +162,7 @@ extern "C" void f1(int) {
// CHECK: call void @_ZN13suspend_maybe12await_resumeEv(ptr {{[^,]*}}
%[[AWAITABLE]])
// Await suspend wrapper
- // CHECK: define {{.*}} i1 @__await_suspend_wrapper_f1_yield(ptr {{[^,]*}}
%[[AWAITABLE_ARG:.+]], ptr {{[^,]*}} %[[FRAME_ARG:.+]])
+ // CHECK: define {{.*}} i1 @f1.__await_suspend_wrapper__yield(ptr {{[^,]*}}
%[[AWAITABLE_ARG:.+]], ptr {{[^,]*}} %[[FRAME_ARG:.+]])
// CHECK: store ptr %[[AWAITABLE_ARG]], ptr %[[AWAITABLE_TMP:.+]],
// CHECK: store ptr %[[FRAME_ARG]], ptr %[[FRAME_TMP:.+]],
// CHECK: %[[AWAITABLE:.+]] = load ptr, ptr %[[AWAITABLE_TMP]]
@@ -370,7 +370,7 @@ extern "C" void TestTailcall() {
// ---
// Call coro.await.suspend
// ---
- // CHECK-NEXT: %[[RESUMED:.+]] = call ptr
@llvm.coro.await.suspend.handle(ptr %[[AWAITABLE]], ptr %[[FRAME]], ptr
@__await_suspend_wrapper_TestTailcall_await)
+ // CHECK-NEXT: %[[RESUMED:.+]] = call ptr
@llvm.coro.await.suspend.handle(ptr %[[AWAITABLE]], ptr %[[FRAME]], ptr
@TestTailcall.__await_suspend_wrapper__await)
// CHECK-NEXT: call void @llvm.coro.resume(ptr %[[RESUMED]])
// CHECK-NEXT: %[[OUTCOME:.+]] = call i8 @llvm.coro.suspend(token
%[[SUSPEND_ID]], i1 false)
// CHECK-NEXT: switch i8 %[[OUTCOME]], label %[[RET_BB:.+]] [
@@ -379,7 +379,7 @@ extern "C" void TestTailcall() {
// CHECK-NEXT: ]
// Await suspend wrapper
- // CHECK: define {{.*}} ptr @__await_suspend_wrapper_TestTailcall_await(ptr
{{
[clang] [clang-format] Remove YAML hack to emit a BasedOnStyle comment (PR #89228)
https://github.com/HazardyKnusperkeks approved this pull request. I don't see a use case for that comment, and thus I see no problem in removing it. https://github.com/llvm/llvm-project/pull/89228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Ensure ToolChain::LibraryPaths is not empty for non-Darwin (PR #87866)
nico wrote: > I would suggest we revert this - and at least collect all the observed side > effects and declare them before considering relanding it. That sounds good to me. Do you have a list of PRs to revert? > ... then we do still get the old name embedded. Sure. The motivation on our side is a distributed compile service where the library doesn't exist on the remote end. This patch means we'll have to add knowledge about path layouts at link time to the remote setup at compile time. That's certainly doable, but kind of janky. (What we'll actually do is use the flag from #89642 to disable all this guessing of libs and just explicitly pass the path to the lib at link time. So this won't actually affect us then, but reverting and relanding in one commit with a list of side effects still sounds like a good thing independent of that.) https://github.com/llvm/llvm-project/pull/87866 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
@@ -147,19 +147,25 @@ void
WebAssemblyTargetInfo::setFeatureEnabled(llvm::StringMap &Features,
bool WebAssemblyTargetInfo::initFeatureMap(
llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector &FeaturesVec) const {
- if (CPU == "bleeding-edge") {
-Features["nontrapping-fptoint"] = true;
+ auto addGenericFeatures = [&]() {
Features["sign-ext"] = true;
+Features["mutable-globals"] = true;
+Features["reference-types"] = true;
+Features["multivalue"] = true;
+ };
+ auto addBleedingEdgeFeatures = [&]() {
+addGenericFeatures();
+Features["nontrapping-fptoint"] = true;
tlively wrote:
Oh, I see, if we think we would need a Binaryen lowering pass first, then
proceeding without this SGTM.
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo,
/// Whether to support HIP image/texture API's.
virtual bool hasHIPImageSupport() const { return true; }
+ /// The minimum offset between two objects to avoid false sharing.
+ virtual unsigned hardwareDestructiveInterferenceSize() const { return 64; }
jyknight wrote:
I vaguely wonder if we should make this a single "hardwareInterferenceSizes"
function, returning a std::pair, because otherwise, when we
start add per-CPU tuning to the values, it's very likely to result in
duplicating the same series of conditionals in each of the two functions.
Also, with a single function, we are less likely to accidentally end up with an
override that returns values such that `destructive < constructive`.
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo,
/// Whether to support HIP image/texture API's.
virtual bool hasHIPImageSupport() const { return true; }
+ /// The minimum offset between two objects to avoid false sharing.
jyknight wrote:
Might add a comment here that this is not considered part of the ABI, and is
okay to change, for clarity of future target maintainers.
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
https://github.com/jyknight edited https://github.com/llvm/llvm-project/pull/89446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
https://github.com/jyknight commented: I think having the on-by-default diagnostic before we release this functionality is critically important -- but the primarily-useful part of that is going to be for the public libc++ APIs which expose these values (and, that already landed in mainline). This PR is almost an internal implementation detail, so doesn't really make things much worse than they are, so I don't feel like it needs to be held up by that. I do really hope that diagnostic does get added soon. I concur with previous comments that getting the values exactly right for each target in the first commit isn't super-important: each target maintainer may adjust as desired in the future, since these are abi-unstable values. However, I do note that we already _almost_ have the required data in the LLVM backend for many targets, via TargetTransformInfo::getCacheLineSize. That is only a single value, so it's only correct if requesting tuning for a single CPU-model, vs a generic tuning which must express the full range of possibilities. But, when collecting the values to use here, that existing data has been ignored, which I think is unfortunate. Ideally, we would actually _share_ the data, rather than duplicating it in two different places. Though, due to architectural decisions made way-back-in-time, we often have trouble achieving actual sharing of backend-specific data... But at the least, if we cannot actually share the same code, maybe we should attempt to be internally-consistent? https://github.com/llvm/llvm-project/pull/89446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
@@ -147,19 +147,25 @@ void
WebAssemblyTargetInfo::setFeatureEnabled(llvm::StringMap &Features,
bool WebAssemblyTargetInfo::initFeatureMap(
llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector &FeaturesVec) const {
- if (CPU == "bleeding-edge") {
-Features["nontrapping-fptoint"] = true;
+ auto addGenericFeatures = [&]() {
Features["sign-ext"] = true;
+Features["mutable-globals"] = true;
+Features["reference-types"] = true;
+Features["multivalue"] = true;
+ };
+ auto addBleedingEdgeFeatures = [&]() {
+addGenericFeatures();
+Features["nontrapping-fptoint"] = true;
tlively wrote:
Looks like this was enabled in Safari in September 2021. Should we enable this
by default as well?
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
https://github.com/tlively approved this pull request. https://github.com/llvm/llvm-project/pull/80923 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)
https://github.com/tlively edited https://github.com/llvm/llvm-project/pull/80923 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Correctly annotate list init braces of class types (PR #89706)
https://github.com/HazardyKnusperkeks approved this pull request. https://github.com/llvm/llvm-project/pull/89706 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] adds a space after not inside macros (PR #78176)
https://github.com/mydeveloperday closed https://github.com/llvm/llvm-project/pull/78176 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Remove YAML hack to emit a BasedOnStyle comment (PR #89228)
mydeveloperday wrote: I'm ok with removing it if @owenca and @HazardyKnusperkeks are. https://github.com/llvm/llvm-project/pull/89228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Only modulemaps of included textual headers are affecting (PR #89729)
@@ -1441,6 +1441,10 @@ void HeaderSearch::MarkFileModuleHeader(FileEntryRef FE,
HFI.isCompilingModuleHeader |= isCompilingModuleHeader;
}
+void HeaderSearch::EnteredTextualFile(FileEntryRef File) {
+ getFileInfo(File).isCompilingModuleHeader = true;
sam-mccall wrote:
Oops, I meant to alter that description in this patch, it seems that change got
lost.
At this point, `isCompilingModuleHeader` is used only for this "is affecting"
check, and for a heuristic related to translating `#include` into `#import`.
The latter only cares about modular headers, so it seems reasonable to change
the semantics for textual headers to something more useful. (But I do need to
be careful we're only setting this for textual modular headers).
https://github.com/llvm/llvm-project/pull/89729
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Tidy up wasm-target-features.c (PR #89778)
https://github.com/tlively approved this pull request. https://github.com/llvm/llvm-project/pull/89778 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [WebAssembly] Fix uses of -DAG and -NOT in wasm-target-features.c (PR #89777)
https://github.com/tlively approved this pull request. Thanks! https://github.com/llvm/llvm-project/pull/89777 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Correctly annotate list init braces of class types (PR #89706)
https://github.com/mydeveloperday approved this pull request. https://github.com/llvm/llvm-project/pull/89706 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
https://github.com/smanna12 updated https://github.com/llvm/llvm-project/pull/89801 >From 326b428c826e866feb538b9dcd33a9df957f9f69 Mon Sep 17 00:00:00 2001 From: "Manna, Soumi" Date: Tue, 23 Apr 2024 10:37:01 -0700 Subject: [PATCH 1/2] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition In the lambda function within clang::Sema::InstantiateFunctionDefinition, the return value of a function that may return null is now checked before dereferencing to avoid potential null pointer dereference issues. --- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp index 787a485e0b2f8c..2490ec4ca614a8 100644 --- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp +++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp @@ -5183,7 +5183,9 @@ void Sema::InstantiateFunctionDefinition(SourceLocation PointOfInstantiation, Function->setTypeSourceInfo(NewSI); ParmVarDecl *Parm = Function->getParamDecl(0); +assert(Parm && "First parameter not found in function declaration."); TypeSourceInfo *NewParmSI = IR.TransformType(Parm->getTypeSourceInfo()); +assert(NewParmSI && "Type transformation failed."); Parm->setType(NewParmSI->getType()); Parm->setTypeSourceInfo(NewParmSI); }; >From d7d5e94eea44246e706c774661b4a7077bd06e2f Mon Sep 17 00:00:00 2001 From: "Manna, Soumi" Date: Tue, 23 Apr 2024 11:39:13 -0700 Subject: [PATCH 2/2] Remove assert when using getParamDecl() --- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp index 2490ec4ca614a8..d544cfac55ba36 100644 --- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp +++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp @@ -5183,7 +5183,6 @@ void Sema::InstantiateFunctionDefinition(SourceLocation PointOfInstantiation, Function->setTypeSourceInfo(NewSI); ParmVarDecl *Parm = Function->getParamDecl(0); -assert(Parm && "First parameter not found in function declaration."); TypeSourceInfo *NewParmSI = IR.TransformType(Parm->getTypeSourceInfo()); assert(NewParmSI && "Type transformation failed."); Parm->setType(NewParmSI->getType()); ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Extend the C support. (PR #89804)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Vassil Vassilev (vgvassilev)
Changes
The IdResolver chain is the main way for C to implement lookup rules. Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.
This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
---
Full diff: https://github.com/llvm/llvm-project/pull/89804.diff
3 Files Affected:
- (modified) clang/lib/Interpreter/IncrementalParser.cpp (+11-2)
- (modified) clang/lib/Sema/SemaDecl.cpp (+2-1)
- (added) clang/test/Interpreter/execute.c (+21)
``diff
diff --git a/clang/lib/Interpreter/IncrementalParser.cpp
b/clang/lib/Interpreter/IncrementalParser.cpp
index ef90fe9e6f5451..f1cb5fc870eb94 100644
--- a/clang/lib/Interpreter/IncrementalParser.cpp
+++ b/clang/lib/Interpreter/IncrementalParser.cpp
@@ -387,8 +387,7 @@ std::unique_ptr
IncrementalParser::GenModule() {
void IncrementalParser::CleanUpPTU(PartialTranslationUnit &PTU) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
- TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
- if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
+ if (StoredDeclsMap *Map = MostRecentTU->getPrimaryContext()->getLookupPtr())
{
for (auto &&[Key, List] : *Map) {
DeclContextLookupResult R = List.getLookupResult();
std::vector NamedDeclsToRemove;
@@ -407,6 +406,16 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
&PTU) {
}
}
}
+
+ // FIXME: We should de-allocate MostRecentTU
+ for (Decl *D : MostRecentTU->decls()) {
+if (!isa(D))
+ continue;
+// Check if we need to clean up the IdResolver chain.
+NamedDecl *ND = cast(D);
+if (ND->getDeclName().getFETokenInfo())
+ getCI()->getSema().IdResolver.RemoveDecl(ND);
+ }
}
llvm::StringRef IncrementalParser::GetMangledName(GlobalDecl GD) const {
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 452e00fa32b102..2a0f73b42d3088 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -2282,7 +2282,8 @@ void Sema::ActOnPopScope(SourceLocation Loc, Scope *S) {
// Remove this name from our lexical scope, and warn on it if we haven't
// already.
-IdResolver.RemoveDecl(D);
+if (!PP.isIncrementalProcessingEnabled())
+ IdResolver.RemoveDecl(D);
auto ShadowI = ShadowingDecls.find(D);
if (ShadowI != ShadowingDecls.end()) {
if (const auto *FD = dyn_cast(ShadowI->second)) {
diff --git a/clang/test/Interpreter/execute.c b/clang/test/Interpreter/execute.c
new file mode 100644
index 00..44a3a32c930112
--- /dev/null
+++ b/clang/test/Interpreter/execute.c
@@ -0,0 +1,21 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -Xclang -Xcc -verify | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -O2 -Xcc -Xclang -Xcc -verify|
FileCheck %s
+int printf(const char *, ...);
+int i = 42; err // expected-error{{use of undeclared identifier}}
+int i = 42;
+struct S { float f; struct S *m;} s = {1.0, 0};
+// FIXME: Making foo inline fails to emit the function.
+int foo() { return 42; }
+void run() {\
+ printf("i = %d\n", i);\
+ printf("S[f=%f, m=0x%llx]\n", s.f, (unsigned long long)s.m); \
+ int r3 = foo(); \
+}
+run();
+// CHECK: i = 42
+// CHECK-NEXT: S[f=1.00, m=0x0]
+
+%quit
``
https://github.com/llvm/llvm-project/pull/89804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Extend the C support. (PR #89804)
https://github.com/vgvassilev created
https://github.com/llvm/llvm-project/pull/89804
The IdResolver chain is the main way for C to implement lookup rules. Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.
This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
>From 8317ce33d07d0986e314de0b39aa977f784e0619 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 18:07:06 +
Subject: [PATCH] [clang-repl] Extend the C support.
The IdResolver chain is the main way for C to implement lookup rules. Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.
This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
---
clang/lib/Interpreter/IncrementalParser.cpp | 13 +++--
clang/lib/Sema/SemaDecl.cpp | 3 ++-
clang/test/Interpreter/execute.c| 21 +
3 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 clang/test/Interpreter/execute.c
diff --git a/clang/lib/Interpreter/IncrementalParser.cpp
b/clang/lib/Interpreter/IncrementalParser.cpp
index ef90fe9e6f5451..f1cb5fc870eb94 100644
--- a/clang/lib/Interpreter/IncrementalParser.cpp
+++ b/clang/lib/Interpreter/IncrementalParser.cpp
@@ -387,8 +387,7 @@ std::unique_ptr
IncrementalParser::GenModule() {
void IncrementalParser::CleanUpPTU(PartialTranslationUnit &PTU) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
- TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
- if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
+ if (StoredDeclsMap *Map = MostRecentTU->getPrimaryContext()->getLookupPtr())
{
for (auto &&[Key, List] : *Map) {
DeclContextLookupResult R = List.getLookupResult();
std::vector NamedDeclsToRemove;
@@ -407,6 +406,16 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
&PTU) {
}
}
}
+
+ // FIXME: We should de-allocate MostRecentTU
+ for (Decl *D : MostRecentTU->decls()) {
+if (!isa(D))
+ continue;
+// Check if we need to clean up the IdResolver chain.
+NamedDecl *ND = cast(D);
+if (ND->getDeclName().getFETokenInfo())
+ getCI()->getSema().IdResolver.RemoveDecl(ND);
+ }
}
llvm::StringRef IncrementalParser::GetMangledName(GlobalDecl GD) const {
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 452e00fa32b102..2a0f73b42d3088 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -2282,7 +2282,8 @@ void Sema::ActOnPopScope(SourceLocation Loc, Scope *S) {
// Remove this name from our lexical scope, and warn on it if we haven't
// already.
-IdResolver.RemoveDecl(D);
+if (!PP.isIncrementalProcessingEnabled())
+ IdResolver.RemoveDecl(D);
auto ShadowI = ShadowingDecls.find(D);
if (ShadowI != ShadowingDecls.end()) {
if (const auto *FD = dyn_cast(ShadowI->second)) {
diff --git a/clang/test/Interpreter/execute.c b/clang/test/Interpreter/execute.c
new file mode 100644
index 00..44a3a32c930112
--- /dev/null
+++ b/clang/test/Interpreter/execute.c
@@ -0,0 +1,21 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -Xclang -Xcc -verify | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -O2 -Xcc -Xclang -Xcc -verify|
FileCheck %s
+int printf(const char *, ...);
+int i = 42; err // expected-error{{use of undeclared identifier}}
+int i = 42;
+struct S { float f; struct S *m;} s = {1.0, 0};
+// FIXME: Making foo inline fails to emit the function.
+int foo() { return 42; }
+void run() {\
+ printf("i = %d\n", i);\
+ printf("S[f=%f, m=0x%llx]\n", s.f, (unsigned long long)s.m); \
+ int r3 = foo(); \
+}
+run();
+// CHECK: i = 42
+// CHECK-NEXT: S[f=1.00, m=0x0]
+
+%quit
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
Sirraide wrote: And moreover, `getParamDecl()` already asserts that the index is in bounds. https://github.com/llvm/llvm-project/pull/89801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++17 Feature Support
+^
+- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
+ predefined macros to support standard library implementations of
+ ``std::hardware_destructive_interference_size`` and
+ ``std::hardware_constructive_interference_size``, respectively. These macros
+ are predefined in all C and C++ language modes. These macros can be
+ overridden on the command line with ``-D``, if desired. The values the macros
AaronBallman wrote:
I want to make sure I'm on the same page with what you're asking.
```
struct alignas(__GCC_CONSTRUCTIVE_SIZE) S {}; // #1
struct alignas(std::hardware_constructive_interference_size) T {}; // #2
static_assert(__GCC_CONSTRUCTIVE_SIZE > 0); // #3
static_assert(std::hardware_constructive_interference_size > 0); // #4
```
There is nothing wrong with either (3) or (4) and I don't think we should
diagnose that kind of use. So "any use in a header file" is too strict IMO. The
problem with (1) and (2) is that it's a fragile diagnostic unless we're willing
to put in significant effort.
The easy way to do (1) is to see if the operand to `alignas` (within a header)
comes from a macro and see if the macro was named `__GCC_CONSTRUCTIVE_SIZE` (or
destructive). However, that misses these kinds of scenarios:
```
#define DERP __GCC_CONSTRUCTIVE_SIZE
struct alignas(DERP) S {};
struct alignas(__GCC_CONSTRUCTIVE_SIZE + 0) T {};
```
(I'm not worried about people doing arithmetic in `alignas` getting false
negatives, they earned them. But I am worried we're going to have to do macro
chasing because of `#if` use.)
Resolving names in the STL is non-trivial thanks to inline namespaces, which
makes (2) a bit of a challenge. But (2) runs into even worse issues than (1):
```
constexpr size_t MySize = std::hardware_constructive_interference_size;
struct alignas(MySize) S {};
```
and we're no longer doing macro chasing, now we're trying to unpack constant
expressions.
Further, if the request is "ABI issues in general", all bets are off because
people can do fantastic things like:
```
struct S {
int array[std::hardware_constructive_interference_size];
};
```
and now we're playing whack-a-mole trying to identify safe vs unsafe uses in
header files.
So I think the only thing that's reasonable to consider would be
```
struct alignas(__GCC_CONSTRUCTIVE_SIZE) S {};
struct alignas(std::hardware_constructive_interference_size) T{};
```
and nothing else, but that doesn't actually address your concern about catching
ABI issues. FWIW, I think @cor3ntin is correct in that we don't really make
special cases for all the other potentially ABI-terrible ideas people can come
up with in a header file and there's nothing particularly special about this
one.
We already have [ODR checking
facilities](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fsanitize-address-use-odr-indicator)
and that seems sufficient to catch issues that happen in practice. (Note, I'm
not saying we should never add a diagnostic to help users catch potential ODR
issues earlier. But I think it's not necessary for this PR to move forward and
we should consider such diagnostics in a broader context than just this one
narrow case.)
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
https://github.com/Sirraide commented: A pr that just adds assertions and nothing else seems like a very weird thing to do. Moreover, a few lines above in the same function, we return if this isn’t a copy/move ctor/assignment operator, which always has at least one parameter; I don’t think it is possible for `Parm` to be `nullptr` here. Do you have any code examples that would trigger this asertion here? https://github.com/llvm/llvm-project/pull/89801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [coro] Lower `llvm.coro.await.suspend.handle` to resume with tail call (PR #89751)
zmodem wrote: > Does this address > https://discourse.llvm.org/t/coro-pre-split-handling-of-the-suspend-edge/75043? > Could you add a note there in that direction - a few folks were looking at > going at the direction @jyknight was suggesting there, and it'd be good to > have closure on the topic. Thanks for the pointer! If I understand things correctly: * Yes, my patch addresses the problem of instructions in the suspend block getting in the way of lowering symmetric transfer as a tail call. * With my patch, something could still put instructions between the llvm.coro.await.suspend.handle and the suspend, and those would become unreachable. I don't think that's a problem in practice though. The frontend shouldn't do that, and I don't think any transform would move instructions across the intrinsic call. * My patch doesn't address the more general concern in that thread about that edge being a strange representation. https://github.com/llvm/llvm-project/pull/89751 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)
@@ -592,6 +592,48 @@ class AttrSubjectMatcherAggregateRule
{
def SubjectMatcherForNamed : AttrSubjectMatcherAggregateRule;
+// Late Attribute parsing mode enum
+class LateAttrParseKind {
+ int Kind = val;
+}
+
+// Never late parsed
+def LateAttrParseNever : LateAttrParseKind<0>;
+
+// Standard late attribute parsing
+//
+// This is language dependent. For example:
+//
+// * For C++ enables late parsing of a declaration attributes
+// * For C does not enable late parsing of attributes
+//
+def LateAttrParseStandard: LateAttrParseKind<1>;
+
+// Experimental extension to standard late attribute parsing
+//
+// This extension behaves like `LateAttrParseStandard` but allows
+// late parsing attributes in more contexts.
+//
+// In contexts where `LateAttrParseStandard` attributes are late
+// parsed, `LateAttrParseExperimentalExt` attributes will also
+// be late parsed.
+//
+// In contexts that only late parse `LateAttrParseExperimentalExt` attributes
+// (see `LateParsedAttrList::lateAttrParseExperimentalExtOnly()`)
+//
+// * If `-fexperimental-late-parse-attributes`
+// (`LangOpts.ExperimentalLateParseAttributes`) is enabled the attribute
+// will be late parsed.
+// * If `-fexperimental-late-parse-attributes`
+// (`LangOpts.ExperimentalLateParseAttributes`) is disabled the attribute
+// will **not** be late parsed (i.e parsed immediately).
+//
+// The following contexts are supported:
+//
+// * TODO: Add contexts here when they are implemented.
+//
delcypher wrote:
@AaronBallman
Is it ok to clarify that when the first use of `LateAttrParseExperimentalExt`
is landed? The first new context where this going to be allowed is late parsing
attributes on FieldDecls in C. However, I didn't think it made sense to mention
in the patch because none of the implementation is here to do that.
Or did you have something else in mind?
https://github.com/llvm/llvm-project/pull/88596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AMDGPU] Correctly determine the toolchain linker (PR #89803)
jhuber6 wrote: Note that this doesn't affect OpenMP or HIP. The former uses the `clang-linker-wrapper` while the latter calls `lld` directly. https://github.com/llvm/llvm-project/pull/89803 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AMDGPU] Correctly determine the toolchain linker (PR #89803)
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-backend-amdgpu
Author: Joseph Huber (jhuber6)
Changes
Summary:
The AMDGPU toolchain simply took the short name to get the link job
instead of using the common utilities that respect options like
`-fuse-ld`. Any linker that isn't `ld.lld` will fail, however we should
be able to override it.
---
Full diff: https://github.com/llvm/llvm-project/pull/89803.diff
2 Files Affected:
- (modified) clang/lib/Driver/ToolChains/AMDGPU.cpp (+1-2)
- (modified) clang/test/Driver/amdgpu-toolchain.c (+6)
``diff
diff --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 4e6362a0f40632..07965b487ea79b 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -617,8 +617,7 @@ void amdgpu::Linker::ConstructJob(Compilation &C, const
JobAction &JA,
const InputInfoList &Inputs,
const ArgList &Args,
const char *LinkingOutput) const {
-
- std::string Linker = getToolChain().GetProgramPath(getShortName());
+ std::string Linker = getToolChain().GetLinkerPath();
ArgStringList CmdArgs;
CmdArgs.push_back("--no-undefined");
CmdArgs.push_back("-shared");
diff --git a/clang/test/Driver/amdgpu-toolchain.c
b/clang/test/Driver/amdgpu-toolchain.c
index 4300e7e9f66705..d21ce857f3c57a 100644
--- a/clang/test/Driver/amdgpu-toolchain.c
+++ b/clang/test/Driver/amdgpu-toolchain.c
@@ -24,3 +24,9 @@
// RUN: -L. -fconvergent-functions %s 2>&1 | FileCheck -check-prefix=MCPU %s
// LTO: clang{{.*}} "-flto=full"{{.*}}"-fconvergent-functions"
// MCPU: ld.lld{{.*}}"-L."{{.*}}"-plugin-opt=mcpu=gfx906"
+
+// We do not suppor the BFD linker, but we should be able to override the
+// default even if it will error during linking.
+// RUN: %clang -### --target=amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
+// RUN: -fuse-ld=bfd %s 2>&1 | FileCheck -check-prefixes=LD %s
+// LD: ld.bfd"
``
https://github.com/llvm/llvm-project/pull/89803
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AMDGPU] Correctly determine the toolchain linker (PR #89803)
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/89803
Summary:
The AMDGPU toolchain simply took the short name to get the link job
instead of using the common utilities that respect options like
`-fuse-ld`. Any linker that isn't `ld.lld` will fail, however we should
be able to override it.
>From 9389f7831f89e201b09d13bda4e3852968718e32 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Apr 2024 12:46:09 -0500
Subject: [PATCH] [AMDGPU] Correctly determine the toolchain linker
Summary:
The AMDGPU toolchain simply took the short name to get the link job
instead of using the common utilities that respect options like
`-fuse-ld`. Any linker that isn't `ld.lld` will fail, however we should
be able to override it.
---
clang/lib/Driver/ToolChains/AMDGPU.cpp | 3 +--
clang/test/Driver/amdgpu-toolchain.c | 6 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 4e6362a0f40632..07965b487ea79b 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -617,8 +617,7 @@ void amdgpu::Linker::ConstructJob(Compilation &C, const
JobAction &JA,
const InputInfoList &Inputs,
const ArgList &Args,
const char *LinkingOutput) const {
-
- std::string Linker = getToolChain().GetProgramPath(getShortName());
+ std::string Linker = getToolChain().GetLinkerPath();
ArgStringList CmdArgs;
CmdArgs.push_back("--no-undefined");
CmdArgs.push_back("-shared");
diff --git a/clang/test/Driver/amdgpu-toolchain.c
b/clang/test/Driver/amdgpu-toolchain.c
index 4300e7e9f66705..d21ce857f3c57a 100644
--- a/clang/test/Driver/amdgpu-toolchain.c
+++ b/clang/test/Driver/amdgpu-toolchain.c
@@ -24,3 +24,9 @@
// RUN: -L. -fconvergent-functions %s 2>&1 | FileCheck -check-prefix=MCPU %s
// LTO: clang{{.*}} "-flto=full"{{.*}}"-fconvergent-functions"
// MCPU: ld.lld{{.*}}"-L."{{.*}}"-plugin-opt=mcpu=gfx906"
+
+// We do not suppor the BFD linker, but we should be able to override the
+// default even if it will error during linking.
+// RUN: %clang -### --target=amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
+// RUN: -fuse-ld=bfd %s 2>&1 | FileCheck -check-prefixes=LD %s
+// LD: ld.bfd"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)
mahtohappy wrote: Hi @ilovepi Sure. Looking at this. https://github.com/llvm/llvm-project/pull/89036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)
ilovepi wrote: I think we're seeing some build failures after this patch, and it isn't clear to me that this is a bug in the source, so I'd appreciate it if you could take a look. ``` FAILED: obj/src/media/audio/tools/signal_generator/signal_generator.signal_generator.cc.o ../../prebuilt/third_party/clang/custom/bin/clang++ -MD -MF obj/src/media/audio/tools/signal_generator/signal_generator.signal_generator.cc.o.d -D_LIBCPP_DISABLE_DEPRECATION_WARNINGS -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -DZX_ASSERT_LEVEL=2 -I../.. -Igen -Ifidling/gen/sdk/fidl/fuchsia.media/fuchsia.media/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.hardware.audio/fuchsia.hardware.audio/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.hardware.audio.signalprocessing/fuchsia.hardware.audio.signalprocessing/hlcpp -I../../sdk -Igen/sdk -I../../sdk/lib/fidl_base/include -I../../src/zircon/lib/zircon/include -Ifidling/gen/zircon/vdso/zx/zither/legacy_syscall_cdecl -I../../sdk/lib/fit/include -I../../sdk/lib/stdcompat/include -I../../sdk/lib/fit-promise/include -I../../sdk/lib/fidl/include -I../../zircon/system/ulib/zx/include -I../../zircon/system/ulib/async/include -I../../zircon/system/ulib/async-default/include -Ifidling/gen/sdk/fidl/fuchsia.images/fuchsia.images/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.sysmem/fuchsia.sysmem/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.io/fuchsia.io/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.unknown/fuchsia.unknown/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.images2/fuchsia.images2/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.math/fuchsia.math/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.media.audio/fuchsia.media.audio/hlcpp -Ifidling/gen/sdk/fidl/fuchsia.ultrasound/fuchsia.ultrasound/hlcpp -I../../sdk/lib/fidl/cpp/wire/include -I../../zircon/system/ulib/sync/include -I../../sdk/lib/fdio/include -I../../zircon/system/public -I../../zircon/system/ulib/fbl/include -I../../third_party/googletest/src/googletest/include -I../../zircon/system/ulib/affine/include -I../../zircon/system/ulib/zircon-internal/include -I../../third_party/re2/src -I../../zircon/system/ulib/async-loop/include -I../../zircon/system/ulib/fzl/include -fcolor-diagnostics -fcrash-diagnostics-dir=clang-crashreports -fcrash-diagnostics=all -gen-reproducer=error -ffp-contract=off --sysroot=gen/zircon/public/sysroot/cpp --target=x86_64-unknown-fuchsia -ffuchsia-api-level=4294967295 -march=x86-64-v2 -mtune=generic -mbranches-within-32B-boundaries -ffile-compilation-dir=. -no-canonical-prefixes -fno-omit-frame-pointer -momit-leaf-frame-pointer -fdata-sections -ffunction-sections -O0 -Xclang -debug-info-kind=constructor -g3 -grecord-gcc-switches -gdwarf-5 -gz=zstd -Wall -Wextra -Wconversion -Wextra-semi -Wimplicit-fallthrough -Wnewline-eof -Wstrict-prototypes -Wwrite-strings -Wno-sign-conversion -Wno-unused-parameter -Wnonportable-system-include-path -Wno-missing-field-initializers -Wno-extra-qualification -Wno-cast-function-type-strict -Wno-cast-function-type-mismatch -Wno-unknown-warning-option -Wno-deprecated-pragma -fvisibility=hidden -Werror -Wa,--fatal-warnings -ftrivial-auto-var-init=pattern -Wthread-safety -Wno-unknown-warning-option -Wno-thread-safety-reference-return -Wno-undef -fvisibility-inlines-hidden -std=c++17 -fno-exceptions -fno-rtti -ftemplate-backtrace-limit=0 -c ../../src/media/audio/tools/signal_generator/signal_generator.cc -o obj/src/media/audio/tools/signal_generator/signal_generator.signal_generator.cc.o In file included from ../../src/media/audio/tools/signal_generator/signal_generator.cc:4: In file included from ../../src/media/audio/tools/signal_generator/signal_generator.h:7: In file included from fidling/gen/sdk/fidl/fuchsia.media/fuchsia.media/hlcpp/fuchsia/media/cpp/fidl.h:6: In file included from ../../sdk/lib/fidl/cpp/internal/header.h:11: In file included from ../../sdk/lib/fit/include/lib/fit/function.h:9: In file included from ../../prebuilt/third_party/clang/custom/bin/../include/c++/v1/memory:937: In file included from ../../prebuilt/third_party/clang/custom/bin/../include/c++/v1/__memory/shared_ptr.h:32: ../../prebuilt/third_party/clang/custom/bin/../include/c++/v1/__memory/unique_ptr.h:627:10: error: no matching conversion for functional-style cast from 'double *' to 'unique_ptr' 627 | return unique_ptr<_Tp>(new _Up[__n]()); | ^~~ ../../src/media/audio/tools/signal_generator/signal_generator.cc:803:25: note: in instantiation of function template specialization 'std::make_unique' requested here 803 | input_history_ = std::make_unique(num_channels_); | ^ ../../prebuilt/third_party/clang/custom/bin/../include/c++/v1/__memory/unique_ptr.h:125:59: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'double *' to 'const unique_ptr' for 1st
[clang] [llvm] [ARM] Armv8-R does not require fp64 or neon. (PR #88287)
chrisnc wrote: Updated to fix the conflict with the ARM.td refactor. Ready for review. https://github.com/llvm/llvm-project/pull/88287 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)
delcypher wrote: @AaronBallman Thanks for the feedback > We should probably add a release note to tell users about the new command > line option, unless you think it makes more sense to do so after something > uses `LateAttrParseExperimentalExt`? I had a think about it and I'll add a release note but note that it doesn't do anything and then update the note in the PR that introduces the first use of `LateAttrParseExperimentalExt`. I think the commit history will be cleanest this way. > > One concern I have is that nothing is testing the new parsing behavior in > ParseDecl.cpp, but I presume that will get tested shortly by making use of > the new form? So we have this work-in-progress PR https://github.com/llvm/llvm-project/pull/87596 up that will use `LateAttrParseExperimentalExt`. Although we could have landed these two PRs as one I thought it would be better to split them up to make reviewing more manageable. https://github.com/llvm/llvm-project/pull/88596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [ARM] Armv8-R does not require fp64 or neon. (PR #88287)
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 0a3a3c29b599df0cc6e3066b3388151fdb313cc2 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
Specifying cortex-r52 still enables neon and fp64.
Change the default Armv8-R cpu from cortex-r52 to generic so it will not
enable these features by default.
Remove the GENERIC case from llvm/test/CodeGen/ARM/useaa.ll because it
is the same as the USEAA case now that AA is enabled for all targets.
---
clang/test/Driver/arm-cortex-cpus-1.c | 8
clang/test/Driver/arm-features.c | 2 +-
clang/test/Preprocessor/arm-target-features.c | 4 ++--
llvm/docs/ReleaseNotes.rst | 2 ++
llvm/include/llvm/TargetParser/ARMTargetParser.def | 4 ++--
llvm/lib/Target/ARM/ARMArchitectures.td| 5 ++---
llvm/lib/Target/ARM/ARMProcessors.td | 2 ++
llvm/test/Analysis/CostModel/ARM/arith.ll | 2 +-
llvm/test/Analysis/CostModel/ARM/cast.ll | 4 ++--
llvm/test/Analysis/CostModel/ARM/cast_ldst.ll | 4 ++--
llvm/test/Analysis/CostModel/ARM/cmps.ll | 4 ++--
llvm/test/Analysis/CostModel/ARM/divrem.ll | 2 +-
llvm/test/CodeGen/ARM/cortex-a57-misched-basic.ll | 2 +-
llvm/test/CodeGen/ARM/fpconv.ll| 4 ++--
llvm/test/CodeGen/ARM/half.ll | 4 ++--
llvm/test/CodeGen/ARM/useaa.ll | 6 +-
llvm/unittests/TargetParser/TargetParserTest.cpp | 4 ++--
17 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/clang/test/Driver/arm-cortex-cpus-1.c
b/clang/test/Driver/arm-cortex-cpus-1.c
index 25abbe1e3a8ad7..6f0b64910f9b07 100644
--- a/clang/test/Driver/arm-cortex-cpus-1.c
+++ b/clang/test/Driver/arm-cortex-cpus-1.c
@@ -153,23 +153,23 @@
// RUN: %clang -target armv8r-linux-gnueabi -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V8R %s
// RUN: %clang -target arm -march=armv8r -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V8R %s
// RUN: %clang -target arm -march=armv8-r -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V8R %s
-// CHECK-V8R: "-cc1"{{.*}} "-triple" "armv8r-{{.*}} "-target-cpu" "cortex-r52"
+// CHECK-V8R: "-cc1"{{.*}} "-triple" "armv8r-{{.*}} "-target-cpu" "generic"
// RUN: %clang -target armv8r-linux-gnueabi -mbig-endian -### -c %s 2>&1 |
FileCheck -check-prefix=CHECK-V8R-BIG %s
// RUN: %clang -target arm -march=armv8r -mbig-endian -### -c %s 2>&1 |
FileCheck -check-prefix=CHECK-V8R-BIG %s
// RUN: %clang -target arm -march=armv8-r -mbig-endian -### -c %s 2>&1 |
FileCheck -check-prefix=CHECK-V8R-BIG %s
-// CHECK-V8R-BIG: "-cc1"{{.*}} "-triple" "armebv8r-{{.*}} "-target-cpu"
"cortex-r52"
+// CHECK-V8R-BIG: "-cc1"{{.*}} "-triple" "armebv8r-{{.*}} "-target-cpu"
"generic"
// RUN: %clang -target armv8r-linux-gnueabi -mthumb -### -c %s 2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-V8R-THUMB %s
// RUN: %clang -target arm -march=armv8r -mthumb -### -c %s 2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-V8R-THUMB %s
-// CHECK-V8R-THUMB: "-cc1"{{.*}} "-triple" "thumbv8r-{{.*}} "-target-cpu"
"cortex-r52"
+// CHECK-V8R-THUMB: "-cc1"{{.*}} "-triple" "thumbv8r-{{.*}} "-target-cpu"
"generic"
// RUN: %clang -target armv8r-linux-gnueabi -mthumb -mbig-endian -### -c %s
2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-V8R-THUMB-BIG %s
// RUN: %clang -target arm -march=armv8r -mthumb -mbig-endian -### -c %s 2>&1
| \
// RUN: FileCheck -check-prefix=CHECK-V8R-THUMB-BIG %s
-// CHECK-V8R-THUMB-BIG: "-cc1"{{.*}} "-triple" "thumbebv8r-{{.*}}
"-target-cpu" "cortex-r52"
+// CHECK-V8R-THUMB-BIG: "-cc1"{{.*}} "-triple" "thumbebv8r-{{.*}}
"-target-cpu" "generic"
// RUN: %clang -mcpu=generic -target armv8 -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V8A-GENERIC %s
// RUN: %clang -mcpu=generic -target arm -march=armv8 -### -c %s 2>&1 |
FileCheck -check-prefix=CHECK-V8A-GENERIC %s
diff --git a/clang/test/Driver/arm-features.c b/clang/test/Driver/arm-features.c
index e043244f18a61f..eb424f5f61116b 100644
--- a/clang/test/Driver/arm-features.c
+++ b/clang/test/Driver/arm-features.c
@@ -74,7 +74,7 @@
// Check +crypto for M and R profiles:
//
// RUN: %clang -target arm-arm-none-eabi -march=armv8-r+crypto -### -c %s
2>&1 | FileCheck -check-prefix=CHECK-CRYPTO-R %s
-// CHECK-CRYPTO-R: "-cc1"{{.*}} "-target-cpu" "cortex-r52"{{.*}}
"-target-feature" "+sha2" "-target-feature" "+aes"
+// CHECK-CRYPTO-R: "-cc1"{{.*}} "-target-cpu" "generic"{{.*}}
"-target-feature" "+sha2" "-target-feature" "+aes"
// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.base+crypto -### -c %s
2>&1 | FileCheck -check-prefix=CHECK-NOCRYPTO5 %s
// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main+crypto -### -c %s
2>&1 | FileCheck -check-prefix=CHECK-NOCRYPTO5 %s
// RUN: %clang -target arm-arm-none-eabi -mcpu=cortex-m23+crypto -### -c %s
2>
[clang] [llvm] [CodeGen][i386] Move -mregparm storage earlier and fix Runtime calls (PR #89707)
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType *FTy, StringRef Name, } } setDSOLocal(F); + markRegisterParameterAttributes(F); efriedma-quic wrote: This really shouldn't work this way: we should go through CodeGenModule::SetLLVMFunctionAttributes to get all the correct attributes for a function. Unfortunately, that's a bit complicated in this context because you need to construct a CGFunctionInfo, and none of the callers currently do that. Which might be more work than you really want... CC @JonPsson1 @jdoerfert @jhuber6 https://github.com/llvm/llvm-project/pull/89707 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)
MaskRay wrote: My recollection of the past discussions is that we want users to switch to the new hierarchy. *BSD, Linux, and z/OS have migrated but I am not familiar with the Windows ecosystems. `ToolChain::getCompilerRT` detects both the old and new compiler-rt directory. Does it not work for PlayStation? > The old status quo has been that you can build the runtimes with either > layout, and clang will use whichever it finds, when invoking the linker. Yes. We try avoiding a CMake variable that customizes this detection. We need detection for both old and new file hierarchies for now. > The recent changes, #81037 and #87866, were (as far as I know) only intended > to change what is printed as error messages, when neither is found, to help > users correct their setup for the new style layout. But those changes also > seem to have unexpected effects in changing e.g. what gets emitted as > embedded directive, when the compiler doesn't see either of them at compile > time (with e.g. distributed build systems), while they might be available at > link time. This matches my understanding. I am not aware of the embedded directive? Do you embed a path to a compiler-rt library to the generated object files? I think while technically a new clang can use an old compiler-rt file hierarchy, technically it is unsupported: kinda like that a very old libc++ may not be built with a new Clang. I know that changing anything here is tricky as there may be users doing it and we perhaps need to wait a few releases to drop support for the old hierarchy. The intention is that eventually everyone will use the new file hierarchy. If we avoid hard-coded library names in compiler-generated relocatable files (just called "object files" on Windows?). there should be no distributed build system concern. I am fine if more path probing is added to help users migrate, but the end result (in a few years) should be everyone using a new file hierarchy. https://github.com/llvm/llvm-project/pull/89775 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
https://github.com/smanna12 edited https://github.com/llvm/llvm-project/pull/89801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC] Rename hlsl semantics to hlsl annotations (PR #89309)
https://github.com/bob80905 edited https://github.com/llvm/llvm-project/pull/89309 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Test explicit emission of dtors in runtime interface builder (NFC) (PR #89734)
Stefan =?utf-8?q?Gr=C3=A4nitz?= Message-ID: In-Reply-To: https://github.com/vgvassilev approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/89734 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Improve documented sampling profiler steps to best known methods (PR #88438)
https://github.com/chrulski-intel approved this pull request. https://github.com/llvm/llvm-project/pull/88438 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes +C++17 Feature Support +^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros to support standard library implementations of + ``std::hardware_destructive_interference_size`` and + ``std::hardware_constructive_interference_size``, respectively. These macros + are predefined in all C and C++ language modes. These macros can be + overridden on the command line with ``-D``, if desired. The values the macros cor3ntin wrote: My comment was only to not encourage using `-D`. The fact it's defined through a macro is really an implementation details, the macro is not meant to be user facing. As for whether we need something specific for ODR here... we certainly do not for other abi-impacting feature. you can already get into issues if the target is different in different TUs. Or if any define is different across TUs (C++ modules already catch that sort of ODR issues when use in alignas etc) I'm also not sure whether we usually warn when undocumented macros are used. https://github.com/llvm/llvm-project/pull/89446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
https://github.com/smanna12 edited https://github.com/llvm/llvm-project/pull/89801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] [NFC] Prevent null pointer dereference in Sema::InstantiateFunctionDefinition (PR #89801)
llvmbot wrote: @llvm/pr-subscribers-clang Author: None (smanna12) Changes …nctionDefinition In the lambda function within clang::Sema::InstantiateFunctionDefinition, the return value of a function that may return null is now checked before dereferencing to avoid potential null pointer dereference issues. --- Full diff: https://github.com/llvm/llvm-project/pull/89801.diff 1 Files Affected: - (modified) clang/lib/Sema/SemaTemplateInstantiateDecl.cpp (+2) ``diff diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp index 787a485e0b2f8c..2490ec4ca614a8 100644 --- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp +++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp @@ -5183,7 +5183,9 @@ void Sema::InstantiateFunctionDefinition(SourceLocation PointOfInstantiation, Function->setTypeSourceInfo(NewSI); ParmVarDecl *Parm = Function->getParamDecl(0); +assert(Parm && "First parameter not found in function declaration."); TypeSourceInfo *NewParmSI = IR.TransformType(Parm->getTypeSourceInfo()); +assert(NewParmSI && "Type transformation failed."); Parm->setType(NewParmSI->getType()); Parm->setTypeSourceInfo(NewParmSI); }; `` https://github.com/llvm/llvm-project/pull/89801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
