[PATCH] D96110: [X86] Pass to transform tdpbf16ps intrinsics to scalar operation.

[Bing Yu via Phabricator via cfe-commits]

yubing updated this revision to Diff 331766.
yubing added a comment.

address Pengfei's comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96110/new/

https://reviews.llvm.org/D96110

Files:
  llvm/lib/Target/X86/X86LowerAMXIntrinsics.cpp
  llvm/test/CodeGen/X86/AMX/amx-low-intrinsics.ll

Index: llvm/test/CodeGen/X86/AMX/amx-low-intrinsics.ll
===
--- llvm/test/CodeGen/X86/AMX/amx-low-intrinsics.ll
+++ llvm/test/CodeGen/X86/AMX/amx-low-intrinsics.ll
@@ -97,8 +97,8 @@
   ret void
 }
 
-define dso_local void @test_amx_dp(i16 signext %row, i16 signext %col, i16 signext %k, <256 x i32> %c, <256 x i32> %a, <256 x i32> %b, <256 x i32>* %vptr) #0 {
-; CHECK-LABEL: @test_amx_dp(
+define dso_local void @test_amx_dpbssd(i16 signext %row, i16 signext %col, i16 signext %k, <256 x i32> %c, <256 x i32> %a, <256 x i32> %b, <256 x i32>* %vptr) #0 {
+; CHECK-LABEL: @test_amx_dpbssd(
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[A_AMX:%.*]] = bitcast <256 x i32> [[A:%.*]] to x86_amx
 ; CHECK-NEXT:[[B_AMX:%.*]] = bitcast <256 x i32> [[B:%.*]] to x86_amx
@@ -172,6 +172,84 @@
   ret void
 }
 
+define dso_local void @test_amx_dpbf16ps(i16 signext %row, i16 signext %col, i16 signext %k, <256 x i32> %c, <256 x i32> %a, <256 x i32> %b, <256 x i32>* %vptr) #0 {
+; CHECK-LABEL: @test_amx_dpbf16ps(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[A_AMX:%.*]] = bitcast <256 x i32> [[A:%.*]] to x86_amx
+; CHECK-NEXT:[[B_AMX:%.*]] = bitcast <256 x i32> [[B:%.*]] to x86_amx
+; CHECK-NEXT:[[C_AMX:%.*]] = bitcast <256 x i32> [[C:%.*]] to x86_amx
+; CHECK-NEXT:[[TMP0:%.*]] = lshr i16 [[COL:%.*]], 2
+; CHECK-NEXT:[[TMP1:%.*]] = lshr i16 [[K:%.*]], 2
+; CHECK-NEXT:br label [[TDPBF16PS_SCALARIZE_ROWS_HEADER:%.*]]
+; CHECK:   tdpbf16ps.scalarize.rows.header:
+; CHECK-NEXT:[[TDPBF16PS_SCALARIZE_ROWS_IV:%.*]] = phi i16 [ 0, [[ENTRY:%.*]] ], [ [[TDPBF16PS_SCALARIZE_ROWS_STEP:%.*]], [[TDPBF16PS_SCALARIZE_ROWS_LATCH:%.*]] ]
+; CHECK-NEXT:[[VEC_C_PHI_ROW:%.*]] = phi <256 x i32> [ [[C]], [[ENTRY]] ], [ [[TMP21:%.*]], [[TDPBF16PS_SCALARIZE_ROWS_LATCH]] ]
+; CHECK-NEXT:[[VEC_D_PHI_ROW:%.*]] = phi <256 x i32> [ zeroinitializer, [[ENTRY]] ], [ [[TMP23:%.*]], [[TDPBF16PS_SCALARIZE_ROWS_LATCH]] ]
+; CHECK-NEXT:br label [[TDPBF16PS_SCALARIZE_ROWS_BODY:%.*]]
+; CHECK:   tdpbf16ps.scalarize.rows.body:
+; CHECK-NEXT:br label [[TDPBF16PS_SCALARIZE_COLS_HEADER:%.*]]
+; CHECK:   tdpbf16ps.scalarize.cols.header:
+; CHECK-NEXT:[[TDPBF16PS_SCALARIZE_COLS_IV:%.*]] = phi i16 [ 0, [[TDPBF16PS_SCALARIZE_ROWS_BODY]] ], [ [[TDPBF16PS_SCALARIZE_COLS_STEP:%.*]], [[TDPBF16PS_SCALARIZE_COLS_LATCH:%.*]] ]
+; CHECK-NEXT:[[VEC_C_PHI_COL:%.*]] = phi <256 x i32> [ [[VEC_C_PHI_ROW]], [[TDPBF16PS_SCALARIZE_ROWS_BODY]] ], [ [[TMP21]], [[TDPBF16PS_SCALARIZE_COLS_LATCH]] ]
+; CHECK-NEXT:[[VEC_D_PHI_COL:%.*]] = phi <256 x i32> [ [[VEC_D_PHI_ROW]], [[TDPBF16PS_SCALARIZE_ROWS_BODY]] ], [ [[TMP23]], [[TDPBF16PS_SCALARIZE_COLS_LATCH]] ]
+; CHECK-NEXT:[[TMP2:%.*]] = mul i16 [[TDPBF16PS_SCALARIZE_ROWS_IV]], 16
+; CHECK-NEXT:[[TMP3:%.*]] = add i16 [[TMP2]], [[TDPBF16PS_SCALARIZE_COLS_IV]]
+; CHECK-NEXT:br label [[TDPBF16PS_SCALARIZE_COLS_BODY:%.*]]
+; CHECK:   tdpbf16ps.scalarize.cols.body:
+; CHECK-NEXT:br label [[TDPBF16PS_SCALARIZE_INNER_HEADER:%.*]]
+; CHECK:   tdpbf16ps.scalarize.inner.header:
+; CHECK-NEXT:[[TDPBF16PS_SCALARIZE_INNER_IV:%.*]] = phi i16 [ 0, [[TDPBF16PS_SCALARIZE_COLS_BODY]] ], [ [[TDPBF16PS_SCALARIZE_INNER_STEP:%.*]], [[TDPBF16PS_SCALARIZE_INNER_LATCH:%.*]] ]
+; CHECK-NEXT:[[VEC_C_INNER_PHI:%.*]] = phi <256 x i32> [ [[VEC_C_PHI_COL]], [[TDPBF16PS_SCALARIZE_COLS_BODY]] ], [ [[TMP21]], [[TDPBF16PS_SCALARIZE_INNER_LATCH]] ]
+; CHECK-NEXT:br label [[TDPBF16PS_SCALARIZE_INNER_BODY:%.*]]
+; CHECK:   tdpbf16ps.scalarize.inner.body:
+; CHECK-NEXT:[[TMP4:%.*]] = mul i16 [[TDPBF16PS_SCALARIZE_ROWS_IV]], 16
+; CHECK-NEXT:[[TMP5:%.*]] = add i16 [[TMP4]], [[TDPBF16PS_SCALARIZE_INNER_IV]]
+; CHECK-NEXT:[[TMP6:%.*]] = mul i16 [[TDPBF16PS_SCALARIZE_INNER_IV]], 16
+; CHECK-NEXT:[[TMP7:%.*]] = add i16 [[TMP6]], [[TDPBF16PS_SCALARIZE_COLS_IV]]
+; CHECK-NEXT:[[TMP8:%.*]] = extractelement <256 x i32> [[VEC_C_INNER_PHI]], i16 [[TMP3]]
+; CHECK-NEXT:[[TMP9:%.*]] = bitcast i32 [[TMP8]] to float
+; CHECK-NEXT:[[TMP10:%.*]] = extractelement <256 x i32> [[A]], i16 [[TMP5]]
+; CHECK-NEXT:[[TMP11:%.*]] = bitcast i32 [[TMP10]] to <2 x i16>
+; CHECK-NEXT:[[TMP12:%.*]] = extractelement <256 x i32> [[B]], i16 [[TMP7]]
+; CHECK-NEXT:[[TMP13:%.*]] = bitcast i32 [[TMP12]] to <2 x i16>
+; CHECK-NEXT:[[TMP14:%.*]] = shufflevector <2 x i16> [[TMP11]], <2 x i16> zeroinitializer, <4 x i32> 
+; CHECK-NEXT:[[TMP15:%.*]] = bitcast <4 x i16> [[TMP14]] to <2 x float>
+; CHECK-NEXT:[[TMP16:%.*]] = shufflevector <2 x i16> [[TMP13]], <2 x i16> 

[PATCH] D96110: [X86] Pass to transform tdpbf16ps intrinsics to scalar operation.

[Bing Yu via Phabricator via cfe-commits]

yubing added inline comments.



Comment at: llvm/lib/Target/X86/X86LowerAMXIntrinsics.cpp:318-319
+// calculate idxa, idxb, idxc
+// %eltc = extractelement <256 x i32> %vec.c.inner.phi, i16 %idxc
+// %eltcf32 = bitcast i32 %eltc to float
+// %elta = extractelement <256 x i32> %veca, i16 %idxa

pengfei wrote:
> Can we create vecC with <256 x float>?
In fact, we are trying to find a bitcast whose operand is <256 x i32>, as shown 
in line229.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96110/new/

https://reviews.llvm.org/D96110

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Hongtao Yu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGfc1812a0ad75: [UniqueLinkageName] Use consistent checks when 
mangling symbo linkage name and… (authored by hoy).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98799/new/

https://reviews.llvm.org/D98799

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/unique-internal-linkage-names-dwarf.c


Index: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
===
--- clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
+++ clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
@@ -8,21 +8,48 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux -debug-info-kind=limited 
-dwarf-version=5 -funique-internal-linkage-names -emit-llvm -o -  %s | 
FileCheck %s --check-prefix=UNIQUE
 
 static int glob;
+// foo should be given a uniquefied name under -funique-internal-linkage-names.
 static int foo(void) {
   return glob;
 }
 
+// bar should not be given a uniquefied name under 
-funique-internal-linkage-names, 
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{
+  return glob + a;
+}
+
+// go should be given a uniquefied name under -funique-internal-linkage-names, 
even 
+// if its definition doesn't come with a valid prototype, but the declaration 
here
+// has a prototype.
+static int go(int);
+
 void baz() {
   foo();
+  bar(1);
+  go(2);
 }
 
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+
 // PLAIN: @glob = internal global i32
 // PLAIN: define internal i32 @foo()
+// PLAIN: define internal i32 @bar(i32 %a)
 // PLAIN: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // PLAIN: distinct !DISubprogram(name: "foo"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "bar"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "go"{{.*}})
 // PLAIN-NOT: linkageName:
 //
 // UNIQUE: @glob = internal global i32
 // UNIQUE: define internal i32 @_ZL3foov.[[MODHASH:__uniq.[0-9]+]]()
+// UNIQUE: define internal i32 @bar(i32 %a)
+// UNIQUE: define internal i32 @_ZL2goi.[[MODHASH]](i32 %a)
 // UNIQUE: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // UNIQUE: distinct !DISubprogram(name: "foo", linkageName: 
"_ZL3foov.[[MODHASH]]"{{.*}})
+// UNIQUE: distinct !DISubprogram(name: "go", linkageName: 
"_ZL2goi.[[MODHASH]]"{{.*}})
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3522,7 +3522,7 @@
llvm::DIScope *,
llvm::DINodeArray ,
llvm::DINode::DIFlags ) {
-  const auto *FD = cast(GD.getDecl());
+  const auto *FD = cast(GD.getCanonicalDecl().getDecl());
   Name = getFunctionName(FD);
   // Use mangled name as linkage name for C/C++ functions.
   if (FD->hasPrototype()) {
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -640,7 +640,7 @@
 
   // For C functions without prototypes, return false as their
   // names should not be mangled.
-  if (!FD->getType()->getAs())
+  if (!FD->hasPrototype())
 return false;
 
   if (isInternalLinkageDecl(ND))


Index: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
===
--- clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
+++ clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
@@ -8,21 +8,48 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux -debug-info-kind=limited -dwarf-version=5 -funique-internal-linkage-names -emit-llvm -o -  %s | FileCheck %s --check-prefix=UNIQUE
 
 static int glob;
+// foo should be given a uniquefied name under -funique-internal-linkage-names.
 static int foo(void) {
   return glob;
 }
 
+// bar should not be given a uniquefied name under -funique-internal-linkage-names, 
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{
+  return glob + a;
+}
+
+// go should be given a uniquefied name under -funique-internal-linkage-names, even 
+// if its definition doesn't come with a valid prototype, but the declaration here
+// has a prototype.
+static int go(int);
+
 void baz() {
   foo();
+  bar(1);
+  go(2);
 }
 
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+
 // PLAIN: @glob = internal global i32
 // PLAIN: define internal i32 @foo()
+// PLAIN: define internal i32 @bar(i32 %a)
 // PLAIN: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // PLAIN: distinct !DISubprogram(name: "foo"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "bar"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "go"{{.*}})
 // PLAIN-NOT: linkageName:
 //
 // UNIQUE: @glob = internal global i32
 // UNIQUE: define 

[clang] fc1812a - [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Hongtao Yu via cfe-commits]

Author: Hongtao Yu
Date: 2021-03-18T22:11:16-07:00
New Revision: fc1812a0ad757838b66aab57e1df720ec205a16a

URL: 
https://github.com/llvm/llvm-project/commit/fc1812a0ad757838b66aab57e1df720ec205a16a
DIFF: 
https://github.com/llvm/llvm-project/commit/fc1812a0ad757838b66aab57e1df720ec205a16a.diff

LOG: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name 
and debug linkage name.

C functions may be declared and defined in different prototypes like below. 
This patch unifies the checks for mangling names in symbol linkage name 
emission and debug linkage name emission so that the two names are consistent.

static int go(int);

static int go(a) int a;
{
  return a;
}

Test Plan:

Differential Revision: https://reviews.llvm.org/D98799

Added: 


Modified: 
clang/lib/AST/ItaniumMangle.cpp
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGen/unique-internal-linkage-names-dwarf.c

Removed: 




diff  --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index ba96fda6cd57..3e6e29207f08 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -640,7 +640,7 @@ bool ItaniumMangleContextImpl::isUniqueInternalLinkageDecl(
 
   // For C functions without prototypes, return false as their
   // names should not be mangled.
-  if (!FD->getType()->getAs())
+  if (!FD->hasPrototype())
 return false;
 
   if (isInternalLinkageDecl(ND))

diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 468c2b78b488..c80249a9c9fc 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3522,7 +3522,7 @@ void CGDebugInfo::collectFunctionDeclProps(GlobalDecl GD, 
llvm::DIFile *Unit,
llvm::DIScope *,
llvm::DINodeArray ,
llvm::DINode::DIFlags ) {
-  const auto *FD = cast(GD.getDecl());
+  const auto *FD = cast(GD.getCanonicalDecl().getDecl());
   Name = getFunctionName(FD);
   // Use mangled name as linkage name for C/C++ functions.
   if (FD->hasPrototype()) {

diff  --git a/clang/test/CodeGen/unique-internal-linkage-names-dwarf.c 
b/clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
index a3583426de79..e5d507e154ae 100644
--- a/clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
+++ b/clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
@@ -8,21 +8,48 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux -debug-info-kind=limited 
-dwarf-version=5 -funique-internal-linkage-names -emit-llvm -o -  %s | 
FileCheck %s --check-prefix=UNIQUE
 
 static int glob;
+// foo should be given a uniquefied name under -funique-internal-linkage-names.
 static int foo(void) {
   return glob;
 }
 
+// bar should not be given a uniquefied name under 
-funique-internal-linkage-names, 
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{
+  return glob + a;
+}
+
+// go should be given a uniquefied name under -funique-internal-linkage-names, 
even 
+// if its definition doesn't come with a valid prototype, but the declaration 
here
+// has a prototype.
+static int go(int);
+
 void baz() {
   foo();
+  bar(1);
+  go(2);
 }
 
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+
 // PLAIN: @glob = internal global i32
 // PLAIN: define internal i32 @foo()
+// PLAIN: define internal i32 @bar(i32 %a)
 // PLAIN: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // PLAIN: distinct !DISubprogram(name: "foo"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "bar"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "go"{{.*}})
 // PLAIN-NOT: linkageName:
 //
 // UNIQUE: @glob = internal global i32
 // UNIQUE: define internal i32 @_ZL3foov.[[MODHASH:__uniq.[0-9]+]]()
+// UNIQUE: define internal i32 @bar(i32 %a)
+// UNIQUE: define internal i32 @_ZL2goi.[[MODHASH]](i32 %a)
 // UNIQUE: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // UNIQUE: distinct !DISubprogram(name: "foo", linkageName: 
"_ZL3foov.[[MODHASH]]"{{.*}})
+// UNIQUE: distinct !DISubprogram(name: "go", linkageName: 
"_ZL2goi.[[MODHASH]]"{{.*}})



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98918: [clang][lit] Allow test cases to use the compiler that are used to compile Clang

[Ella Ma via Phabricator via cfe-commits]

OikawaKirie created this revision.
OikawaKirie added reviewers: thakis, steakhal.
OikawaKirie added a project: clang.
OikawaKirie requested review of this revision.
Herald added a subscriber: cfe-commits.

Required by D83660 . Test cases may want to 
use the host compiler to compile some mocks for the test case. This patch adds 
two substitutions `%host_cc` and `%host_cxx` to use the host compilers set via 
variable `CMAKE_C_COMPILER` and `CMAKE_CXX_COMPILER`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98918

Files:
  clang/test/lit.cfg.py
  clang/test/lit.site.cfg.py.in


Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -15,6 +15,7 @@
 config.clang_tools_dir = path(r"@CLANG_TOOLS_DIR@")
 config.host_triple = "@LLVM_HOST_TRIPLE@"
 config.target_triple = "@TARGET_TRIPLE@"
+config.host_cc = "@CMAKE_C_COMPILER@"
 config.host_cxx = "@CMAKE_CXX_COMPILER@"
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -92,6 +92,9 @@
 ('%hmaptool', "'%s' %s" % (config.python_executable,
  os.path.join(config.clang_tools_dir, 
'hmaptool'
 
+config.substitutions.append(('%host_cc', config.host_cc))
+config.substitutions.append(('%host_cxx', config.host_cxx))
+
 
 # Plugins (loadable modules)
 if config.has_plugins and config.llvm_plugin_ext:


Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -15,6 +15,7 @@
 config.clang_tools_dir = path(r"@CLANG_TOOLS_DIR@")
 config.host_triple = "@LLVM_HOST_TRIPLE@"
 config.target_triple = "@TARGET_TRIPLE@"
+config.host_cc = "@CMAKE_C_COMPILER@"
 config.host_cxx = "@CMAKE_CXX_COMPILER@"
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -92,6 +92,9 @@
 ('%hmaptool', "'%s' %s" % (config.python_executable,
  os.path.join(config.clang_tools_dir, 'hmaptool'
 
+config.substitutions.append(('%host_cc', config.host_cc))
+config.substitutions.append(('%host_cxx', config.host_cxx))
+
 
 # Plugins (loadable modules)
 if config.has_plugins and config.llvm_plugin_ext:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] d8ab7ad - Fix example in documentation.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-03-18T20:06:17-07:00
New Revision: d8ab7ad317305d80e405ffdb4f33983f743a6ca2

URL: 
https://github.com/llvm/llvm-project/commit/d8ab7ad317305d80e405ffdb4f33983f743a6ca2
DIFF: 
https://github.com/llvm/llvm-project/commit/d8ab7ad317305d80e405ffdb4f33983f743a6ca2.diff

LOG: Fix example in documentation.

Added: 


Modified: 
clang/include/clang/Basic/AttrDocs.td

Removed: 




diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 734cf026ae87..7f30c6300e91 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3057,8 +3057,8 @@ function by writing the attribute after the function type:
 
 .. code-block:: c++
 
-struct string_view {
-  // ...
+struct string {
+  // The returned pointer should not outlive ``*this``.
   const char *data() const [[clang::lifetimebound]];
 };
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5c689e4 - Improve documentation for the [[clang::lifetimebound]] attribute.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-03-18T19:58:21-07:00
New Revision: 5c689e4bb0473e08645547ddbf9874b5e2fa04d0

URL: 
https://github.com/llvm/llvm-project/commit/5c689e4bb0473e08645547ddbf9874b5e2fa04d0
DIFF: 
https://github.com/llvm/llvm-project/commit/5c689e4bb0473e08645547ddbf9874b5e2fa04d0.diff

LOG: Improve documentation for the [[clang::lifetimebound]] attribute.

Added: 


Modified: 
clang/include/clang/Basic/AttrDocs.td

Removed: 




diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index f73fbd08e3bf..734cf026ae87 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3032,10 +3032,39 @@ is retained by the return value of the annotated 
function
 (or, for a parameter of a constructor, in the value of the constructed object).
 It is only supported in C++.
 
-This attribute provides an experimental implementation of the facility
-described in the C++ committee paper `P0936R0 `_,
-and is subject to change as the design of the corresponding functionality
-changes.
+This attribute causes warnings to be produced if a temporary object does not
+live long enough. For example:
+
+.. code-block:: c++
+
+template
+const U _or_default(std::map , const T ,
+const U _value [[clang::lifetimebound]]);
+
+std::map m;
+// warning: temporary "bar"s that might be bound to local reference 'val'
+// will be destroyed at the end of the full-expression
+const std::string  = get_or_default(m, "foo"s, "bar"s);
+
+When applied to a reference parameter, the referenced object is assumed to be
+retained by the return value of the function. When applied to a non-reference
+parameter (for example, a pointer or a class type), all temporaries referenced
+by the parameter are assumed to be retained by the return value of the
+function.
+
+The attribute can be applied to the implicit ``this`` parameter of a member
+function by writing the attribute after the function type:
+
+.. code-block:: c++
+
+struct string_view {
+  // ...
+  const char *data() const [[clang::lifetimebound]];
+};
+
+This attribute is inspired by the C++ committee paper `P0936R0
+`_, but does not affect whether temporary objects
+have their lifetimes extended.
   }];
 }
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

@tra, so you think we should not do this? The user will see a link error late I 
assume, might be better.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98902/new/

https://reviews.llvm.org/D98902

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98912: Fix -Winteger-overflow to diagnose regardless of the top-level syntactic form.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith created this revision.
rsmith added a reviewer: vsapsai.
rsmith requested review of this revision.
Herald added a project: clang.

Previously -Winteger-overflow did not do any checking of expressions
whose top-level syntactic form wasn't one of a small list of special
cases. This meant that the warning would appear and disappear depending
on enclosing syntax.

Additionally, if constant evaluation hit a case that it didn't
understand, it would often bail out without visiting subexpressions, so
we wouldn't see warnings on overflow in subexpressions depending on the
form of intervening expressions.

We now walk all evaluated subexpressions of a particular expression when
checking for overflow, and evaluate subtrees rooted on each operation
that might overflow. If such evaluation hits an unevaluatable
subexpression, we switch back to walking the AST looking for
subexpressions to evaluate.

The extra evaluation here also exposed an issue where casts between
complex and fixed-point types would create bogus AST nodes using
CK_IntegralCast, which would lead to the constant evaluator asserting.
That's fixed here too.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98912

Files:
  clang/include/clang/AST/EvaluatedExprVisitor.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/Sema/integer-overflow.c
  clang/test/SemaCXX/integer-overflow.cpp

Index: clang/test/SemaCXX/integer-overflow.cpp
===
--- clang/test/SemaCXX/integer-overflow.cpp
+++ clang/test/SemaCXX/integer-overflow.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -std=gnu++98 -triple x86_64-pc-linux-gnu
-// RUN: %clang_cc1 %s -verify -fsyntax-only -std=gnu++2a -triple x86_64-pc-linux-gnu
+// RUN: %clang_cc1 %s -verify -fsyntax-only -std=gnu++98 -triple x86_64-pc-linux-gnu -fcxx-exceptions
+// RUN: %clang_cc1 %s -verify -fsyntax-only -std=gnu++2a -triple x86_64-pc-linux-gnu -fcxx-exceptions
 
 typedef unsigned long long uint64_t;
 typedef unsigned int uint32_t;
@@ -188,6 +188,20 @@
 
 // expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
   (void)f2(0, f0(4608 * 1024 * 1024));
+
+#if __cplusplus >= 201103L
+// expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
+  uint64_t n = uint64_t{f0(4608 * 1024 * 1024)};
+#endif
+
+// expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
+  throw 4608 * 1024 * 1024;
+
+  // No warning, UB is not reachable.
+  void(1 ? 1 : 4608 * 1024 * 1024);
+
+// expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
+  void(0 ? 1 : 4608 * 1024 * 1024);
 }
 
 // Tests that ensure that evaluation-for-overflow of random expressions doesn't
Index: clang/test/Sema/integer-overflow.c
===
--- clang/test/Sema/integer-overflow.c
+++ clang/test/Sema/integer-overflow.c
@@ -6,6 +6,7 @@
 int array64[sizeof(uint64_t) == 8 ? 1 : -1];
 int array32[sizeof(uint32_t) == 4 ? 1 : -1];
 int arrayint[sizeof(int) < sizeof(uint64_t) ? 1 : -1];
+extern int array[];
 
 uint64_t f0(uint64_t);
 uint64_t f1(uint64_t, uint32_t);
@@ -39,6 +40,10 @@
 // expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
   overflow =  0 ? 0 : 4608 * 1024 * 1024;
 
+  if (i == 1)
+// expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
+return array[4608 * 1024 * 1024];
+
 // expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
   if (4608 * 1024 * 1024)
 return 0;
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -6381,9 +6381,15 @@
   return QualType();
 }
 
-LHS = ImpCastExprToType(LHS.get(), ResTy, PrepareScalarCast(LHS, ResTy));
-RHS = ImpCastExprToType(RHS.get(), ResTy, PrepareScalarCast(RHS, ResTy));
+CastKind LHSCK = PrepareScalarCast(LHS, ResTy);
+if (LHS.isInvalid())
+  return QualType();
+CastKind RHSCK = PrepareScalarCast(RHS, ResTy);
+if (RHS.isInvalid())
+  return QualType();
 
+LHS = ImpCastExprToType(LHS.get(), ResTy, LHSCK);
+RHS = ImpCastExprToType(RHS.get(), ResTy, RHSCK);
 return ResTy;
   }
 
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -7122,7 +7122,8 @@
   Diag(Src.get()->getExprLoc(),
diag::err_unimplemented_conversion_with_fixed_point_type)
   << DestTy;
-  return CK_IntegralCast;
+  Src = ExprError();
+  return CK_Dependent;
 case Type::STK_CPointer:
 case 

[PATCH] D98493: [WoA][MSVC] Use default linker setting in MSVC-compatible driver

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

This is still broken, we're seeing multiple failing tests, can we please revert 
this change for now?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98493/new/

https://reviews.llvm.org/D98493

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97902: [docs] Improve documentation of -B and --gcc-toolchain

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 331738.
MaskRay retitled this revision from "[Driver] Clarify --gcc-toolchain" to 
"[docs] Improve documentation of -B and --gcc-toolchain".
MaskRay added a comment.

Rebase on D97993 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97902/new/

https://reviews.llvm.org/D97902

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -601,8 +601,14 @@
 def _DASH_DASH : Option<["--"], "", KIND_REMAINING_ARGS>,
 Flags<[NoXarchOption, CoreOption]>;
 def A : JoinedOrSeparate<["-"], "A">, Flags<[RenderJoined]>, 
Group;
-def B : JoinedOrSeparate<["-"], "B">, MetaVarName<"">,
-HelpText<"Add  to search path for binaries and object files used 
implicitly">;
+def B : JoinedOrSeparate<["-"], "B">, MetaVarName<"">,
+HelpText<"Search $prefix/$triple-$file and $prefix$file for executables, 
libraries, "
+"includes, and data files used by the compiler. $prefix may or may not be 
a directory">;
+def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
+  HelpText<"Search for GCC installation in the specified directory on targets 
which commonly use GCC. "
+  "The directory usually contains 'lib{,32,64}/gcc{,-cross}/$triple' and 
'include'. If specified, "
+  "sysroot is skipped for GCC detection. Note: executables (e.g. ld) used by 
the compiler are not "
+  "overridden by the selected GCC installation">;
 def CC : Flag<["-"], "CC">, Flags<[CC1Option]>, Group,
 HelpText<"Include comments from within macros in preprocessed output">,
 MarshallingInfoFlag>;
@@ -3671,8 +3677,6 @@
   MarshallingInfoFlag>;
 def mcpu_EQ_QUESTION : Flag<["-"], "mcpu=?">, Alias;
 def mtune_EQ_QUESTION : Flag<["-"], "mtune=?">, Alias;
-def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
-  HelpText<"Use the gcc toolchain at the given directory">;
 def time : Flag<["-"], "time">,
   HelpText<"Time individual commands">;
 def traditional_cpp : Flag<["-", "--"], "traditional-cpp">, Flags<[CC1Option]>,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -18,9 +18,9 @@
 
 
 .. program:: clang
-.. option:: -B, --prefix , --prefix=
+.. option:: -B, --prefix , --prefix=
 
-Add  to search path for binaries and object files used implicitly
+Search $prefix/$triple-$file and $prefix$file for executables, libraries, 
includes, and data files used by the compiler. $prefix may or may not be a 
directory
 
 .. option:: -F
 
@@ -256,7 +256,7 @@
 
 .. option:: --gcc-toolchain=, -gcc-toolchain 
 
-Use the gcc toolchain at the given directory
+Search for GCC installation in the specified directory on targets which 
commonly use GCC. The directory usually contains 
'lib{,32,64}/gcc{,-cross}/$triple' and 'include'. If specified, sysroot is 
skipped for GCC detection. Note: executables (e.g. ld) used by the compiler are 
not overridden by the selected GCC installation
 
 .. option:: -gcodeview
 


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -601,8 +601,14 @@
 def _DASH_DASH : Option<["--"], "", KIND_REMAINING_ARGS>,
 Flags<[NoXarchOption, CoreOption]>;
 def A : JoinedOrSeparate<["-"], "A">, Flags<[RenderJoined]>, Group;
-def B : JoinedOrSeparate<["-"], "B">, MetaVarName<"">,
-HelpText<"Add  to search path for binaries and object files used implicitly">;
+def B : JoinedOrSeparate<["-"], "B">, MetaVarName<"">,
+HelpText<"Search $prefix/$triple-$file and $prefix$file for executables, libraries, "
+"includes, and data files used by the compiler. $prefix may or may not be a directory">;
+def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
+  HelpText<"Search for GCC installation in the specified directory on targets which commonly use GCC. "
+  "The directory usually contains 'lib{,32,64}/gcc{,-cross}/$triple' and 'include'. If specified, "
+  "sysroot is skipped for GCC detection. Note: executables (e.g. ld) used by the compiler are not "
+  "overridden by the selected GCC installation">;
 def CC : Flag<["-"], "CC">, Flags<[CC1Option]>, Group,
 HelpText<"Include comments from within macros in preprocessed output">,
 MarshallingInfoFlag>;
@@ -3671,8 +3677,6 @@
   MarshallingInfoFlag>;
 def mcpu_EQ_QUESTION : Flag<["-"], "mcpu=?">, Alias;
 def mtune_EQ_QUESTION : Flag<["-"], "mtune=?">, Alias;
-def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
-  HelpText<"Use the gcc toolchain 

[PATCH] D97993: [Driver] Suppress GCC detection under -B

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:76-77
+- ``-B `` (when ``>`` is a directory) used to detect GCC
+  installations under .  This behavior is incompatible with GCC,
+  causes interop issues with ``--gcc-toolchain``, and is thus dropped. Specify
+  ``--gcc-toolchain=`` instead.

nickdesaulniers wrote:
> The first time I read `This behavior is incompatible with GCC,  causes 
> interop issues with ``--gcc-toolchain``, and is thus dropped.` I thought you 
> were dropping the `-B` flag entirely.  I see now you're referring to `This 
> behavior` being dropped, but maybe this can be reworded to avoid confusing 
> others?
Thanks for the feedback. Updated.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:1911
+  SmallVector Prefixes;
+  if (TargetTriple.isAndroid())
+Prefixes.assign(D.PrefixDirs.begin(), D.PrefixDirs.end());

nickdesaulniers wrote:
> MaskRay wrote:
> > srhines wrote:
> > > danalbert wrote:
> > > > I'm not entirely sure what `D.PrefixDirs` represents so maybe Android 
> > > > doesn't need this either.
> > > > 
> > > > The behavior the NDK depends on is being able to find tools co-located 
> > > > with the Clang driver location. Aside from `as`, these are all LLVM 
> > > > tools (lld and co).
> > > > 
> > > > The sysroot is expected to be in `$CLANG/../sysroot`. All our headers, 
> > > > libraries (aside from libgcc/libatomic), and CRT objects are located 
> > > > there.
> > > > 
> > > > The clang driver install location is expected to also be a GCC install 
> > > > directory, so libgcc/libatomic are expected at 
> > > > `$CLANG/../lib/gcc/$TRIPLE/$GCC_VERSION`.
> > > > 
> > > > Typical usage for the NDK does not involve `-gcc-toolchain` or `-B` at 
> > > > all.
> > > > 
> > > > If I've understood correctly, your change can be applied to Android as 
> > > > well without breaking any of those behaviors. @srhines will need to 
> > > > comment on whether the Android platform build needs this, but aiui 
> > > > anyone depending on this behavior just needs to fix their build to use 
> > > > `-gcc-toolchain` where they were previously using `-B`.
> > > > 
> > > > Of course, I can't speak to what our users with custom build systems 
> > > > that don't follow our docs might be doing.
> > > From a look at Android's build system, we are using `-B` but we don't 
> > > currently use `--sysroot` or `-gcc-toolchain` for platform builds. I did 
> > > try a build with this patch (but not retaining the Android-specific 
> > > part), and it still worked fine. From looking at the constructed command 
> > > lines, the platform build generally adds the appropriate include paths, 
> > > library paths, and invokes separate tools directly, so we aren't relying 
> > > on `-B` for this purpose. Cleaning this up is on my list of things to 
> > > eventually do, but as I see it, we're not going to be negatively impacted 
> > > even with the more aggressive version of this patch.
> > > 
> > > > Of course, I can't speak to what our users with custom build systems 
> > > > that don't follow our docs might be doing.
> > > I do share this concern a bit, but it's very hard for me to quantify how 
> > > hard it would be for someone to just adapt their build if we did make a 
> > > more aggressive change here. If it's really as easy as passing 
> > > `-gcc-toolchain`, then perhaps that would be fine for the Release Notes.
> > It should be as easy as passing `--gcc-toolchain`. I edited the summary to 
> > state more clearly that the current behavior actually makes interop with 
> > `--gcc-toolchain` difficult.
> > 
> > I'll not touch Android to restrict the influence to regular Linux 
> > distributions in this patch.
> > Android can be fixed separately (which require two test changes.)
> > I did try a build with this patch (but not retaining the Android-specific 
> > part), and it still worked fine.
> 
> Then we should drop this Android specific part.  If @srhines tested it 
> without, there's no issue.
> 
> > From a look at Android's build system, we are using -B but we don't 
> > currently use --sysroot or -gcc-toolchain for platform builds
> 
> We're probably mostly using LLVM utils anyways.
> 
> > It should be as easy as passing --gcc-toolchain.
> 
> Yep.
Thank for the feedback that Android does not need this. I was unsure so I tried 
to keep Android unchanged. Seems that the special case is not actually needed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97993/new/

https://reviews.llvm.org/D97993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97993: [Driver] Suppress GCC detection under -B

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 331736.
MaskRay marked 5 inline comments as done.
MaskRay retitled this revision from "[Driver] Suppress GCC detection under -B 
for non-Android" to "[Driver] Suppress GCC detection under -B".
MaskRay edited the summary of this revision.
MaskRay added a comment.

Reword. Drop the special case for Android as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97993/new/

https://reviews.llvm.org/D97993

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/android-ndk-standalone.cpp
  clang/test/Driver/android-standalone.cpp
  clang/test/Driver/gcc-toolchain.cpp
  clang/test/Driver/print-multi-directory.c

Index: clang/test/Driver/print-multi-directory.c
===
--- clang/test/Driver/print-multi-directory.c
+++ clang/test/Driver/print-multi-directory.c
@@ -19,7 +19,7 @@
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>/dev/null \
 // RUN: -target arm-linux-androideabi21 \
 // RUN: -mthumb \
-// RUN: -B%S/Inputs/basic_android_ndk_tree \
+// RUN: --gcc-toolchain=%S/Inputs/basic_android_ndk_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
 // RUN: -print-multi-directory \
 // RUN:   | FileCheck --match-full-lines --check-prefix=CHECK-ARM-MULTILIBS %s
Index: clang/test/Driver/gcc-toolchain.cpp
===
--- clang/test/Driver/gcc-toolchain.cpp
+++ clang/test/Driver/gcc-toolchain.cpp
@@ -29,3 +29,14 @@
 // CHECK: "{{[^"]*}}/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5{{/|}}crtbegin.o"
 // CHECK: "-L[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5"
 // CHECK: "-L[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../.."
+
+/// Test we don't detect GCC installation under -B.
+// RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
+// RUN:   --target=aarch64-suse-linux --gcc-toolchain=%S/Inputs/opensuse_42.2_aarch64_tree/usr | \
+// RUN:   FileCheck %s --check-prefix=AARCH64
+// RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
+// RUN:   --target=aarch64-suse-linux -B%S/Inputs/opensuse_42.2_aarch64_tree/usr | \
+// RUN:   FileCheck %s --check-prefix=NO_AARCH64
+
+// AARCH64:Inputs{{[^"]+}}aarch64-suse-linux/{{[^"]+}}crt1.o"
+// NO_AARCH64-NOT: Inputs{{[^"]+}}aarch64-suse-linux/{{[^"]+}}crt1.o"
Index: clang/test/Driver/android-standalone.cpp
===
--- clang/test/Driver/android-standalone.cpp
+++ clang/test/Driver/android-standalone.cpp
@@ -3,7 +3,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target arm-linux-androideabi -stdlib=libstdc++ \
-// RUN: -B%S/Inputs/basic_android_tree \
+// RUN: --gcc-toolchain=%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck  %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
@@ -18,7 +18,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target aarch64-linux-android -stdlib=libstdc++ \
-// RUN: -B%S/Inputs/basic_android_tree \
+// RUN: --gcc-toolchain=%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-AARCH64 %s
 // CHECK-AARCH64: {{.*}}clang{{.*}}" "-cc1"
@@ -33,7 +33,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target arm64-linux-android -stdlib=libstdc++ \
-// RUN: -B%S/Inputs/basic_android_tree \
+// RUN: --gcc-toolchain=%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM64 %s
 // CHECK-ARM64: {{.*}}clang{{.*}}" "-cc1"
@@ -49,7 +49,7 @@
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
 // RUN: -mips32 -stdlib=libstdc++ \
-// RUN: -B%S/Inputs/basic_android_tree \
+// RUN: --gcc-toolchain=%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-MIPS %s
 // CHECK-MIPS: {{.*}}clang{{.*}}" "-cc1"
@@ -65,7 +65,7 @@
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
 // RUN: -march=mips32 -mips32r2 -stdlib=libstdc++ \
-// RUN: -B%S/Inputs/basic_android_tree \
+// RUN: --gcc-toolchain=%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-MIPSR2 %s
 // CHECK-MIPSR2: {{.*}}clang{{.*}}" "-cc1"
@@ -81,7 +81,7 @@
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
 // RUN: -mips32 -march=mips32r2 -stdlib=libstdc++ \
-// RUN: -B%S/Inputs/basic_android_tree \
+// RUN: 

[PATCH] D98881: [RISCV] Fix mcount name for Linux

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added a comment.

Such a diff does not look too bad:

  diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
  index 539466c4f678..c32972c1e04e 100644
  --- a/clang/lib/Basic/Targets/OSTargets.h
  +++ b/clang/lib/Basic/Targets/OSTargets.h
  @@ -256,6 +256,8 @@ public:
   case llvm::Triple::ppcle:
   case llvm::Triple::ppc64:
   case llvm::Triple::ppc64le:
  +case llvm::Triple::riscv32:
  +case llvm::Triple::riscv64:
 this->MCountName = "_mcount";
 break;
   case llvm::Triple::arm:
  @@ -488,6 +490,8 @@ public:
   case llvm::Triple::ppc:
   case llvm::Triple::ppc64:
   case llvm::Triple::ppc64le:
  +case llvm::Triple::riscv32:
  +case llvm::Triple::riscv64:
   case llvm::Triple::sparcv9:
 this->MCountName = "_mcount";
 break;
  @@ -885,7 +889,14 @@ protected:
   public:
 FuchsiaTargetInfo(const llvm::Triple , const TargetOptions )
 : OSTargetInfo(Triple, Opts) {
  -this->MCountName = "__mcount";
  +switch (Triple.getArch()) {
  +case llvm::Triple::riscv32:
  +case llvm::Triple::riscv64:
  +  break;
  +default:
  +  this->MCountName = "__mcount";
  +  break;
  +}
   this->TheCXXABI.set(TargetCXXABI::Fuchsia);
 }
   };
  diff --git a/clang/lib/Basic/Targets/RISCV.h b/clang/lib/Basic/Targets/RISCV.h
  index abae51e75a19..8df6e05ebcd5 100644
  --- a/clang/lib/Basic/Targets/RISCV.h
  +++ b/clang/lib/Basic/Targets/RISCV.h
  @@ -59,6 +59,7 @@ public:
   WCharType = SignedInt;
   WIntType = UnsignedInt;
   HasRISCVVTypes = true;
  +MCountName = "_mcount";
 }
   
 bool setCPU(const std::string ) override {
  diff --git a/clang/test/CodeGen/mcount.c b/clang/test/CodeGen/mcount.c
  index 649f0b56949d..2883a6370d34 100644
  --- a/clang/test/CodeGen/mcount.c
  +++ b/clang/test/CodeGen/mcount.c
  @@ -12,6 +12,14 @@
   // RUN: %clang_cc1 -pg -triple mipsel-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
   // RUN: %clang_cc1 -pg -triple mips64-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
   // RUN: %clang_cc1 -pg -triple mips64el-unknown-gnu-linux -emit-llvm -o - %s 
| FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv32 -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv64 -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv32-linux -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv64-linux -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv32-freebsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv64-freebsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv64-fuschia -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
  +// RUN: %clang_cc1 -pg -triple riscv64-openbsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
   // RUN: %clang_cc1 -pg -triple powerpc-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
   // RUN: %clang_cc1 -pg -triple powerpc64-netbsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
   // RUN: %clang_cc1 -pg -triple powerpc64le-netbsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98881/new/

https://reviews.llvm.org/D98881

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98904: Instantiate static constexpr data members on MS ABI.

[Zoe Carver via Phabricator via cfe-commits]

zoecarver added a comment.

> So. I think the status quo is OK but not great; we accept invalid code, in 
> the name of MSVC compatibility, that MSVC doesn't accept. I don't think 
> following MSVC would be a good thing, as that'd lead to our rejecting valid 
> code (that MSVC also rejects but that we currently accept). If we can split 
> the difference, and eagerly instantiate only in the case where the language 
> rules say the variable is not inline but MSVC says it is inline, that would 
> be an improvement, but it seems awkward as I think we've already lost the 
> relevant information by the point we need to make the decision.

I agree. And, I think you're right about the fact that we've unfortunately lost 
the relevant info at the point. Even though it's a C++17 extension, someone 
could make `value` inline explicitly (as is done in your Godbolt) and we'd 
still error pre-c++17. Based on that, I'm going to close this for now. But if 
you (or someone else) thinks of another solution, or reason that it would be 
good to move forward with this, I'd be happy to re-open it and continue to work 
on it.

Thanks for all the help with this bug and patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98904/new/

https://reviews.llvm.org/D98904

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98904: Instantiate static constexpr data members on MS ABI.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D98904#2636109 , @zoecarver wrote:

> I think we'd basically need a condition that says: `is-microsoft && 
> less-than-cxx17 && is-constexpr && is-static-data-member`.

Yes.

Looking back over the history a bit here, https://reviews.llvm.org/D47956 
suggests that treating these static constexpr data members as implicitly inline 
matches the MS behavior. And I don't think I can disprove that: considering 
https://godbolt.org/z/7z6T3q, it looks like MSVC gets the "don't instantiate 
the initializer of an inline static data member with the class" rule wrong in 
general, which (perhaps by chance alone) means that MSVC doesn't have the same 
accepts-invalid bug that we have, but only because it's being hidden by a 
rejects-valid bug for the same case!

So. I think the status quo is OK but not great; we accept invalid code, in the 
name of MSVC compatibility, that MSVC doesn't accept. I don't think following 
MSVC would be a good thing, as that'd lead to our rejecting valid code (that 
MSVC also rejects but that we currently accept). If we can split the 
difference, and eagerly instantiate only in the case where the language rules 
say the variable is not inline but MSVC says it is inline, that would be an 
improvement, but it seems awkward as I think we've already lost the relevant 
information by the point we need to make the decision.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98904/new/

https://reviews.llvm.org/D98904

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97993: [Driver] Suppress GCC detection under -B for non-Android

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers requested changes to this revision.
nickdesaulniers added a comment.
This revision now requires changes to proceed.

Let's drop the Android part, too? Update the description (commit message), too?

I checked our oldest supported kernel version, and we don't use `-B` either: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=v4.4.262#n606




Comment at: clang/docs/ReleaseNotes.rst:75
 - -Wshadow now also checks for shadowed structured bindings
+- ``-B `` (when ``>`` is a directory) used to detect GCC
+  installations under .  This behavior is incompatible with GCC,

is there an extra `>` in the second occurrence of `prefix` on this line?



Comment at: clang/docs/ReleaseNotes.rst:76-77
+- ``-B `` (when ``>`` is a directory) used to detect GCC
+  installations under .  This behavior is incompatible with GCC,
+  causes interop issues with ``--gcc-toolchain``, and is thus dropped. Specify
+  ``--gcc-toolchain=`` instead.

The first time I read `This behavior is incompatible with GCC,  causes interop 
issues with ``--gcc-toolchain``, and is thus dropped.` I thought you were 
dropping the `-B` flag entirely.  I see now you're referring to `This behavior` 
being dropped, but maybe this can be reworded to avoid confusing others?



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:1911
+  SmallVector Prefixes;
+  if (TargetTriple.isAndroid())
+Prefixes.assign(D.PrefixDirs.begin(), D.PrefixDirs.end());

MaskRay wrote:
> srhines wrote:
> > danalbert wrote:
> > > I'm not entirely sure what `D.PrefixDirs` represents so maybe Android 
> > > doesn't need this either.
> > > 
> > > The behavior the NDK depends on is being able to find tools co-located 
> > > with the Clang driver location. Aside from `as`, these are all LLVM tools 
> > > (lld and co).
> > > 
> > > The sysroot is expected to be in `$CLANG/../sysroot`. All our headers, 
> > > libraries (aside from libgcc/libatomic), and CRT objects are located 
> > > there.
> > > 
> > > The clang driver install location is expected to also be a GCC install 
> > > directory, so libgcc/libatomic are expected at 
> > > `$CLANG/../lib/gcc/$TRIPLE/$GCC_VERSION`.
> > > 
> > > Typical usage for the NDK does not involve `-gcc-toolchain` or `-B` at 
> > > all.
> > > 
> > > If I've understood correctly, your change can be applied to Android as 
> > > well without breaking any of those behaviors. @srhines will need to 
> > > comment on whether the Android platform build needs this, but aiui anyone 
> > > depending on this behavior just needs to fix their build to use 
> > > `-gcc-toolchain` where they were previously using `-B`.
> > > 
> > > Of course, I can't speak to what our users with custom build systems that 
> > > don't follow our docs might be doing.
> > From a look at Android's build system, we are using `-B` but we don't 
> > currently use `--sysroot` or `-gcc-toolchain` for platform builds. I did 
> > try a build with this patch (but not retaining the Android-specific part), 
> > and it still worked fine. From looking at the constructed command lines, 
> > the platform build generally adds the appropriate include paths, library 
> > paths, and invokes separate tools directly, so we aren't relying on `-B` 
> > for this purpose. Cleaning this up is on my list of things to eventually 
> > do, but as I see it, we're not going to be negatively impacted even with 
> > the more aggressive version of this patch.
> > 
> > > Of course, I can't speak to what our users with custom build systems that 
> > > don't follow our docs might be doing.
> > I do share this concern a bit, but it's very hard for me to quantify how 
> > hard it would be for someone to just adapt their build if we did make a 
> > more aggressive change here. If it's really as easy as passing 
> > `-gcc-toolchain`, then perhaps that would be fine for the Release Notes.
> It should be as easy as passing `--gcc-toolchain`. I edited the summary to 
> state more clearly that the current behavior actually makes interop with 
> `--gcc-toolchain` difficult.
> 
> I'll not touch Android to restrict the influence to regular Linux 
> distributions in this patch.
> Android can be fixed separately (which require two test changes.)
> I did try a build with this patch (but not retaining the Android-specific 
> part), and it still worked fine.

Then we should drop this Android specific part.  If @srhines tested it without, 
there's no issue.

> From a look at Android's build system, we are using -B but we don't currently 
> use --sysroot or -gcc-toolchain for platform builds

We're probably mostly using LLVM utils anyways.

> It should be as easy as passing --gcc-toolchain.

Yep.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97993/new/

https://reviews.llvm.org/D97993

___
cfe-commits 

[PATCH] D98907: [WebAssembly] Remove experimental instructions from wasm_simd128.h

[Thomas Lively via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcbab2cd6bf77: [WebAssembly] Remove experimental instructions 
from wasm_simd128.h (authored by tlively).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98907/new/

https://reviews.llvm.org/D98907

Files:
  clang/lib/Headers/wasm_simd128.h


Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -825,18 +825,6 @@
   return (v128_t)(-(__u64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_any_true(v128_t __a) {
-  return __builtin_wasm_any_true_i64x2((__i64x2)__a);
-}
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_all_true(v128_t __a) {
-  return __builtin_wasm_all_true_i64x2((__i64x2)__a);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_i64x2_shl(v128_t __a,
int32_t __b) {
   return (v128_t)((__i64x2)__a << (int64_t)__b);
@@ -879,24 +867,6 @@
   return (v128_t)__builtin_wasm_sqrt_f32x4((__f32x4)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_add(v128_t __a,
v128_t __b) {
   return (v128_t)((__f32x4)__a + (__f32x4)__b);
@@ -949,24 +919,6 @@
   return (v128_t)__builtin_wasm_sqrt_f64x2((__f64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f64x2((__f64x2)__a, (__f64x2)__b,
-   (__f64x2)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f64x2((__f64x2)__a, (__f64x2)__b,
-   (__f64x2)__c);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_add(v128_t __a,
v128_t __b) {
   return (v128_t)((__f64x2)__a + (__f64x2)__b);


Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -825,18 +825,6 @@
   return (v128_t)(-(__u64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_any_true(v128_t __a) {
-  return __builtin_wasm_any_true_i64x2((__i64x2)__a);
-}
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_all_true(v128_t __a) {
-  return __builtin_wasm_all_true_i64x2((__i64x2)__a);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_i64x2_shl(v128_t __a,
int32_t __b) {
   return (v128_t)((__i64x2)__a << (int64_t)__b);
@@ -879,24 +867,6 @@
   return (v128_t)__builtin_wasm_sqrt_f32x4((__f32x4)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f32x4((__f32x4)__a, (__f32x4)__b,
-   

[clang] cbab2cd - [WebAssembly] Remove experimental instructions from wasm_simd128.h

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2021-03-18T17:13:50-07:00
New Revision: cbab2cd6bf77f121c0d8a46abf607895b2911a20

URL: 
https://github.com/llvm/llvm-project/commit/cbab2cd6bf77f121c0d8a46abf607895b2911a20
DIFF: 
https://github.com/llvm/llvm-project/commit/cbab2cd6bf77f121c0d8a46abf607895b2911a20.diff

LOG: [WebAssembly] Remove experimental instructions from wasm_simd128.h

These experimental builtin functions and the feature macro they were gated
behind have been removed.

Reviewed By: aheejin

Differential Revision: https://reviews.llvm.org/D98907

Added: 


Modified: 
clang/lib/Headers/wasm_simd128.h

Removed: 




diff  --git a/clang/lib/Headers/wasm_simd128.h 
b/clang/lib/Headers/wasm_simd128.h
index 20f5a85b3224..eb2a42f303b6 100644
--- a/clang/lib/Headers/wasm_simd128.h
+++ b/clang/lib/Headers/wasm_simd128.h
@@ -825,18 +825,6 @@ static __inline__ v128_t __DEFAULT_FN_ATTRS 
wasm_i64x2_neg(v128_t __a) {
   return (v128_t)(-(__u64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_any_true(v128_t __a) {
-  return __builtin_wasm_any_true_i64x2((__i64x2)__a);
-}
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_all_true(v128_t __a) {
-  return __builtin_wasm_all_true_i64x2((__i64x2)__a);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_i64x2_shl(v128_t __a,
int32_t __b) {
   return (v128_t)((__i64x2)__a << (int64_t)__b);
@@ -879,24 +867,6 @@ static __inline__ v128_t __DEFAULT_FN_ATTRS 
wasm_f32x4_sqrt(v128_t __a) {
   return (v128_t)__builtin_wasm_sqrt_f32x4((__f32x4)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_add(v128_t __a,
v128_t __b) {
   return (v128_t)((__f32x4)__a + (__f32x4)__b);
@@ -949,24 +919,6 @@ static __inline__ v128_t __DEFAULT_FN_ATTRS 
wasm_f64x2_sqrt(v128_t __a) {
   return (v128_t)__builtin_wasm_sqrt_f64x2((__f64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f64x2((__f64x2)__a, (__f64x2)__b,
-   (__f64x2)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f64x2((__f64x2)__a, (__f64x2)__b,
-   (__f64x2)__c);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_add(v128_t __a,
v128_t __b) {
   return (v128_t)((__f64x2)__a + (__f64x2)__b);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98907: [WebAssembly] Remove qfma/qfms from wasm_simd128.h

[Thomas Lively via Phabricator via cfe-commits]

tlively created this revision.
tlively added reviewers: aheejin, dschuff.
Herald added subscribers: wingo, ecnelises, sunfish, jgravelle-google, sbc100.
tlively requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

These experimental builtin functions and the feature macro they were gated
behind have been removed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98907

Files:
  clang/lib/Headers/wasm_simd128.h


Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -825,18 +825,6 @@
   return (v128_t)(-(__u64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_any_true(v128_t __a) {
-  return __builtin_wasm_any_true_i64x2((__i64x2)__a);
-}
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_all_true(v128_t __a) {
-  return __builtin_wasm_all_true_i64x2((__i64x2)__a);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_i64x2_shl(v128_t __a,
int32_t __b) {
   return (v128_t)((__i64x2)__a << (int64_t)__b);
@@ -879,24 +867,6 @@
   return (v128_t)__builtin_wasm_sqrt_f32x4((__f32x4)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_add(v128_t __a,
v128_t __b) {
   return (v128_t)((__f32x4)__a + (__f32x4)__b);
@@ -949,24 +919,6 @@
   return (v128_t)__builtin_wasm_sqrt_f64x2((__f64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f64x2((__f64x2)__a, (__f64x2)__b,
-   (__f64x2)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfms_f64x2((__f64x2)__a, (__f64x2)__b,
-   (__f64x2)__c);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f64x2_add(v128_t __a,
v128_t __b) {
   return (v128_t)((__f64x2)__a + (__f64x2)__b);


Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -825,18 +825,6 @@
   return (v128_t)(-(__u64x2)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_any_true(v128_t __a) {
-  return __builtin_wasm_any_true_i64x2((__i64x2)__a);
-}
-
-static __inline__ bool __DEFAULT_FN_ATTRS wasm_i64x2_all_true(v128_t __a) {
-  return __builtin_wasm_all_true_i64x2((__i64x2)__a);
-}
-
-#endif // __wasm_unimplemented_simd128__
-
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_i64x2_shl(v128_t __a,
int32_t __b) {
   return (v128_t)((__i64x2)__a << (int64_t)__b);
@@ -879,24 +867,6 @@
   return (v128_t)__builtin_wasm_sqrt_f32x4((__f32x4)__a);
 }
 
-#ifdef __wasm_unimplemented_simd128__
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfma(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return (v128_t)__builtin_wasm_qfma_f32x4((__f32x4)__a, (__f32x4)__b,
-   (__f32x4)__c);
-}
-
-static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_f32x4_qfms(v128_t __a,
-v128_t __b,
-v128_t __c) {
-  return 

[PATCH] D98904: Instantiate static constexpr data members on MS ABI.

[Zoe Carver via Phabricator via cfe-commits]

zoecarver added a comment.

> (I think you're missing something here to trigger the instantiation of the 
> class, such as Invalid x;.)

Yes, you're right.

> The above example is valid in C++17 onwards, because in C++17 onwards, static 
> constexpr data members are implicitly inline, and the delayed instantiation 
> behavior here is correct for inline static data members. We'll need to 
> distinguish here between the case where the variable is implicitly inline 
> solely because of the MS ABI rules and the case where the variable is inline 
> because of the actual language rules (where it's declared either inline or 
> constexpr).

Hmm. This is interesting. Thanks for explaining. Because this patch isn't going 
to help solve the Swift interop issue anymore, I don't feel a need to continue 
with it. However, if you still think it would be a valuable change to make, I'm 
happy to continue working on it.

I think we'd basically need a condition that says: `is-microsoft && 
less-than-cxx17 && is-constexpr && is-static-data-member`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98904/new/

https://reviews.llvm.org/D98904

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98904: Instantiate static constexpr data members on MS ABI.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D98904#2636021 , @zoecarver wrote:

> So, as I mentioned in the description of this patch, the reason that these 
> members are treated as definitions is that Clang implicitly marks them as 
> inline when targeting MS. This is sort of interesting a) because it only 
> applies to constexpr vars, and b) because this also happens on all platforms 
> for `std=c++17`. This means that the following program will compile 
> successfully with `std=c++17`:
>
>   template 
>   struct GetTypeValue {
> static constexpr const bool value = T::value;
>   };
>   
>   using Invalid = GetTypeValue;

(I think you're missing something here to trigger the instantiation of the 
class, such as `Invalid x;`.)

> However, if the `constexpr` is removed, it will fail to compile. Conversely, 
> after this patch is applied, that will not happen on Windows (it will fail to 
> compile regardless of the targeted standard or constexprness). I think it 
> would make sense to "fix" this for `std=c++17` as well, but I'm not sure if 
> that's in line with the standard.

The above example is valid in C++17 onwards, because in C++17 onwards, static 
constexpr data members are implicitly inline, and the delayed instantiation 
behavior here is correct for inline static data members. We'll need to 
distinguish here between the case where the variable is implicitly inline 
solely because of the MS ABI rules and the case where the variable is inline 
because of the actual language rules (where it's declared either `inline` or 
`constexpr`).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98904/new/

https://reviews.llvm.org/D98904

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97993: [Driver] Suppress GCC detection under -B for non-Android

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97993/new/

https://reviews.llvm.org/D97993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

I tried the patch in our environment and it works.  LG.  Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98902/new/

https://reviews.llvm.org/D98902

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98904: Instantiate static constexpr data members on MS ABI.

[Zoe Carver via Phabricator via cfe-commits]

zoecarver added a comment.

So, as I mentioned in the description of this patch, the reason that these 
members are treated as definitions is that Clang implicitly marks them as 
inline when targeting MS. This is sort of interesting a) because it only 
applies to constexpr vars, and b) because this also happens on all platforms 
for `std=c++17`. This means that the following program will compile 
successfully with `std=c++17`:

  template 
  struct GetTypeValue {
static constexpr const bool value = T::value;
  };
  
  using Invalid = GetTypeValue;

However, if the `constexpr` is removed, it will fail to compile. Conversely, 
after this patch is applied, that will not happen on Windows (it will fail to 
compile regardless of the targeted standard or constexprness). I think it would 
make sense to "fix" this for `std=c++17` as well, but I'm not sure if that's in 
line with the standard.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98904/new/

https://reviews.llvm.org/D98904

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98338: [clang-tidy] Fix bugprone-terminating-continue when continue appears inside a switch

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 331713.
njames93 marked an inline comment as done.
njames93 added a comment.

Add test case for do inside switch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98338/new/

https://reviews.llvm.org/D98338

Files:
  clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
@@ -32,6 +32,15 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 'continue' in loop with false 
condition is equivalent to 'break' [bugprone-terminating-continue]
 // CHECK-FIXES: if (x > 0) break;
   } while (false);
+
+  switch (2) {
+  case 2:
+do {
+  continue; // LoopInSwitch
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'continue' in loop with 
false condition is equivalent to 'break' [bugprone-terminating-continue]
+  // CHECK-FIXES: break; // LoopInSwitch
+} while (0);
+  }
 }
 
 void g() {
@@ -62,4 +71,12 @@
   if (n>2) continue;
 }
   } while (false);
+
+  do {
+switch (2) {
+case 1:
+case 2:
+  continue;
+}
+  } while (false);
 }
Index: clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
@@ -26,10 +26,11 @@
  equalsBoundNode("closestLoop"));
 
   Finder->addMatcher(
-  continueStmt(hasAncestor(stmt(anyOf(forStmt(), whileStmt(),
-  cxxForRangeStmt(), doStmt()))
-   .bind("closestLoop")),
-   hasAncestor(DoWithFalse))
+  continueStmt(
+  hasAncestor(stmt(anyOf(forStmt(), whileStmt(), cxxForRangeStmt(),
+ doStmt(), switchStmt()))
+  .bind("closestLoop")),
+  hasAncestor(DoWithFalse))
   .bind("continue"),
   this);
 }


Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
@@ -32,6 +32,15 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 'continue' in loop with false condition is equivalent to 'break' [bugprone-terminating-continue]
 // CHECK-FIXES: if (x > 0) break;
   } while (false);
+
+  switch (2) {
+  case 2:
+do {
+  continue; // LoopInSwitch
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'continue' in loop with false condition is equivalent to 'break' [bugprone-terminating-continue]
+  // CHECK-FIXES: break; // LoopInSwitch
+} while (0);
+  }
 }
 
 void g() {
@@ -62,4 +71,12 @@
   if (n>2) continue;
 }
   } while (false);
+
+  do {
+switch (2) {
+case 1:
+case 2:
+  continue;
+}
+  } while (false);
 }
Index: clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
@@ -26,10 +26,11 @@
  equalsBoundNode("closestLoop"));
 
   Finder->addMatcher(
-  continueStmt(hasAncestor(stmt(anyOf(forStmt(), whileStmt(),
-  cxxForRangeStmt(), doStmt()))
-   .bind("closestLoop")),
-   hasAncestor(DoWithFalse))
+  continueStmt(
+  hasAncestor(stmt(anyOf(forStmt(), whileStmt(), cxxForRangeStmt(),
+ doStmt(), switchStmt()))
+  .bind("closestLoop")),
+  hasAncestor(DoWithFalse))
   .bind("continue"),
   this);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98904: Instantiate static constexpr data members on MS ABI.

[Zoe Carver via Phabricator via cfe-commits]

zoecarver created this revision.
zoecarver added a reviewer: rsmith.
zoecarver requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Because MSVC will not treat the definition of a static data member as part of 
the declaration, it will not get instantiated. This means Clang won't diagnose 
instantiation errors until the data member itself is used.

Note: this only happens for constexpr data members because they are the only 
ones that are marked as implicitly inline and therefore not part of the 
declaration.

Refs: https://llvm.org/PR49618
Refs: https://github.com/apple/swift/pull/35962


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98904

Files:
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/SemaCXX/windows-data-member-instantiation-errors.cpp


Index: clang/test/SemaCXX/windows-data-member-instantiation-errors.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/windows-data-member-instantiation-errors.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -verify -std=c++17 %s
+
+template 
+struct GetTypeValue {
+  // expected-error@+1{{type 'int' cannot be used prior to '::' because it has 
no members}}
+  static constexpr const bool value = T::value;
+};
+
+using Invalid = GetTypeValue;
+
+// expected-note@+1{{in instantiation of template class 'GetTypeValue' 
requested here}}
+void test(Invalid) {}
+
+// expected-note@+2{{candidate constructor (the implicit copy constructor) not 
viable: no known conversion from 'int' to 'const S &' for 1st argument}}
+// expected-note@+1{{candidate constructor (the implicit move constructor) not 
viable: no known conversion from 'int' to 'S &&' for 1st argument}}
+struct S {};
+
+template 
+struct MakeS {
+  // expected-error@+1{{no viable conversion from 'int' to 'const S'}}
+  static constexpr const S value = T();
+};
+
+using Invalid2 = MakeS;
+
+// expected-note@+1{{in instantiation of template class 'MakeS' requested 
here}}
+void test2(Invalid2) {}
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5111,7 +5111,11 @@
 InstantiateVariableInitializer(NewVar, OldVar, TemplateArgs);
   } else if (InstantiatingSpecFromTemplate ||
  (OldVar->isInline() && OldVar->isThisDeclarationADefinition() &&
-  !NewVar->isThisDeclarationADefinition())) {
+  !NewVar->isThisDeclarationADefinition() &&
+  // On Microsoft's ABI, the new var's initializer will be part of
+  // the definition. But, we still want to instanciate it so that
+  // we can catch instantiation errors.
+  !Context.getTargetInfo().getCXXABI().isMicrosoft())) {
 // Delay instantiation of the initializer for variable template
 // specializations or inline static data members until a definition of the
 // variable is needed.


Index: clang/test/SemaCXX/windows-data-member-instantiation-errors.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/windows-data-member-instantiation-errors.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -verify -std=c++17 %s
+
+template 
+struct GetTypeValue {
+  // expected-error@+1{{type 'int' cannot be used prior to '::' because it has no members}}
+  static constexpr const bool value = T::value;
+};
+
+using Invalid = GetTypeValue;
+
+// expected-note@+1{{in instantiation of template class 'GetTypeValue' requested here}}
+void test(Invalid) {}
+
+// expected-note@+2{{candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const S &' for 1st argument}}
+// expected-note@+1{{candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'S &&' for 1st argument}}
+struct S {};
+
+template 
+struct MakeS {
+  // expected-error@+1{{no viable conversion from 'int' to 'const S'}}
+  static constexpr const S value = T();
+};
+
+using Invalid2 = MakeS;
+
+// expected-note@+1{{in instantiation of template class 'MakeS' requested here}}
+void test2(Invalid2) {}
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5111,7 +5111,11 @@
 InstantiateVariableInitializer(NewVar, OldVar, TemplateArgs);
   } else if (InstantiatingSpecFromTemplate ||
  (OldVar->isInline() && OldVar->isThisDeclarationADefinition() &&
-  

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 added a comment.

In D98902#2635930 , @tra wrote:

>> My question is, if DeviceOffloadingKind == Action::OFK_Cuda, and we use -S, 
>> do we also want to skip as well?
>
> I do not think so. Libdevice is needed to implement some libcalls that LLVM 
> currently does not know how to handle.
> We do need it even when we compile with `-S`. It may work without it in many 
> cases, but it's still needed in general.

Thanks for the answer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98902/new/

https://reviews.llvm.org/D98902

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

> My question is, if DeviceOffloadingKind == Action::OFK_Cuda, and we use -S, 
> do we also want to skip as well?

I do not think so. Libdevice is needed to implement some libcalls that LLVM 
currently does not know how to handle.
We do need it even when we compile with `-S`. It may work without it in many 
cases, but it's still needed in general.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98902/new/

https://reviews.llvm.org/D98902

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97371: [clang][parser] Remove questionable ProhibitAttributes() call in objc parsing

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Yes, I think that would be reasonable, thank you.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97371/new/

https://reviews.llvm.org/D97371

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 created this revision.
Herald added subscribers: guansong, yaxunl.
tianshilei1992 requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

https://lists.llvm.org/pipermail/openmp-dev/2021-March/003940.html reports
test failure in `openmp-offload-gpu.c`. The failure is, when using `-S` in the
clang driver, it still reports bitcode library doesn't exist. However, it is not
exposed in my local run and Phabiractor test. The reason it escaped from 
Phabricator
test is, the test machine doesn't have CUDA, so `LibDeviceFile` is empty. In 
this
case, the check of `OPT_S` will be hit, and we get "expected" result. However, 
if
the test machine has CUDA, `LibDeviceFile` will not be empty, then the check 
will
not be done, and it just proceeds, trying to add the bitcode library. The reason
it escaped from my local run is, I didn't build ALL targets, so this case was
marked UNSUPPORTED.

In this patch, I just moved the check out of the code block, but the check is
guarded by the `DeviceOffloadingKind == Action::OFK_OpenMP`. My question is, if
`DeviceOffloadingKind == Action::OFK_Cuda`, and we use `-S`, do we also want to
skip as well?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98902

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -696,13 +696,12 @@
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return;
 
-  std::string LibDeviceFile = CudaInstallation.getLibDeviceFile(GpuArch);
+  if (DeviceOffloadingKind == Action::OFK_OpenMP &&
+  DriverArgs.hasArg(options::OPT_S))
+return;
 
+  std::string LibDeviceFile = CudaInstallation.getLibDeviceFile(GpuArch);
   if (LibDeviceFile.empty()) {
-if (DeviceOffloadingKind == Action::OFK_OpenMP &&
-DriverArgs.hasArg(options::OPT_S))
-  return;
-
 getDriver().Diag(diag::err_drv_no_cuda_libdevice) << GpuArch;
 return;
   }


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -696,13 +696,12 @@
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return;
 
-  std::string LibDeviceFile = CudaInstallation.getLibDeviceFile(GpuArch);
+  if (DeviceOffloadingKind == Action::OFK_OpenMP &&
+  DriverArgs.hasArg(options::OPT_S))
+return;
 
+  std::string LibDeviceFile = CudaInstallation.getLibDeviceFile(GpuArch);
   if (LibDeviceFile.empty()) {
-if (DeviceOffloadingKind == Action::OFK_OpenMP &&
-DriverArgs.hasArg(options::OPT_S))
-  return;
-
 getDriver().Diag(diag::err_drv_no_cuda_libdevice) << GpuArch;
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98862: [clang] Update unit-tests after linker selection fix for *-msvc targets

[Amy Kwan via Phabricator via cfe-commits]

amyk added a comment.

Hi,

Thanks for fixing the tests. I've tested this patch on the environment of 
`clang-ppc64le-rhel` (https://lab.llvm.org/buildbot/#/builders/57), and there 
seems to be two failures that still remain:

  Failed Tests (2):
Clang :: OpenMP/linking.c
Clang :: Driver/msvc-link.c

`OpenMP/linking.c` fails on:

  Exit Code: 1
  
  Command Output (stderr):
  --
  /home/docker/amy/llvm-project/clang/test/OpenMP/linking.c:106:25: error: 
CHECK-MSVC-ILINK-64: expected string not found in input
  // CHECK-MSVC-ILINK-64: link.exe

`Driver/msvc-link.c` fails on:

  Exit Code: 1
  
  Command Output (stderr):
  --
  /home/docker/amy/llvm-project/clang/test/Driver/msvc-link.c:10:9: error: DLL: 
expected string not found in input
  // DLL: link.exe"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98862/new/

https://reviews.llvm.org/D98862

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98881: [RISCV] Fix mcount name for Linux

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added a comment.

Would it be better to hoist it into `RISCVTargetInfo` and modify the BSD switch 
statements to respect that in their respective TargetInfo constructors?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98881/new/

https://reviews.llvm.org/D98881

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98881: [RISCV] Fix mcount name for Linux

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

This should really be for all OSes on RISC-V, which I think means copying it N 
times? :/

(GCC defines MCOUNT_NAME in riscv/riscv.h, not riscv/linux.h)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98881/new/

https://reviews.llvm.org/D98881

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98895: [X86][Draft] Disable long double type for -mno-x87 option

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic added a comment.

I'm not sure that this is the right approach, but I wanted to get feedback on
how the issue should be fixed. Currently, the compiler crashes on almost any
code with `long double` (excluding cases where CG does not properly disable 
x87):

  long double foo(long double x, long double y)
  {
long double z = x + y;
if (z < 0.0)
  return z;
else
  return 0.0;
  }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98895/new/

https://reviews.llvm.org/D98895

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98895: [X86][Draft] Disable long double type for -mno-x87 option

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic created this revision.
asavonic added a reviewer: andrew.w.kaylor.
Herald added a subscriber: pengfei.
asavonic requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch attempts to fix a compiler crash that occurs when `long double` type
is used with `-mno-x87` compiler option.

The option disables x87 target feature, which in turn disables x87 registers, so
CG cannot select them for `x86_fp80` LLVM IR type. Long double is lowered as
`x86_fp80` for some targets, so it leads to a crash.

The option seems to contradict the SystemV ABI, which requires `long double` to
be represented as a 80-bit floating point, and it also requires to use x87 
registers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98895

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/x86-no-x87.c

Index: clang/test/Sema/x86-no-x87.c
===
--- /dev/null
+++ clang/test/Sema/x86-no-x87.c
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple x86_64-linux-gnu -target-feature -x87
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple x86_64-linux-gnu -DNOERROR
+
+#ifdef NOERROR
+// expected-no-diagnostics
+#endif
+
+typedef long double long_double;
+
+#ifndef NOERROR
+// expected-error@+3{{long double is not supported on this target}}
+// expected-error@+2{{long double is not supported on this target}}
+#endif
+double ld_args(long_double x, long_double y);
+
+long_double ld_ret(double x, double y);
+
+double args(double x, double y) {
+  return ld_args(x, y);
+}
+
+double ret(double x, double y) {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  return ld_ret(x, y);
+}
+
+double binop(double x, double y) {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  double z = (long_double)x * (long_double)y;
+  return z;
+}
+
+void assign1(long_double *ret, double x) {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  *ret = x;
+}
+
+struct st_long_double {
+  long_double ld;
+};
+
+void assign2() {
+  struct st_long_double st;
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  st.ld = 0.42;
+}
+
+void assign3() {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  long_double ld = 0.42;
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -13917,6 +13917,17 @@
 }
   }
 
+  if (!Context.getTargetInfo().hasLongDoubleType()) {
+QualType LHSTy = LHSExpr->getType();
+QualType RHSTy = RHSExpr->getType();
+
+if ((LHSTy.getCanonicalType() == Context.LongDoubleTy) ||
+(RHSTy.getCanonicalType() == Context.LongDoubleTy)) {
+  Diag(OpLoc, diag::err_type_unsupported) << "long double";
+  return ExprError();
+}
+  }
+
   switch (Opc) {
   case BO_Assign:
 ResultTy = CheckAssignmentOperands(LHS.get(), RHS, OpLoc, QualType());
@@ -14755,6 +14766,13 @@
   if (Opc != UO_AddrOf && Opc != UO_Deref)
 CheckArrayAccess(Input.get());
 
+  if (!Context.getTargetInfo().hasLongDoubleType() &&
+  (resultType.getCanonicalType() == Context.LongDoubleTy ||
+   InputExpr->getType().getCanonicalType() == Context.LongDoubleTy)) {
+Diag(OpLoc, diag::err_type_unsupported) << "long double";
+return ExprError();
+  }
+
   auto *UO =
   UnaryOperator::Create(Context, Input.get(), Opc, resultType, VK, OK,
 OpLoc, CanOverflow, CurFPFeatureOverrides());
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -7244,6 +7244,11 @@
 diagnoseOpenCLTypes(S, *this, D, DC, NewVD->getType());
   }
 
+  if (!Context.getTargetInfo().hasLongDoubleType() &&
+  NewVD->getType().getCanonicalType() == Context.LongDoubleTy) {
+Diag(NewVD->getLocation(), diag::err_type_unsupported) << "long double";
+  }
+
   // Handle attributes prior to checking for duplicates in MergeVarDecl
   ProcessDeclAttributes(S, NewVD, D);
 
@@ -14136,6 +14141,17 @@
   CheckParmsForFunctionDef(FD->parameters(),
/*CheckParameterNames=*/true);
 
+  if (!Context.getTargetInfo().hasLongDoubleType()) {
+if (ResultType.getCanonicalType() == Context.LongDoubleTy) {
+  Diag(FD->getLocation(), diag::err_type_unsupported) << "long double";
+}
+for (ParmVarDecl *Param : FD->parameters()) {
+  if (Param->getType().getCanonicalType() == Context.LongDoubleTy) {

[PATCH] D98889: [clang] Replaced some manual pointer tagging with llvm::PointerIntPair.

[Josh Haberman via Phabricator via cfe-commits]

haberman marked an inline comment as done.
haberman added a comment.

> Thanks! Do we need InitializedEntity::getDecl to return a pointer to 
> non-const?

Yes, if I try to propagate `const` the change starts to snowball.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98889/new/

https://reviews.llvm.org/D98889

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98889: [clang] Replaced some manual pointer tagging with llvm::PointerIntPair.

[Josh Haberman via Phabricator via cfe-commits]

haberman updated this revision to Diff 331679.
haberman added a comment.

Updated comment "the low bit" -> "the integer".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98889/new/

https://reviews.llvm.org/D98889

Files:
  clang/include/clang/Sema/Initialization.h


Index: clang/include/clang/Sema/Initialization.h
===
--- clang/include/clang/Sema/Initialization.h
+++ clang/include/clang/Sema/Initialization.h
@@ -187,7 +187,7 @@
 ObjCMethodDecl *MethodDecl;
 
 /// When Kind == EK_Parameter, the ParmVarDecl, with the
-/// low bit indicating whether the parameter is "consumed".
+/// integer indicating whether the parameter is "consumed".
 llvm::PointerIntPair Parameter;
 
 /// When Kind == EK_Temporary or EK_CompoundLiteralInit, the type
@@ -197,7 +197,7 @@
 struct LN LocAndNRVO;
 
 /// When Kind == EK_Base, the base specifier that provides the
-/// base class. The lower bit specifies whether the base is an inherited
+/// base class. The integer specifies whether the base is an inherited
 /// virtual base.
 llvm::PointerIntPair Base;
 


Index: clang/include/clang/Sema/Initialization.h
===
--- clang/include/clang/Sema/Initialization.h
+++ clang/include/clang/Sema/Initialization.h
@@ -187,7 +187,7 @@
 ObjCMethodDecl *MethodDecl;
 
 /// When Kind == EK_Parameter, the ParmVarDecl, with the
-/// low bit indicating whether the parameter is "consumed".
+/// integer indicating whether the parameter is "consumed".
 llvm::PointerIntPair Parameter;
 
 /// When Kind == EK_Temporary or EK_CompoundLiteralInit, the type
@@ -197,7 +197,7 @@
 struct LN LocAndNRVO;
 
 /// When Kind == EK_Base, the base specifier that provides the
-/// base class. The lower bit specifies whether the base is an inherited
+/// base class. The integer specifies whether the base is an inherited
 /// virtual base.
 llvm::PointerIntPair Base;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98893: Updated comment "the low bit" -> "the integer".

[Josh Haberman via Phabricator via cfe-commits]

haberman abandoned this revision.
haberman added a comment.

This was meant to be an update on https://reviews.llvm.org/D98889


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98893/new/

https://reviews.llvm.org/D98893

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98893: Updated comment "the low bit" -> "the integer".

[Josh Haberman via Phabricator via cfe-commits]

haberman created this revision.
haberman requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98893

Files:
  clang/include/clang/Sema/Initialization.h


Index: clang/include/clang/Sema/Initialization.h
===
--- clang/include/clang/Sema/Initialization.h
+++ clang/include/clang/Sema/Initialization.h
@@ -187,7 +187,7 @@
 ObjCMethodDecl *MethodDecl;
 
 /// When Kind == EK_Parameter, the ParmVarDecl, with the
-/// low bit indicating whether the parameter is "consumed".
+/// integer indicating whether the parameter is "consumed".
 llvm::PointerIntPair Parameter;
 
 /// When Kind == EK_Temporary or EK_CompoundLiteralInit, the type
@@ -197,7 +197,7 @@
 struct LN LocAndNRVO;
 
 /// When Kind == EK_Base, the base specifier that provides the
-/// base class. The lower bit specifies whether the base is an inherited
+/// base class. The integer specifies whether the base is an inherited
 /// virtual base.
 llvm::PointerIntPair Base;
 


Index: clang/include/clang/Sema/Initialization.h
===
--- clang/include/clang/Sema/Initialization.h
+++ clang/include/clang/Sema/Initialization.h
@@ -187,7 +187,7 @@
 ObjCMethodDecl *MethodDecl;
 
 /// When Kind == EK_Parameter, the ParmVarDecl, with the
-/// low bit indicating whether the parameter is "consumed".
+/// integer indicating whether the parameter is "consumed".
 llvm::PointerIntPair Parameter;
 
 /// When Kind == EK_Temporary or EK_CompoundLiteralInit, the type
@@ -197,7 +197,7 @@
 struct LN LocAndNRVO;
 
 /// When Kind == EK_Base, the base specifier that provides the
-/// base class. The lower bit specifies whether the base is an inherited
+/// base class. The integer specifies whether the base is an inherited
 /// virtual base.
 llvm::PointerIntPair Base;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98892: [HWASan] Mention x86_64 aliasing mode in design doc.

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis accepted this revision.
eugenis added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: clang/docs/HardwareAssistedAddressSanitizerDesign.rst:279
+
+HWASAN's approach is not applicable to 32-bit architectures.
 

This statement seems a bit too strong. Maybe say something along these lines: 
none of the existing 32-bit platforms provide a practical way to put tag bits 
in the pointer, and the address space constraints make it hard to do anyway, so 
hwasan does not support 32-bit at the moment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98892/new/

https://reviews.llvm.org/D98892

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98887: [clang-cl] make -ffile-compilation-dir a CoreOption.

[Zequan Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1c740b29fae3: [clang-cl] make -ffile-compilation-dir a 
CoreOption. (authored by zequanwu).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98887/new/

https://reviews.llvm.org/D98887

Files:
  clang/include/clang/Driver/Options.td
  clang/test/Driver/cl-options.c


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -643,6 +643,7 @@
 // RUN: -fno-diagnostics-color \
 // RUN: -fdebug-compilation-dir . \
 // RUN: -fdebug-compilation-dir=. \
+// RUN: -ffile-compilation-dir=. \
 // RUN: -fdiagnostics-parseable-fixits \
 // RUN: -fdiagnostics-absolute-paths \
 // RUN: -ferror-limit=10 \
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1125,6 +1125,7 @@
 HelpText<"The compilation directory to embed in the coverage mapping.">,
 MarshallingInfoString>;
 def ffile_compilation_dir_EQ : Joined<["-"], "ffile-compilation-dir=">, 
Group,
+Flags<[CoreOption]>,
 HelpText<"The compilation directory to embed in the debug info and 
coverage mapping.">;
 defm debug_info_for_profiling : BoolFOption<"debug-info-for-profiling",
   CodeGenOpts<"DebugInfoForProfiling">, DefaultFalse,


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -643,6 +643,7 @@
 // RUN: -fno-diagnostics-color \
 // RUN: -fdebug-compilation-dir . \
 // RUN: -fdebug-compilation-dir=. \
+// RUN: -ffile-compilation-dir=. \
 // RUN: -fdiagnostics-parseable-fixits \
 // RUN: -fdiagnostics-absolute-paths \
 // RUN: -ferror-limit=10 \
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1125,6 +1125,7 @@
 HelpText<"The compilation directory to embed in the coverage mapping.">,
 MarshallingInfoString>;
 def ffile_compilation_dir_EQ : Joined<["-"], "ffile-compilation-dir=">, Group,
+Flags<[CoreOption]>,
 HelpText<"The compilation directory to embed in the debug info and coverage mapping.">;
 defm debug_info_for_profiling : BoolFOption<"debug-info-for-profiling",
   CodeGenOpts<"DebugInfoForProfiling">, DefaultFalse,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 1c740b2 - [clang-cl] make -ffile-compilation-dir a CoreOption.

[Zequan Wu via cfe-commits]

Author: Zequan Wu
Date: 2021-03-18T13:20:47-07:00
New Revision: 1c740b29fae3962a9c8644496352b10798d925ef

URL: 
https://github.com/llvm/llvm-project/commit/1c740b29fae3962a9c8644496352b10798d925ef
DIFF: 
https://github.com/llvm/llvm-project/commit/1c740b29fae3962a9c8644496352b10798d925ef.diff

LOG: [clang-cl] make -ffile-compilation-dir a CoreOption.

Let clang-cl accepts `-ffile-compilation-dir` flag.

Differential Revision: https://reviews.llvm.org/D98887

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/test/Driver/cl-options.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 9c5013ee88d9..a9b43a8fe620 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1125,6 +1125,7 @@ def fcoverage_compilation_dir_EQ : Joined<["-"], 
"fcoverage-compilation-dir=">,
 HelpText<"The compilation directory to embed in the coverage mapping.">,
 MarshallingInfoString>;
 def ffile_compilation_dir_EQ : Joined<["-"], "ffile-compilation-dir=">, 
Group,
+Flags<[CoreOption]>,
 HelpText<"The compilation directory to embed in the debug info and 
coverage mapping.">;
 defm debug_info_for_profiling : BoolFOption<"debug-info-for-profiling",
   CodeGenOpts<"DebugInfoForProfiling">, DefaultFalse,

diff  --git a/clang/test/Driver/cl-options.c b/clang/test/Driver/cl-options.c
index 7d83b3d60b1e..90f865d9c7c0 100644
--- a/clang/test/Driver/cl-options.c
+++ b/clang/test/Driver/cl-options.c
@@ -643,6 +643,7 @@
 // RUN: -fno-diagnostics-color \
 // RUN: -fdebug-compilation-dir . \
 // RUN: -fdebug-compilation-dir=. \
+// RUN: -ffile-compilation-dir=. \
 // RUN: -fdiagnostics-parseable-fixits \
 // RUN: -fdiagnostics-absolute-paths \
 // RUN: -ferror-limit=10 \



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98892: [HWASan] Mention x86_64 aliasing mode in design doc.

[Matt Morehouse via Phabricator via cfe-commits]

morehouse updated this revision to Diff 331670.
morehouse added a comment.

- Format `fork()` as code.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98892/new/

https://reviews.llvm.org/D98892

Files:
  clang/docs/HardwareAssistedAddressSanitizerDesign.rst


Index: clang/docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- clang/docs/HardwareAssistedAddressSanitizerDesign.rst
+++ clang/docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -19,13 +19,17 @@
 sources of AddressSanitizer's memory overhead.
 See the `AddressSanitizer paper`_ for details.
 
-AArch64 has the `Address Tagging`_ (or top-byte-ignore, TBI), a hardware 
feature that allows
-software to use 8 most significant bits of a 64-bit pointer as
+AArch64 has `Address Tagging`_ (or top-byte-ignore, TBI), a hardware feature 
that allows
+software to use the 8 most significant bits of a 64-bit pointer as
 a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
 
+Intel's `Linear Address Masking`_ (LAM) also provides address tagging for
+x86_64, though it is not widely available in hardware yet.  For x86_64, HWASAN
+has a limited implementation using page aliasing instead.
+
 Algorithm
 =
 * Every heap/stack/global memory object is forcibly aligned by `TG` bytes
@@ -266,7 +270,13 @@
 will have limited deployability since not all of the code is
 typically instrumented.
 
-The HWASAN's approach is not applicable to 32-bit architectures.
+On x86_64, HWASAN utilizes page aliasing to place tags in userspace address
+bits.  Currently only heap tagging is supported.  The page aliases rely on
+shared memory, which will cause heap memory to be shared between processes if
+the application calls ``fork()``.  Therefore x86_64 is really only safe for
+applications that do not fork.
+
+HWASAN's approach is not applicable to 32-bit architectures.
 
 
 Related Work
@@ -284,4 +294,4 @@
 .. _SPARC ADI: 
https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
 .. _AddressSanitizer paper: 
https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
 .. _Address Tagging: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html
-
+.. _Linear Address Masking: 
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html


Index: clang/docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- clang/docs/HardwareAssistedAddressSanitizerDesign.rst
+++ clang/docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -19,13 +19,17 @@
 sources of AddressSanitizer's memory overhead.
 See the `AddressSanitizer paper`_ for details.
 
-AArch64 has the `Address Tagging`_ (or top-byte-ignore, TBI), a hardware feature that allows
-software to use 8 most significant bits of a 64-bit pointer as
+AArch64 has `Address Tagging`_ (or top-byte-ignore, TBI), a hardware feature that allows
+software to use the 8 most significant bits of a 64-bit pointer as
 a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
 
+Intel's `Linear Address Masking`_ (LAM) also provides address tagging for
+x86_64, though it is not widely available in hardware yet.  For x86_64, HWASAN
+has a limited implementation using page aliasing instead.
+
 Algorithm
 =
 * Every heap/stack/global memory object is forcibly aligned by `TG` bytes
@@ -266,7 +270,13 @@
 will have limited deployability since not all of the code is
 typically instrumented.
 
-The HWASAN's approach is not applicable to 32-bit architectures.
+On x86_64, HWASAN utilizes page aliasing to place tags in userspace address
+bits.  Currently only heap tagging is supported.  The page aliases rely on
+shared memory, which will cause heap memory to be shared between processes if
+the application calls ``fork()``.  Therefore x86_64 is really only safe for
+applications that do not fork.
+
+HWASAN's approach is not applicable to 32-bit architectures.
 
 
 Related Work
@@ -284,4 +294,4 @@
 .. _SPARC ADI: https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
 .. _AddressSanitizer paper: https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
 .. _Address Tagging: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html
-
+.. _Linear Address Masking: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D98892: [HWASan] Mention x86_64 aliasing mode in design doc.

[Matt Morehouse via Phabricator via cfe-commits]

morehouse created this revision.
morehouse added reviewers: pcc, eugenis.
morehouse requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98892

Files:
  clang/docs/HardwareAssistedAddressSanitizerDesign.rst


Index: clang/docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- clang/docs/HardwareAssistedAddressSanitizerDesign.rst
+++ clang/docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -19,13 +19,17 @@
 sources of AddressSanitizer's memory overhead.
 See the `AddressSanitizer paper`_ for details.
 
-AArch64 has the `Address Tagging`_ (or top-byte-ignore, TBI), a hardware 
feature that allows
-software to use 8 most significant bits of a 64-bit pointer as
+AArch64 has `Address Tagging`_ (or top-byte-ignore, TBI), a hardware feature 
that allows
+software to use the 8 most significant bits of a 64-bit pointer as
 a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
 
+Intel's `Linear Address Masking`_ (LAM) also provides address tagging for
+x86_64, though it is not widely available in hardware yet.  For x86_64, HWASAN
+has a limited implementation using page aliasing instead.
+
 Algorithm
 =
 * Every heap/stack/global memory object is forcibly aligned by `TG` bytes
@@ -266,7 +270,13 @@
 will have limited deployability since not all of the code is
 typically instrumented.
 
-The HWASAN's approach is not applicable to 32-bit architectures.
+On x86_64, HWASAN utilizes page aliasing to place tags in userspace address
+bits.  Currently only heap tagging is supported.  The page aliases rely on
+shared memory, which will cause heap memory to be shared between processes if
+the application calls fork().  Therefore x86_64 is really only safe for
+applications that do not fork.
+
+HWASAN's approach is not applicable to 32-bit architectures.
 
 
 Related Work
@@ -284,4 +294,4 @@
 .. _SPARC ADI: 
https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
 .. _AddressSanitizer paper: 
https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
 .. _Address Tagging: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html
-
+.. _Linear Address Masking: 
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html


Index: clang/docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- clang/docs/HardwareAssistedAddressSanitizerDesign.rst
+++ clang/docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -19,13 +19,17 @@
 sources of AddressSanitizer's memory overhead.
 See the `AddressSanitizer paper`_ for details.
 
-AArch64 has the `Address Tagging`_ (or top-byte-ignore, TBI), a hardware feature that allows
-software to use 8 most significant bits of a 64-bit pointer as
+AArch64 has `Address Tagging`_ (or top-byte-ignore, TBI), a hardware feature that allows
+software to use the 8 most significant bits of a 64-bit pointer as
 a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
 
+Intel's `Linear Address Masking`_ (LAM) also provides address tagging for
+x86_64, though it is not widely available in hardware yet.  For x86_64, HWASAN
+has a limited implementation using page aliasing instead.
+
 Algorithm
 =
 * Every heap/stack/global memory object is forcibly aligned by `TG` bytes
@@ -266,7 +270,13 @@
 will have limited deployability since not all of the code is
 typically instrumented.
 
-The HWASAN's approach is not applicable to 32-bit architectures.
+On x86_64, HWASAN utilizes page aliasing to place tags in userspace address
+bits.  Currently only heap tagging is supported.  The page aliases rely on
+shared memory, which will cause heap memory to be shared between processes if
+the application calls fork().  Therefore x86_64 is really only safe for
+applications that do not fork.
+
+HWASAN's approach is not applicable to 32-bit architectures.
 
 
 Related Work
@@ -284,4 +294,4 @@
 .. _SPARC ADI: https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
 .. _AddressSanitizer paper: https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
 .. _Address Tagging: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html
-
+.. _Linear Address Masking: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D98746: [clang][amdgpu] Use implicit code object default

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1115-1124
+  // Currently defaults to 3 in AMDGPUBaseInfo.cpp
+  // Using that default lets clang emit IR for amdgcn when llvm has been built
+  // without that target, provided the user wants this code object version
+  if (CodeObjVer != 3) {
+CmdArgs.insert(CmdArgs.begin() + 1,
+   Args.MakeArgString(Twine("--amdhsa-code-object-version=") +
+  Twine(CodeObjVer)));

JonChesterfield wrote:
> yaxunl wrote:
> > jdoerfert wrote:
> > > JonChesterfield wrote:
> > > > t-tye wrote:
> > > > > This seem rather fragile. If the backend default changes and this 
> > > > > code is not updated it will likely result in creating the wrong code 
> > > > > object version.
> > > > That is true, though numbers 2 through 4 are used in 
> > > > getOrCheckAMDGPUCodeObjectVersion with 3 as the default there too.
> > > > 
> > > > Equally, today if we change the default in clang and forget to update 
> > > > the backend, we won't notice because we always pass this argument.
> > > > 
> > > > What we have at present is the back end has the state and the front end 
> > > > chooses the default. Needing to write '3' in both places is a symptom 
> > > > of that. Perhaps the back end should not have a default for it, 
> > > > requiring this to always be passed, at which point we are going to have 
> > > > a bad time building amdgpu openmp by default.
> > > > 
> > > > This change decouples the two for the (likely common) case where the 
> > > > user has not chosen to override the value. It's not ideal, but equally 
> > > > we don't change the version that often and there are lit tests that 
> > > > notice if we get it wrong. Plus stuff seems to break if the code object 
> > > > version is not as expected.
> > > > 
> > > > There may be a better solution. Target specific variable set by clang 
> > > > feels like something that will occur elsewhere.
> > > Arguably, the backend should have a default, the option should be used by 
> > > users that don't like the default.
> > > 
> > I think a reasonable behavior of clang is to add -mllvm 
> > --amdhsa-code-object-version=x only if users use -mcode-object-version=x or 
> > equivalent explicitly. Otherwise clang should not add -mllvm 
> > --amdhsa-code-object-version=x and let the backend decides the default code 
> > object version.
> > 
> > @t-tye @kzhuravl what do you think? thanks.
> That sounds right to me. It's slightly more complicated to implement than 
> this, will need to rework getOrCheckAMDGPUCodeObjectVersion to distinguish 
> between the get and check parts.
well as Tony pointed out, clang itself needs to know the default code object 
version, since it need it to emit the correct bundle entry ID.

I think the issue is that clang is used to compile HIP to bitcode for amdgpu 
when amdgpu is not a registered target. Although there is a slight concern that 
whether this will always result in valid bitcode for amdgpu, this may be OK 
since the backend should be able to consume bitcode generated with -O0.

If we are confident the LLVM option --amdhsa-code-object-version=x is only 
needed for emitting ISA and can be omitted for emitting bitcode, a fix may be 
to check output type and skip emitting this LLVM option if the output is 
bitcode.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98746/new/

https://reviews.llvm.org/D98746

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98887: [clang-cl] make -ffile-compilation-dir a CoreOption.

[Petr Hosek via Phabricator via cfe-commits]

phosek accepted this revision.
phosek added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98887/new/

https://reviews.llvm.org/D98887

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98338: [clang-tidy] Fix bugprone-terminating-continue when continue appears inside a switch

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.
Herald added a project: clang-tools-extra.

LGTM, but please commit with a better commit message.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp:72
+}
+  } while (false);
 }

I'd appreciate an additional test:
```
switch (2) {
case 2: do {
  continue; // Should still diagnose this one
} while (0);
}
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98338/new/

https://reviews.llvm.org/D98338

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98890: [SystemZ][z/OS] Ignore leading zero width bitfield alignment on z/OS target

[Fanbo Meng via Phabricator via cfe-commits]

fanbo-meng created this revision.
fanbo-meng added reviewers: abhina.sreeskantharajan, hubert.reinterpretcast, 
Kai, SeanP, rsmith.
fanbo-meng requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Zero length bitfield alignment is not respected if they are leading members on 
z/OS target.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98890

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/CodeGen/SystemZ/zos-alignment.c

Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -83,6 +83,35 @@
 // CHECK-NEXT: 8 |   char *[] b
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
+struct s7 {
+  long  :0;
+  short a;
+} S7;
+// CHECK:  0 | struct s7
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
+#pragma pack(2)
+struct s8 {
+  unsigned long   :0;
+  long long   a;
+} S8;
+#pragma pack()
+// CHECK:  0 | struct s8
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=2]
+
+struct s9 {
+  unsigned int   :0;
+  unsigned short :0;
+} S9;
+// CHECK:  0 | struct s9
+// CHECK-NEXT:   0:- |   unsigned int
+// CHECK-NEXT:   0:- |   unsigned short
+// CHECK-NEXT:   | [sizeof=0, align=1]
+
 struct s10 {
  unsigned int __attribute__((aligned)) a;
 } S10;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -790,6 +790,7 @@
 this->WCharType = TargetInfo::UnsignedInt;
 this->UseBitFieldTypeAlignment = false;
 this->UseZeroLengthBitfieldAlignment = true;
+this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
 this->MinGlobalAlign = 0;
 this->DefaultAlignForAttributeAligned = 128;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -104,6 +104,7 @@
   UseSignedCharForObjCBool = true;
   UseBitFieldTypeAlignment = true;
   UseZeroLengthBitfieldAlignment = false;
+  UseLeadingZeroLengthBitfield = true;
   UseExplicitBitFieldAlignment = true;
   ZeroLengthBitfieldBoundary = 0;
   HalfFormat = ::APFloat::IEEEhalf();
Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1627,12 +1627,17 @@
 // Some such targets do honor it on zero-width bitfields.
 if (FieldSize == 0 &&
 Context.getTargetInfo().useZeroLengthBitfieldAlignment()) {
-  // The alignment to round up to is the max of the field's natural
-  // alignment and a target-specific fixed value (sometimes zero).
-  unsigned ZeroLengthBitfieldBoundary =
-Context.getTargetInfo().getZeroLengthBitfieldBoundary();
-  FieldAlign = std::max(FieldAlign, ZeroLengthBitfieldBoundary);
-
+  // Some targets don't honor leading zero-width bitfield.
+  if (!IsUnion && FieldOffset == 0 &&
+  !Context.getTargetInfo().useLeadingZeroLengthBitfield())
+FieldAlign = 1;
+  else {
+// The alignment to round up to is the max of the field's natural
+// alignment and a target-specific fixed value (sometimes zero).
+unsigned ZeroLengthBitfieldBoundary =
+Context.getTargetInfo().getZeroLengthBitfieldBoundary();
+FieldAlign = std::max(FieldAlign, ZeroLengthBitfieldBoundary);
+  }
 // If that doesn't apply, just ignore the field alignment.
 } else {
   FieldAlign = 1;
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -155,6 +155,10 @@
   /// zero-length bitfield.
   unsigned UseZeroLengthBitfieldAlignment : 1;
 
+  /// Whether zero length bitfield alignment is respected if they are the
+  /// leading members.
+  unsigned UseLeadingZeroLengthBitfield : 1;
+
   ///  Whether explicit bit field alignment attributes are honored.
   unsigned UseExplicitBitFieldAlignment : 1;
 
@@ -768,6 +772,12 @@
 return UseZeroLengthBitfieldAlignment;
   }
 
+  /// Check whether zero length bitfield alignment is respected if they are
+  /// leading members.
+  bool useLeadingZeroLengthBitfield() const {
+return UseLeadingZeroLengthBitfield;
+  }
+
   /// Get the fixed alignment value in bits for a member that 

[PATCH] D98889: [clang] Replaced some manual pointer tagging with llvm::PointerIntPair.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

Thanks! Do we need `InitializedEntity::getDecl` to return a pointer to 
non-const? Looks good assuming we do.




Comment at: clang/include/clang/Sema/Initialization.h:190
 /// When Kind == EK_Parameter, the ParmVarDecl, with the
 /// low bit indicating whether the parameter is "consumed".
+llvm::PointerIntPair Parameter;

Here and below, consider updating "the low[er] bit" to "the integer" or similar.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98889/new/

https://reviews.llvm.org/D98889

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 331660.
hoy added a comment.

Addresssing David's comment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98799/new/

https://reviews.llvm.org/D98799

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/unique-internal-linkage-names-dwarf.c


Index: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
===
--- clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
+++ clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
@@ -8,21 +8,48 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux -debug-info-kind=limited 
-dwarf-version=5 -funique-internal-linkage-names -emit-llvm -o -  %s | 
FileCheck %s --check-prefix=UNIQUE
 
 static int glob;
+// foo should be given a uniquefied name under -funique-internal-linkage-names.
 static int foo(void) {
   return glob;
 }
 
+// bar should not be given a uniquefied name under 
-funique-internal-linkage-names, 
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{
+  return glob + a;
+}
+
+// go should be given a uniquefied name under -funique-internal-linkage-names, 
even 
+// if its definition doesn't come with a valid prototype, but the declaration 
here
+// has a prototype.
+static int go(int);
+
 void baz() {
   foo();
+  bar(1);
+  go(2);
 }
 
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+
 // PLAIN: @glob = internal global i32
 // PLAIN: define internal i32 @foo()
+// PLAIN: define internal i32 @bar(i32 %a)
 // PLAIN: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // PLAIN: distinct !DISubprogram(name: "foo"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "bar"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "go"{{.*}})
 // PLAIN-NOT: linkageName:
 //
 // UNIQUE: @glob = internal global i32
 // UNIQUE: define internal i32 @_ZL3foov.[[MODHASH:__uniq.[0-9]+]]()
+// UNIQUE: define internal i32 @bar(i32 %a)
+// UNIQUE: define internal i32 @_ZL2goi.[[MODHASH]](i32 %a)
 // UNIQUE: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // UNIQUE: distinct !DISubprogram(name: "foo", linkageName: 
"_ZL3foov.[[MODHASH]]"{{.*}})
+// UNIQUE: distinct !DISubprogram(name: "go", linkageName: 
"_ZL2goi.[[MODHASH]]"{{.*}})
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3522,7 +3522,7 @@
llvm::DIScope *,
llvm::DINodeArray ,
llvm::DINode::DIFlags ) {
-  const auto *FD = cast(GD.getDecl());
+  const auto *FD = cast(GD.getCanonicalDecl().getDecl());
   Name = getFunctionName(FD);
   // Use mangled name as linkage name for C/C++ functions.
   if (FD->hasPrototype()) {
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -640,7 +640,7 @@
 
   // For C functions without prototypes, return false as their
   // names should not be mangled.
-  if (!FD->getType()->getAs())
+  if (!FD->hasPrototype())
 return false;
 
   if (isInternalLinkageDecl(ND))


Index: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
===
--- clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
+++ clang/test/CodeGen/unique-internal-linkage-names-dwarf.c
@@ -8,21 +8,48 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux -debug-info-kind=limited -dwarf-version=5 -funique-internal-linkage-names -emit-llvm -o -  %s | FileCheck %s --check-prefix=UNIQUE
 
 static int glob;
+// foo should be given a uniquefied name under -funique-internal-linkage-names.
 static int foo(void) {
   return glob;
 }
 
+// bar should not be given a uniquefied name under -funique-internal-linkage-names, 
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{
+  return glob + a;
+}
+
+// go should be given a uniquefied name under -funique-internal-linkage-names, even 
+// if its definition doesn't come with a valid prototype, but the declaration here
+// has a prototype.
+static int go(int);
+
 void baz() {
   foo();
+  bar(1);
+  go(2);
 }
 
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+
 // PLAIN: @glob = internal global i32
 // PLAIN: define internal i32 @foo()
+// PLAIN: define internal i32 @bar(i32 %a)
 // PLAIN: distinct !DIGlobalVariable(name: "glob"{{.*}})
 // PLAIN: distinct !DISubprogram(name: "foo"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "bar"{{.*}})
+// PLAIN: distinct !DISubprogram(name: "go"{{.*}})
 // PLAIN-NOT: linkageName:
 //
 // UNIQUE: @glob = internal global i32
 // UNIQUE: define internal i32 @_ZL3foov.[[MODHASH:__uniq.[0-9]+]]()
+// UNIQUE: define internal i32 @bar(i32 %a)
+// UNIQUE: define 

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:3525-3526
llvm::DINode::DIFlags ) {
-  const auto *FD = cast(GD.getDecl());
+  GlobalDecl CanonicalGD = GD.getCanonicalDecl();
+  const auto *FD = cast(CanonicalGD.getDecl());
   Name = getFunctionName(FD);

dblaikie wrote:
> I'd probably roll this into the expression rather than adding another named 
> variable - it doesn't seem to add much readability to me at least. Up to you.
Good point, fixed.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:18
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{

tmsriram wrote:
> Nice test, I didnt know you could do this!
I didn't know either. It's an old C usage. We hit this when compiling mysql.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

dblaikie wrote:
> Does this need to be down here? Or would the code be a well exercised if it 
> was up next to the go declaration above?
Yes, it needs to be here. Otherwise it will just like the function `bar` above 
that doesn't get a uniquefied name. I think moving the definition up to right 
after the declaration hides the declaration.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98799/new/

https://reviews.llvm.org/D98799

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98889: [clang] Replaced some manual pointer tagging with llvm::PointerIntPair.

[Josh Haberman via Phabricator via cfe-commits]

haberman created this revision.
haberman added a reviewer: rsmith.
haberman requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

There is no functional change here (hence no new tests). The only change
is to replace a couple uintptr_t members with llvm::PointerIntPair<> to
clean up the code, making it more readable and less error prone.

This cleanup highlighted that the old code was effectively casting away
const. This is fixed by changing some function signatures.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98889

Files:
  clang/include/clang/Sema/Initialization.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaInit.cpp

Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -24,6 +24,7 @@
 #include "clang/Sema/Lookup.h"
 #include "clang/Sema/SemaInternal.h"
 #include "llvm/ADT/APInt.h"
+#include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
@@ -3281,10 +3282,7 @@
   InitializedEntity Result;
   Result.Kind = EK_Base;
   Result.Parent = Parent;
-  Result.Base = reinterpret_cast(Base);
-  if (IsInheritedVirtualBase)
-Result.Base |= 0x01;
-
+  Result.Base = {Base, IsInheritedVirtualBase};
   Result.Type = Base->getType();
   return Result;
 }
@@ -3293,7 +3291,7 @@
   switch (getKind()) {
   case EK_Parameter:
   case EK_Parameter_CF_Audited: {
-ParmVarDecl *D = reinterpret_cast(Parameter & ~0x1);
+ParmVarDecl *D = Parameter.getPointer();
 return (D ? D->getDeclName() : DeclarationName());
   }
 
@@ -3336,7 +3334,7 @@
 
   case EK_Parameter:
   case EK_Parameter_CF_Audited:
-return reinterpret_cast(Parameter & ~0x1);
+return Parameter.getPointer();
 
   case EK_Result:
   case EK_StmtExprResult:
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -254,8 +254,7 @@
 ComputedEST = EST_None;
 }
 
-ExprResult Sema::ConvertParamDefaultArgument(const ParmVarDecl *Param,
- Expr *Arg,
+ExprResult Sema::ConvertParamDefaultArgument(ParmVarDecl *Param, Expr *Arg,
  SourceLocation EqualLoc) {
   if (RequireCompleteType(Param->getLocation(), Param->getType(),
   diag::err_typecheck_decl_incomplete_type))
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -2702,8 +2702,7 @@
   void ActOnParamUnparsedDefaultArgument(Decl *param, SourceLocation EqualLoc,
  SourceLocation ArgLoc);
   void ActOnParamDefaultArgumentError(Decl *param, SourceLocation EqualLoc);
-  ExprResult ConvertParamDefaultArgument(const ParmVarDecl *Param,
- Expr *DefaultArg,
+  ExprResult ConvertParamDefaultArgument(ParmVarDecl *Param, Expr *DefaultArg,
  SourceLocation EqualLoc);
   void SetParamDefaultArgument(ParmVarDecl *Param, Expr *DefaultArg,
SourceLocation EqualLoc);
Index: clang/include/clang/Sema/Initialization.h
===
--- clang/include/clang/Sema/Initialization.h
+++ clang/include/clang/Sema/Initialization.h
@@ -188,7 +188,7 @@
 
 /// When Kind == EK_Parameter, the ParmVarDecl, with the
 /// low bit indicating whether the parameter is "consumed".
-uintptr_t Parameter;
+llvm::PointerIntPair Parameter;
 
 /// When Kind == EK_Temporary or EK_CompoundLiteralInit, the type
 /// source information for the temporary.
@@ -199,7 +199,7 @@
 /// When Kind == EK_Base, the base specifier that provides the
 /// base class. The lower bit specifies whether the base is an inherited
 /// virtual base.
-uintptr_t Base;
+llvm::PointerIntPair Base;
 
 /// When Kind == EK_ArrayElement, EK_VectorElement, or
 /// EK_ComplexElement, the index of the array or vector element being
@@ -252,15 +252,14 @@
 
   /// Create the initialization entity for a parameter.
   static InitializedEntity InitializeParameter(ASTContext ,
-   const ParmVarDecl *Parm) {
+   ParmVarDecl *Parm) {
 return InitializeParameter(Context, Parm, Parm->getType());
   }
 
   /// Create the initialization entity for a parameter, but use
   /// another type.
-  static InitializedEntity InitializeParameter(ASTContext ,
-   const ParmVarDecl *Parm,
-   

[PATCH] D98827: [AST] Ensure that an empty json file is generated if compile errors

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

In D98827#2635303 , @njames93 wrote:

> Are there any tests that ensure something is always outputted?

The test verifies that the generated c++ either gives no introspection data or 
introspection data which the test expects.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98827/new/

https://reviews.llvm.org/D98827

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98887: [clang-cl] make -ffile-compilation-dir a CoreOption.

[Zequan Wu via Phabricator via cfe-commits]

zequanwu created this revision.
zequanwu added reviewers: thakis, phosek.
Herald added subscribers: jansvoboda11, dang.
zequanwu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Let clang-cl accepts `-ffile-compilation-dir` flag.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98887

Files:
  clang/include/clang/Driver/Options.td
  clang/test/Driver/cl-options.c


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -643,6 +643,7 @@
 // RUN: -fno-diagnostics-color \
 // RUN: -fdebug-compilation-dir . \
 // RUN: -fdebug-compilation-dir=. \
+// RUN: -ffile-compilation-dir=. \
 // RUN: -fdiagnostics-parseable-fixits \
 // RUN: -fdiagnostics-absolute-paths \
 // RUN: -ferror-limit=10 \
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1125,6 +1125,7 @@
 HelpText<"The compilation directory to embed in the coverage mapping.">,
 MarshallingInfoString>;
 def ffile_compilation_dir_EQ : Joined<["-"], "ffile-compilation-dir=">, 
Group,
+Flags<[CoreOption]>,
 HelpText<"The compilation directory to embed in the debug info and 
coverage mapping.">;
 defm debug_info_for_profiling : BoolFOption<"debug-info-for-profiling",
   CodeGenOpts<"DebugInfoForProfiling">, DefaultFalse,


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -643,6 +643,7 @@
 // RUN: -fno-diagnostics-color \
 // RUN: -fdebug-compilation-dir . \
 // RUN: -fdebug-compilation-dir=. \
+// RUN: -ffile-compilation-dir=. \
 // RUN: -fdiagnostics-parseable-fixits \
 // RUN: -fdiagnostics-absolute-paths \
 // RUN: -ferror-limit=10 \
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1125,6 +1125,7 @@
 HelpText<"The compilation directory to embed in the coverage mapping.">,
 MarshallingInfoString>;
 def ffile_compilation_dir_EQ : Joined<["-"], "ffile-compilation-dir=">, Group,
+Flags<[CoreOption]>,
 HelpText<"The compilation directory to embed in the debug info and coverage mapping.">;
 defm debug_info_for_profiling : BoolFOption<"debug-info-for-profiling",
   CodeGenOpts<"DebugInfoForProfiling">, DefaultFalse,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:18
+// since it doesn't come with valid prototype.
+static int bar(a) int a;
+{

Nice test, I didnt know you could do this!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98799/new/

https://reviews.llvm.org/D98799

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[David Blaikie via Phabricator via cfe-commits]

dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.

Looks good - couple of minor/optional things.




Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:3525-3526
llvm::DINode::DIFlags ) {
-  const auto *FD = cast(GD.getDecl());
+  GlobalDecl CanonicalGD = GD.getCanonicalDecl();
+  const auto *FD = cast(CanonicalGD.getDecl());
   Name = getFunctionName(FD);

I'd probably roll this into the expression rather than adding another named 
variable - it doesn't seem to add much readability to me at least. Up to you.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

Does this need to be down here? Or would the code be a well exercised if it was 
up next to the go declaration above?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98799/new/

https://reviews.llvm.org/D98799

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98881: [RISCV] Fix mcount name for Linux

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance created this revision.
Herald added subscribers: vkmr, evandro, luismarques, sameer.abuasal, 
s.egerton, Jim, benna, psnobl, PkmX, rogfer01, shiva0217, kito-cheng, simoncook.
nathanchance requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

GCC's name for this symbol is _mcount, which the Linux kernel expects in
a few different place:

$ echo 'int main(void) { return 0; }' | riscv32-linux-gcc -c -pg -o tmp.o -x c -

$ llvm-objdump -dr tmp.o | grep mcount

  000c:  R_RISCV_CALL _mcount

$ echo 'int main(void) { return 0; }' | riscv64-linux-gcc -c -pg -o tmp.o -x c -

$ llvm-objdump -dr tmp.o | grep mcount

  000c:  R_RISCV_CALL _mcount

$ echo 'int main(void) { return 0; }' | clang -c -pg -o tmp.o 
--target=riscv32-linux-gnu -x c -

$ llvm-objdump -dr tmp.o | grep mcount

  000a:  R_RISCV_CALL_PLT mcount

$ echo 'int main(void) { return 0; }' | clang -c -pg -o tmp.o 
--target=riscv64-linux-gnu -x c -

$ llvm-objdump -dr tmp.o | grep mcount

  000a:  R_RISCV_CALL_PLT mcount

Signed-off-by: Nathan Chancellor 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98881

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/CodeGen/mcount.c


Index: clang/test/CodeGen/mcount.c
===
--- clang/test/CodeGen/mcount.c
+++ clang/test/CodeGen/mcount.c
@@ -12,6 +12,8 @@
 // RUN: %clang_cc1 -pg -triple mipsel-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips64-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips64el-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple riscv32-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple riscv64-unknown-gnu-linux -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc64-netbsd -emit-llvm -o - %s | FileCheck 
-check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc64le-netbsd -emit-llvm -o - %s | 
FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -417,6 +417,8 @@
 case llvm::Triple::ppcle:
 case llvm::Triple::ppc64:
 case llvm::Triple::ppc64le:
+case llvm::Triple::riscv32:
+case llvm::Triple::riscv64:
   this->MCountName = "_mcount";
   break;
 case llvm::Triple::x86:


Index: clang/test/CodeGen/mcount.c
===
--- clang/test/CodeGen/mcount.c
+++ clang/test/CodeGen/mcount.c
@@ -12,6 +12,8 @@
 // RUN: %clang_cc1 -pg -triple mipsel-unknown-gnu-linux -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips64-unknown-gnu-linux -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple mips64el-unknown-gnu-linux -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple riscv32-unknown-gnu-linux -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
+// RUN: %clang_cc1 -pg -triple riscv64-unknown-gnu-linux -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc-netbsd -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc64-netbsd -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
 // RUN: %clang_cc1 -pg -triple powerpc64le-netbsd -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK-DOUBLE-PREFIXED,NO-MCOUNT1 %s
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -417,6 +417,8 @@
 case llvm::Triple::ppcle:
 case llvm::Triple::ppc64:
 case llvm::Triple::ppc64le:
+case llvm::Triple::riscv32:
+case llvm::Triple::riscv64:
   this->MCountName = "_mcount";
   break;
 case llvm::Triple::x86:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98745: [clang] Add fixit for Wreorder-ctor

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

Thanks for this! The changes LGTM, but wait to land it for a day or two in case 
@rsmith has concerns.




Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5242
+  if (Previous->isAnyMemberInitializer())
+Diag << 0 << Previous->getAnyMember()->getDeclName();
+  else

njames93 wrote:
> aaron.ballman wrote:
> > 
> This was copied from the old impl, Not sure it this is going to change 
> behaviour though.
> No tests needed to be updated though,
The diagnostic engine knows how to format anything that's a `NamedDecl` 
(including quoting it properly, etc), but it does the same work for 
`DeclarationName`. There shouldn't be a change in behavior in this case, just a 
slight simplification of code.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98745/new/

https://reviews.llvm.org/D98745

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98827: [AST] Ensure that an empty json file is generated if compile errors

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Are there any tests that ensure something is always outputted?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98827/new/

https://reviews.llvm.org/D98827

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98676: [WebAssembly] Finalize SIMD names and opcodes

[Thomas Lively via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf5764a8654e3: [WebAssembly] Finalize SIMD names and opcodes 
(authored by tlively).

Changed prior to commit:
  https://reviews.llvm.org/D98676?vs=330859=331639#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98676/new/

https://reviews.llvm.org/D98676

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/wasm_simd128.h
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-extending.ll
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
  llvm/test/CodeGen/WebAssembly/simd-widening.ll
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -280,38 +280,51 @@
 # CHECK: v128.bitselect # encoding: [0xfd,0x52]
 v128.bitselect
 
-# CHECK: v128.load8_lane 32, 1 # encoding: [0xfd,0x58,0x00,0x20,0x01]
+# TODO: v128.any_true # encoding: [0xfd,0x53]
+
+# CHECK: v128.load8_lane 32, 1 # encoding: [0xfd,0x54,0x00,0x20,0x01]
 v128.load8_lane 32, 1
 
-# CHECK: v128.load16_lane 32, 1 # encoding: [0xfd,0x59,0x01,0x20,0x01]
+# CHECK: v128.load16_lane 32, 1 # encoding: [0xfd,0x55,0x01,0x20,0x01]
 v128.load16_lane 32, 1
 
-# CHECK: v128.load32_lane 32, 1 # encoding: [0xfd,0x5a,0x02,0x20,0x01]
+# CHECK: v128.load32_lane 32, 1 # encoding: [0xfd,0x56,0x02,0x20,0x01]
 v128.load32_lane 32, 1
 
-# CHECK: v128.load64_lane 32, 1 # encoding: [0xfd,0x5b,0x03,0x20,0x01]
+# CHECK: v128.load64_lane 32, 1 # encoding: [0xfd,0x57,0x03,0x20,0x01]
 v128.load64_lane 32, 1
 
-# CHECK: v128.store8_lane 32, 1 # encoding: [0xfd,0x5c,0x00,0x20,0x01]
+# CHECK: v128.store8_lane 32, 1 # encoding: [0xfd,0x58,0x00,0x20,0x01]
 v128.store8_lane 32, 1
 
-# CHECK: v128.store16_lane 32, 1 # encoding: [0xfd,0x5d,0x01,0x20,0x01]
+# CHECK: v128.store16_lane 32, 1 # encoding: [0xfd,0x59,0x01,0x20,0x01]
 v128.store16_lane 32, 1
 
-# CHECK: v128.store32_lane 32, 1 # encoding: [0xfd,0x5e,0x02,0x20,0x01]
+# CHECK: v128.store32_lane 32, 1 # encoding: [0xfd,0x5a,0x02,0x20,0x01]
 v128.store32_lane 32, 1
 
-# CHECK: v128.store64_lane 32, 1 # encoding: [0xfd,0x5f,0x03,0x20,0x01]
+# CHECK: v128.store64_lane 32, 1 # encoding: [0xfd,0x5b,0x03,0x20,0x01]
 v128.store64_lane 32, 1
 
+# CHECK: v128.load32_zero 32 # encoding: [0xfd,0x5c,0x02,0x20]
+v128.load32_zero 32
+
+# CHECK: v128.load64_zero 32 # encoding: [0xfd,0x5d,0x03,0x20]
+v128.load64_zero 32
+
+# CHECK: f32x4.demote_zero_f64x2 # encoding: [0xfd,0x5e]
+f32x4.demote_zero_f64x2
+
+# CHECK: f64x2.promote_low_f32x4 # encoding: [0xfd,0x5f]
+f64x2.promote_low_f32x4
+
 # CHECK: i8x16.abs # encoding: [0xfd,0x60]
 i8x16.abs
 
 # CHECK: i8x16.neg # encoding: [0xfd,0x61]
 i8x16.neg
 
-# CHECK: i8x16.any_true # encoding: [0xfd,0x62]
-i8x16.any_true
+# TODO: i8x16.popcnt # encoding: [0xfd,0x62]
 
 # CHECK: i8x16.all_true # encoding: [0xfd,0x63]
 i8x16.all_true
@@ -325,6 +338,18 @@
 # CHECK: i8x16.narrow_i16x8_u # encoding: [0xfd,0x66]
 i8x16.narrow_i16x8_u
 
+# CHECK: f32x4.ceil # encoding: [0xfd,0x67]
+f32x4.ceil
+
+# CHECK: f32x4.floor # encoding: [0xfd,0x68]
+f32x4.floor
+
+# CHECK: f32x4.trunc # encoding: [0xfd,0x69]
+f32x4.trunc
+
+# CHECK: f32x4.nearest # encoding: [0xfd,0x6a]
+f32x4.nearest
+
 # CHECK: i8x16.shl # encoding: [0xfd,0x6b]
 i8x16.shl
 
@@ -337,20 +362,26 @@
 # CHECK: i8x16.add # encoding: [0xfd,0x6e]
 i8x16.add
 
-# CHECK: i8x16.add_saturate_s # encoding: [0xfd,0x6f]
-i8x16.add_saturate_s
+# CHECK: i8x16.add_sat_s # encoding: [0xfd,0x6f]
+i8x16.add_sat_s
 
-# CHECK: i8x16.add_saturate_u # encoding: [0xfd,0x70]
-i8x16.add_saturate_u
+# CHECK: i8x16.add_sat_u # encoding: [0xfd,0x70]
+i8x16.add_sat_u
 
 # CHECK: i8x16.sub # encoding: [0xfd,0x71]
 i8x16.sub
 
-# CHECK: i8x16.sub_saturate_s # encoding: [0xfd,0x72]
-i8x16.sub_saturate_s
+# CHECK: i8x16.sub_sat_s # encoding: [0xfd,0x72]
+i8x16.sub_sat_s
 
-# CHECK: i8x16.sub_saturate_u # encoding: [0xfd,0x73]
-i8x16.sub_saturate_u
+# CHECK: i8x16.sub_sat_u # encoding: [0xfd,0x73]
+i8x16.sub_sat_u
+
+# CHECK: f64x2.ceil # encoding: [0xfd,0x74]
+f64x2.ceil
+
+# CHECK: f64x2.floor # encoding: [0xfd,0x75]
+f64x2.floor
 
 # CHECK: i8x16.min_s # encoding: [0xfd,0x76]
 

[clang] f5764a8 - [WebAssembly] Finalize SIMD names and opcodes

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2021-03-18T11:21:25-07:00
New Revision: f5764a8654e3caa6ca5dab3a89238c165062228f

URL: 
https://github.com/llvm/llvm-project/commit/f5764a8654e3caa6ca5dab3a89238c165062228f
DIFF: 
https://github.com/llvm/llvm-project/commit/f5764a8654e3caa6ca5dab3a89238c165062228f.diff

LOG: [WebAssembly] Finalize SIMD names and opcodes

Updates the names (e.g. widen => extend, saturate => sat) and opcodes of all
SIMD instructions to match the finalized SIMD spec. Deliberately does not change
the public interface in wasm_simd128.h yet; that will require more care.

Depends on D98466.

Differential Revision: https://reviews.llvm.org/D98676

Added: 
llvm/test/CodeGen/WebAssembly/simd-extending.ll

Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Headers/wasm_simd128.h
clang/test/CodeGen/builtins-wasm.c
llvm/include/llvm/IR/IntrinsicsWebAssembly.td
llvm/lib/Target/WebAssembly/WebAssemblyISD.def
llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
llvm/test/MC/WebAssembly/simd-encodings.s

Removed: 
llvm/test/CodeGen/WebAssembly/simd-widening.ll



diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index 2f51376ba15a..6ea59026cd02 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -84,15 +84,15 @@ TARGET_BUILTIN(__builtin_wasm_replace_lane_i64x2, 
"V2LLiV2LLiIiLLi", "nc", "simd
 TARGET_BUILTIN(__builtin_wasm_replace_lane_f32x4, "V4fV4fIif", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_replace_lane_f64x2, "V2dV2dIid", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_add_saturate_s_i8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_add_saturate_u_i8x16, "V16UcV16UcV16Uc", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_add_saturate_s_i16x8, "V8sV8sV8s", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_add_saturate_u_i16x8, "V8UsV8UsV8Us", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_add_sat_s_i8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_add_sat_u_i8x16, "V16UcV16UcV16Uc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_add_sat_s_i16x8, "V8sV8sV8s", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_add_sat_u_i16x8, "V8UsV8UsV8Us", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_s_i8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_u_i8x16, "V16UcV16UcV16Uc", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_s_i16x8, "V8sV8sV8s", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_u_i16x8, "V8UsV8UsV8Us", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_sat_s_i8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_sat_u_i8x16, "V16UcV16UcV16Uc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_sat_s_i16x8, "V8sV8sV8s", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_sat_u_i16x8, "V8UsV8UsV8Us", "nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_abs_i8x16, "V16ScV16Sc", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_abs_i16x8, "V8sV8s", "nc", "simd128")
@@ -116,7 +116,7 @@ TARGET_BUILTIN(__builtin_wasm_avgr_u_i16x8, "V8UsV8UsV8Us", 
"nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_popcnt_i8x16, "V16ScV16Sc", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_q15mulr_saturate_s_i16x8, "V8sV8sV8s", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_q15mulr_sat_s_i16x8, "V8sV8sV8s", "nc", 
"simd128")
 
 TARGET_BUILTIN(__builtin_wasm_extmul_low_i8x16_s_i16x8, "V8sV16ScV16Sc", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_extmul_high_i8x16_s_i16x8, "V8sV16ScV16Sc", 
"nc", "simd128")
@@ -191,15 +191,15 @@ TARGET_BUILTIN(__builtin_wasm_narrow_u_i8x16_i16x8, 
"V16UcV8UsV8Us", "nc", "simd
 TARGET_BUILTIN(__builtin_wasm_narrow_s_i16x8_i32x4, "V8sV4iV4i", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_narrow_u_i16x8_i32x4, "V8UsV4UiV4Ui", "nc", 
"simd128")
 
-TARGET_BUILTIN(__builtin_wasm_widen_low_s_i32x4_i64x2, "V2LLiV4i", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_widen_high_s_i32x4_i64x2, "V2LLiV4i", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_widen_low_u_i32x4_i64x2, "V2LLUiV4Ui", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_widen_high_u_i32x4_i64x2, "V2LLUiV4Ui", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_extend_low_s_i32x4_i64x2, "V2LLiV4i", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_extend_high_s_i32x4_i64x2, "V2LLiV4i", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_extend_low_u_i32x4_i64x2, "V2LLUiV4Ui", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_extend_high_u_i32x4_i64x2, "V2LLUiV4Ui", "nc", 
"simd128")
 
 TARGET_BUILTIN(__builtin_wasm_convert_low_s_i32x4_f64x2, "V2dV4i", "nc", 

[PATCH] D98466: [WebAssembly] Remove experimental SIMD instructions

[Thomas Lively via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2f2ae08da91d: [WebAssembly] Remove experimental SIMD 
instructions (authored by tlively).

Changed prior to commit:
  https://reviews.llvm.org/D98466?vs=330116=331638#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98466/new/

https://reviews.llvm.org/D98466

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
  llvm/test/CodeGen/WebAssembly/simd-prefetch-offset.ll
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -664,18 +664,6 @@
 # CHECK: v128.load64_zero 32 # encoding: [0xfd,0xfd,0x01,0x03,0x20]
 v128.load64_zero 32
 
-# CHECK: f32x4.qfma # encoding: [0xfd,0xb4,0x01]
-f32x4.qfma
-
-# CHECK: f32x4.qfms # encoding: [0xfd,0xd4,0x01]
-f32x4.qfms
-
-# CHECK: f64x2.qfma # encoding: [0xfd,0xfe,0x01]
-f64x2.qfma
-
-# CHECK: f64x2.qfms # encoding: [0xfd,0xff,0x01]
-f64x2.qfms
-
 # CHECK: i16x8.extmul_low_i8x16_s # encoding: [0xfd,0x9a,0x01]
 i16x8.extmul_low_i8x16_s
 
@@ -712,18 +700,6 @@
 # CHECK: i64x2.extmul_high_i32x4_u # encoding: [0xfd,0xd7,0x01]
 i64x2.extmul_high_i32x4_u
 
-# CHECK: i8x16.signselect # encoding: [0xfd,0x7d]
-i8x16.signselect
-
-# CHECK: i16x8.signselect # encoding: [0xfd,0x7e]
-i16x8.signselect
-
-# CHECK: i32x4.signselect # encoding: [0xfd,0x7f]
-i32x4.signselect
-
-# CHECK: i64x2.signselect # encoding: [0xfd,0x94,0x01]
-i64x2.signselect
-
 # CHECK: i16x8.extadd_pairwise_i8x16_s # encoding: [0xfd,0xc2,0x01]
 i16x8.extadd_pairwise_i8x16_s
 
@@ -736,12 +712,6 @@
 # CHECK: i32x4.extadd_pairwise_i16x8_u # encoding: [0xfd,0xa6,0x01]
 i32x4.extadd_pairwise_i16x8_u
 
-# CHECK: prefetch.t 16 # encoding: [0xfd,0xc5,0x01,0x00,0x10]
-prefetch.t 16
-
-# CHECK: prefetch.nt 16 # encoding: [0xfd,0xc6,0x01,0x00,0x10]
-prefetch.nt 16
-
 # CHECK: f64x2.convert_low_i32x4_s # encoding: [0xfd,0x53]
 f64x2.convert_low_i32x4_s
 
@@ -760,10 +730,4 @@
 # CHECK: f64x2.promote_low_f32x4 # encoding: [0xfd,0x69]
 f64x2.promote_low_f32x4
 
-# CHECK: i32x4.widen_i8x16_s 3 # encoding: [0xfd,0x67,0x03]
-i32x4.widen_i8x16_s 3
-
-# CHECK: i32x4.widen_i8x16_u 3 # encoding: [0xfd,0x68,0x03]
-i32x4.widen_i8x16_u 3
-
 end_function
Index: llvm/test/CodeGen/WebAssembly/simd-prefetch-offset.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-prefetch-offset.ll
+++ /dev/null
@@ -1,235 +0,0 @@
-; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc < %s -verify-machineinstrs -mattr=+simd128 | FileCheck %s
-
-; Test experimental prefetch instructions
-
-target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
-target triple = "wasm32-unknown-unknown"
-
-declare void @llvm.wasm.prefetch.t(i8*)
-declare void @llvm.wasm.prefetch.nt(i8*)
-@gv = global i8 0
-
-;===
-; prefetch.t
-;===
-
-define void @prefetch_t_no_offset(i8* %p) {
-; CHECK-LABEL: prefetch_t_no_offset:
-; CHECK: .functype prefetch_t_no_offset (i32) -> ()
-; CHECK-NEXT:  # %bb.0:
-; CHECK-NEXT:local.get 0
-; CHECK-NEXT:prefetch.t 0
-; CHECK-NEXT:# fallthrough-return
-  tail call void @llvm.wasm.prefetch.t(i8* %p)
-  ret void
-}
-
-define void @prefetch_t_with_folded_offset(i8* %p) {
-; CHECK-LABEL: prefetch_t_with_folded_offset:
-; CHECK: .functype prefetch_t_with_folded_offset (i32) -> ()
-; CHECK-NEXT:  # %bb.0:
-; CHECK-NEXT:local.get 0
-; CHECK-NEXT:i32.const 24
-; CHECK-NEXT:i32.add
-; CHECK-NEXT:prefetch.t 0
-; CHECK-NEXT:# fallthrough-return
-  %q = ptrtoint i8* %p to i32
-  %r = add nuw i32 %q, 24
-  %s = inttoptr i32 %r to i8*
-  tail call void @llvm.wasm.prefetch.t(i8* %s)
-  ret void
-}
-
-define void @prefetch_t_with_folded_gep_offset(i8* %p) {
-; CHECK-LABEL: prefetch_t_with_folded_gep_offset:
-; CHECK: .functype prefetch_t_with_folded_gep_offset (i32) -> ()
-; CHECK-NEXT:  # %bb.0:
-; CHECK-NEXT:local.get 0
-; CHECK-NEXT:i32.const 6
-; CHECK-NEXT:i32.add
-; CHECK-NEXT:prefetch.t 0
-; CHECK-NEXT:# fallthrough-return
-  %s = getelementptr 

[clang] 2f2ae08 - [WebAssembly] Remove experimental SIMD instructions

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2021-03-18T11:21:24-07:00
New Revision: 2f2ae08da91dc5c188d5bb4d8b0b096d0a120a4a

URL: 
https://github.com/llvm/llvm-project/commit/2f2ae08da91dc5c188d5bb4d8b0b096d0a120a4a
DIFF: 
https://github.com/llvm/llvm-project/commit/2f2ae08da91dc5c188d5bb4d8b0b096d0a120a4a.diff

LOG: [WebAssembly] Remove experimental SIMD instructions

Removes the instruction definitions, intrinsics, and builtins for qfma/qfms,
signselect, and prefetch instructions, which were not included in the final
WebAssembly SIMD spec.

Depends on D98457.

Differential Revision: https://reviews.llvm.org/D98466

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-wasm.c
llvm/include/llvm/IR/IntrinsicsWebAssembly.td
llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h
llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
llvm/test/MC/WebAssembly/simd-encodings.s

Removed: 
llvm/test/CodeGen/WebAssembly/simd-prefetch-offset.ll



diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index 38de66587cba..2f51376ba15a 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -141,11 +141,6 @@ 
TARGET_BUILTIN(__builtin_wasm_extadd_pairwise_i16x8_u_i32x4, "V4UiV8Us", "nc", "
 
 TARGET_BUILTIN(__builtin_wasm_bitselect, "V4iV4iV4iV4i", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_signselect_i8x16, "V16ScV16ScV16ScV16Sc", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_signselect_i16x8, "V8sV8sV8sV8s", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_signselect_i32x4, "V4iV4iV4iV4i", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_signselect_i64x2, "V2LLiV2LLiV2LLiV2LLi", "nc", 
"simd128")
-
 TARGET_BUILTIN(__builtin_wasm_shuffle_v8x16, 
"V16ScV16ScV16ScIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi", "nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_any_true_i8x16, "iV16Sc", "nc", "simd128")
@@ -188,11 +183,6 @@ TARGET_BUILTIN(__builtin_wasm_dot_s_i32x4_i16x8, 
"V4iV8sV8s", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_sqrt_f32x4, "V4fV4f", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_sqrt_f64x2, "V2dV2d", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_qfma_f32x4, "V4fV4fV4fV4f", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_qfms_f32x4, "V4fV4fV4fV4f", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_qfma_f64x2, "V2dV2dV2dV2d", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_qfms_f64x2, "V2dV2dV2dV2d", "nc", "simd128")
-
 TARGET_BUILTIN(__builtin_wasm_trunc_saturate_s_i32x4_f32x4, "V4iV4f", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_trunc_saturate_u_i32x4_f32x4, "V4iV4f", "nc", 
"simd128")
 
@@ -206,9 +196,6 @@ TARGET_BUILTIN(__builtin_wasm_widen_high_s_i32x4_i64x2, 
"V2LLiV4i", "nc", "simd1
 TARGET_BUILTIN(__builtin_wasm_widen_low_u_i32x4_i64x2, "V2LLUiV4Ui", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_widen_high_u_i32x4_i64x2, "V2LLUiV4Ui", "nc", 
"simd128")
 
-TARGET_BUILTIN(__builtin_wasm_widen_s_i8x16_i32x4, "V4iV16ScIi", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_widen_u_i8x16_i32x4, "V4UiV16UcIi", "nc", 
"simd128")
-
 TARGET_BUILTIN(__builtin_wasm_convert_low_s_i32x4_f64x2, "V2dV4i", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_convert_low_u_i32x4_f64x2, "V2dV4Ui", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_trunc_saturate_zero_s_f64x2_i32x4, "V4iV2d", 
"nc", "simd128")
@@ -230,8 +217,5 @@ TARGET_BUILTIN(__builtin_wasm_store64_lane, "vLLi*V2LLiIi", 
"n", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_eq_i64x2, "V2LLiV2LLiV2LLi", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_prefetch_t, "vv*", "n", "simd128")
-TARGET_BUILTIN(__builtin_wasm_prefetch_nt, "vv*", "n", "simd128")
-
 #undef BUILTIN
 #undef TARGET_BUILTIN

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 8d1d3c50870c..96df7b0d6222 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -17366,17 +17366,6 @@ Value 
*CodeGenFunction::EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
 CGM.getIntrinsic(Intrinsic::wasm_bitselect, ConvertType(E->getType()));
 return Builder.CreateCall(Callee, {V1, V2, C});
   }
-  case WebAssembly::BI__builtin_wasm_signselect_i8x16:
-  case WebAssembly::BI__builtin_wasm_signselect_i16x8:
-  case WebAssembly::BI__builtin_wasm_signselect_i32x4:
-  case WebAssembly::BI__builtin_wasm_signselect_i64x2: {
-Value *V1 = EmitScalarExpr(E->getArg(0));
-Value *V2 = EmitScalarExpr(E->getArg(1));
-Value *C = EmitScalarExpr(E->getArg(2));
-Function *Callee =
-CGM.getIntrinsic(Intrinsic::wasm_signselect, 
ConvertType(E->getType()));
-return Builder.CreateCall(Callee, {V1, V2, 

[PATCH] D98745: [clang] Add fixit for Wreorder-ctor

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 331635.
njames93 marked an inline comment as done.
njames93 added a comment.

Address nits.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98745/new/

https://reviews.llvm.org/D98745

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/FixIt/fixit-cxx-init-order.cpp
  clang/test/SemaCXX/constructor-initializer.cpp
  clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp

Index: clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
===
--- clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
+++ clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
@@ -4,15 +4,14 @@
 
 struct BB1 {};
 
-class complex : public BB, BB1 { 
-public: 
+class complex : public BB, BB1 {
+public:
   complex()
-: s2(1), // expected-warning {{field 's2' will be initialized after field 's1'}}
-  s1(1),
-  s3(3), // expected-warning {{field 's3' will be initialized after base 'BB1'}} 
-  BB1(), // expected-warning {{base class 'BB1' will be initialized after base 'BB'}}
-  BB()
-  {}
+  : s2(1), // expected-warning {{initializer order does not match the declaration order}} expected-note {{field 's2' will be initialized after field 's1'}}
+s1(1),
+s3(3), // expected-note {{field 's3' will be initialized after base 'BB1'}}
+BB1(), // expected-note {{base class 'BB1' will be initialized after base 'BB'}}
+BB() {}
   int s1;
   int s2;
   int s3;
Index: clang/test/SemaCXX/constructor-initializer.cpp
===
--- clang/test/SemaCXX/constructor-initializer.cpp
+++ clang/test/SemaCXX/constructor-initializer.cpp
@@ -91,13 +91,14 @@
 
 struct Current : Derived {
   int Derived;
-  Current() : Derived(1), ::Derived(), // expected-warning {{field 'Derived' will be initialized after base '::Derived'}} \
-   // expected-warning {{base class '::Derived' will be initialized after base 'Derived::V'}}
-  ::Derived::Base(), // expected-error {{type '::Derived::Base' is not a direct or virtual base of 'Current'}}
-   Derived::Base1(), // expected-error {{type 'Derived::Base1' is not a direct or virtual base of 'Current'}}
-   Derived::V(),
-   ::NonExisting(), // expected-error {{member initializer 'NonExisting' does not name a non-static data member or}}
-   INT::NonExisting()  {} // expected-error {{'INT' (aka 'int') is not a class, namespace, or enumeration}} \
+  Current() : Derived(1), ::Derived(), // expected-warning {{initializer order does not match the declaration order}} \
+   // expected-note {{field 'Derived' will be initialized after base '::Derived'}} \
+   // expected-note {{base class '::Derived' will be initialized after base 'Derived::V'}}
+  ::Derived::Base(),   // expected-error {{type '::Derived::Base' is not a direct or virtual base of 'Current'}}
+  Derived::Base1(),// expected-error {{type 'Derived::Base1' is not a direct or virtual base of 'Current'}}
+  Derived::V(),
+  ::NonExisting(),  // expected-error {{member initializer 'NonExisting' does not name a non-static data member or}}
+  INT::NonExisting() {} // expected-error {{'INT' (aka 'int') is not a class, namespace, or enumeration}} \
   // expected-error {{member initializer 'NonExisting' does not name a non-static data member or}}
 };
 
Index: clang/test/FixIt/fixit-cxx-init-order.cpp
===
--- /dev/null
+++ clang/test/FixIt/fixit-cxx-init-order.cpp
@@ -0,0 +1,22 @@
+// Due to the fix having multiple edits we can't use
+// '-fdiagnostics-parseable-fixits' to determine if fixes are correct. However,
+// running fixit recompile with 'Werror' should fail if the fixes are invalid.
+
+// RUN: %clang_cc1 %s -Werror=reorder-ctor -fixit-recompile -fixit-to-temporary
+// RUN: %clang_cc1 %s -Wreorder-ctor -verify -verify-ignore-unexpected=note
+
+struct Foo {
+  int A, B, C;
+
+  Foo() : A(1), B(3), C(2) {}
+  Foo(int) : A(1), C(2), B(3) {}  // expected-warning {{field 'C' will be initialized after field 'B'}}
+  Foo(unsigned) : C(2), B(3), A(1) {} // expected-warning {{initializer order does not match the declaration order}}
+};
+
+struct Bar : Foo {
+  int D, E, F;
+
+  Bar() : Foo(), D(1), E(2), F(3) {}
+  Bar(int) : D(1), E(2), F(3), Foo(4) {}  // expected-warning {{field 'F' will be initialized after base 'Foo'}}
+  Bar(unsigned) : F(3), E(2), D(1), Foo(4) {} // expected-warning {{initializer order does not match the declaration order}}
+};

[PATCH] D98745: [clang] Add fixit for Wreorder-ctor

[Nathan James via Phabricator via cfe-commits]

njames93 marked 4 inline comments as done.
njames93 added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5242
+  if (Previous->isAnyMemberInitializer())
+Diag << 0 << Previous->getAnyMember()->getDeclName();
+  else

aaron.ballman wrote:
> 
This was copied from the old impl, Not sure it this is going to change 
behaviour though.
No tests needed to be updated though,


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98745/new/

https://reviews.llvm.org/D98745

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98867: [HIP] Fix ROCm detection

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:271
+}
+if (LatestROCm < FileName)
+  LatestROCm = FileName.str();

This will rank `rocm-3.9` higher than `rocm-3.10`. I think you do need to 
extract and compare the version.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98867/new/

https://reviews.llvm.org/D98867

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98278: [test] Add ability to get error messages from CMake for errc substitution

[Markus Böck via Phabricator via cfe-commits]

zero9178 added a comment.

In D98278#2635190 , @ashi1 wrote:

> In D98278#2618936 , @zero9178 wrote:
>
>> In D98278#2616932 , @mstorsjo wrote:
>>
>>> In D98278#2616916 , @zero9178 
>>> wrote:
>>>
 Add GetErrcMessages.cmake, which contains a cmake function to 
 automatically get the error messages of various posix error codes needed 
 by lit by running a small C++ program.
 Currently ENOENT, EISDIR, EINVAL and EACCES are supplied. 
 These error messages are then currently supplied to clang, llvm and lld as 
 the errc_messages config parameter.

 Regarding Cross compiling: the function uses try_run which when cross 
 compiling may use the CMAKE_CROSSCOMPILING_EMULATOR to run the code.
>>>
>>> How does it behave if such a thing isn't hooked up? Ideally it'd fall back 
>>> silently and these parts of tests would just fail, but not block things 
>>> overall.
>>
>> It will fall back to using Python's strerror, potentially failing if pythons 
>> strerror would not return the same strings (only the case for MSVC I 
>> believe).
>
> Hi, this patch is causing a failure when cmake runs `try_run()` with a 
> `CMAKE_TOOLCHAIN_FILE` defined. It seems related to having a fall back if the 
> try_run fails.
> Here is the error, and the build uses MSVC. What do you think we could do 
> about this? Thanks.
>
>   [06:48:06][Step 1/4] CMake Error: TRY_RUN() invoked in cross-compiling 
> mode, please set the following cache variables appropriately:
>   [06:48:06][Step 1/4]errc_exit_code (advanced)
>   [06:48:06][Step 1/4]errc_exit_code__TRYRUN_OUTPUT (advanced)
>   [06:48:06][Step 1/4] For details see /TryRunResults.cmake

Hello! There is actually an ongoing discussion about this here 
https://reviews.llvm.org/D98861. For the time being you have two options if you 
have a cross compiling setup that can't natively run Windows programs.

1. Set CMAKE_CROSSCOMPILING_EMULATOR to an emulator that could execute the 
Windows program on your host. Wine comes to my mind as an example
2. You should be able to set the variables `errc_exit_code` to the value 0 and 
then set `errc_exit_code__TRYRUN_OUTPUT` to the stdout of the Windows program 
(alternatively leave it empty, but a few tests will fail)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98278/new/

https://reviews.llvm.org/D98278

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98812: [OPENMP]Map data field with l-value reference types.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev updated this revision to Diff 331623.
ABataev added a comment.

Rebase + fixes for references to complex data structures mapping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98812/new/

https://reviews.llvm.org/D98812

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_map_codegen_28.cpp
  clang/test/OpenMP/target_map_codegen_35.cpp
  openmp/libomptarget/test/mapping/data_member_ref.cpp

Index: openmp/libomptarget/test/mapping/data_member_ref.cpp
===
--- /dev/null
+++ openmp/libomptarget/test/mapping/data_member_ref.cpp
@@ -0,0 +1,69 @@
+// RUN: %libomptarget-compilexx-run-and-check-aarch64-unknown-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64le-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-x86_64-pc-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-nvptx64-nvidia-cuda
+
+#include 
+
+struct View {
+  int Data;
+};
+
+struct ViewPtr {
+  int *Data;
+};
+
+template  struct Foo {
+  Foo(T ) : VRef(V) {}
+  T 
+};
+
+int main() {
+  View V;
+  V.Data = 123456;
+  Foo Bar(V);
+  ViewPtr V1;
+  int Data = 123456;
+  V1.Data = 
+  Foo Baz(V1);
+
+  // CHECK: Host 123456.
+  printf("Host %d.\n", Bar.VRef.Data);
+#pragma omp target map(Bar.VRef)
+  {
+// CHECK: Device 123456.
+printf("Device %d.\n", Bar.VRef.Data);
+V.Data = 654321;
+// CHECK: Device 654321.
+printf("Device %d.\n", Bar.VRef.Data);
+  }
+  // CHECK: Host 654321 654321.
+  printf("Host %d %d.\n", Bar.VRef.Data, V.Data);
+  V.Data = 123456;
+  // CHECK: Host 123456.
+  printf("Host %d.\n", Bar.VRef.Data);
+#pragma omp target map(Bar) map(Bar.VRef)
+  {
+// CHECK: Device 123456.
+printf("Device %d.\n", Bar.VRef.Data);
+V.Data = 654321;
+// CHECK: Device 654321.
+printf("Device %d.\n", Bar.VRef.Data);
+  }
+  // CHECK: Host 654321 654321.
+  printf("Host %d %d.\n", Bar.VRef.Data, V.Data);
+  // CHECK: Host 123456.
+  printf("Host %d.\n", *Baz.VRef.Data);
+#pragma omp target map(*Baz.VRef.Data)
+  {
+// CHECK: Device 123456.
+printf("Device %d.\n", *Baz.VRef.Data);
+*V1.Data = 654321;
+// CHECK: Device 654321.
+printf("Device %d.\n", *Baz.VRef.Data);
+  }
+  // CHECK: Host 654321 654321 654321.
+  printf("Host %d %d %d.\n", *Baz.VRef.Data, *V1.Data, Data);
+  return 0;
+}
Index: clang/test/OpenMP/target_map_codegen_35.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_map_codegen_35.cpp
@@ -0,0 +1,182 @@
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+///==///
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix CK35 --check-prefix CK35-64
+// RUN: %clang_cc1 -DCK35 -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK35 --check-prefix CK35-64
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s  --check-prefix CK35 --check-prefix CK35-32
+// RUN: %clang_cc1 -DCK35 -fopenmp -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK35 --check-prefix CK35-32
+
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY32 %s
+// RUN: %clang_cc1 -DCK35 -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY32 %s
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY32 %s
+// RUN: %clang_cc1 -DCK35 -fopenmp-simd -fopenmp-version=50 

[PATCH] D98278: [test] Add ability to get error messages from CMake for errc substitution

[Aaron Enye Shi via Phabricator via cfe-commits]

ashi1 added a comment.

In D98278#2618936 , @zero9178 wrote:

> In D98278#2616932 , @mstorsjo wrote:
>
>> In D98278#2616916 , @zero9178 wrote:
>>
>>> Add GetErrcMessages.cmake, which contains a cmake function to automatically 
>>> get the error messages of various posix error codes needed by lit by 
>>> running a small C++ program.
>>> Currently ENOENT, EISDIR, EINVAL and EACCES are supplied. 
>>> These error messages are then currently supplied to clang, llvm and lld as 
>>> the errc_messages config parameter.
>>>
>>> Regarding Cross compiling: the function uses try_run which when cross 
>>> compiling may use the CMAKE_CROSSCOMPILING_EMULATOR to run the code.
>>
>> How does it behave if such a thing isn't hooked up? Ideally it'd fall back 
>> silently and these parts of tests would just fail, but not block things 
>> overall.
>
> It will fall back to using Python's strerror, potentially failing if pythons 
> strerror would not return the same strings (only the case for MSVC I believe).

Hi, this patch is causing a failure when cmake runs `try_run()` with a 
`CMAKE_TOOLCHAIN_FILE` defined. It seems related to having a fall back if the 
try_run fails.
Here is the error, and the build uses MSVC. What do you think we could do about 
this? Thanks.

  [06:48:06][Step 1/4] CMake Error: TRY_RUN() invoked in cross-compiling mode, 
please set the following cache variables appropriately:
  [06:48:06][Step 1/4]errc_exit_code (advanced)
  [06:48:06][Step 1/4]errc_exit_code__TRYRUN_OUTPUT (advanced)
  [06:48:06][Step 1/4] For details see /TryRunResults.cmake


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98278/new/

https://reviews.llvm.org/D98278

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98855: [OpenCL] Support template parameters for as_type

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added inline comments.
Herald added a subscriber: ldrumm.



Comment at: clang/test/SemaOpenCLCXX/template-astype.cl:5
+auto templated_astype(T x) {
+  return as_int2(x);
+  // expected-error@-1{{invalid reinterpretation: sizes of 'int2' (vector of 2 
'int' values) and '__private int' must match}}

Anastasia wrote:
> could we also add another template with use of `__builtin_astype` directly?
> 
> In case we change as_type implementation one day the clang builtin will still 
> be tested too. :)
Sure, I can add extend this test with the following before committing, if that 
is okay with you?

```// Test __builtin_astype.
template 
auto templated_builtin_astype(T x) {
  return __builtin_astype(x, int2);
}

auto test_builtin(char8 x) { return templated_builtin_astype(x); }```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98855/new/

https://reviews.llvm.org/D98855

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98824: [Tooling] Handle compilation databases containing commands with double dashes

[Janusz Nykiel via Phabricator via cfe-commits]

jnykiel updated this revision to Diff 331605.
jnykiel added a comment.

Fixed logic error in `injectResourceDir` causing a test failure on the build 
machine.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98824/new/

https://reviews.llvm.org/D98824

Files:
  clang/lib/Tooling/ArgumentsAdjusters.cpp
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp

Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -812,6 +812,16 @@
   EXPECT_EQ(getCommand("dir/bar.cpp"), "clang -D dir/foo.cpp -Wall");
 }
 
+TEST_F(InterpolateTest, StripDoubleDash) {
+  add("dir/foo.cpp", "-o foo.o -std=c++14 -Wall -- dir/foo.cpp");
+  // input file and output option are removed
+  // -Wall flag isn't
+  // -std option gets re-added as the last argument before --
+  // new input file gets added after --
+  EXPECT_EQ(getCommand("dir/bar.cpp"),
+"clang -D dir/foo.cpp -Wall -std=c++14 --");
+}
+
 TEST_F(InterpolateTest, Case) {
   add("FOO/BAR/BAZ/SHOUT.cc");
   add("foo/bar/baz/quiet.cc");
Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -435,13 +435,18 @@
 static void injectResourceDir(CommandLineArguments , const char *Argv0,
   void *MainAddr) {
   // Allow users to override the resource dir.
-  for (StringRef Arg : Args)
+  for (StringRef Arg : Args) {
+if (Arg == "--")
+  break;
 if (Arg.startswith("-resource-dir"))
   return;
+  }
 
   // If there's no override in place add our resource dir.
-  Args.push_back("-resource-dir=" +
- CompilerInvocation::GetResourcesPath(Argv0, MainAddr));
+  std::string resourceDir = "-resource-dir=";
+  resourceDir.append(CompilerInvocation::GetResourcesPath(Argv0, MainAddr));
+  Args = getInsertArgumentAdjuster(CommandLineArguments(1, resourceDir),
+   ArgumentInsertPosition::END)(Args, "");
 }
 
 int ClangTool::run(ToolAction *Action) {
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -132,6 +132,8 @@
   LangStandard::Kind Std = LangStandard::lang_unspecified;
   // Whether the command line is for the cl-compatible driver.
   bool ClangCLMode;
+  // Whether to insert a double dash before the input file(s).
+  bool InsertDoubleDash = false;
 
   TransferableCommand(CompileCommand C)
   : Cmd(std::move(C)), Type(guessType(Cmd.Filename)),
@@ -177,6 +179,13 @@
Opt.matches(OPT__SLASH_Fo
 continue;
 
+  // ...including when the inputs are passed after --.
+  // If that is the case, record it.
+  if (Opt.matches(OPT__DASH_DASH)) {
+InsertDoubleDash = true;
+break;
+  }
+
   // Strip -x, but record the overridden language.
   if (const auto GivenType = tryParseTypeArg(*Arg)) {
 Type = *GivenType;
@@ -235,6 +244,8 @@
   llvm::Twine(ClangCLMode ? "/std:" : "-std=") +
   LangStandard::getLangStandardForKind(Std).getName()).str());
 }
+if (InsertDoubleDash)
+  Result.CommandLine.push_back("--");
 Result.CommandLine.push_back(std::string(Filename));
 return Result;
   }
Index: clang/lib/Tooling/ArgumentsAdjusters.cpp
===
--- clang/lib/Tooling/ArgumentsAdjusters.cpp
+++ clang/lib/Tooling/ArgumentsAdjusters.cpp
@@ -41,8 +41,13 @@
 "-save-temps",
 "--save-temps",
 };
-for (size_t i = 0, e = Args.size(); i < e; ++i) {
+size_t i = 0;
+for (size_t e = Args.size(); i < e; ++i) {
   StringRef Arg = Args[i];
+
+  if (Arg == "--")
+break;
+
   // Skip output commands.
   if (llvm::any_of(OutputCommands, [](llvm::StringRef OutputCommand) {
 return Arg.startswith(OutputCommand);
@@ -63,6 +68,8 @@
 }
 if (!HasSyntaxOnly)
   AdjustedArgs.push_back("-fsyntax-only");
+for (size_t e = Args.size(); i < e; ++i)
+  AdjustedArgs.push_back(Args[i]);
 return AdjustedArgs;
   };
 }
@@ -137,7 +144,7 @@
 
 CommandLineArguments::iterator I;
 if (Pos == ArgumentInsertPosition::END) {
-  I = Return.end();
+  I = std::find(Return.begin(), Return.end(), "--");
 } else {
   I = Return.begin();
   ++I; // To leave the program name in place
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98876: [clang][ASTImporter] Add import support for SourceLocExpr.

[Balázs Kéri via Phabricator via cfe-commits]

balazske created this revision.
Herald added subscribers: martong, teemperor, gamesh411, Szelethus, dkrupp.
Herald added a reviewer: a.sidorin.
Herald added a reviewer: shafik.
balazske requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

It is possible that imported SourceLocExpr
can cause not expected behavior (if __builtin_LINE() is used
together with __LINE__ for example) but still it may be worth
to import these because some projects use it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98876

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -246,6 +246,24 @@
   EXPECT_FALSE(path.hasCycleAtBack());
 }
 
+const internal::VariadicDynCastAllOfMatcher sourceLocExpr;
+
+AST_MATCHER_P(SourceLocExpr, hasBuiltinStr, StringRef, Str) {
+  return Node.getBuiltinStr() == Str;
+}
+
+TEST_P(ImportExpr, ImportSourceLocExpr) {
+  MatchVerifier Verifier;
+  testImport("void declToImport() { (void)__builtin_FILE(); }", Lang_CXX03, "",
+ Lang_CXX03, Verifier,
+ functionDecl(hasDescendant(
+ sourceLocExpr(hasBuiltinStr("__builtin_FILE");
+  testImport("void declToImport() { (void)__builtin_COLUMN(); }", Lang_CXX03,
+ "", Lang_CXX03, Verifier,
+ functionDecl(hasDescendant(
+ sourceLocExpr(hasBuiltinStr("__builtin_COLUMN");
+}
+
 TEST_P(ImportExpr, ImportStringLiteral) {
   MatchVerifier Verifier;
   testImport("void declToImport() { (void)\"foo\"; }", Lang_CXX03, "",
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -574,6 +574,7 @@
 
 // Importing expressions
 ExpectedStmt VisitExpr(Expr *E);
+ExpectedStmt VisitSourceLocExpr(SourceLocExpr *E);
 ExpectedStmt VisitVAArgExpr(VAArgExpr *E);
 ExpectedStmt VisitChooseExpr(ChooseExpr *E);
 ExpectedStmt VisitGNUNullExpr(GNUNullExpr *E);
@@ -6482,6 +6483,21 @@
   return make_error(ImportError::UnsupportedConstruct);
 }
 
+ExpectedStmt ASTNodeImporter::VisitSourceLocExpr(SourceLocExpr *E) {
+  Error Err = Error::success();
+  auto BLoc = importChecked(Err, E->getBeginLoc());
+  auto RParenLoc = importChecked(Err, E->getEndLoc());
+  if (Err)
+return std::move(Err);
+  auto ParentContextOrErr = Importer.ImportContext(E->getParentContext());
+  if (!ParentContextOrErr)
+return ParentContextOrErr.takeError();
+
+  return new (Importer.getToContext())
+  SourceLocExpr(Importer.getToContext(), E->getIdentKind(), BLoc, 
RParenLoc,
+*ParentContextOrErr);
+}
+
 ExpectedStmt ASTNodeImporter::VisitVAArgExpr(VAArgExpr *E) {
 
   Error Err = Error::success();


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -246,6 +246,24 @@
   EXPECT_FALSE(path.hasCycleAtBack());
 }
 
+const internal::VariadicDynCastAllOfMatcher sourceLocExpr;
+
+AST_MATCHER_P(SourceLocExpr, hasBuiltinStr, StringRef, Str) {
+  return Node.getBuiltinStr() == Str;
+}
+
+TEST_P(ImportExpr, ImportSourceLocExpr) {
+  MatchVerifier Verifier;
+  testImport("void declToImport() { (void)__builtin_FILE(); }", Lang_CXX03, "",
+ Lang_CXX03, Verifier,
+ functionDecl(hasDescendant(
+ sourceLocExpr(hasBuiltinStr("__builtin_FILE");
+  testImport("void declToImport() { (void)__builtin_COLUMN(); }", Lang_CXX03,
+ "", Lang_CXX03, Verifier,
+ functionDecl(hasDescendant(
+ sourceLocExpr(hasBuiltinStr("__builtin_COLUMN");
+}
+
 TEST_P(ImportExpr, ImportStringLiteral) {
   MatchVerifier Verifier;
   testImport("void declToImport() { (void)\"foo\"; }", Lang_CXX03, "",
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -574,6 +574,7 @@
 
 // Importing expressions
 ExpectedStmt VisitExpr(Expr *E);
+ExpectedStmt VisitSourceLocExpr(SourceLocExpr *E);
 ExpectedStmt VisitVAArgExpr(VAArgExpr *E);
 ExpectedStmt VisitChooseExpr(ChooseExpr *E);
 ExpectedStmt VisitGNUNullExpr(GNUNullExpr *E);
@@ -6482,6 +6483,21 @@
   return make_error(ImportError::UnsupportedConstruct);
 }
 
+ExpectedStmt ASTNodeImporter::VisitSourceLocExpr(SourceLocExpr *E) {
+  Error Err = Error::success();
+  auto BLoc = importChecked(Err, E->getBeginLoc());
+  auto RParenLoc = importChecked(Err, E->getEndLoc());
+  if (Err)
+return std::move(Err);
+  auto ParentContextOrErr = 

[PATCH] D98745: [clang] Add fixit for Wreorder-ctor

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8611
+def warn_some_initializers_out_of_order : Warning<
+  "some initializers aren't given in the correct order">,
+  InGroup, DefaultIgnore;

Hmmm, how about `initializer order does not match the declaration order` or 
something along those lines? The "some" and "in the correct order" feel a bit 
hand-wavy for a warning.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5242
+  if (Previous->isAnyMemberInitializer())
+Diag << 0 << Previous->getAnyMember()->getDeclName();
+  else





Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5247
+  if (Current->isAnyMemberInitializer())
+Diag << 0 << Current->getAnyMember()->getDeclName();
+  else





Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5304
+  SmallVector WarnIndexes;
+  // Correllates the index of an initializer in the init-list to the index of
+  // the field/base in the class.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98745/new/

https://reviews.llvm.org/D98745

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98864: [SystemZ][z/OS] Set maximum value to truncate attribute aligned to for static variables on z/OS target

[Abhina Sree via Phabricator via cfe-commits]

abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan added a comment.
This revision is now accepted and ready to land.

LGTM


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98864/new/

https://reviews.llvm.org/D98864

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 92ccc6c - Reapply "[NPM][CGSCC] FunctionAnalysisManagerCGSCCProxy: do not clear immutable function passes"

[Mircea Trofin via cfe-commits]

Author: Mircea Trofin
Date: 2021-03-18T09:44:34-07:00
New Revision: 92ccc6cb17a4fd1b9506bac51f2eb1a96f4cd345

URL: 
https://github.com/llvm/llvm-project/commit/92ccc6cb17a4fd1b9506bac51f2eb1a96f4cd345
DIFF: 
https://github.com/llvm/llvm-project/commit/92ccc6cb17a4fd1b9506bac51f2eb1a96f4cd345.diff

LOG: Reapply "[NPM][CGSCC] FunctionAnalysisManagerCGSCCProxy: do not clear 
immutable function passes"

This reverts commit 11b70b9e3a7458b5b78c30020b56e8ca563a4801.

The bot failure was due to ArgumentPromotion deleting functions
without deleting their analyses. This was separately fixed in 4b1c807.

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
llvm/lib/Analysis/CGSCCPassManager.cpp
llvm/unittests/Analysis/CGSCCPassManagerTest.cpp

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-newpm.ll 
b/clang/test/CodeGen/thinlto-distributed-newpm.ll
index 867203417754..1e9d5d4d2629 100644
--- a/clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ b/clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -12,7 +12,7 @@
 ; RUN: %clang -target x86_64-grtev4-linux-gnu \
 ; RUN:   -O2 -fexperimental-new-pass-manager -Xclang -fdebug-pass-manager \
 ; RUN:   -c -fthinlto-index=%t.o.thinlto.bc \
-; RUN:   -o %t.native.o -x ir %t.o 2>&1 | FileCheck 
-check-prefixes=CHECK-O,CHECK-O2 %s --dump-input=fail
+; RUN:   -o %t.native.o -x ir %t.o 2>&1 | FileCheck -check-prefix=CHECK-O %s 
--dump-input=fail
 
 ; RUN: %clang -target x86_64-grtev4-linux-gnu \
 ; RUN:   -O3 -fexperimental-new-pass-manager -Xclang -fdebug-pass-manager \
@@ -70,24 +70,19 @@
 ; CHECK-O: Starting CGSCC pass manager run.
 ; CHECK-O: Running pass: InlinerPass on (main)
 ; CHECK-O: Running pass: PostOrderFunctionAttrsPass on (main)
-; CHECK-O: Clearing all analysis results for: main
+; CHECK-O: Invalidating analysis: DominatorTreeAnalysis on main
+; CHECK-O: Invalidating analysis: BasicAA on main
+; CHECK-O: Invalidating analysis: AAManager on main
 ; CHECK-O3: Running pass: ArgumentPromotionPass on (main)
-; CHECK-O3: Running analysis: TargetIRAnalysis on main
 ; CHECK-O: Starting {{.*}}Function pass manager run.
 ; CHECK-O: Running pass: SROA on main
 ; These next two can appear in any order since they are accessed as parameters
 ; on the same call to SROA::runImpl
 ; CHECK-O-DAG: Running analysis: DominatorTreeAnalysis on main
-; CHECK-O-DAG: Running analysis: AssumptionAnalysis on main
 ; CHECK-O: Running pass: EarlyCSEPass on main
-; CHECK-O: Running analysis: TargetLibraryAnalysis on main
-; CHECK-O2: Running analysis: TargetIRAnalysis on main
 ; CHECK-O: Running analysis: MemorySSAAnalysis on main
 ; CHECK-O: Running analysis: AAManager on main
 ; CHECK-O: Running analysis: BasicAA on main
-; CHECK-O: Running analysis: ScopedNoAliasAA on main
-; CHECK-O: Running analysis: TypeBasedAA on main
-; CHECK-O: Running analysis: OuterAnalysisManagerProxy
 ; CHECK-O: Running pass: SpeculativeExecutionPass on main
 ; CHECK-O: Running pass: JumpThreadingPass on main
 ; CHECK-O: Running analysis: LazyValueAnalysis on main
@@ -96,7 +91,6 @@
 ; CHECK-O: Running pass: SimplifyCFGPass on main
 ; CHECK-O3: Running pass: AggressiveInstCombinePass on main
 ; CHECK-O: Running pass: InstCombinePass on main
-; CHECK-O: Running analysis: OptimizationRemarkEmitterAnalysis on main
 ; CHECK-O: Running pass: LibCallsShrinkWrapPass on main
 ; CHECK-O: Running pass: TailCallElimPass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main

diff  --git a/llvm/lib/Analysis/CGSCCPassManager.cpp 
b/llvm/lib/Analysis/CGSCCPassManager.cpp
index 9dc62b877ae2..eaaa3d09a7f2 100644
--- a/llvm/lib/Analysis/CGSCCPassManager.cpp
+++ b/llvm/lib/Analysis/CGSCCPassManager.cpp
@@ -720,7 +720,7 @@ bool FunctionAnalysisManagerCGSCCProxy::Result::invalidate(
   auto PAC = PA.getChecker();
   if (!PAC.preserved() && 
!PAC.preservedSet>()) {
 for (LazyCallGraph::Node  : C)
-  FAM->clear(N.getFunction(), N.getFunction().getName());
+  FAM->invalidate(N.getFunction(), PA);
 
 return false;
   }

diff  --git a/llvm/unittests/Analysis/CGSCCPassManagerTest.cpp 
b/llvm/unittests/Analysis/CGSCCPassManagerTest.cpp
index 59ff97d0fc1a..ceaeaaf83e5d 100644
--- a/llvm/unittests/Analysis/CGSCCPassManagerTest.cpp
+++ b/llvm/unittests/Analysis/CGSCCPassManagerTest.cpp
@@ -1942,5 +1942,30 @@ TEST_F(CGSCCPassManagerTest, 
TestInsertionOfNewNonTrivialCallEdge) {
   ASSERT_TRUE(Ran);
 }
 
+TEST_F(CGSCCPassManagerTest, TestFunctionPassesAreQueriedForInvalidation) {
+  std::unique_ptr M = parseIR("define void @f() { ret void }");
+  CGSCCPassManager CGPM;
+  bool SCCCalled = false;
+  FunctionPassManager FPM;
+  int ImmRuns = 0;
+  FAM.registerPass([&] { return TestImmutableFunctionAnalysis(ImmRuns); });
+  FPM.addPass(RequireAnalysisPass());
+  CGPM.addPass(
+  LambdaSCCPass([&](LazyCallGraph::SCC , CGSCCAnalysisManager ,
+LazyCallGraph , 

[PATCH] D95460: [flang][driver] Add forced form flags and -ffixed-line-length

[Joachim Protze via Phabricator via cfe-commits]

protze.joachim added a comment.

Hi Andrzej,

thanks for the detailed insights. I think I really misunderstood, what the -W 
flags can do here. I also was not up-to-date regarding the state of the flang 
implementation.

I just found, that compiling Spec OMP 2012 with clang-12 worked fine with my 
configuration, but compiling with current HEAD failed. Bisecting brought me to 
this patch.
What my build configuration basically does is to use gfortran to compile 
Fortran source to object files. Then I use clang/clang++ to link all the object 
files, basically:

  gfortran -c foo.f
  clang -lgfortran --gcc-toolchain=$(dirname $(dirname $(which gcc))) foo.o

In the build configuration, I can set FPORTABILITY flags for specific apps, but 
these flags are unfortunately passed to both the compile and the link step. 
Setting FLD to clang used to work, and now it broke.

One of my reasons for linking with clang is to make sure, that as much LLVM 
libraries as possible are linked. Especially, I want to pick up the LLVM 
version of the ThreadSanitizer runtime.

I tried to change my build configuration to use flang. After fixing some of the 
code (removing save keyword from variables, when having a global save), I could 
successfully compile one of the codes. Since flang under the hood uses gfortran 
for linking, this configuration picks up the GNU version of the ThreadSanitizer 
runtime. The GNU runtime is typically built as a dynamic library and comes with 
~30-40% performance penalty. So, even when compiling with flang, I would prefer 
to link using clang.

I have no idea about the compiler internals, but would it be possible to mark 
the flang flags as known to the compiler tool-chain, but not used in case of 
clang? Finally, this would result in a `-Wunused-command-line-argument` warning.

Best
Joachim


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95460/new/

https://reviews.llvm.org/D95460

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Whisperity via Phabricator via cfe-commits]

whisperity marked 5 inline comments as done.
whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:377
+
+  bool indicatesMixability() const { return Flags > MIX_None; }
+

aaron.ballman wrote:
> Should this be `MIX_WorkaroundDisableCanonicalEquivalence` instead of 
> `MIX_None`?
In this patch I changed the value of `None` to be `2`, and `Workaround...` 
became `1`. So everything above `None` means it's a valid mixability (somehow), 
of course only after `sanitize()` so `Workaround... | CanonicalType` becomes 
`None`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75041/new/

https://reviews.llvm.org/D75041

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98834: [OPENMP51]Support for the 'destroy' clause with interop variable

[Mike Rice via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc2f8e158f57c: [OPENMP51]Support for the destroy 
clause with interop variable. (authored by mikerice).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98834/new/

https://reviews.llvm.org/D98834

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/interop_ast_print.cpp
  clang/test/OpenMP/interop_messages.cpp
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -1650,6 +1650,7 @@
   let allowedClauses = [
 VersionedClause,
 VersionedClause,
+VersionedClause,
 VersionedClause,
 VersionedClause,
 VersionedClause,
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2286,7 +2286,10 @@
   Visitor->AddStmt(C->getInteropVar());
 }
 
-void OMPClauseEnqueue::VisitOMPDestroyClause(const OMPDestroyClause *) {}
+void OMPClauseEnqueue::VisitOMPDestroyClause(const OMPDestroyClause *C) {
+  if (C->getInteropVar())
+Visitor->AddStmt(C->getInteropVar());
+}
 
 void OMPClauseEnqueue::VisitOMPUnifiedAddressClause(
 const OMPUnifiedAddressClause *) {}
Index: clang/test/OpenMP/interop_messages.cpp
===
--- clang/test/OpenMP/interop_messages.cpp
+++ clang/test/OpenMP/interop_messages.cpp
@@ -17,6 +17,9 @@
   //expected-error@+1 {{use of undeclared identifier 'NoDeclVar'}}
   #pragma omp interop use(NoDeclVar) use(Another)
 
+  //expected-error@+1 {{use of undeclared identifier 'NoDeclVar'}}
+  #pragma omp interop destroy(NoDeclVar) destroy(Another)
+
   //expected-error@+2 {{expected interop type: 'target' and/or 'targetsync'}}
   //expected-error@+1 {{expected expression}}
   #pragma omp interop init(InteropVar) init(target:Another)
@@ -38,6 +41,9 @@
   //expected-error@+1 {{interop variable must be of type 'omp_interop_t'}}
   #pragma omp interop use(IntVar) use(Another)
 
+  //expected-error@+1 {{interop variable must be of type 'omp_interop_t'}}
+  #pragma omp interop destroy(IntVar) destroy(Another)
+
   //expected-error@+1 {{interop variable must be of type 'omp_interop_t'}}
   #pragma omp interop init(prefer_type(1,"sycl",3),target:SVar) \
   init(target:Another)
@@ -45,6 +51,9 @@
   //expected-error@+1 {{interop variable must be of type 'omp_interop_t'}}
   #pragma omp interop use(SVar) use(Another)
 
+  //expected-error@+1 {{interop variable must be of type 'omp_interop_t'}}
+  #pragma omp interop destroy(SVar) destroy(Another)
+
   int a, b;
   //expected-error@+1 {{expected variable of type 'omp_interop_t'}}
   #pragma omp interop init(target:a+b) init(target:Another)
@@ -52,10 +61,16 @@
   //expected-error@+1 {{expected variable of type 'omp_interop_t'}}
   #pragma omp interop use(a+b) use(Another)
 
+  //expected-error@+1 {{expected variable of type 'omp_interop_t'}}
+  #pragma omp interop destroy(a+b) destroy(Another)
+
   const omp_interop_t C = (omp_interop_t)5;
   //expected-error@+1 {{expected non-const variable of type 'omp_interop_t'}}
   #pragma omp interop init(target:C) init(target:Another)
 
+  //expected-error@+1 {{expected non-const variable of type 'omp_interop_t'}}
+  #pragma omp interop destroy(C) destroy(Another)
+
   //expected-error@+1 {{prefer_list item must be a string literal or constant integral expression}}
   #pragma omp interop init(prefer_type(1.0),target:InteropVar) \
   init(target:Another)
@@ -79,9 +94,18 @@
   //expected-error@+1 {{interop variable 'InteropVar' used in multiple action clauses}}
   #pragma omp interop use(InteropVar) use(InteropVar)
 
+  //expected-error@+1 {{interop variable 'InteropVar' used in multiple action clauses}}
+  #pragma omp interop destroy(InteropVar) destroy(InteropVar)
+
   //expected-error@+1 {{interop variable 'InteropVar' used in multiple action clauses}}
   #pragma omp interop init(target:InteropVar) use(InteropVar)
 
+  //expected-error@+1 {{interop variable 'InteropVar' used in multiple action clauses}}
+  #pragma omp interop init(target:InteropVar) destroy(InteropVar)
+
+  //expected-error@+1 {{interop variable 'InteropVar' used in multiple action clauses}}
+  #pragma omp interop use(InteropVar) destroy(InteropVar)

[clang] c2f8e15 - [OPENMP51]Support for the 'destroy' clause with interop variable.

[Mike Rice via cfe-commits]

Author: Mike Rice
Date: 2021-03-18T09:12:56-07:00
New Revision: c2f8e158f57c173298ac39db8fd44211604ed003

URL: 
https://github.com/llvm/llvm-project/commit/c2f8e158f57c173298ac39db8fd44211604ed003
DIFF: 
https://github.com/llvm/llvm-project/commit/c2f8e158f57c173298ac39db8fd44211604ed003.diff

LOG: [OPENMP51]Support for the 'destroy' clause with interop variable.

Added basic parsing/sema/serialization support to extend the
existing 'destroy' clause for use with the 'interop' directive.

Differential Revision: https://reviews.llvm.org/D98834

Added: 


Modified: 
clang/include/clang/AST/OpenMPClause.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/OpenMPClause.cpp
clang/lib/AST/StmtProfile.cpp
clang/lib/Parse/ParseOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/test/OpenMP/interop_ast_print.cpp
clang/test/OpenMP/interop_messages.cpp
clang/tools/libclang/CIndex.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td

Removed: 




diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index b342ffb93256..f71eb15feea2 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -7561,14 +7561,49 @@ class OMPUseClause final : public OMPClause {
 };
 
 /// This represents 'destroy' clause in the '#pragma omp depobj'
-/// directive.
+/// directive or the '#pragma omp interop' directive..
 ///
 /// \code
 /// #pragma omp depobj(a) destroy
+/// #pragma omp interop destroy(obj)
 /// \endcode
-/// In this example directive '#pragma omp depobj' has 'destroy' clause.
+/// In these examples directive '#pragma omp depobj' and '#pragma omp interop'
+/// have a 'destroy' clause. The 'interop' directive includes an object.
 class OMPDestroyClause final : public OMPClause {
+  friend class OMPClauseReader;
+
+  /// Location of '('.
+  SourceLocation LParenLoc;
+
+  /// Location of interop variable.
+  SourceLocation VarLoc;
+
+  /// The interop variable.
+  Stmt *InteropVar = nullptr;
+
+  /// Set the interop variable.
+  void setInteropVar(Expr *E) { InteropVar = E; }
+
+  /// Sets the location of '('.
+  void setLParenLoc(SourceLocation Loc) { LParenLoc = Loc; }
+
+  /// Sets the location of the interop variable.
+  void setVarLoc(SourceLocation Loc) { VarLoc = Loc; }
+
 public:
+  /// Build 'destroy' clause with an interop variable expression \a InteropVar.
+  ///
+  /// \param InteropVar The interop variable.
+  /// \param StartLoc Starting location of the clause.
+  /// \param LParenLoc Location of '('.
+  /// \param VarLoc Location of the interop variable.
+  /// \param EndLoc Ending location of the clause.
+  OMPDestroyClause(Expr *InteropVar, SourceLocation StartLoc,
+   SourceLocation LParenLoc, SourceLocation VarLoc,
+   SourceLocation EndLoc)
+  : OMPClause(llvm::omp::OMPC_destroy, StartLoc, EndLoc),
+LParenLoc(LParenLoc), VarLoc(VarLoc), InteropVar(InteropVar) {}
+
   /// Build 'destroy' clause.
   ///
   /// \param StartLoc Starting location of the clause.
@@ -7581,11 +7616,24 @@ class OMPDestroyClause final : public OMPClause {
   : OMPClause(llvm::omp::OMPC_destroy, SourceLocation(), SourceLocation()) 
{
   }
 
+  /// Returns the location of '('.
+  SourceLocation getLParenLoc() const { return LParenLoc; }
+
+  /// Returns the location of the interop variable.
+  SourceLocation getVarLoc() const { return VarLoc; }
+
+  /// Returns the interop variable.
+  Expr *getInteropVar() const { return cast_or_null(InteropVar); }
+
   child_range children() {
+if (InteropVar)
+  return child_range(,  + 1);
 return child_range(child_iterator(), child_iterator());
   }
 
   const_child_range children() const {
+if (InteropVar)
+  return const_child_range(,  + 1);
 return const_child_range(const_child_iterator(), const_child_iterator());
   }
 

diff  --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 4a7c234e374b..256f73338bd2 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -3210,7 +3210,8 @@ bool 
RecursiveASTVisitor::VisitOMPUseClause(OMPUseClause *C) {
 }
 
 template 
-bool RecursiveASTVisitor::VisitOMPDestroyClause(OMPDestroyClause *) {
+bool RecursiveASTVisitor::VisitOMPDestroyClause(OMPDestroyClause *C) {
+  TRY_TO(TraverseStmt(C->getInteropVar()));
   return true;
 }
 

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 978c5de57646..b144587650eb 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10998,8 +10998,11 @@ class Sema final {
   SourceLocation VarLoc, 

[PATCH] D98415: [aarch64][WOA64][docs] Release note for WoA-hosted LLVM 12 binary

[Maxim Kuvyrkov via Phabricator via cfe-commits]

maxim-kuvyrkov closed this revision.
maxim-kuvyrkov added a comment.

This is merged to release/12.x branch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98415/new/

https://reviews.llvm.org/D98415

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98745: [clang] Add fixit for Wreorder-ctor

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 331582.
njames93 added a comment.

Arc got confused


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98745/new/

https://reviews.llvm.org/D98745

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/FixIt/fixit-cxx-init-order.cpp
  clang/test/SemaCXX/constructor-initializer.cpp
  clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp

Index: clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
===
--- clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
+++ clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
@@ -5,14 +5,13 @@
 struct BB1 {};
 
 class complex : public BB, BB1 { 
-public: 
+public:
   complex()
-: s2(1), // expected-warning {{field 's2' will be initialized after field 's1'}}
-  s1(1),
-  s3(3), // expected-warning {{field 's3' will be initialized after base 'BB1'}} 
-  BB1(), // expected-warning {{base class 'BB1' will be initialized after base 'BB'}}
-  BB()
-  {}
+  : s2(1), // expected-warning {{some initializers aren't given in the correct order}} expected-note {{field 's2' will be initialized after field 's1'}}
+s1(1),
+s3(3), // expected-note {{field 's3' will be initialized after base 'BB1'}}
+BB1(), // expected-note {{base class 'BB1' will be initialized after base 'BB'}}
+BB() {}
   int s1;
   int s2;
   int s3;
Index: clang/test/SemaCXX/constructor-initializer.cpp
===
--- clang/test/SemaCXX/constructor-initializer.cpp
+++ clang/test/SemaCXX/constructor-initializer.cpp
@@ -91,13 +91,14 @@
 
 struct Current : Derived {
   int Derived;
-  Current() : Derived(1), ::Derived(), // expected-warning {{field 'Derived' will be initialized after base '::Derived'}} \
-   // expected-warning {{base class '::Derived' will be initialized after base 'Derived::V'}}
-  ::Derived::Base(), // expected-error {{type '::Derived::Base' is not a direct or virtual base of 'Current'}}
-   Derived::Base1(), // expected-error {{type 'Derived::Base1' is not a direct or virtual base of 'Current'}}
-   Derived::V(),
-   ::NonExisting(), // expected-error {{member initializer 'NonExisting' does not name a non-static data member or}}
-   INT::NonExisting()  {} // expected-error {{'INT' (aka 'int') is not a class, namespace, or enumeration}} \
+  Current() : Derived(1), ::Derived(), // expected-warning {{some initializers aren't given in the correct order}} \
+   // expected-note {{field 'Derived' will be initialized after base '::Derived'}} \
+   // expected-note {{base class '::Derived' will be initialized after base 'Derived::V'}}
+  ::Derived::Base(),   // expected-error {{type '::Derived::Base' is not a direct or virtual base of 'Current'}}
+  Derived::Base1(),// expected-error {{type 'Derived::Base1' is not a direct or virtual base of 'Current'}}
+  Derived::V(),
+  ::NonExisting(),  // expected-error {{member initializer 'NonExisting' does not name a non-static data member or}}
+  INT::NonExisting() {} // expected-error {{'INT' (aka 'int') is not a class, namespace, or enumeration}} \
   // expected-error {{member initializer 'NonExisting' does not name a non-static data member or}}
 };
 
Index: clang/test/FixIt/fixit-cxx-init-order.cpp
===
--- /dev/null
+++ clang/test/FixIt/fixit-cxx-init-order.cpp
@@ -0,0 +1,22 @@
+// Due to the fix having multiple edits we can't use
+// '-fdiagnostics-parseable-fixits' to determine if fixes are correct. However,
+// running fixit recompile with 'Werror' should fail if the fixes are invalid.
+
+// RUN: %clang_cc1 %s -Werror=reorder-ctor -fixit-recompile -fixit-to-temporary
+// RUN: %clang_cc1 %s -Wreorder-ctor -verify -verify-ignore-unexpected=note
+
+struct Foo {
+  int A, B, C;
+
+  Foo() : A(1), B(3), C(2) {}
+  Foo(int) : A(1), C(2), B(3) {}  // expected-warning {{field 'C' will be initialized after field 'B'}}
+  Foo(unsigned) : C(2), B(3), A(1) {} // expected-warning {{some initializers aren't given in the correct order}}
+};
+
+struct Bar : Foo {
+  int D, E, F;
+
+  Bar() : Foo(), D(1), E(2), F(3) {}
+  Bar(int) : D(1), E(2), F(3), Foo(4) {}  // expected-warning {{field 'F' will be initialized after base 'Foo'}}
+  Bar(unsigned) : F(3), E(2), D(1), Foo(4) {} // expected-warning {{some initializers aren't given in the correct order}}
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp

[PATCH] D98745: [clang] Add fixit for Wreorder-ctor

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 331581.
njames93 added a comment.

Fix formatting issues


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98745/new/

https://reviews.llvm.org/D98745

Files:
  clang/test/SemaCXX/constructor-initializer.cpp
  clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp


Index: clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
===
--- clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
+++ clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
@@ -5,14 +5,13 @@
 struct BB1 {};
 
 class complex : public BB, BB1 { 
-public: 
+public:
   complex()
-: s2(1), // expected-warning {{some initializers aren't given in the 
correct order}} expected-note {{field 's2' will be initialized after field 
's1'}}
-  s1(1),
-  s3(3), // expected-note {{field 's3' will be initialized after base 
'BB1'}} 
-  BB1(), // expected-note {{base class 'BB1' will be initialized after 
base 'BB'}}
-  BB()
-  {}
+  : s2(1), // expected-warning {{some initializers aren't given in the 
correct order}} expected-note {{field 's2' will be initialized after field 
's1'}}
+s1(1),
+s3(3), // expected-note {{field 's3' will be initialized after base 
'BB1'}}
+BB1(), // expected-note {{base class 'BB1' will be initialized after 
base 'BB'}}
+BB() {}
   int s1;
   int s2;
   int s3;
Index: clang/test/SemaCXX/constructor-initializer.cpp
===
--- clang/test/SemaCXX/constructor-initializer.cpp
+++ clang/test/SemaCXX/constructor-initializer.cpp
@@ -94,11 +94,11 @@
   Current() : Derived(1), ::Derived(), // expected-warning {{some initializers 
aren't given in the correct order}} \
// expected-note {{field 'Derived' will 
be initialized after base '::Derived'}} \
// expected-note {{base class 
'::Derived' will be initialized after base 'Derived::V'}}
-  ::Derived::Base(), // expected-error {{type 
'::Derived::Base' is not a direct or virtual base of 'Current'}}
-   Derived::Base1(), // expected-error {{type 
'Derived::Base1' is not a direct or virtual base of 'Current'}}
-   Derived::V(),
-   ::NonExisting(), // expected-error {{member 
initializer 'NonExisting' does not name a non-static data member or}}
-   INT::NonExisting()  {} // expected-error {{'INT' 
(aka 'int') is not a class, namespace, or enumeration}} \
+  ::Derived::Base(),   // expected-error {{type 
'::Derived::Base' is not a direct or virtual base of 'Current'}}
+  Derived::Base1(),// expected-error {{type 
'Derived::Base1' is not a direct or virtual base of 'Current'}}
+  Derived::V(),
+  ::NonExisting(),  // expected-error {{member initializer 
'NonExisting' does not name a non-static data member or}}
+  INT::NonExisting() {} // expected-error {{'INT' (aka 'int') is 
not a class, namespace, or enumeration}} \
   // expected-error {{member 
initializer 'NonExisting' does not name a non-static data member or}}
 };
 


Index: clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
===
--- clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
+++ clang/test/SemaCXX/warn-reorder-ctor-initialization.cpp
@@ -5,14 +5,13 @@
 struct BB1 {};
 
 class complex : public BB, BB1 { 
-public: 
+public:
   complex()
-: s2(1), // expected-warning {{some initializers aren't given in the correct order}} expected-note {{field 's2' will be initialized after field 's1'}}
-  s1(1),
-  s3(3), // expected-note {{field 's3' will be initialized after base 'BB1'}} 
-  BB1(), // expected-note {{base class 'BB1' will be initialized after base 'BB'}}
-  BB()
-  {}
+  : s2(1), // expected-warning {{some initializers aren't given in the correct order}} expected-note {{field 's2' will be initialized after field 's1'}}
+s1(1),
+s3(3), // expected-note {{field 's3' will be initialized after base 'BB1'}}
+BB1(), // expected-note {{base class 'BB1' will be initialized after base 'BB'}}
+BB() {}
   int s1;
   int s2;
   int s3;
Index: clang/test/SemaCXX/constructor-initializer.cpp
===
--- clang/test/SemaCXX/constructor-initializer.cpp
+++ clang/test/SemaCXX/constructor-initializer.cpp
@@ -94,11 +94,11 @@
   Current() : Derived(1), ::Derived(), // expected-warning {{some initializers aren't given in the correct order}} \
// expected-note {{field 'Derived' will be initialized after base '::Derived'}} \

[PATCH] D98113: [Driver] Also search FilePaths for compiler-rt before falling back

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

In D98113#2634758 , @luismarques wrote:

> I just looked at this again and I don't have the full context in my mind 
> right now but won't the test just exercise the BareMetal toolchain and not 
> your changes?

I've since lost my recollection of all the details, but 
BareMetal::AddLinkRuntimeLib is hard-coding -lclang_rt.builtins-$ARCH so I 
think we already do search in the sysroot for the library if it doesn't exist 
in the resources directory. What this tests is -print-libgcc-file-name 
(implemented in the common Driver.cpp) which is the thing that is currently 
"broken" for bare-metal toolchains as it will currently neglect to search the 
sysroot as the linker would, since it calls getCompilerRT directly (which 
BareMetal doesn't override).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98113/new/

https://reviews.llvm.org/D98113

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:377
+
+  bool indicatesMixability() const { return Flags > MIX_None; }
+

Should this be `MIX_WorkaroundDisableCanonicalEquivalence` instead of 
`MIX_None`?



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:486-487
+static MixData
+approximateImplicitConversion(const TheCheck , const QualType LType,
+  const QualType RType, const ASTContext ,
+  ImplicitConversionModellingMode ImplicitMode);





Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:500-501
+static MixData
+calculateMixability(const TheCheck , const QualType LType,
+const QualType RType, const ASTContext ,
+ImplicitConversionModellingMode ImplicitMode) {





Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:520
   // user to understand.
-  if (isa(LType.getTypePtr())) {
-LLVM_DEBUG(llvm::dbgs() << "--- calculateMixability. LHS is ParenType.\n");
+  if (isa(LType.getTypePtr())) {
+LLVM_DEBUG(llvm::dbgs()

What about a `DecayedType`?



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:657-667
+  // Certain kinds unfortunately need to be side-stepped for canonical type
+  // matching.
+  if (LType->getAs() || RType->getAs()) {
+// Unfortunately, the canonical type of a function pointer becomes the
+// same even if exactly one is "noexcept" and the other isn't, making us
+// give a false positive report irrespective of implicit conversions.
+LLVM_DEBUG(llvm::dbgs()

whisperity wrote:
> @aaron.ballman Getting ahead of the curve here. I understand this is ugly. 
> Unfortunately, no matter how much I read the standard, I don't get anything 
> of "canonical type" mentioned, it seems to me this concept is something 
> inherent to the model of Clang.
> 
> Basically why this is here: imagine a `void (*)() noexcept` and a `void 
> (*)()`. One's `noexcept`, the other isn't. Inside the AST, this is a 
> `ParenType` of a `PointerType` to a `FunctionProtoType`. There exists a 
> //one-way// implicit conversion from the `noexcept` to the non-noexcept 
> ("noexceptness can be discarded", similarly to how "constness can be gained")
> Unfortunately, because this is a one-way implicit conversion, it won't return 
> on the code path earlier for implicit conversions.
> 
> Now because of this, the recursive descent in our code will reach the point 
> when the two innermost `FunctionProtoType`s are in our hands. As a fallback 
> case, we simply ask Clang "Hey, do //you// think these two are the same?". 
> And for some weird reason, Clang will say "Yes."... While one of them is a 
> `noexcept` function and the other one isn't.
> 
> I do not know the innards of the AST well enough to even have a glimpse of 
> whether or not this is a bug. So that's the reason why I went ahead and 
> implemented this side-stepping logic. Basically, as the comment says, it'lll 
> **force** the information of "No matter what you do, do NOT consider these 
> mixable!" back up the recursion chain, and handle it appropriately later.
> Unfortunately, no matter how much I read the standard, I don't get anything 
> of "canonical type" mentioned, it seems to me this concept is something 
> inherent to the model of Clang.

It is more of a Clang-centric concept. Basically, a canonical type is one 
that's had all of the typedefs stripped off it.

> Now because of this, the recursive descent in our code will reach the point 
> when the two innermost FunctionProtoTypes are in our hands. As a fallback 
> case, we simply ask Clang "Hey, do you think these two are the same?". And 
> for some weird reason, Clang will say "Yes."... While one of them is a 
> noexcept function and the other one isn't.

I think a confounding factor in this area is that `noexcept` did not used to be 
part of the function type until one day it started being a part of the function 
type. So my guess is that this is fallout from this sort of thing: 
https://godbolt.org/z/EYfj8z (which may be worth keeping in mind when working 
on the check).



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:758
+approximateStandardConversionSequence(const TheCheck ,
+  const QualType From, const QualType To,
+  const ASTContext ) {




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75041/new/

https://reviews.llvm.org/D75041

___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D98113: [Driver] Also search FilePaths for compiler-rt before falling back

[Luís Marques via Phabricator via cfe-commits]

luismarques added a comment.

I just looked at this again and I don't have the full context in my mind right 
now but won't the test just exercise the BareMetal toolchain and not your 
changes?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98113/new/

https://reviews.llvm.org/D98113

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98862: [clang] Update unit-tests after linker selection fix for *-msvc targets

[Maxim Kuvyrkov via Phabricator via cfe-commits]

maxim-kuvyrkov added a comment.

@SureYeaah , does this fix your internal buildbot?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98862/new/

https://reviews.llvm.org/D98862

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98873: Document -fcrash-diagnostics-dir

[Paul Robinson via Phabricator via cfe-commits]

probinson created this revision.
probinson added a reviewer: hans.
Herald added subscribers: jansvoboda11, dang.
probinson requested review of this revision.
Herald added a project: clang.

This was added in LLVM 7.0 but without help text or other docs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98873

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1277,7 +1277,9 @@
 Group;
 def fno_crash_diagnostics : Flag<["-"], "fno-crash-diagnostics">, 
Group, Flags<[NoArgumentUnused, CoreOption]>,
   HelpText<"Disable auto-generation of preprocessed source files and a script 
for reproduction during a clang crash">;
-def fcrash_diagnostics_dir : Joined<["-"], "fcrash-diagnostics-dir=">, 
Group, Flags<[NoArgumentUnused, CoreOption]>;
+def fcrash_diagnostics_dir : Joined<["-"], "fcrash-diagnostics-dir=">,
+  Group, Flags<[NoArgumentUnused, CoreOption]>,
+  HelpText<"Put crash-report files in ">, MetaVarName<"">;
 def fcreate_profile : Flag<["-"], "fcreate-profile">, Group;
 defm cxx_exceptions: BoolFOption<"cxx-exceptions",
   LangOpts<"CXXExceptions">, DefaultFalse,
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -674,6 +674,11 @@
 The -fno-crash-diagnostics flag can be helpful for speeding the process
 of generating a delta reduced test case.
 
+.. option:: -fcrash-diagnostics-dir=
+
+  Specify where to write the crash diagnostics files; defaults to the
+  usual location for temporary files.
+
 Clang is also capable of generating preprocessed source file(s) and associated
 run script(s) even without a crash. This is specially useful when trying to
 generate a reproducer for warnings or errors while using modules.
@@ -3629,6 +3634,8 @@
   -fcomplete-member-pointers
   Require member pointer base types to be complete 
if they would be significant under the Microsoft ABI
   -fcoverage-mapping  Generate coverage mapping to enable code 
coverage analysis
+  -fcrash-diagnostics-dir=
+  Put crash-report files in 
   -fdebug-macro   Emit macro debug information
   -fdelayed-template-parsing
   Parse templated function definitions at the end 
of the translation unit


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1277,7 +1277,9 @@
 Group;
 def fno_crash_diagnostics : Flag<["-"], "fno-crash-diagnostics">, Group, Flags<[NoArgumentUnused, CoreOption]>,
   HelpText<"Disable auto-generation of preprocessed source files and a script for reproduction during a clang crash">;
-def fcrash_diagnostics_dir : Joined<["-"], "fcrash-diagnostics-dir=">, Group, Flags<[NoArgumentUnused, CoreOption]>;
+def fcrash_diagnostics_dir : Joined<["-"], "fcrash-diagnostics-dir=">,
+  Group, Flags<[NoArgumentUnused, CoreOption]>,
+  HelpText<"Put crash-report files in ">, MetaVarName<"">;
 def fcreate_profile : Flag<["-"], "fcreate-profile">, Group;
 defm cxx_exceptions: BoolFOption<"cxx-exceptions",
   LangOpts<"CXXExceptions">, DefaultFalse,
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -674,6 +674,11 @@
 The -fno-crash-diagnostics flag can be helpful for speeding the process
 of generating a delta reduced test case.
 
+.. option:: -fcrash-diagnostics-dir=
+
+  Specify where to write the crash diagnostics files; defaults to the
+  usual location for temporary files.
+
 Clang is also capable of generating preprocessed source file(s) and associated
 run script(s) even without a crash. This is specially useful when trying to
 generate a reproducer for warnings or errors while using modules.
@@ -3629,6 +3634,8 @@
   -fcomplete-member-pointers
   Require member pointer base types to be complete if they would be significant under the Microsoft ABI
   -fcoverage-mapping  Generate coverage mapping to enable code coverage analysis
+  -fcrash-diagnostics-dir=
+  Put crash-report files in 
   -fdebug-macro   Emit macro debug information
   -fdelayed-template-parsing
   Parse templated function definitions at the end of the translation unit
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98824: [Tooling] Handle compilation databases containing commands with double dashes

[Janusz Nykiel via Phabricator via cfe-commits]

jnykiel updated this revision to Diff 331570.
jnykiel retitled this revision from "[Tooling] Handle compilation databases 
with clang-cl commands generated by CMake 3.19+" to "[Tooling] Handle 
compilation databases containing commands with double dashes".
jnykiel edited the summary of this revision.
jnykiel added a comment.

I have addressed some of your comments. The second revision is good enough to 
get the tests to pass - the `injectResourceDir` change was necessary for the 
one clang-tidy test that started failing after leaving the `--` in. I don't 
feel familiar enough with clangd specifically to attempt comprehensive fixes 
there. The clangd issue report specifically mentions `-fsyntax-only` and 
`-resource-dir` as well - so while not comprehensive, the fix may be good for 
that too.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98824/new/

https://reviews.llvm.org/D98824

Files:
  clang/lib/Tooling/ArgumentsAdjusters.cpp
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp

Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -812,6 +812,16 @@
   EXPECT_EQ(getCommand("dir/bar.cpp"), "clang -D dir/foo.cpp -Wall");
 }
 
+TEST_F(InterpolateTest, StripDoubleDash) {
+  add("dir/foo.cpp", "-o foo.o -std=c++14 -Wall -- dir/foo.cpp");
+  // input file and output option are removed
+  // -Wall flag isn't
+  // -std option gets re-added as the last argument before --
+  // new input file gets added after --
+  EXPECT_EQ(getCommand("dir/bar.cpp"),
+"clang -D dir/foo.cpp -Wall -std=c++14 --");
+}
+
 TEST_F(InterpolateTest, Case) {
   add("FOO/BAR/BAZ/SHOUT.cc");
   add("foo/bar/baz/quiet.cc");
Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -435,13 +435,18 @@
 static void injectResourceDir(CommandLineArguments , const char *Argv0,
   void *MainAddr) {
   // Allow users to override the resource dir.
-  for (StringRef Arg : Args)
+  for (StringRef Arg : Args) {
+if (Arg == "--")
+  break;
 if (Arg.startswith("-resource-dir"))
   return;
+  }
 
   // If there's no override in place add our resource dir.
-  Args.push_back("-resource-dir=" +
- CompilerInvocation::GetResourcesPath(Argv0, MainAddr));
+  std::string resourceDir = "-resource-dir=";
+  resourceDir.append(CompilerInvocation::GetResourcesPath(Argv0, MainAddr));
+  getInsertArgumentAdjuster(CommandLineArguments(1, resourceDir),
+ArgumentInsertPosition::END)(Args, "");
 }
 
 int ClangTool::run(ToolAction *Action) {
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -132,6 +132,8 @@
   LangStandard::Kind Std = LangStandard::lang_unspecified;
   // Whether the command line is for the cl-compatible driver.
   bool ClangCLMode;
+  // Whether to insert a double dash before the input file(s).
+  bool InsertDoubleDash = false;
 
   TransferableCommand(CompileCommand C)
   : Cmd(std::move(C)), Type(guessType(Cmd.Filename)),
@@ -177,6 +179,13 @@
Opt.matches(OPT__SLASH_Fo
 continue;
 
+  // ...including when the inputs are passed after --.
+  // If that is the case, record it.
+  if (Opt.matches(OPT__DASH_DASH)) {
+InsertDoubleDash = true;
+break;
+  }
+
   // Strip -x, but record the overridden language.
   if (const auto GivenType = tryParseTypeArg(*Arg)) {
 Type = *GivenType;
@@ -235,6 +244,8 @@
   llvm::Twine(ClangCLMode ? "/std:" : "-std=") +
   LangStandard::getLangStandardForKind(Std).getName()).str());
 }
+if (InsertDoubleDash)
+  Result.CommandLine.push_back("--");
 Result.CommandLine.push_back(std::string(Filename));
 return Result;
   }
Index: clang/lib/Tooling/ArgumentsAdjusters.cpp
===
--- clang/lib/Tooling/ArgumentsAdjusters.cpp
+++ clang/lib/Tooling/ArgumentsAdjusters.cpp
@@ -41,8 +41,13 @@
 "-save-temps",
 "--save-temps",
 };
-for (size_t i = 0, e = Args.size(); i < e; ++i) {
+size_t i = 0;
+for (size_t e = Args.size(); i < e; ++i) {
   StringRef Arg = Args[i];
+
+  if (Arg == "--")
+break;
+
   // Skip output commands.
   if (llvm::any_of(OutputCommands, [](llvm::StringRef OutputCommand) {
 return Arg.startswith(OutputCommand);
@@ -63,6 +68,8 @@
 }
 if (!HasSyntaxOnly)
   

[PATCH] D98855: [OpenCL] Support template parameters for as_type

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia accepted this revision.
Anastasia added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/SemaOpenCLCXX/template-astype.cl:5
+auto templated_astype(T x) {
+  return as_int2(x);
+  // expected-error@-1{{invalid reinterpretation: sizes of 'int2' (vector of 2 
'int' values) and '__private int' must match}}

could we also add another template with use of `__builtin_astype` directly?

In case we change as_type implementation one day the clang builtin will still 
be tested too. :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98855/new/

https://reviews.llvm.org/D98855

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98747: Thread safety analysis: Don't warn about managed locks on join points

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert updated this revision to Diff 331567.
aaronpuchert added a comment.

Negative capabilities don't need to be considered as managed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98747/new/

https://reviews.llvm.org/D98747

Files:
  clang/lib/Analysis/ThreadSafety.cpp
  clang/test/SemaCXX/warn-thread-safety-analysis.cpp


Index: clang/test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- clang/test/SemaCXX/warn-thread-safety-analysis.cpp
+++ clang/test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -2595,6 +2595,7 @@
   if (c) {// test join point -- held/not held during release
 rlock.Release();
   }
+  // No warning on join point because the lock will be released by the scope 
object anyway.
 }
 
 void Foo::test3() {
@@ -2615,7 +2616,7 @@
   if (c) {
 rlock.Release();
   }
-  // no warning on join point for managed lock.
+  // No warning on join point because the lock will be released by the scope 
object anyway.
   rlock.Release();  // expected-warning {{releasing mutex 'mu_' that was not 
held}}
 }
 
@@ -2659,6 +2660,7 @@
 
 Mutex mu;
 int x GUARDED_BY(mu);
+bool b;
 
 void print(int);
 
@@ -2740,6 +2742,23 @@
   scope.Lock(); // expected-warning {{acquiring mutex 'mu' that is already 
held}}
 }
 
+void lockJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.Lock();
+  // No warning on join point because the lock will be released by the scope 
object anyway.
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 
'mu' exclusively}}
+}
+
+void unlockJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  scope.Lock();
+  if (b)
+scope.Unlock();
+  // No warning on join point because the lock will be released by the scope 
object anyway.
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 
'mu' exclusively}}
+}
+
 void directUnlock() {
   RelockableExclusiveMutexLock scope();
   mu.Unlock();
@@ -2871,10 +2890,9 @@
 
 void join() EXCLUSIVE_LOCKS_REQUIRED(mu) {
   MutexUnlock scope();
-  if (c) {
-scope.Lock(); // expected-note{{mutex acquired here}}
-  }
-  // expected-warning@+1{{mutex 'mu' is not held on every path through here}}
+  if (c)
+scope.Lock();
+  // No warning on join point because the lock will be released by the scope 
object anyway.
   scope.Lock();
 }
 
Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -983,7 +983,7 @@
 } else {
   FSet.removeLock(FactMan, !Cp);
   FSet.addLock(FactMan,
-   std::make_unique(Cp, kind, loc));
+   std::make_unique(Cp, kind, loc, true));
 }
   }
 


Index: clang/test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- clang/test/SemaCXX/warn-thread-safety-analysis.cpp
+++ clang/test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -2595,6 +2595,7 @@
   if (c) {// test join point -- held/not held during release
 rlock.Release();
   }
+  // No warning on join point because the lock will be released by the scope object anyway.
 }
 
 void Foo::test3() {
@@ -2615,7 +2616,7 @@
   if (c) {
 rlock.Release();
   }
-  // no warning on join point for managed lock.
+  // No warning on join point because the lock will be released by the scope object anyway.
   rlock.Release();  // expected-warning {{releasing mutex 'mu_' that was not held}}
 }
 
@@ -2659,6 +2660,7 @@
 
 Mutex mu;
 int x GUARDED_BY(mu);
+bool b;
 
 void print(int);
 
@@ -2740,6 +2742,23 @@
   scope.Lock(); // expected-warning {{acquiring mutex 'mu' that is already held}}
 }
 
+void lockJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.Lock();
+  // No warning on join point because the lock will be released by the scope object anyway.
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
+void unlockJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  scope.Lock();
+  if (b)
+scope.Unlock();
+  // No warning on join point because the lock will be released by the scope object anyway.
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
 void directUnlock() {
   RelockableExclusiveMutexLock scope();
   mu.Unlock();
@@ -2871,10 +2890,9 @@
 
 void join() EXCLUSIVE_LOCKS_REQUIRED(mu) {
   MutexUnlock scope();
-  if (c) {
-scope.Lock(); // expected-note{{mutex acquired here}}
-  }
-  // expected-warning@+1{{mutex 'mu' is not held on every path through here}}
+  if (c)
+scope.Lock();
+  // No warning on join point because the lock will be released by the scope object anyway.
   scope.Lock();
 }
 
Index: clang/lib/Analysis/ThreadSafety.cpp

[PATCH] D95736: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with `typedef` and `const &` diagnostics

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95736/new/

https://reviews.llvm.org/D95736

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72235: [clang-tidy] new altera unroll loops check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

Mostly just nits for the check, otherwise this LGTM.




Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:65
+}
+if (isa(Loop) || isa(Loop)) {
+  diag(Loop->getBeginLoc(),





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:83-84
+UnrollLoopsCheck::unrollType(const Stmt *Statement, ASTContext *Context) {
+  const clang::DynTypedNodeList Parents = 
Context->getParents(*Statement);
+  for (const clang::DynTypedNode  : Parents) {
+const auto *ParentStmt = Parent.get();

Pretty sure you don't need to use a qualified name here.



Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:116-120
+  if (isa(Statement)) {
+if (CXXLoopBound)
+  return true;
+return false;
+  }





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:123
+  // unrolling for these.
+  if (isa(Statement) || isa(Statement))
+return false;





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:176-177
+  if (isa(Statement)) {
+const auto *LoopBoundExpr = dyn_cast(CXXLoopBound);
+return exprHasLargeNumIterations(LoopBoundExpr, Context);
+  }

The cast isn't necessary (`IntergerLiteral` is already an `Expr`). You should 
probably assert that `CXXLoopBound` isn't null here though.



Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:180-181
+  const auto *ForLoop = dyn_cast(Statement);
+  if (!ForLoop)
+llvm_unreachable("Unknown loop");
+  const Stmt *Initializer = ForLoop->getInit();





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:196-197
+  }
+  if (!isa(Conditional))
+llvm_unreachable("Conditional is not a binary operator");
+  int EndValue;




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72235/new/

https://reviews.llvm.org/D72235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78652: [clang-tidy] Suppress reports to similarly used parameters in 'bugprone-easily-swappable-parameters'

[Whisperity via Phabricator via cfe-commits]

whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:529
+/// ReturnStmts return them from the function.
+class Returned {
+  llvm::SmallVector 
ReturnedParams;

aaron.ballman wrote:
> whisperity wrote:
> > whisperity wrote:
> > > aaron.ballman wrote:
> > > > Question: would it make sense to (someday, not now) consider output 
> > > > parameters similar to return statements? e.g.,
> > > > ```
> > > > void int_swap(int , int ) {
> > > >   int temp = foo;
> > > >   foo = bar;
> > > >   bar = temp;
> > > > }
> > > > ```
> > > > As a question for today: should `co_return` should be handled similarly 
> > > > as `return`?
> > > 1. Maybe. Unfortunately, one needs to be careful with that. Originally I 
> > > did implement a "5th" heuristic that dealt with ignoring parameters that 
> > > had the same builtin operator used on them. However, while it silenced a 
> > > few false positives, it started creating **massive** amounts of false 
> > > negatives.
> > > (In the concrete example, I think `foo = bar` will silence them because 
> > > //"appears in the same expression"//.)
> > > 
> > > 2. I don't know. It would require a deeper understanding of Coroutines 
> > > themselves, and how people use them.
> > If you don't mind me posting images, I can show a direct example. Things 
> > where the inability to track data flow really bites us in the backside.
> > 
> > Examples from Apache Xerces:
> > 
> > Here's a false positive that would be silenced by the logic of //"using the 
> > same operateur on the two params"//.
> > {F15891567}
> > 
> > And here is a false negative from the exact same logic.
> > {F15891568}
> > 
> > Maybe it could be //some// solace that we're restricting to 
> > non-const-lvalue-references (and pointers-to-non-const ??) and only 
> > assignment (**only** assignment?!))...
> Ah, point #1 is an excellent point. As for #2, I think we can handle it in a 
> follow-up, but I believe `co_return` follows the same usage patterns as 
> `return`, generally.
Added a TODO for `co_return`, so we don't forget.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78652/new/

https://reviews.llvm.org/D78652

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78652: [clang-tidy] Suppress reports to similarly used parameters in 'bugprone-easily-swappable-parameters'

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 331564.
whisperity marked 4 inline comments as done.
whisperity added a comment.

**NFC** Turned some `Optional` into just `T`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78652/new/

https://reviews.llvm.org/D78652

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -2,7 +2,8 @@
 // RUN:   -config='{CheckOptions: [ \
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"} \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
@@ -0,0 +1,229 @@
+// RUN: %check_clang_tidy %s bugprone-easily-swappable-parameters %t \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 1} \
+// RUN:  ]}' --
+
+namespace std {
+template 
+T max(const T , const T );
+} // namespace std
+
+bool coin();
+void f(int);
+void g(int);
+void h(int, int);
+void i(int, bool);
+void i(int, char);
+
+struct Tmp {
+  int f(int);
+  int g(int, int);
+};
+
+struct Int {
+  int I;
+};
+
+void compare(int Left, int Right) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:14: warning: 2 adjacent parameters of 'compare' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-2]]:18: note: the first parameter in the range is 'Left'
+// CHECK-MESSAGES: :[[@LINE-3]]:28: note: the last parameter in the range is 'Right'
+
+int decideSequence(int A, int B) {
+  if (A)
+return 1;
+  if (B)
+return 2;
+  return 3;
+}
+// CHECK-MESSAGES: :[[@LINE-7]]:20: warning: 2 adjacent parameters of 'decideSequence' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-8]]:24: note: the first parameter in the range is 'A'
+// CHECK-MESSAGES: :[[@LINE-9]]:31: note: the last parameter in the range is 'B'
+
+int myMax(int A, int B) { // NO-WARN: Appears in same expression.
+  return A < B ? A : B;
+}
+
+int myMax2(int A, int B) { // NO-WARN: Appears in same expression.
+  if (A < B)
+return A;
+  return B;
+}
+
+int myMax3(int A, int B) { // NO-WARN: Appears in same expression.
+  return std::max(A, B);
+}
+
+int binaryToUnary(int A, int) {
+  return A;
+}
+// CHECK-MESSAGES: :[[@LINE-3]]:19: warning: 2 adjacent parameters of 'binaryToUnary' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-4]]:23: note: the first parameter in the range is 'A'
+// CHECK-MESSAGES: :[[@LINE-5]]:29: note: the last parameter in the range is ''
+
+int randomReturn1(int A, int B) { // NO-WARN: Appears in same expression.
+  return coin() ? A : B;
+}
+
+int randomReturn2(int A, int B) { // NO-WARN: Both parameters returned.
+  if (coin())
+return A;
+  return B;
+}
+
+int randomReturn3(int A, int B) { // NO-WARN: Both parameters returned.
+  bool Flip = coin();
+  if (Flip)
+return A;
+  Flip = coin();
+  if (Flip)
+return B;
+  Flip = coin();
+  if (!Flip)
+return 0;
+  return -1;
+}
+
+void passthrough1(int A, 

[clang] c539be1 - [Hexagon] Add support for named registers cs0 and cs1

[Sid Manning via cfe-commits]

Author: Sid Manning
Date: 2021-03-18T09:53:22-05:00
New Revision: c539be1dcbcf88530cfaf1728b077feb564b72ec

URL: 
https://github.com/llvm/llvm-project/commit/c539be1dcbcf88530cfaf1728b077feb564b72ec
DIFF: 
https://github.com/llvm/llvm-project/commit/c539be1dcbcf88530cfaf1728b077feb564b72ec.diff

LOG: [Hexagon] Add support for named registers cs0 and cs1

Allow inline assembly code to referece cs0 and cs1.

Added: 


Modified: 
clang/lib/Basic/Targets/Hexagon.cpp
llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
llvm/test/CodeGen/Hexagon/namedreg.ll

Removed: 




diff  --git a/clang/lib/Basic/Targets/Hexagon.cpp 
b/clang/lib/Basic/Targets/Hexagon.cpp
index ba10459e9690..d1613fb22930 100644
--- a/clang/lib/Basic/Targets/Hexagon.cpp
+++ b/clang/lib/Basic/Targets/Hexagon.cpp
@@ -136,7 +136,7 @@ const char *const HexagonTargetInfo::GCCRegNames[] = {
 "r9",  "r10", "r11", "r12", "r13", "r14", "r15", "r16", "r17",
 "r18", "r19", "r20", "r21", "r22", "r23", "r24", "r25", "r26",
 "r27", "r28", "r29", "r30", "r31", "p0",  "p1",  "p2",  "p3",
-"sa0", "lc0", "sa1", "lc1", "m0",  "m1",  "usr", "ugp",
+"sa0", "lc0", "sa1", "lc1", "m0",  "m1",  "usr", "ugp", "cs0", "cs1",
 "r1:0", "r3:2", "r5:4", "r7:6", "r9:8", "r11:10", "r13:12", "r15:14",
 "r17:16", "r19:18", "r21:20", "r23:22", "r25:24", "r27:26", "r29:28",
 "r31:30"

diff  --git a/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp 
b/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
index 30c3d3d4f570..a7e9ed34bfcb 100644
--- a/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
+++ b/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
@@ -308,6 +308,8 @@ Register HexagonTargetLowering::getRegisterByName(
  .Case("m1", Hexagon::M1)
  .Case("usr", Hexagon::USR)
  .Case("ugp", Hexagon::UGP)
+ .Case("cs0", Hexagon::CS0)
+ .Case("cs1", Hexagon::CS1)
  .Default(Register());
   if (Reg)
 return Reg;

diff  --git a/llvm/test/CodeGen/Hexagon/namedreg.ll 
b/llvm/test/CodeGen/Hexagon/namedreg.ll
index 72ca50868828..a905332b2dee 100644
--- a/llvm/test/CodeGen/Hexagon/namedreg.ll
+++ b/llvm/test/CodeGen/Hexagon/namedreg.ll
@@ -4,10 +4,29 @@ entry:
   %0 = call i32 @llvm.read_register.i32(metadata !0)
   ret i32 %0
 }
-
 declare i32 @llvm.read_register.i32(metadata) #1
 
+define dso_local i32 @rcs0() #0 {
+entry:
+  %0 = call i32 @llvm.read_register.i32(metadata !1)
+  ret i32 %0
+}
+
+define dso_local i32 @rcs1() #0 {
+entry:
+  %0 = call i32 @llvm.read_register.i32(metadata !2)
+  ret i32 %0
+}
+
+
+
 !llvm.named.register.r19 = !{!0}
+!llvm.named.register.cs0 = !{!1}
+!llvm.named.register.cs1 = !{!2}
 
 !0 = !{!"r19"}
+!1 = !{!"cs0"}
+!2 = !{!"cs1"}
 ; CHECK: r0 = r19
+; CHECK: r0 = cs0
+; CHECK: r0 = cs1



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D20689: [clang-tidy] Add 'readability-suspicious-call-argument' check

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 331560.
whisperity marked 2 inline comments as done.
whisperity added a comment.

- **NFC** Fixed some nits
- Added a new check option, //`MinimumIdentifierNameLength`// instead of a 
hardcoded `3` value. Defaults to `3`.
- Fixed an issue with heuristics matching only in one direction but not in the 
other direction silenced a warning that clearly should have been there.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D20689/new/

https://reviews.llvm.org/D20689

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
  clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-suspicious-call-argument.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-suspicious-call-argument.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-suspicious-call-argument.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-suspicious-call-argument.cpp
@@ -0,0 +1,477 @@
+// RUN: %check_clang_tidy %s readability-suspicious-call-argument %t -- -- -std=c++11
+
+void foo_1(int aa, int bb) {}
+
+void foo_2(int source, int aa) {}
+
+void foo_3(int valToRet, int aa) {}
+
+void foo_4(int pointer, int aa) {}
+
+void foo_5(int aa, int bb, int cc, ...) {}
+
+void foo_6(const int dd, bool ) {}
+
+void foo_7(int aa, int bb, int cc, int ff = 7) {}
+
+void foo_8(int frobble1, int frobble2) {}
+
+// Test functions for convertible argument--parameter types.
+void fun(const int );
+void fun2() {
+  int m = 3;
+  fun(m);
+}
+
+// Test cases for parameters of const reference and value.
+void value_const_reference(int ll, const int );
+
+void const_ref_value_swapped() {
+  const int  = 42;
+  const int  = 42;
+  value_const_reference(kk, ll);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 1st argument 'kk' (passed to 'll') looks like it might be swapped with the 2nd, 'll' (passed to 'kk') [readability-suspicious-call-argument]
+  // CHECK-MESSAGES: :[[@LINE-7]]:6: note: in the call to 'value_const_reference', declared here
+}
+
+// Const, non const references.
+void const_nonconst_parameters(const int , int );
+
+void const_nonconst_swap1() {
+  const int  = 42;
+  int mm;
+  // Do not check, because non-const reference parameter cannot bind to const reference argument.
+  const_nonconst_parameters(nn, mm);
+}
+
+void const_nonconst_swap3() {
+  const int nn = 42;
+  int m = 42;
+  int  = m;
+  // Do not check, const int does not bind to non const reference.
+  const_nonconst_parameters(nn, mm);
+}
+
+void const_nonconst_swap2() {
+  int nn;
+  int mm;
+  // Check for swapped arguments. (Both arguments are non-const.)
+  const_nonconst_parameters(nn, mm);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 1st argument 'nn' (passed to 'mm') looks like it might be swapped with the 2nd, 'mm' (passed to 'nn')
+}
+
+void const_nonconst_pointers(const int *mm, int *nn);
+void const_nonconst_pointers2(const int *mm, const int *nn);
+
+void const_nonconst_pointers_swapped() {
+  int *mm;
+  const int *nn;
+  const_nonconst_pointers(nn, mm);
+}
+
+void const_nonconst_pointers_swapped2() {
+  const int *mm;
+  int *nn;
+  const_nonconst_pointers2(nn, mm);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 1st argument 'nn' (passed to 'mm') looks like it might be swapped with the 2nd, 'mm' (passed to 'nn')
+}
+
+// Test cases for pointers and arrays.
+void pointer_array_parameters(
+int *pp, int qq[4]);
+
+void pointer_array_swap() {
+  int qq[5];
+  int *pp;
+  // Check for swapped arguments. An array implicitly converts to a pointer.
+  pointer_array_parameters(qq, pp);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 1st argument 'qq' (passed to 'pp') looks like it might be swapped with the 2nd, 'pp' (passed to 'qq')
+}
+
+// Test cases for multilevel pointers.
+void multilevel_pointer_parameters(int *const **pp,
+   const int *const *volatile const *qq);
+void multilevel_pointer_parameters2(
+char *nn, char *volatile *const *const *const *const );
+
+typedef float T;
+typedef T *S;
+typedef S *const volatile R;
+typedef R *Q;
+typedef Q *P;
+typedef P *O;
+void multilevel_pointer_parameters3(float **const volatile ***rr, O );
+
+void multilevel_pointer_swap() {
+  int *const **qq;
+  int *const **pp;
+  multilevel_pointer_parameters(qq, pp);

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D96033#2632848 , @rjmccall wrote:

> In D96033#2630978 , @v.g.vassilev 
> wrote:
>
 I'm nervous in general about the looming idea of declaration unloading, 
 but the fact that it's been working in Cling for a long time gives me some 
 confidence that we can do that in a way that's not prohibitively expensive 
 and invasive.
>>>
>>> I don't really know the jargon here.
>>
>> "Code unloading" is mentioned here 
>> https://reviews.llvm.org/D96033?id=323531#inline-911819
>
> I see.  So you want to be able to sort of "roll back" Sema to a previous 
> version of the semantic state, and yet you also need IRGen to *not* be rolled 
> back because of lazy emission.

The state should match the state of Sema (at least that's the current case for 
cling).

That seems... tough.  I don't think we're really architected to support that 
goal — frankly, I'm not sure C and C++ are architected to support that goal — 
and I'm concerned that it might require a ton of extra complexity and risk for 
us.  I say this not to be dismissive, but to clarify how I see our various 
responsibilities here.  Clang's primary mission is to be a static compiler, and 
it's been architected with that in mind, and it's acceptable for us to put that 
mission above other goals if we think they're in conflict.  So as I see it, 
your responsibility here is to persuade us of one of the following:

> - that you can achieve your goals without introducing major problems for 
> Clang's primary mission,
> - that the changes you'll need to make will ultimately have substantial 
> benefits for Clang's primary mission, or
> - that we should change how we think about Clang's primary mission.

We have, over the years, deliberately have taken a very conservative stance and 
we have tried to achieve that goal without major modifications in clang in 
general. Cling has been ou-of-tree so clang design changes were not on the 
table then and now. In my opinion, we have managed to go long way using this 
set of changes 
 in 
clang which in my view is fairly minimal considering the case we enable. My 
understanding of clang is limited so I cannot really judge if the approach we 
took is sustainable but over the years we have mostly suffered from having to 
selectively reset CodeGen state across incremental inputs. Plus some state in 
Sema which comes from another feature which requires recursive parsing but I 
would not consider that feature central for this particular discussion.

> We probably need to talk about it.

+1. Do you use discord/slack/skype?

In D96033#2633479 , @rjmccall wrote:

> To be clear, what I'm trying to say is that — absent consensus that it's a 
> major architecture shift is appropriate — we need to consider what 
> functionality is reasonably achievable without it.  I'm sure that covers most 
> of what you're trying to do; it just may not include everything.

I understand and would like to thank you for bringing this up! I concur with 
that preference.

> One of the fortunate things about working in a REPL is that many ABI 
> considerations go completely out the window.  The most important of those is 
> the abstract need for symbol-matching; that is, there's practically no reason 
> why a C REPL needs to use the simple C symbol mangling, because nobody 
> expects code written outside the REPL to link up with user-entered 
> declarations.  So we can be quite aggressive about how we emit declarations 
> "behind the scenes"; C mode really just means C's user-level semantics, 
> calling convention, and type layout, but not any of C's ordinary 
> interoperation/compatibility requirements.

I have never thought about ABI being a bi-directional problem, and indeed we 
can probably define away one direction. Do I understand that correctly? If I 
do, that would mean we can still embed the C REPL into third party code and be 
able to call compiled code from libraries?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96033/new/

https://reviews.llvm.org/D96033

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98868: [Driver] Add -print-runtime-dir

[Markus Böck via Phabricator via cfe-commits]

zero9178 created this revision.
zero9178 added reviewers: rnk, phosek, MaskRay.
Herald added subscribers: jansvoboda11, dang.
zero9178 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds a new command line option to clang which outputs the directory 
containing clangs runtime libraries to stdout.

The primary use case for this command line flag is for build systems using 
clang-cl. Build systems when using clang-cl invoke the linker, that is either 
link or lld-link in this case, directly instead of invoking the compiler for 
the linking process as is common with the other drivers. This leads to issues 
when runtime libraries of clang, such as sanitizers or profiling, have to be 
linked in as the compiler cannot communicate the link directory to the linker.

Using this flag, build systems would be capable of getting the directory 
containing all of clang's runtime libraries and add it to the linker path.

One such implementation is in LLVM's CMake scripts which currently gets the 
path to the builtins library and uses the containing directory. This also has 
issues however when the builtins library does not exist, which AFAIK is not a 
prerequisite to using clang-cl. More info here: https://reviews.llvm.org/D98786


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98868

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/Inputs/resource_dir/lib/windows/clang_rt.builtins-x86_64.lib
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-pc-windows-msvc/clang_rt.builtins.lib
  clang/test/Driver/immediate-options.c


Index: clang/test/Driver/immediate-options.c
===
--- clang/test/Driver/immediate-options.c
+++ clang/test/Driver/immediate-options.c
@@ -17,3 +17,15 @@
 // Allow unspecified output because the value of CLANG_RESOURCE_DIR is unknown.
 // RUN: %clang -print-resource-dir | FileCheck %s 
-check-prefix=PRINT-RESOURCE-DIR
 // PRINT-RESOURCE-DIR: {{.+}}
+
+// Default resource-dir layout
+// RUN: %clang -print-runtime-dir --target=x86_64-pc-windows-msvc \
+// RUN:-resource-dir=%S/Inputs/resource_dir \
+// RUN:  | FileCheck --check-prefix=PRINT-RUNTIME-DIR %s
+// PRINT-RUNTIME-DIR: lib{{/|\\}}windows
+
+// Per target dir layout
+// RUN: %clang -print-runtime-dir --target=x86_64-pc-windows-msvc \
+// RUN:-resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:  | FileCheck --check-prefix=PRINT-RUNTIME-DIR-PER-TARGET %s
+// PRINT-RUNTIME-DIR-PER-TARGET: lib{{/|\\}}x86_64-pc-windows-msvc
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -1824,6 +1824,15 @@
 return false;
   }
 
+  if (C.getArgs().hasArg(options::OPT_print_runtime_dir)) {
+if (auto RuntimePath = TC.getRuntimePath()) {
+  llvm::outs() << *RuntimePath << '\n';
+  return false;
+}
+llvm::outs() << TC.getCompilerRTPath() << '\n';
+return false;
+  }
+
   // FIXME: The following handlers should use a callback mechanism, we don't
   // know what the client would like to do.
   if (Arg *A = C.getArgs().getLastArg(options::OPT_print_file_name_EQ)) {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3567,6 +3567,8 @@
   HelpText<"Print the registered targets">;
 def print_rocm_search_dirs : Flag<["-", "--"], "print-rocm-search-dirs">,
   HelpText<"Print the paths used for finding ROCm installation">;
+def print_runtime_dir : Flag<["-", "--"], "print-runtime-dir">,
+  HelpText<"Print the directory pathname containing clangs runtime libraries">;
 def private__bundle : Flag<["-"], "private_bundle">;
 def pthreads : Flag<["-"], "pthreads">;
 defm pthread : BoolOption<"", "pthread",


Index: clang/test/Driver/immediate-options.c
===
--- clang/test/Driver/immediate-options.c
+++ clang/test/Driver/immediate-options.c
@@ -17,3 +17,15 @@
 // Allow unspecified output because the value of CLANG_RESOURCE_DIR is unknown.
 // RUN: %clang -print-resource-dir | FileCheck %s -check-prefix=PRINT-RESOURCE-DIR
 // PRINT-RESOURCE-DIR: {{.+}}
+
+// Default resource-dir layout
+// RUN: %clang -print-runtime-dir --target=x86_64-pc-windows-msvc \
+// RUN:-resource-dir=%S/Inputs/resource_dir \
+// RUN:  | FileCheck --check-prefix=PRINT-RUNTIME-DIR %s
+// PRINT-RUNTIME-DIR: lib{{/|\\}}windows
+
+// Per target dir layout
+// RUN: %clang -print-runtime-dir --target=x86_64-pc-windows-msvc \
+// RUN:-resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:  | FileCheck --check-prefix=PRINT-RUNTIME-DIR-PER-TARGET %s
+// 

[PATCH] D98864: [SystemZ][z/OS] Set maximum value to truncate attribute aligned to for static variables on z/OS target

[Fanbo Meng via Phabricator via cfe-commits]

fanbo-meng updated this revision to Diff 331559.
fanbo-meng added a comment.

remove accidentally included diff patch file


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98864/new/

https://reviews.llvm.org/D98864

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -1,4 +1,16 @@
-// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos 
-fdump-record-layouts %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos 
-fdump-record-layouts %s | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -emit-llvm -triple s390x-none-zos %s -o - | FileCheck %s 
--check-prefix=DECL
+
+static int __attribute__((aligned(32))) v0;
+int __attribute__((aligned(32))) v1;
+typedef int __attribute__((aligned(32))) int32;
+static int32 v2;
+int32 v3;
+int f0() { return v0 + v1 + v2 + v3; }
+// DECL:  @v0 {{.*}} align 16
+// DECL-NEXT: @v1 {{.*}} align 32
+// DECL-NEXT: @v2 {{.*}} align 16
+// DECL-NEXT: @v3 {{.*}} align 32
 
 struct s0 {
   short a:3;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -788,6 +788,7 @@
   ZOSTargetInfo(const llvm::Triple , const TargetOptions )
   : OSTargetInfo(Triple, Opts) {
 this->WCharType = TargetInfo::UnsignedInt;
+this->MaxAlignedAttribute = 128;
 this->UseBitFieldTypeAlignment = false;
 this->UseZeroLengthBitfieldAlignment = true;
 this->ZeroLengthBitfieldBoundary = 32;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -106,6 +106,7 @@
   UseZeroLengthBitfieldAlignment = false;
   UseExplicitBitFieldAlignment = true;
   ZeroLengthBitfieldBoundary = 0;
+  MaxAlignedAttribute = 0;
   HalfFormat = ::APFloat::IEEEhalf();
   FloatFormat = ::APFloat::IEEEsingle();
   DoubleFormat = ::APFloat::IEEEdouble();
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -1783,6 +1783,13 @@
 }
   }
 
+  // Some targets have hard limitation on the maximum requestable alignment in
+  // aligned attribute for static variables.
+  const unsigned MaxAlignedAttr = getTargetInfo().getMaxAlignedAttribute();
+  const auto *VD = dyn_cast(D);
+  if (MaxAlignedAttr && VD && VD->getStorageClass() == SC_Static)
+Align = std::min(Align, MaxAlignedAttr);
+
   return toCharUnitsFromBits(Align);
 }
 
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -161,6 +161,10 @@
   /// If non-zero, specifies a fixed alignment value for bitfields that follow
   /// zero length bitfield, regardless of the zero length bitfield type.
   unsigned ZeroLengthBitfieldBoundary;
+
+  /// If non-zero, specifies a maximum alignment to truncate alignment
+  /// specified in the aligned attribute of a static variable to this value.
+  unsigned MaxAlignedAttribute;
 };
 
 /// OpenCL type kinds.
@@ -774,6 +778,10 @@
 return ZeroLengthBitfieldBoundary;
   }
 
+  /// Get the maximum alignment in bits for a static variable with
+  /// aligned attribute.
+  unsigned getMaxAlignedAttribute() const { return MaxAlignedAttribute; }
+
   /// Check whether explicit bitfield alignment attributes should be
   //  honored, as in "__attribute__((aligned(2))) int b : 1;".
   bool useExplicitBitFieldAlignment() const {


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -1,4 +1,16 @@
-// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos -fdump-record-layouts %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos -fdump-record-layouts %s | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -emit-llvm -triple s390x-none-zos %s -o - | FileCheck %s --check-prefix=DECL
+
+static int __attribute__((aligned(32))) v0;
+int __attribute__((aligned(32))) v1;
+typedef int __attribute__((aligned(32))) int32;
+static int32 v2;
+int32 v3;
+int f0() { return v0 + v1 + v2 + v3; }
+// DECL:  @v0 {{.*}} align 16
+// DECL-NEXT: @v1 {{.*}} align 32
+// DECL-NEXT: @v2 {{.*}} align 16
+// DECL-NEXT: @v3 {{.*}} align 32
 
 struct s0 {
   short a:3;
Index: clang/lib/Basic/Targets/OSTargets.h