[PATCH] D99400: [debug-info] support new tuning debugger type DBX for XCOFF DWARF

2021-03-26 Thread ChenZheng via Phabricator via cfe-commits
shchenz created this revision.
Herald added subscribers: jansvoboda11, dexonsmith, dang.
shchenz requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

add new tuning debugger type DBX for XCOFF DWARF.

Based on this debugger type, we plan to:
1: use inline string by default for XCOFF DWARF
2: generate no column info for debug line table.
3: may need to add a new DWARF flag/option, like strict DWARF to make sure 
DWARF info is generated under the correct DWARF version. See 
https://reviews.llvm.org/D99250


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99400

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/AIX.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/debug-options.c
  llvm/include/llvm/Target/TargetOptions.h

Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -108,7 +108,8 @@
 Default,  // No specific tuning requested.
 GDB,  // Tune debug info for gdb.
 LLDB, // Tune debug info for lldb.
-SCE   // Tune debug info for SCE targets (e.g. PS4).
+SCE,  // Tune debug info for SCE targets (e.g. PS4).
+DBX   // Tune debug info for dbx.
   };
 
   /// Enable abort calls when global instruction selection fails to lower/select
Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -18,6 +18,8 @@
 // RUN: | FileCheck -check-prefix=G_STANDALONE -check-prefix=G_LLDB %s
 // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \
 // RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_SCE %s
+// RUN: %clang -### -c -gdbx %s -target x86_64-linux-gnu 2>&1 \
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DBX %s
 
 // Android.
 // Android should always generate DWARF4.
@@ -102,6 +104,12 @@
 // RUN: %clang -### -c %s -gsce -target x86_64-unknown-linux 2>&1 \
 // RUN: | FileCheck -check-prefix=NOCI %s
 
+// On the AIX, -g defaults to -gdbx and limited debug info.
+// RUN: %clang -### -c -g %s -target powerpc-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DBX %s
+// RUN: %clang -### -c -g %s -target powerpc64-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DBX %s
+
 // RUN: %clang -### -c -gdwarf-2 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=G_ONLY_DWARF2 %s
 //
@@ -294,6 +302,7 @@
 // G_GDB:  "-debugger-tuning=gdb"
 // G_LLDB: "-debugger-tuning=lldb"
 // G_SCE:  "-debugger-tuning=sce"
+// G_DBX:  "-debugger-tuning=dbx"
 //
 // G_NOTUNING: "-cc1"
 // G_NOTUNING-NOT: "-debugger-tuning="
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -550,6 +550,8 @@
   CmdArgs.push_back("-plugin-opt=-debugger-tune=lldb");
 else if (A->getOption().matches(options::OPT_gsce))
   CmdArgs.push_back("-plugin-opt=-debugger-tune=sce");
+else if (A->getOption().matches(options::OPT_gdbx))
+  CmdArgs.push_back("-plugin-opt=-debugger-tune=dbx");
 else
   CmdArgs.push_back("-plugin-opt=-debugger-tune=gdb");
   }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1051,6 +1051,9 @@
   case llvm::DebuggerKind::SCE:
 CmdArgs.push_back("-debugger-tuning=sce");
 break;
+  case llvm::DebuggerKind::DBX:
+CmdArgs.push_back("-debugger-tuning=dbx");
+break;
   default:
 break;
   }
@@ -3895,6 +3898,8 @@
 DebuggerTuning = llvm::DebuggerKind::LLDB;
   else if (A->getOption().matches(options::OPT_gsce))
 DebuggerTuning = llvm::DebuggerKind::SCE;
+  else if (A->getOption().matches(options::OPT_gdbx))
+DebuggerTuning = llvm::DebuggerKind::DBX;
   else
 DebuggerTuning = llvm::DebuggerKind::GDB;
 }
Index: clang/lib/Driver/ToolChains/AIX.h
===
--- clang/lib/Driver/ToolChains/AIX.h
+++ clang/lib/Driver/ToolChains/AIX.h
@@ -77,6 +77,10 @@
   // Set default DWARF version to 3 for now as latest AIX OS supports version 3.
   unsigned GetDefaultDwarfVersion() const override { return 3; }
 
+  llvm::DebuggerKind getDefaultDebuggerTuning() const override {
+return llvm::DebuggerKind::DBX;
+  }
+
 protected:
   Tool *buildAssembler() const override;
   

[PATCH] D99344: [Analyzer] Track RValue expressions

2021-03-26 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 333508.
martong marked 5 inline comments as done.
martong added a comment.

- Use isZeroConstant()
- Make trackRValueExpression private (static function)
- Fix clang-tidy report: auto *BO  --->  const auto *BO


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99344

Files:
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/test/Analysis/division-by-zero-track-zero.c
  clang/test/Analysis/division-by-zero-track-zero.cpp
  clang/test/Analysis/nullptr.cpp

Index: clang/test/Analysis/nullptr.cpp
===
--- clang/test/Analysis/nullptr.cpp
+++ clang/test/Analysis/nullptr.cpp
@@ -64,7 +64,7 @@
 
 typedef __INTPTR_TYPE__ intptr_t;
 void zoo1multiply() {
-  char **p = 0; // FIXME-should-be-note:{{'p' initialized to a null pointer value}}
+  char **p = 0; // expected-note{{'p' initialized to a null pointer value}}
   delete *((char **)((intptr_t)p * 2)); // expected-warning{{Dereference of null pointer}}
// expected-note@-1{{Dereference of null pointer}}
 }
Index: clang/test/Analysis/division-by-zero-track-zero.cpp
===
--- /dev/null
+++ clang/test/Analysis/division-by-zero-track-zero.cpp
@@ -0,0 +1,98 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core \
+// RUN:   -analyzer-output=text \
+// RUN:   -verify %s
+
+namespace test_tracking_of_lhs_multiplier {
+  int f(int x, int y) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}} \
+  // expected-note {{'p0' initialized to 0}}
+int div = p0 * y; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_lhs_multiplier
+
+namespace test_tracking_of_rhs_multiplier {
+  int f(int x, int y) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}} \
+  // expected-note {{'p0' initialized to 0}}
+int div = y * p0; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_rhs_multiplier
+
+namespace test_tracking_of_nested_multiplier {
+  int f(int x, int y, int z) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}} \
+  // expected-note {{'p0' initialized to 0}}
+int div = y*z*p0; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_nested_multiplier
+
+namespace test_tracking_through_multiple_stmts {
+  int f(int x, int y) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}}
+bool p1 = p0 ? 0 : 1; // expected-note {{'p0' is false}} \
+  // expected-note {{'?' condition is false}}
+bool p2 = 1 - p1; // expected-note {{'p2' initialized to 0}}
+int div = p2 * y; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_through_multiple_stmts
+
+namespace test_tracking_both_lhs_and_rhs {
+  int f(int x, int y) {
+bool p0 = x < 0;   // expected-note {{Assuming 'x' is >= 0}} \
+   // expected-note {{'p0' initialized to 0}}
+bool p1 = y < 0;   // expected-note {{Assuming 'y' is >= 0}} \
+   // expected-note {{'p1' initialized to 0}}
+int div = p0 * p1; // expected-note {{'div' initialized to 0}}
+return 1 / div;// expected-note {{Division by zero}} \
+   // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_both_lhs_and_rhs
+
+namespace test_tracking_of_multiplier_and_parens {
+  int f(int x, int y, int z) {
+bool p0 = x < 0;// expected-note {{Assuming 'x' is >= 0}} \
+// expected-note {{'p0' initialized to 0}}
+int div = y*(z*p0); // expected-note {{'div' initialized to 0}}
+return 1 / div; // expected-note {{Division by zero}} \
+// expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_multiplier_and_parens
+
+namespace test_tracking_of_divisible {
+  int f(int x, int y) {
+bool p0 = x < 0;// expected-note {{Assuming 'x' is >= 0}} \
+// expected-note {{'p0' initialized to 0}}
+int div = p0 / y;   // expected-note {{'div' initialized to 0}}
+return 1 / div; // expected-note {{Division by zero}} \
+// expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of

[PATCH] D99344: [Analyzer] Track RValue expressions

2021-03-26 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Guys, thanks for the review! :)




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1945
+
+  auto IsZero = [&BVF](const Optional &CI) {
+if (!CI)

NoQ wrote:
> `SVal::isZeroConstant()` please ^.^
Yeah good catch, I wish I knew this before :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99344

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


[PATCH] D99360: [OpenMP][WIP] Add standard notes for ELF offload images

2021-03-26 Thread James Henderson via Phabricator via cfe-commits
jhenderson added a comment.

It might make sense to do the llvm-readobj portions of this patch in a separate 
review, since they are somewhat independent.


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

https://reviews.llvm.org/D99360

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


[PATCH] D99402: [AMDGPU][OpenMP] Add /include to the search path

2021-03-26 Thread Pushpinder Singh via Phabricator via cfe-commits
pdhaliwal created this revision.
pdhaliwal added reviewers: ronlieb, JonChesterfield, jdoerfert.
Herald added subscribers: kerbowa, guansong, t-tye, tpr, dstuttard, yaxunl, 
nhaehnle, jvesely, kzhuravl.
pdhaliwal requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, wdng.
Herald added a project: clang.

Fixes the include error for omp.h as compiler was not looking in the
correct directory.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99402

Files:
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -4,7 +4,7 @@
 // RUN:   | FileCheck %s
 
 // verify the tools invocations
-// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" 
"c"{{.*}}
+// CHECK: clang{{.*}}"-cc1" "-triple" 
"x86_64-unknown-linux-gnu"{{.*}}"-internal-isystem" 
"{{.*}}/bin/../include"{{.*}}"-x" "c"{{.*}}
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" 
"ir"{{.*}}
 // CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" 
"-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
 // CHECK: llvm-link{{.*}}"-o" 
"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -244,6 +244,11 @@
 
 void AMDGPUOpenMPToolChain::AddClangSystemIncludeArgs(
 const ArgList &DriverArgs, ArgStringList &CC1Args) const {
+  const Driver &D = HostTC.getDriver();
+  CC1Args.push_back("-internal-isystem");
+  SmallString<128> P(D.Dir);
+  llvm::sys::path::append(P, "..", "include");
+  CC1Args.push_back(DriverArgs.MakeArgString(P));
   HostTC.AddClangSystemIncludeArgs(DriverArgs, CC1Args);
 }
 


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -4,7 +4,7 @@
 // RUN:   | FileCheck %s
 
 // verify the tools invocations
-// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "c"{{.*}}
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-internal-isystem" "{{.*}}/bin/../include"{{.*}}"-x" "c"{{.*}}
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "ir"{{.*}}
 // CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" "-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
 // CHECK: llvm-link{{.*}}"-o" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -244,6 +244,11 @@
 
 void AMDGPUOpenMPToolChain::AddClangSystemIncludeArgs(
 const ArgList &DriverArgs, ArgStringList &CC1Args) const {
+  const Driver &D = HostTC.getDriver();
+  CC1Args.push_back("-internal-isystem");
+  SmallString<128> P(D.Dir);
+  llvm::sys::path::append(P, "..", "include");
+  CC1Args.push_back(DriverArgs.MakeArgString(P));
   HostTC.AddClangSystemIncludeArgs(DriverArgs, CC1Args);
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D97362: [clang][parser] Allow attributes in explicit template instantiations

2021-03-26 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 333510.

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

https://reviews.llvm.org/D97362

Files:
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/Parser/cxx0x-attributes.cpp


Index: clang/test/Parser/cxx0x-attributes.cpp
===
--- clang/test/Parser/cxx0x-attributes.cpp
+++ clang/test/Parser/cxx0x-attributes.cpp
@@ -179,6 +179,7 @@
 struct [[]] Template t; // expected-error {{an attribute list cannot 
appear here}}
 struct [[]] ::template Template u; // expected-error {{an attribute list 
cannot appear here}}
 template struct [[]] Template; // expected-error {{an attribute list 
cannot appear here}}
+template struct __attribute__((pure)) Template; // We still allow 
GNU-style attributes here
 template <> struct [[]] Template;
 
 enum [[]] E1 {};
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -1836,7 +1836,8 @@
 } else if (TemplateInfo.Kind == ParsedTemplateInfo::ExplicitInstantiation 
&&
 TUK == Sema::TUK_Declaration) {
   // This is an explicit instantiation of a class template.
-  ProhibitAttributes(attrs);
+  ProhibitCXX11Attributes(attrs, diag::err_attributes_not_allowed,
+  /*DiagnoseEmptyAttrs=*/true);
 
   TagOrTempResult = Actions.ActOnExplicitInstantiation(
   getCurScope(), TemplateInfo.ExternLoc, TemplateInfo.TemplateLoc,
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -1607,7 +1607,30 @@
 }
 
 void Parser::ProhibitCXX11Attributes(ParsedAttributesWithRange &Attrs,
- unsigned DiagID) {
+ unsigned DiagID, bool DiagnoseEmptyAttrs) 
{
+
+  if (DiagnoseEmptyAttrs && Attrs.empty() && Attrs.Range.isValid()) {
+// An attribute list has been parsed, but it was empty.
+// This is the case for [[]].
+const auto &LangOpts = getLangOpts();
+auto &SM = PP.getSourceManager();
+Token FirstLSquare;
+Lexer::getRawToken(Attrs.Range.getBegin(), FirstLSquare, SM, LangOpts);
+
+if (FirstLSquare.is(tok::l_square)) {
+  llvm::Optional SecondLSquare =
+  Lexer::findNextToken(FirstLSquare.getLocation(), SM, LangOpts);
+
+  if (SecondLSquare && SecondLSquare->is(tok::l_square)) {
+// The attribute range starts with [[, but is empty. So this must
+// be [[]], which we are supposed to diagnose because
+// DiagnoseEmptyAttrs is true.
+Diag(Attrs.Range.getBegin(), DiagID) << Attrs.Range;
+return;
+  }
+}
+  }
+
   for (const ParsedAttr &AL : Attrs) {
 if (!AL.isCXX11Attribute() && !AL.isC2xAttribute())
   continue;
Index: clang/include/clang/Parse/Parser.h
===
--- clang/include/clang/Parse/Parser.h
+++ clang/include/clang/Parse/Parser.h
@@ -2639,7 +2639,8 @@
   // which standard permits but we don't supported yet, for example, attributes
   // appertain to decl specifiers.
   void ProhibitCXX11Attributes(ParsedAttributesWithRange &Attrs,
-   unsigned DiagID);
+   unsigned DiagID,
+   bool DiagnoseEmptyAttrs = false);
 
   /// Skip C++11 and C2x attributes and return the end location of the
   /// last one.


Index: clang/test/Parser/cxx0x-attributes.cpp
===
--- clang/test/Parser/cxx0x-attributes.cpp
+++ clang/test/Parser/cxx0x-attributes.cpp
@@ -179,6 +179,7 @@
 struct [[]] Template t; // expected-error {{an attribute list cannot appear here}}
 struct [[]] ::template Template u; // expected-error {{an attribute list cannot appear here}}
 template struct [[]] Template; // expected-error {{an attribute list cannot appear here}}
+template struct __attribute__((pure)) Template; // We still allow GNU-style attributes here
 template <> struct [[]] Template;
 
 enum [[]] E1 {};
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -1836,7 +1836,8 @@
 } else if (TemplateInfo.Kind == ParsedTemplateInfo::ExplicitInstantiation &&
 TUK == Sema::TUK_Declaration) {
   // This is an explicit instantiation of a class template.
-  ProhibitAttributes(attrs);
+  ProhibitCXX11Attributes(attrs, diag::err_attributes_not_allowed,
+  /*DiagnoseEmptyAttrs=*/true);
 
   TagOrTempResult = Actions.ActOnExplicitInstantiation(
   getCurScope(), TemplateInfo.ExternLoc, TemplateInfo.

[PATCH] D99338: [clang][parser] Allow GNU-style attributes in enum specifiers

2021-03-26 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 333511.

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

https://reviews.llvm.org/D99338

Files:
  clang/lib/Parse/ParseDecl.cpp


Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -4653,7 +4653,8 @@
   // or opaque-enum-declaration anywhere.
   if (IsElaboratedTypeSpecifier && !getLangOpts().MicrosoftExt &&
   !getLangOpts().ObjC) {
-ProhibitAttributes(attrs);
+ProhibitCXX11Attributes(attrs, diag::err_attributes_not_allowed,
+/*DiagnoseEmptyAttrs=*/true);
 if (BaseType.isUsable())
   Diag(BaseRange.getBegin(), diag::ext_enum_base_in_type_specifier)
   << (AllowEnumSpecifier == AllowDefiningTypeSpec::Yes) << BaseRange;


Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -4653,7 +4653,8 @@
   // or opaque-enum-declaration anywhere.
   if (IsElaboratedTypeSpecifier && !getLangOpts().MicrosoftExt &&
   !getLangOpts().ObjC) {
-ProhibitAttributes(attrs);
+ProhibitCXX11Attributes(attrs, diag::err_attributes_not_allowed,
+/*DiagnoseEmptyAttrs=*/true);
 if (BaseType.isUsable())
   Diag(BaseRange.getBegin(), diag::ext_enum_base_in_type_specifier)
   << (AllowEnumSpecifier == AllowDefiningTypeSpec::Yes) << BaseRange;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99402: [AMDGPU][OpenMP] Add /include to the search path

2021-03-26 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Any chance you might be interested in fixing the more general problem, 
benefiting every clang openmp user, not just amdgpu?
D55725 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99402

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


[PATCH] D99344: [Analyzer] Track RValue expressions

2021-03-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

Some minor logical issues inline.




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1944-1945
+return;
+  if (!BO->isMultiplicativeOp())
+return;
+

There are only 3 multiplicative operators:
```
BINARY_OPERATION(Mul, "*")
BINARY_OPERATION(Div, "/")
BINARY_OPERATION(Rem, "%")
```
So, the opcode can never be `BO_MulAssign` later.
The comment for the else block is also inaccurate for the same reason.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99344

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


[PATCH] D96090: [analyzer] Replace StoreManager::CastRetrievedVal with SValBuilder::evalCast

2021-03-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal accepted this revision.
steakhal added a comment.
This revision is now accepted and ready to land.

I don't know. I think it's already way better than it was.
I think we can reiterate this later.

I want to get the `llvm_unreachable("Unknown SVal kind")` statements back. 
Besides those, I have no objections to this patch.
It preserves the old semantics, so it should be safe to land.
What do you think @NoQ?




Comment at: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:564-565
   }
-
-  llvm_unreachable("Unknown SVal kind");
 }

You probably don't want to remove this. The same applies to similar ones.


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

https://reviews.llvm.org/D96090

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


[PATCH] D99407: [clang][ItaniumMangle] Check SizeExpr for DependentSizedArrayType (PR49478)

2021-03-26 Thread Tommy Chiang via Phabricator via cfe-commits
oToToT created this revision.
oToToT added reviewers: rsmith, gbenyei, MaskRay, yaxunl.
oToToT added a project: clang.
oToToT requested review of this revision.
Herald added a subscriber: cfe-commits.

As `ArrayType::ArrayType` mentioned in `clang/lib/AST/Type.cpp`, a 
DependentSizedArrayType might not have size expression because it it used as 
the type of a dependent array of unknown bound with a dependent braced 
initializer.

Thus, I add a check when mangling array of that type.

This should fix https://bugs.llvm.org/show_bug.cgi?id=49478


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99407

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/test/AST/ast-dump-array-json.cpp


Index: clang/test/AST/ast-dump-array-json.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-array-json.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ast-dump=json 
-ast-dump-filter Test %s | FileCheck %s
+
+template struct A { static const int Test[]; };
+template const int A::Test[] = { N... };
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3204,7 +3204,11 @@
 }
 void CXXNameMangler::mangleType(const DependentSizedArrayType *T) {
   Out << 'A';
-  mangleExpression(T->getSizeExpr());
+  // A DependentSizedArrayType might not have size expression as below
+  // 
+  //   template int arr[] = {N...};
+  if (T->getSizeExpr())
+mangleExpression(T->getSizeExpr());
   Out << '_';
   mangleType(T->getElementType());
 }


Index: clang/test/AST/ast-dump-array-json.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-array-json.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ast-dump=json -ast-dump-filter Test %s | FileCheck %s
+
+template struct A { static const int Test[]; };
+template const int A::Test[] = { N... };
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3204,7 +3204,11 @@
 }
 void CXXNameMangler::mangleType(const DependentSizedArrayType *T) {
   Out << 'A';
-  mangleExpression(T->getSizeExpr());
+  // A DependentSizedArrayType might not have size expression as below
+  // 
+  //   template int arr[] = {N...};
+  if (T->getSizeExpr())
+mangleExpression(T->getSizeExpr());
   Out << '_';
   mangleType(T->getElementType());
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99407: [clang][ItaniumMangle] Check SizeExpr for DependentSizedArrayType (PR49478)

2021-03-26 Thread Tommy Chiang via Phabricator via cfe-commits
oToToT updated this revision to Diff 333526.
oToToT added a comment.

Remove redundant whitespace in comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99407

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/test/AST/ast-dump-array-json.cpp


Index: clang/test/AST/ast-dump-array-json.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-array-json.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ast-dump=json 
-ast-dump-filter Test %s | FileCheck %s
+
+template struct A { static const int Test[]; };
+template const int A::Test[] = { N... };
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3204,7 +3204,11 @@
 }
 void CXXNameMangler::mangleType(const DependentSizedArrayType *T) {
   Out << 'A';
-  mangleExpression(T->getSizeExpr());
+  // A DependentSizedArrayType might not have the size expression as below.
+  //
+  //   template int arr[] = {N...};
+  if (T->getSizeExpr())
+mangleExpression(T->getSizeExpr());
   Out << '_';
   mangleType(T->getElementType());
 }


Index: clang/test/AST/ast-dump-array-json.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-array-json.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ast-dump=json -ast-dump-filter Test %s | FileCheck %s
+
+template struct A { static const int Test[]; };
+template const int A::Test[] = { N... };
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3204,7 +3204,11 @@
 }
 void CXXNameMangler::mangleType(const DependentSizedArrayType *T) {
   Out << 'A';
-  mangleExpression(T->getSizeExpr());
+  // A DependentSizedArrayType might not have the size expression as below.
+  //
+  //   template int arr[] = {N...};
+  if (T->getSizeExpr())
+mangleExpression(T->getSizeExpr());
   Out << '_';
   mangleType(T->getElementType());
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] bc5d4bc - [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Abhina Sreeskantharajan via cfe-commits

Author: Abhina Sreeskantharajan
Date: 2021-03-26T07:12:46-04:00
New Revision: bc5d4bcc2deb71ab647270c9754a83484b3d6f87

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

LOG: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF 
translation

This patch should fix the errors shown on the Windows bots by turning off text 
mode. I plan to investigate a better fix but this should unblock the buildbots 
for now.

Reviewed By: rnk

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

Added: 


Modified: 
clang/lib/Frontend/Rewrite/FrontendActions.cpp
llvm/lib/TableGen/Main.cpp

Removed: 




diff  --git a/clang/lib/Frontend/Rewrite/FrontendActions.cpp 
b/clang/lib/Frontend/Rewrite/FrontendActions.cpp
index 13e668a47a2f..45960068220b 100644
--- a/clang/lib/Frontend/Rewrite/FrontendActions.cpp
+++ b/clang/lib/Frontend/Rewrite/FrontendActions.cpp
@@ -185,7 +185,7 @@ RewriteObjCAction::CreateASTConsumer(CompilerInstance &CI, 
StringRef InFile) {
 void RewriteMacrosAction::ExecuteAction() {
   CompilerInstance &CI = getCompilerInstance();
   std::unique_ptr OS =
-  CI.createDefaultOutputFile(/*Binary=*/false, 
getCurrentFileOrBufferName());
+  CI.createDefaultOutputFile(/*Binary=*/true, 
getCurrentFileOrBufferName());
   if (!OS) return;
 
   RewriteMacrosInInput(CI.getPreprocessor(), OS.get());
@@ -194,7 +194,7 @@ void RewriteMacrosAction::ExecuteAction() {
 void RewriteTestAction::ExecuteAction() {
   CompilerInstance &CI = getCompilerInstance();
   std::unique_ptr OS =
-  CI.createDefaultOutputFile(false, getCurrentFileOrBufferName());
+  CI.createDefaultOutputFile(/*Binary=*/true, 
getCurrentFileOrBufferName());
   if (!OS) return;
 
   DoRewriteTest(CI.getPreprocessor(), OS.get());

diff  --git a/llvm/lib/TableGen/Main.cpp b/llvm/lib/TableGen/Main.cpp
index 0b1024648b66..a58defaf515f 100644
--- a/llvm/lib/TableGen/Main.cpp
+++ b/llvm/lib/TableGen/Main.cpp
@@ -93,7 +93,7 @@ int llvm::TableGenMain(const char *argv0, TableGenMainFn 
*MainFn) {
 
   Records.startTimer("Parse, build records");
   ErrorOr> FileOrErr =
-  MemoryBuffer::getFileOrSTDIN(InputFilename, /*IsText=*/true);
+  MemoryBuffer::getFileOrSTDIN(InputFilename, /*IsText=*/false);
   if (std::error_code EC = FileOrErr.getError())
 return reportError(argv0, "Could not open input file '" + InputFilename +
   "': " + EC.message() + "\n");
@@ -138,7 +138,7 @@ int llvm::TableGenMain(const char *argv0, TableGenMainFn 
*MainFn) {
 // This prevents recompilation of all the files depending on it if there
 // aren't any.
 if (auto ExistingOrErr =
-MemoryBuffer::getFile(OutputFilename, /*IsText=*/true))
+MemoryBuffer::getFile(OutputFilename, /*IsText=*/false))
   if (std::move(ExistingOrErr.get())->getBuffer() == Out.str())
 WriteFile = false;
   }



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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Abhina Sree via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbc5d4bcc2deb: [Windows] Turn off text mode in TableGen and 
Rewriter to stop CRLF translation (authored by abhina.sreeskantharajan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

Files:
  clang/lib/Frontend/Rewrite/FrontendActions.cpp
  llvm/lib/TableGen/Main.cpp


Index: llvm/lib/TableGen/Main.cpp
===
--- llvm/lib/TableGen/Main.cpp
+++ llvm/lib/TableGen/Main.cpp
@@ -93,7 +93,7 @@
 
   Records.startTimer("Parse, build records");
   ErrorOr> FileOrErr =
-  MemoryBuffer::getFileOrSTDIN(InputFilename, /*IsText=*/true);
+  MemoryBuffer::getFileOrSTDIN(InputFilename, /*IsText=*/false);
   if (std::error_code EC = FileOrErr.getError())
 return reportError(argv0, "Could not open input file '" + InputFilename +
   "': " + EC.message() + "\n");
@@ -138,7 +138,7 @@
 // This prevents recompilation of all the files depending on it if there
 // aren't any.
 if (auto ExistingOrErr =
-MemoryBuffer::getFile(OutputFilename, /*IsText=*/true))
+MemoryBuffer::getFile(OutputFilename, /*IsText=*/false))
   if (std::move(ExistingOrErr.get())->getBuffer() == Out.str())
 WriteFile = false;
   }
Index: clang/lib/Frontend/Rewrite/FrontendActions.cpp
===
--- clang/lib/Frontend/Rewrite/FrontendActions.cpp
+++ clang/lib/Frontend/Rewrite/FrontendActions.cpp
@@ -185,7 +185,7 @@
 void RewriteMacrosAction::ExecuteAction() {
   CompilerInstance &CI = getCompilerInstance();
   std::unique_ptr OS =
-  CI.createDefaultOutputFile(/*Binary=*/false, 
getCurrentFileOrBufferName());
+  CI.createDefaultOutputFile(/*Binary=*/true, 
getCurrentFileOrBufferName());
   if (!OS) return;
 
   RewriteMacrosInInput(CI.getPreprocessor(), OS.get());
@@ -194,7 +194,7 @@
 void RewriteTestAction::ExecuteAction() {
   CompilerInstance &CI = getCompilerInstance();
   std::unique_ptr OS =
-  CI.createDefaultOutputFile(false, getCurrentFileOrBufferName());
+  CI.createDefaultOutputFile(/*Binary=*/true, 
getCurrentFileOrBufferName());
   if (!OS) return;
 
   DoRewriteTest(CI.getPreprocessor(), OS.get());


Index: llvm/lib/TableGen/Main.cpp
===
--- llvm/lib/TableGen/Main.cpp
+++ llvm/lib/TableGen/Main.cpp
@@ -93,7 +93,7 @@
 
   Records.startTimer("Parse, build records");
   ErrorOr> FileOrErr =
-  MemoryBuffer::getFileOrSTDIN(InputFilename, /*IsText=*/true);
+  MemoryBuffer::getFileOrSTDIN(InputFilename, /*IsText=*/false);
   if (std::error_code EC = FileOrErr.getError())
 return reportError(argv0, "Could not open input file '" + InputFilename +
   "': " + EC.message() + "\n");
@@ -138,7 +138,7 @@
 // This prevents recompilation of all the files depending on it if there
 // aren't any.
 if (auto ExistingOrErr =
-MemoryBuffer::getFile(OutputFilename, /*IsText=*/true))
+MemoryBuffer::getFile(OutputFilename, /*IsText=*/false))
   if (std::move(ExistingOrErr.get())->getBuffer() == Out.str())
 WriteFile = false;
   }
Index: clang/lib/Frontend/Rewrite/FrontendActions.cpp
===
--- clang/lib/Frontend/Rewrite/FrontendActions.cpp
+++ clang/lib/Frontend/Rewrite/FrontendActions.cpp
@@ -185,7 +185,7 @@
 void RewriteMacrosAction::ExecuteAction() {
   CompilerInstance &CI = getCompilerInstance();
   std::unique_ptr OS =
-  CI.createDefaultOutputFile(/*Binary=*/false, getCurrentFileOrBufferName());
+  CI.createDefaultOutputFile(/*Binary=*/true, getCurrentFileOrBufferName());
   if (!OS) return;
 
   RewriteMacrosInInput(CI.getPreprocessor(), OS.get());
@@ -194,7 +194,7 @@
 void RewriteTestAction::ExecuteAction() {
   CompilerInstance &CI = getCompilerInstance();
   std::unique_ptr OS =
-  CI.createDefaultOutputFile(false, getCurrentFileOrBufferName());
+  CI.createDefaultOutputFile(/*Binary=*/true, getCurrentFileOrBufferName());
   if (!OS) return;
 
   DoRewriteTest(CI.getPreprocessor(), OS.get());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99402: [AMDGPU][OpenMP] Add /include to the search path

2021-03-26 Thread Pushpinder Singh via Phabricator via cfe-commits
pdhaliwal added a comment.

I was not aware that it was a general problem. I will check if I could get a 
general solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99402

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


[PATCH] D99402: [AMDGPU][OpenMP] Add /include to the search path

2021-03-26 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

The general problem looks harder but important to fix. Finding the right 
headers but the wrong shared library is bad, and iirc we currently have to use 
LD_LIBRARY_PATH to bodge the latter which is not a good UX.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99402

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


[PATCH] D99414: [clang][tooling] Create SourceManager for DiagnosticsEngine before command-line parsing

2021-03-26 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 created this revision.
jansvoboda11 added a reviewer: rupprecht.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In D84673 , we started using 
`DiagnosticsEngine` during command-line parsing in more contexts.

When using `ToolInvocation`, a custom `DiagnosticsConsumer` can be specified 
and it might expect `SourceManager` to be present on the emitted diagnostics.

This patch ensures the `SourceManager` is set up in such scenarios.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99414

Files:
  clang/lib/Tooling/Tooling.cpp
  clang/unittests/Tooling/ToolingTest.cpp


Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -221,6 +221,43 @@
   EXPECT_TRUE(Invocation.run());
 }
 
+struct DiagnosticConsumerExpectingSourceManager : public DiagnosticConsumer {
+  bool SawSourceManager;
+
+  DiagnosticConsumerExpectingSourceManager() : SawSourceManager(false) {}
+
+  void HandleDiagnostic(clang::DiagnosticsEngine::Level,
+const clang::Diagnostic &info) override {
+SawSourceManager = info.hasSourceManager();
+  }
+};
+
+TEST(ToolInvocation, DiagConsumerExpectingSourceManager) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  // Note: intentional error; user probably meant -ferror-limit=0.
+  Args.push_back("-ferror-limit=-1");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int main() {}\n"));
+
+  DiagnosticConsumerExpectingSourceManager Consumer;
+  Invocation.setDiagnosticConsumer(&Consumer);
+
+  EXPECT_TRUE(Invocation.run());
+  EXPECT_TRUE(Consumer.SawSourceManager);
+}
+
 struct VerifyEndCallback : public SourceFileCallbacks {
   VerifyEndCallback() : BeginCalled(0), EndCalled(0), Matched(false) {}
   bool handleBeginSource(CompilerInstance &CI) override {
Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -334,6 +334,10 @@
   DiagnosticsEngine Diagnostics(
   IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
   DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
+  // Although `Diagnostics` are used only for command-line parsing, the custom
+  // `DiagConsumer` might expect a `SourceManager` to be present.
+  SourceManager SrcMgr(Diagnostics, *Files);
+  Diagnostics.setSourceManager(&SrcMgr);
 
   const std::unique_ptr Driver(
   newDriver(&Diagnostics, BinaryName, &Files->getVirtualFileSystem()));


Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -221,6 +221,43 @@
   EXPECT_TRUE(Invocation.run());
 }
 
+struct DiagnosticConsumerExpectingSourceManager : public DiagnosticConsumer {
+  bool SawSourceManager;
+
+  DiagnosticConsumerExpectingSourceManager() : SawSourceManager(false) {}
+
+  void HandleDiagnostic(clang::DiagnosticsEngine::Level,
+const clang::Diagnostic &info) override {
+SawSourceManager = info.hasSourceManager();
+  }
+};
+
+TEST(ToolInvocation, DiagConsumerExpectingSourceManager) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  // Note: intentional error; user probably meant -ferror-limit=0.
+  Args.push_back("-ferror-limit=-1");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int main() {}\n"));
+
+  DiagnosticConsumerExpectingSourceManager Consumer;
+  Invocation.setDiagnosticConsumer(&Consumer);
+
+  EXPECT_TRUE(Invocation.run());
+  EXPECT_TRUE(Consumer.SawSourceManager);
+}
+
 struct VerifyEndCallback : public S

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

2021-03-26 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

Sorry for taking so long. I created a patch that should fix the missing 
`SourceManager`: D99414 

@rupprecht can you confirm this works for your use-case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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


[PATCH] D99250: [DebugInfo] Fix the mismatching of C++ language tags and Dwarf versions.

2021-03-26 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In D99250#2651394 , @jsji wrote:

> The list is growing,  but sure,  we will post a thread in llvm-dev about what 
> we met so far.
> Two big one would be that DBX not supporting string section(DW_FORM_strp) and 
>  column-info  in line no table.

Our practice has been for a "tuning" option to, effectively, expand into other 
options to control various bits of behavior.  Basically, there should never be 
behavior that can be controlled _only_ via the tuning option.  This is a design 
decision that was debated at length when we introduced tuning.

There is already an option to turn off column-info in the line table, so a new 
tuning option could easily imply that.  I'm not sure we support suppressing 
.debug_str, but if we do (or add it), that would be another option, and the new 
tuning would imply that. And so on.

If we want to emit different sets of language codes based on something other 
than the DWARF version, we'd need to invent a new option to control that, and 
then tuning could control whether that's on or off.

In D99250#2651204 , @dblaikie wrote:

> Does anyone else have a DWARFv3 consumer they care about? (@aprantl and 
> @probinson)
>
> Does anyone have a DWARF consumer that changes significantly based on the 
> language version (I guess lldb (@aprantl can you confirm?)? I doubt gdb does 
> (yeah, it just treats all C++ versions the same 
> )?
>  how about Sony?)

I believe Sony is only using v4/v5 at this point.  Regarding dialect 
controlling debugger behavior, I think it's unlikely, as distinguishing C++ 
dialects is new in v5, its adoption is pretty recent (at least for us), and 
we'd want behavior to be consistent across v4/v5 as much as possible.  I'll 
verify that with our debugger guys.

If LLDB actually does _not_ have behavior change based on dialect, then we 
might as well control language codes based on DWARF version, and the patch 
should proceed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99250

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


[PATCH] D99250: [DebugInfo] Fix the mismatching of C++ language tags and Dwarf versions.

2021-03-26 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added a comment.

> Our practice has been for a "tuning" option to, effectively, expand into 
> other options to control various bits of behavior.  Basically, there should 
> never be behavior that can be controlled _only_ via the tuning option.  This 
> is a design decision that was debated at length when we introduced tuning.

Agree, this is a good practise, we will certainly follow.

> I believe Sony is only using v4/v5 at this point. Regarding dialect 
> controlling debugger behavior, I think it's unlikely, as distinguishing C++ 
> dialects is new in v5, its adoption is pretty recent (at least for us), and 
> we'd want behavior to be consistent across v4/v5 as much as possible. I'll 
> verify that with our debugger guys.

Thank you Paul!

> If LLDB actually does _not_ have behavior change based on dialect, then we 
> might as well control language codes based on DWARF version, and the patch 
> should proceed.

We will wait for LLDB's confirmation then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99250

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


[clang] a819256 - [OpenCL][Docs] Update status of OpenCL 3.0 development

2021-03-26 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-03-26T13:07:06Z
New Revision: a81925664bbbc62dc854df919e1b5180f0abfa56

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

LOG: [OpenCL][Docs] Update status of OpenCL 3.0 development

Added: 


Modified: 
clang/docs/OpenCLSupport.rst

Removed: 




diff  --git a/clang/docs/OpenCLSupport.rst b/clang/docs/OpenCLSupport.rst
index f7d6b1f7f2c9..8af579a082a9 100644
--- a/clang/docs/OpenCLSupport.rst
+++ b/clang/docs/OpenCLSupport.rst
@@ -360,7 +360,7 @@ implementation status.
 
+--+--+--+---+
 | Predefined macros| New version macro 
   | :good:`done` | https://reviews.llvm.org/D88300 
  |
 
+--+--+--+---+
-| Predefined macros| Feature macros
   | :part:`worked on`| https://reviews.llvm.org/D89869 
  |
+| Predefined macros| Feature macros
   | :good:`done` | https://reviews.llvm.org/D95776 
  |
 
+--+--+--+---+
 | Feature optionality  | Generic address space 
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+



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


[PATCH] D99415: [Utils] Add prefix parameter in update test checks to avoid FileCheck conflicts

2021-03-26 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis created this revision.
Herald added a subscriber: arichardson.
ggeorgakoudis requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99415

Files:
  clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp
  
clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
  clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -16,6 +16,7 @@
 
 
 _verbose = False
+_prefix_filecheck_ir_name = ''
 
 def parse_commandline_args(parser):
   parser.add_argument('--include-generated-funcs', action='store_true',
@@ -32,6 +33,8 @@
   help='Deactivate CHECK line generation from this point forward')
   parser.add_argument('--replace-function-regex', nargs='+', default=[],
   help='List of regular expressions to replace matching function names')
+  parser.add_argument('--prefix-filecheck-ir-name', default='',
+  help='Add a prefix to FileCheck IR value names to avoid conflicts with scripted names')
   args = parser.parse_args()
   global _verbose
   _verbose = args.verbose
@@ -53,6 +56,9 @@
 self.argparse_callback = argparse_callback
 self.path = test
 self.args = args
+if args.prefix_filecheck_ir_name:
+  global _prefix_filecheck_ir_name
+  _prefix_filecheck_ir_name = args.prefix_filecheck_ir_name
 self.argv = argv
 self.input_lines = input_lines
 self.run_lines = find_run_lines(test, self.input_lines)
@@ -515,8 +521,15 @@
 # Create a FileCheck variable name based on an IR name.
 def get_value_name(var, check_prefix):
   var = var.replace('!', '')
+  # This is a nameless value, prepend check_prefix.
   if var.isdigit():
 var = check_prefix + var
+  else:
+# This is a named value that clashes with the check_prefix, prepend with _prefix_filecheck_ir_name,
+# if it has been defined.
+if check_prefix and re.match(r'^' + check_prefix + r'[0-9]+?$', var, re.IGNORECASE) \
+  and _prefix_filecheck_ir_name:
+  var = _prefix_filecheck_ir_name + var
   var = var.replace('.', '_')
   var = var.replace('-', '_')
   return var.upper()
@@ -546,8 +559,10 @@
 pre, check = get_ir_prefix_from_ir_value_match(match)
 var = get_name_from_ir_value_match(match)
 for nameless_value in nameless_values:
-if nameless_value.check_prefix and re.match(r'^' + nameless_value.check_prefix + r'[0-9]+?$', var, re.IGNORECASE):
-warn("Change IR value name '%s' to prevent possible conflict with scripted FileCheck name." % (var,))
+if nameless_value.check_prefix and re.match(r'^' + nameless_value.check_prefix + r'[0-9]+?$', var, re.IGNORECASE) \
+  and not _prefix_filecheck_ir_name:
+  warn("Change IR value name '%s' or use -prefix-ir-filecheck-name to prevent possible conflict"
+" with scripted FileCheck name." % (var,))
 key = (var, get_check_key_from_ir_value_match(match))
 is_local_def = is_local_def_ir_value_match(match)
 if is_local_def and key in vars_seen:
Index: clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
@@ -0,0 +1,8 @@
+## Test that CHECK lines generated avoid naming conflicts with FileCheck IR variables
+
+# RUN: cp %S/Inputs/resolve-tmp-conflict.cpp %t.cpp && %update_cc_test_checks --function-signature --prefix-filecheck-ir-name _ %t.cpp
+# RUN: diff -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
+
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.cpp
+# RUN: diff -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
Index: clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
@@ -0,0 +1,25 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --prefix-filecheck-ir-name _
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: define {{[^@]+}}@_Z3fooi
+// CHECK-SAME: (i32 [[A:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[_TMP0:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[_TMP1:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[REF_TMP:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 [[A]], i32* 

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

Sorry, but after this patch, I still see the issue mentioned in 
https://reviews.llvm.org/D96363#2650460
@abhina.sreeskantharajan are you be able to confirm the issue on your end?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan added a comment.

In D99363#2652899 , @aganea wrote:

> Sorry, but after this patch, I still see the issue mentioned in 
> https://reviews.llvm.org/D96363#2650460
> @abhina.sreeskantharajan are you able to confirm the issue on your end?

I don't have a Windows machine to test on, but I assumed since the problem was 
in rewrite then this patch should have fixed it. Would you be able to confirm 
if reverting the change in clang/lib/Driver/Driver.cpp fixes the problem for 
you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D98514: [RGT] Fix ASTMatchersTest so all assertions are executed

2021-03-26 Thread Paul Robinson via Phabricator via cfe-commits
probinson abandoned this revision.
probinson added a comment.

Problem has gone away, test assertions are now executed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98514

___
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

2021-03-26 Thread Fanbo Meng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6f91cf75d7f5: [SystemZ][z/OS] Ignore leading zero width 
bitfield alignment on z/OS target (authored by fanbo-meng).

Repository:
  rG LLVM Github Monorepo

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

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
@@ -796,6 +796,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 = &llvm::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 follows
   /// a zero length bitfield.
   unsigned getZeroLengthBitf

[clang] 6f91cf7 - [SystemZ][z/OS] Ignore leading zero width bitfield alignment on z/OS target

2021-03-26 Thread Fanbo Meng via cfe-commits

Author: Fanbo Meng
Date: 2021-03-26T10:10:33-04:00
New Revision: 6f91cf75d7f55c7beadeebeac7c1010a2e7c6553

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

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

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

Reviewed By: abhina.sreeskantharajan

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

Added: 


Modified: 
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

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 9791cb6bbee7..01ca9ca0d2a8 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -155,6 +155,10 @@ struct TransferrableTargetInfo {
   /// 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 @@ class TargetInfo : public virtual TransferrableTargetInfo,
 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 follows
   /// a zero length bitfield.
   unsigned getZeroLengthBitfieldBoundary() const {

diff  --git a/clang/lib/AST/RecordLayoutBuilder.cpp 
b/clang/lib/AST/RecordLayoutBuilder.cpp
index 95d69fa5b11a..eb9bfc20342f 100644
--- a/clang/lib/AST/RecordLayoutBuilder.cpp
+++ b/clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1627,12 +1627,17 @@ void ItaniumRecordLayoutBuilder::LayoutBitField(const 
FieldDecl *D) {
 // 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;

diff  --git a/clang/lib/Basic/TargetInfo.cpp b/clang/lib/Basic/TargetInfo.cpp
index bc3c607dd74e..468c8a24498a 100644
--- a/clang/lib/Basic/TargetInfo.cpp
+++ b/clang/lib/Basic/TargetInfo.cpp
@@ -104,6 +104,7 @@ TargetInfo::TargetInfo(const llvm::Triple &T) : 
TargetOpts(), Triple(T) {
   UseSignedCharForObjCBool = true;
   UseBitFieldTypeAlignment = true;
   UseZeroLengthBitfieldAlignment = false;
+  UseLeadingZeroLengthBitfield = true;
   UseExplicitBitFieldAlignment = true;
   ZeroLengthBitfieldBoundary = 0;
   HalfFormat = &llvm::APFloat::IEEEhalf();

diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 4de1b8d2db4f..568f759bfa0d 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -796,6 +796,7 @@ class LLVM_LIBRARY_VISIBILITY ZOSTargetInfo : public 
OSTargetInfo {
 this->WCharType = TargetInfo::UnsignedInt;
 this->UseBitFieldTypeAlignment = false;
 this->UseZeroLengthBitfieldAlignment = true;
+this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
 this->MinGlobalAlign = 0;
 this->DefaultAlignForAttributeAligned = 128;

diff  --git a/clang/test/CodeGen/SystemZ/zos-alignment.c 
b/clang/test/CodeGen/SystemZ/zos-alignment.c
index 4b572fcac5a9..703fd1a46c3b 100644
--- a/clang/test/CodeGen/SystemZ/zos-alignment.c
+++ b/clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -83,6 +83,35 @@ struct s6 {
 // CHECK-NEXT: 8 |   char *[] b
 // CHECK-NEXT:   | [sizeof

[PATCH] D99415: [Utils] Add prefix parameter in update test checks to avoid FileCheck conflicts

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

Cool, thanks. LGTM, two nits.




Comment at: llvm/utils/UpdateTestChecks/common.py:532
+  and _prefix_filecheck_ir_name:
+  var = _prefix_filecheck_ir_name + var
   var = var.replace('.', '_')

Move the re.match into a helper (also used below), maybe: 
`may_clash_with_default_check_prefix_name(check_prefix, var)`



Comment at: llvm/utils/UpdateTestChecks/common.py:563
+if nameless_value.check_prefix and re.match(r'^' + 
nameless_value.check_prefix + r'[0-9]+?$', var, re.IGNORECASE) \
+  and not _prefix_filecheck_ir_name:
+  warn("Change IR value name '%s' or use -prefix-ir-filecheck-name to 
prevent possible conflict"

I would not add the `and not _prefix_filecheck...` stuff here because if the 
other condition holds a warning seems appropriate, maybe the prefix was chosen 
pooreley, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99415

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


[clang] 6e46f0b - [OpenCL] Fix AST check in address-space-templates test

2021-03-26 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-03-26T14:24:30Z
New Revision: 6e46f0b628308ba39feb13872cb21166b857dfdb

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

LOG: [OpenCL] Fix AST check in address-space-templates test

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

Added: 


Modified: 
clang/test/SemaOpenCLCXX/address-space-templates.clcpp

Removed: 




diff  --git a/clang/test/SemaOpenCLCXX/address-space-templates.clcpp 
b/clang/test/SemaOpenCLCXX/address-space-templates.clcpp
index 105a0ddeb35f..0ea1a2a1e4df 100644
--- a/clang/test/SemaOpenCLCXX/address-space-templates.clcpp
+++ b/clang/test/SemaOpenCLCXX/address-space-templates.clcpp
@@ -31,7 +31,7 @@ template  struct as_pointer {
 // Check address space deduction in template parameter deduction.
 struct rep {
   // When there is no address space on a reference use __generic.
-  // CHECK: |-CXXConstructorDecl {{.*}} rep 'void (const __generic rep 
&__private) __generic'
+  // CHECK: |-CXXConstructorDecl {{.*}} rep 'void (const __generic rep 
&__private){{.*}} __generic'
   template::type>
   rep(U&& v) {}
 };
@@ -57,6 +57,6 @@ void bar() {
   rep_outer r;
   int i;
   // Preserve the address space of the type in forwarding reference.
-  // CHECK: CXXMethodDecl {{.*}} operator() 'void (__private int &__private) 
const __generic'
+  // CHECK: CXXMethodDecl {{.*}} operator() 'void (__private int 
&__private){{.*}} const __generic'
   foo4(i, [](auto&& x){;});
 }



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


[PATCH] D99258: [OpenCL] Fix AST check in address-space-templates test

2021-03-26 Thread Anastasia Stulova via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6e46f0b62830: [OpenCL] Fix AST check in 
address-space-templates test (authored by Anastasia).
Herald added a subscriber: ldrumm.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D99258?vs=332954&id=333551#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99258

Files:
  clang/test/SemaOpenCLCXX/address-space-templates.clcpp


Index: clang/test/SemaOpenCLCXX/address-space-templates.clcpp
===
--- clang/test/SemaOpenCLCXX/address-space-templates.clcpp
+++ clang/test/SemaOpenCLCXX/address-space-templates.clcpp
@@ -31,7 +31,7 @@
 // Check address space deduction in template parameter deduction.
 struct rep {
   // When there is no address space on a reference use __generic.
-  // CHECK: |-CXXConstructorDecl {{.*}} rep 'void (const __generic rep 
&__private) __generic'
+  // CHECK: |-CXXConstructorDecl {{.*}} rep 'void (const __generic rep 
&__private){{.*}} __generic'
   template::type>
   rep(U&& v) {}
 };
@@ -57,6 +57,6 @@
   rep_outer r;
   int i;
   // Preserve the address space of the type in forwarding reference.
-  // CHECK: CXXMethodDecl {{.*}} operator() 'void (__private int &__private) 
const __generic'
+  // CHECK: CXXMethodDecl {{.*}} operator() 'void (__private int 
&__private){{.*}} const __generic'
   foo4(i, [](auto&& x){;});
 }


Index: clang/test/SemaOpenCLCXX/address-space-templates.clcpp
===
--- clang/test/SemaOpenCLCXX/address-space-templates.clcpp
+++ clang/test/SemaOpenCLCXX/address-space-templates.clcpp
@@ -31,7 +31,7 @@
 // Check address space deduction in template parameter deduction.
 struct rep {
   // When there is no address space on a reference use __generic.
-  // CHECK: |-CXXConstructorDecl {{.*}} rep 'void (const __generic rep &__private) __generic'
+  // CHECK: |-CXXConstructorDecl {{.*}} rep 'void (const __generic rep &__private){{.*}} __generic'
   template::type>
   rep(U&& v) {}
 };
@@ -57,6 +57,6 @@
   rep_outer r;
   int i;
   // Preserve the address space of the type in forwarding reference.
-  // CHECK: CXXMethodDecl {{.*}} operator() 'void (__private int &__private) const __generic'
+  // CHECK: CXXMethodDecl {{.*}} operator() 'void (__private int &__private){{.*}} const __generic'
   foo4(i, [](auto&& x){;});
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99372: [OpenMP][NFC] Generate check lines with update script

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/test/OpenMP/cancel_codegen.cpp:83
+// OMP-LABEL: @main(
+// OMP-NEXT:  entry:
+// OMP-NEXT:[[RETVAL:%.*]] = alloca i32, align 4

ABataev wrote:
> I think it may fail in release mode, where no symbol names are generated. 
> Need to replace labels with macros too.
Release + Asserts works, I haven't tried w/o asserts yet. That feature is 
tracked here: https://bugs.llvm.org/show_bug.cgi?id=49714


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99372

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


[PATCH] D99407: [clang][ItaniumMangle] Check SizeExpr for DependentSizedArrayType (PR49478)

2021-03-26 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: clang/test/AST/ast-dump-array-json.cpp:6
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",

I am not sure if this test tests the code you change since the mangled variable 
name does not encode type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99407

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


[PATCH] D99079: [ARM][AArch64] Require appropriate features for crypto algorithms

2021-03-26 Thread Tim Northover via Phabricator via cfe-commits
t.p.northover added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:641
+  });
+  if ((ItSHA2 != Features.rend()) || (ItSHA2 != Features.rend()))
+Features.push_back("-crypto");

Both of these checks are identical.

And could we get a comment on the purpose of this sequence? I think I can see 
mechanically what it's doing after a bit of thought, but still haven't come up 
with an example of the kind of problem it's trying to fix (not that I've tried 
terribly hard, that's what comments are for).



Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:643
+Features.push_back("-crypto");
+  if (ItSHA2 != Features.rend()) {
+HasSHA2 = ItSHA2->take_front() == "+";

I think modifying `Features` above might have invalidated the iterator.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99079

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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2021-03-26 Thread Ronan Keryell via Phabricator via cfe-commits
keryell added a comment.
Herald added a subscriber: dexonsmith.

An FPGA programmer is hitting this issue from your unit test:

  c++
signed _ExtInt(1) m; // expected-error{{signed _ExtInt must have a bit size 
of at least 2}}

Why do you not allow a type able to represent `{-1, 0}`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967

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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2021-03-26 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D73967#2653042 , @keryell wrote:

> An FPGA programmer is hitting this issue from your unit test:
>
>   c++
> signed _ExtInt(1) m; // expected-error{{signed _ExtInt must have a bit 
> size of at least 2}}
>
> Why do you not allow a type able to represent `{-1, 0}`?

Our FPGA team didn't see any value in it, so we didn't propose it to WG14, so 
we didn't implement it here.  I'm sure a follow-up paper to WG14 would be 
considered, and if it shows promise/positive reception, we'd welcome a patch 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967

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


[PATCH] D93164: [AST] Add generator for source location introspection

2021-03-26 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

This change breaks cross-compilation now, as it tries running an executable 
built for the target system:

  FAILED: tools/clang/lib/Tooling/ASTNodeAPI.json 
  cd /home/mgorny/llvm-project/build.arm64/tools/clang/lib/Tooling && 
/home/mgorny/llvm-project/build.arm64/bin/clang-ast-dump --skip-processing=0 
--astheader=/home/mgorny/llvm-project/build.arm64/tools/clang/lib/Tooling/ASTTU.cpp
 -I /home/mgorny/llvm-project/build.arm64/lib/clang/13.0.0/include -I 
/home/mgorny/llvm-project/llvm/../clang/include -I 
/home/mgorny/llvm-project/build.arm64/tools/clang/include -I 
/home/mgorny/llvm-project/build.arm64/include -I 
/home/mgorny/llvm-project/llvm/include -I /sysroot/arm64/usr/include/c++/v1 -I 
/usr/lib/clang/11.0.1/include -I /sysroot/arm64/usr/include --json-output-path 
/home/mgorny/llvm-project/build.arm64/tools/clang/lib/Tooling/ASTNodeAPI.json
  /bin/sh: /home/mgorny/llvm-project/build.arm64/bin/clang-ast-dump: Exec 
format error

I guess you can look at TableGens how to correctly generate and use host 
executables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93164

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


[PATCH] D99360: [OpenMP][WIP] Add standard notes for ELF offload images

2021-03-26 Thread Vyacheslav Zakharin via Phabricator via cfe-commits
vzakhari added a comment.

In D99360#2652523 , @jhenderson wrote:

> It might make sense to do the llvm-readobj portions of this patch in a 
> separate review, since they are somewhat independent.

I agree.  I actually have them in two patches, but I squashed them together for 
the complete story.  If everyone agrees with this in general, I will upload two 
separate clang-formatted patches.


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

https://reviews.llvm.org/D99360

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


[PATCH] D99421: [ASTImporter] Import member specialization/instantiation of enum decls

2021-03-26 Thread Gabor Marton via Phabricator via cfe-commits
martong created this revision.
martong added reviewers: teemperor, shafik, balazske, steakhal.
Herald added subscribers: whisperity, gamesh411, Szelethus, dkrupp, rnkovacs.
Herald added a reviewer: a.sidorin.
martong requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We do the import of the member enum specialization similarly to as we do
with member CXXRecordDecl specialization.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99421

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
@@ -6236,6 +6236,26 @@
   EXPECT_NE(FromFD->getCapturedVLAType(), ToFD->getCapturedVLAType());
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, Maci) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template  struct A {
+enum tagname { enumerator };
+  };
+  template struct A;
+  )",
+  Lang_CXX03);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasName("tagname"),
+   hasParent(classTemplateSpecializationDecl(;
+  ASSERT_TRUE(FromD);
+  ASSERT_TRUE(FromD->getMemberSpecializationInfo());
+
+  auto *ToD = Import(FromD, Lang_CXX03);
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2732,7 +2732,20 @@
   D2->setBraceRange(ToBraceRange);
   D2->setAccess(D->getAccess());
   D2->setLexicalDeclContext(LexicalDC);
-  LexicalDC->addDeclInternal(D2);
+  addDeclToContexts(D, D2);
+
+  if (MemberSpecializationInfo *MemberInfo = D->getMemberSpecializationInfo()) 
{
+TemplateSpecializationKind SK = 
MemberInfo->getTemplateSpecializationKind();
+EnumDecl *FromInst = D->getInstantiatedFromMemberEnum();
+if (Expected ToInstOrErr = import(FromInst))
+  D2->setInstantiationOfMemberEnum(*ToInstOrErr, SK);
+else
+  return ToInstOrErr.takeError();
+if (ExpectedSLoc POIOrErr = import(MemberInfo->getPointOfInstantiation()))
+  D2->getMemberSpecializationInfo()->setPointOfInstantiation(*POIOrErr);
+else
+  return POIOrErr.takeError();
+  }
 
   // Import the definition
   if (D->isCompleteDefinition())


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6236,6 +6236,26 @@
   EXPECT_NE(FromFD->getCapturedVLAType(), ToFD->getCapturedVLAType());
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, Maci) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template  struct A {
+enum tagname { enumerator };
+  };
+  template struct A;
+  )",
+  Lang_CXX03);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasName("tagname"),
+   hasParent(classTemplateSpecializationDecl(;
+  ASSERT_TRUE(FromD);
+  ASSERT_TRUE(FromD->getMemberSpecializationInfo());
+
+  auto *ToD = Import(FromD, Lang_CXX03);
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2732,7 +2732,20 @@
   D2->setBraceRange(ToBraceRange);
   D2->setAccess(D->getAccess());
   D2->setLexicalDeclContext(LexicalDC);
-  LexicalDC->addDeclInternal(D2);
+  addDeclToContexts(D, D2);
+
+  if (MemberSpecializationInfo *MemberInfo = D->getMemberSpecializationInfo()) {
+TemplateSpecializationKind SK = MemberInfo->getTemplateSpecializationKind();
+EnumDecl *FromInst = D->getInstantiatedFromMemberEnum();
+if (Expected ToInstOrErr = import(FromInst))
+  D2->setInstantiationOfMemberEnum(*ToInstOrErr, SK);
+else
+  return ToInstOrErr.takeError();
+if (ExpectedSLoc POIOrErr = import(MemberInfo->getPointOfInstantiation()))
+  D2->getMemberSpecializationInfo()->setPointOfInstantiation(*POIOrErr);
+else
+  return POIOrErr.takeError();
+  }
 
   // Import the definition
   if (D->isCompleteDefinition())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D97196: [clang-tidy] Add new check 'bugprone-unhandled-exception-at-new'.

2021-03-26 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-unhandled-exception-at-new.cpp:143
+  f_est_noexcept_dependent_used();
+}

aaron.ballman wrote:
> You have tests for placement new with `nothrow_t`, but I think other forms of 
> placement new are also very interesting to test as those typically don't 
> throw.
> 
> Additionally, perhaps tests where the allocation functions have been replaced 
> by the user (such as a class allocation function)?
I realized that the case of user-defined constructor or allocation function 
allows to throw any kind of exception. So the check should be improved to 
handle this case: Not rely on the syntax of new expression, instead check if 
the called allocation function or the called constructor may throw, and if yes, 
check what exceptions are possible. What is your opinion, is it a better 
approach?
(And a function to collect all possible exceptions called from a function is 
needed, `ExceptionAnalyzer` seems usable.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97196

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


[PATCH] D99421: [ASTImporter] Import member specialization/instantiation of enum decls

2021-03-26 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 333570.
martong added a comment.

- Rename test case name to something meaningful


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99421

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
@@ -6236,6 +6236,26 @@
   EXPECT_NE(FromFD->getCapturedVLAType(), ToFD->getCapturedVLAType());
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportEnumMemberSpecializtion) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template  struct A {
+enum tagname { enumerator };
+  };
+  template struct A;
+  )",
+  Lang_CXX03);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasName("tagname"),
+   hasParent(classTemplateSpecializationDecl(;
+  ASSERT_TRUE(FromD);
+  ASSERT_TRUE(FromD->getMemberSpecializationInfo());
+
+  auto *ToD = Import(FromD, Lang_CXX03);
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2732,7 +2732,20 @@
   D2->setBraceRange(ToBraceRange);
   D2->setAccess(D->getAccess());
   D2->setLexicalDeclContext(LexicalDC);
-  LexicalDC->addDeclInternal(D2);
+  addDeclToContexts(D, D2);
+
+  if (MemberSpecializationInfo *MemberInfo = D->getMemberSpecializationInfo()) 
{
+TemplateSpecializationKind SK = 
MemberInfo->getTemplateSpecializationKind();
+EnumDecl *FromInst = D->getInstantiatedFromMemberEnum();
+if (Expected ToInstOrErr = import(FromInst))
+  D2->setInstantiationOfMemberEnum(*ToInstOrErr, SK);
+else
+  return ToInstOrErr.takeError();
+if (ExpectedSLoc POIOrErr = import(MemberInfo->getPointOfInstantiation()))
+  D2->getMemberSpecializationInfo()->setPointOfInstantiation(*POIOrErr);
+else
+  return POIOrErr.takeError();
+  }
 
   // Import the definition
   if (D->isCompleteDefinition())


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6236,6 +6236,26 @@
   EXPECT_NE(FromFD->getCapturedVLAType(), ToFD->getCapturedVLAType());
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportEnumMemberSpecializtion) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template  struct A {
+enum tagname { enumerator };
+  };
+  template struct A;
+  )",
+  Lang_CXX03);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasName("tagname"),
+   hasParent(classTemplateSpecializationDecl(;
+  ASSERT_TRUE(FromD);
+  ASSERT_TRUE(FromD->getMemberSpecializationInfo());
+
+  auto *ToD = Import(FromD, Lang_CXX03);
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2732,7 +2732,20 @@
   D2->setBraceRange(ToBraceRange);
   D2->setAccess(D->getAccess());
   D2->setLexicalDeclContext(LexicalDC);
-  LexicalDC->addDeclInternal(D2);
+  addDeclToContexts(D, D2);
+
+  if (MemberSpecializationInfo *MemberInfo = D->getMemberSpecializationInfo()) {
+TemplateSpecializationKind SK = MemberInfo->getTemplateSpecializationKind();
+EnumDecl *FromInst = D->getInstantiatedFromMemberEnum();
+if (Expected ToInstOrErr = import(FromInst))
+  D2->setInstantiationOfMemberEnum(*ToInstOrErr, SK);
+else
+  return ToInstOrErr.takeError();
+if (ExpectedSLoc POIOrErr = import(MemberInfo->getPointOfInstantiation()))
+  D2->getMemberSpecializationInfo()->setPointOfInstantiation(*POIOrErr);
+else
+  return POIOrErr.takeError();
+  }
 
   // Import the definition
   if (D->isCompleteDefinition())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99189: [RISCV][Clang] Update new overloading rules for RVV intrinsics.

2021-03-26 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM other than those typos




Comment at: clang/include/clang/Basic/riscv_vector.td:161
+  // This builtin supports non-masked function overloading api.
+  // All masked operations support oerloading api.
+  bit HasNoMaskedOverloaded = true;

oerloading -> overloading



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:10
+// This tablegen backend is responsible for emitting riscv_vector.h which
+// includes a declaration and definition of each intrinsic fucntions specified
+// in https://github.com/riscv/rvv-intrinsic-doc.

fucntions -> functions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99189

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


[PATCH] D99237: [AVR][clang] Fix wrong calling convention in functions return struct type

2021-03-26 Thread Ben Shi via Phabricator via cfe-commits
benshi001 added a comment.

fully fixes https://bugs.llvm.org/show_bug.cgi?id=39251
partially fixes https://bugs.llvm.org/show_bug.cgi?id=46140


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

https://reviews.llvm.org/D99237

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


[PATCH] D96853: [clang][AVR] Support variable decorator '__flash'

2021-03-26 Thread Ben Shi via Phabricator via cfe-commits
benshi001 added a comment.

fixes https://bugs.llvm.org/show_bug.cgi?id=31568


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

https://reviews.llvm.org/D96853

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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

In D99363#2652907 , 
@abhina.sreeskantharajan wrote:

> In D99363#2652899 , @aganea wrote:
>
>> Sorry, but after this patch, I still see the issue mentioned in 
>> https://reviews.llvm.org/D96363#2650460
>> @abhina.sreeskantharajan are you able to confirm the issue on your end?
>
> I don't have a Windows machine to test on, but I assumed since the problem 
> was in rewrite then this patch should have fixed it. Would you be able to 
> confirm if reverting the change in clang/lib/Driver/Driver.cpp fixes the 
> problem for you?

I went back to the version on the left:
F16001158: image.png 
but that does not fix the problem.

Indeed, I've tested & the problem does not occur on Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

I'm just wondering if D96363  and all attached 
subsequent patches shouldn't be reverted for now. This is quite trivial case 
uncovered by tests. On re-land, I would then add a test validating the issue on 
Windows:

  $ cat -A rewrite-includes-clang-cl.cpp
  // REQUIRES: windows^M$
  // RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c 
/clang:-verify /Tp -^M$
  // expected-no-diagnostics^M$
  ^M$
  int foo();^M$
  int bar();^M$
  #define HELLO \^M$
foo(); \^M$
bar();^M$
  ^M$
  int main() {^M$
HELLO^M$
return 0;^M$
  }^M$


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

2021-03-26 Thread Alexey Bader via Phabricator via cfe-commits
bader updated this revision to Diff 333581.
bader added a comment.

Add links to SYCL specification with address space behavior description.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99190

Files:
  clang/docs/SYCLSupport.md
  clang/docs/images/Compiler-HLD.svg
  clang/docs/images/DeviceCodeSplit.svg
  clang/docs/images/DeviceLinkAndWrap.svg
  clang/docs/images/DevicePTXProcessing.svg
  clang/docs/images/SplitCompileAndLink.svg

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


[PATCH] D99400: [debug-info] support new tuning debugger type DBX for XCOFF DWARF

2021-03-26 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl accepted this revision.
aprantl added inline comments.
This revision is now accepted and ready to land.



Comment at: llvm/include/llvm/Target/TargetOptions.h:112
+SCE,  // Tune debug info for SCE targets (e.g. PS4).
+DBX   // Tune debug info for dbx.
   };

Nit: It would be nice to reformat all these comments for Doxygen:
`DBX   ///< Tune debug info for dbx.`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99400

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


[PATCH] D99250: [DebugInfo] Fix the mismatching of C++ language tags and Dwarf versions.

2021-03-26 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for your comments @dblaikie @probinson .

Sent out a mail to llvm-dev for continuous discussion. 
https://lists.llvm.org/pipermail/llvm-dev/2021-March/149446.html

Welcome your comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99250

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


[PATCH] D99250: [DebugInfo] Fix the mismatching of C++ language tags and Dwarf versions.

2021-03-26 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In D99250#2651953 , @probinson wrote:

> In D99250#2651204 , @dblaikie wrote:
>
>> Does anyone else have a DWARFv3 consumer they care about? (@aprantl and 
>> @probinson)
>>
>> Does anyone have a DWARF consumer that changes significantly based on the 
>> language version (I guess lldb (@aprantl can you confirm?)? I doubt gdb does 
>> (yeah, it just treats all C++ versions the same 
>> )?
>>  how about Sony?)
>
> I believe Sony is only using v4/v5 at this point.  Regarding dialect 
> controlling debugger behavior, I think it's unlikely, as distinguishing C++ 
> dialects is new in v5, its adoption is pretty recent (at least for us), and 
> we'd want behavior to be consistent across v4/v5 as much as possible.  I'll 
> verify that with our debugger guys.

I've confirmed that our intent is not to have dialect-specific behavior.

> If LLDB actually does _not_ have behavior change based on dialect, then we 
> might as well control language codes based on DWARF version, and the patch 
> should proceed.

I grepped the lldb tree and found nothing...  @aprantl can you confirm?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99250

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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2021-03-26 Thread Ronan Keryell via Phabricator via cfe-commits
keryell added a comment.

In D73967#2653044 , @erichkeane wrote:

> In D73967#2653042 , @keryell wrote:
>
>> 



>> Why do you not allow a type able to represent `{-1, 0}`?
>
> Our FPGA team didn't see any value in it, so we didn't propose it to WG14, so 
> we didn't implement it here.  I'm sure a follow-up paper to WG14 would be 
> considered, and if it shows promise/positive reception, we'd welcome a patch 
> here.

It comes from an FPGA tool programmer who knows about HLS *and* modern C++, so 
probably a very rare specie. :-)
The typical FPGA programmer and tool writer is often more focused on C, so 
knows barely nothing about generic programming.
In the meantime we can probably use C++20 concepts, a C++ wrapping type and 
some specialization for the 1bit case to handle this negative cases or just 
have a SYCL-specific fork...
Probably simpler to have a fork than trying to convince the C committee or FPGA 
people not understanding C++.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967

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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2021-03-26 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D73967#2653246 , @keryell wrote:

> In D73967#2653044 , @erichkeane 
> wrote:
>
>> In D73967#2653042 , @keryell wrote:
>>
>>> 
>
>
>
>>> Why do you not allow a type able to represent `{-1, 0}`?
>>
>> Our FPGA team didn't see any value in it, so we didn't propose it to WG14, 
>> so we didn't implement it here.  I'm sure a follow-up paper to WG14 would be 
>> considered, and if it shows promise/positive reception, we'd welcome a patch 
>> here.
>
> It comes from an FPGA tool programmer who knows about HLS *and* modern C++, 
> so probably a very rare specie. :-)
> The typical FPGA programmer and tool writer is often more focused on C, so 
> knows barely nothing about generic programming.
> In the meantime we can probably use C++20 concepts, a C++ wrapping type and 
> some specialization for the 1bit case to handle this negative cases or just 
> have a SYCL-specific fork...
> Probably simpler to have a fork than trying to convince the C committee or 
> FPGA people not understanding C++.

Our FPGA team DOES know HLS and (most of) modern C++, they are the implementers 
of 
https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html.

That said, I can see potential value (though the SFINAE to get the unsigned vs 
signed seems easy enough), but would suggest either the WG14 paper, or to 
suggest it to the authors of the WG14 paper and see what they say.  Feel free 
to include me in the chain.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967

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


[PATCH] D99425: [OpenCL] Fix parsing of opencl-c.h in CL 3.0

2021-03-26 Thread Kévin Petit via Phabricator via cfe-commits
kpet created this revision.
kpet added a reviewer: Anastasia.
kpet added a project: clang.
Herald added subscribers: ldrumm, kristof.beyls, yaxunl.
kpet requested review of this revision.
Herald added a subscriber: cfe-commits.

Ensure that the cl_khr_3d_image_writes pragma is enabled by making
cl_khr_3d_image_writes an optional core feature in CL 3.0 in addition
to being an available extension in 1.0 onwards and a core feature in
CL 2.0.

Signed-off-by: Kevin Petit 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99425

Files:
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/test/Headers/opencl-c-header.cl
  clang/test/SemaOpenCL/extension-version.cl


Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -93,12 +93,12 @@
 // expected-warning@-2{{OpenCL extension 'cl_khr_fp64' is core feature or 
supported optional core feature - ignoring}}
 #endif
 
-//Core feature in CL 2.0
+//Core feature in CL 2.0, optional core feature in CL 3.0
 #ifndef cl_khr_3d_image_writes
 #error "Missing cl_khr_3d_image_writes define"
 #endif
 #pragma OPENCL EXTENSION cl_khr_3d_image_writes : enable
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200) && 
defined TEST_CORE_FEATURES
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200 || 
__OPENCL_C_VERSION__ == 300) && defined TEST_CORE_FEATURES
 // expected-warning@-2{{OpenCL extension 'cl_khr_3d_image_writes' is core 
feature or supported optional core feature - ignoring}}
 #endif
 
Index: clang/test/Headers/opencl-c-header.cl
===
--- clang/test/Headers/opencl-c-header.cl
+++ clang/test/Headers/opencl-c-header.cl
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.1 
| FileCheck %s
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.2 
| FileCheck %s
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=clc++ 
| FileCheck %s --check-prefix=CHECK20
+// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL3.0 
| FileCheck %s
 
 // Test including the default header as a module.
 // The module should be compiled only once and loaded from cache afterwards.
@@ -81,7 +82,7 @@
 #endif
 
 // Verify that ATOMIC_VAR_INIT is defined.
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_2_0)
+#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
 global atomic_int z = ATOMIC_VAR_INIT(99);
 #endif //__OPENCL_C_VERSION__
 // CHECK-MOD: Reading modules
Index: clang/include/clang/Basic/OpenCLExtensions.def
===
--- clang/include/clang/Basic/OpenCLExtensions.def
+++ clang/include/clang/Basic/OpenCLExtensions.def
@@ -68,7 +68,7 @@
 OPENCL_EXTENSION(cl_khr_fp16, true, 100)
 OPENCL_EXTENSION(cl_khr_int64_base_atomics, true, 100)
 OPENCL_EXTENSION(cl_khr_int64_extended_atomics, true, 100)
-OPENCL_COREFEATURE(cl_khr_3d_image_writes, true, 100, OCL_C_20)
+OPENCL_GENERIC_EXTENSION(cl_khr_3d_image_writes, true, 100, OCL_C_20, OCL_C_30)
 
 // EMBEDDED_PROFILE
 OPENCL_EXTENSION(cles_khr_int64, true, 110)


Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -93,12 +93,12 @@
 // expected-warning@-2{{OpenCL extension 'cl_khr_fp64' is core feature or supported optional core feature - ignoring}}
 #endif
 
-//Core feature in CL 2.0
+//Core feature in CL 2.0, optional core feature in CL 3.0
 #ifndef cl_khr_3d_image_writes
 #error "Missing cl_khr_3d_image_writes define"
 #endif
 #pragma OPENCL EXTENSION cl_khr_3d_image_writes : enable
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200) && defined TEST_CORE_FEATURES
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200 || __OPENCL_C_VERSION__ == 300) && defined TEST_CORE_FEATURES
 // expected-warning@-2{{OpenCL extension 'cl_khr_3d_image_writes' is core feature or supported optional core feature - ignoring}}
 #endif
 
Index: clang/test/Headers/opencl-c-header.cl
===
--- clang/test/Headers/opencl-c-header.cl
+++ clang/test/Headers/opencl-c-header.cl
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.1 | FileCheck %s
 // RUN

[PATCH] D17183: Make TargetInfo store an actual DataLayout instead of a string.

2021-03-26 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Zombie comment time! I kind of don't love this change. clang's libBasic 
shouldn't depend on llvm/lib/IR: Practically there's no reason that building 
clang-format should build lib/IR and its deps, and more importantly 
semantically the dependency feels off too.

The dep from libBasic to lib/IR was added in 
https://reviews.llvm.org/rG8d043e82ef1179fed1d3d85171905c55bda7312f (oct 2014) 
then one day later 
http://reviews.llvm.org/rG86204b21e98b9d73b9ab381c87862837d2357082 formalized 
that but https://reviews.llvm.org/rGa0ac3c2bf049eb28e77a19dd70cbd570585f4747 
(two days later, also oct 2014) removed the dependency again. Alas, not from 
the CMakeLists.txt. Then, 1.5 years later, this added it back, and it's still 
here. I'd like to remove the dependency from clangBasic on lib/IR again.

I see these options:

1. Kind of revert this patch. Make TargetInfo again store the datalayout str 
and the prefix, and then assert somewhere that sees both layers (CodeGen) that 
the prefix matches the mangling in the layout string. Practically, I'd give 
resetDataLayout() the prefix as 2nd arg since that seems like a good place to 
set both. This abstractly makes sense to me since TargetInfo for the most part 
duplicates DataLayout.

2. split llvm/IR/DataLayout into DataLayoutString that just does the parsing 
and pointer width and primitive things and move that part to llvm/Support, and 
make IR/DataLayout use that new llvm/Support/DataLayoutString to do the 
llvm::Type-dependent bits. That way, TargetInfo could lean _more_ on the 
DataLayoutString for pointer sizes and widths and whatnot. But this general 
approach leads to everything being in llvm/Support over time :)

3. (not sure if feasible) move TargetInfo stuff out of Basic into a new 
libTargetInfo. Then the dep on IR could stay. That fixes layering but doesn't 
address that TargetInfo is independent of DataLayout except for this one thing.

I lean towards (1) since that feels like it's most in the spirit of the 
original TargetInfo design.

Does anyone have strong opinions?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D17183

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


[PATCH] D99415: [Utils] Add prefix parameter in update test checks to avoid FileCheck conflicts

2021-03-26 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis updated this revision to Diff 333584.
ggeorgakoudis marked an inline comment as done.
ggeorgakoudis added a comment.

Update for comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99415

Files:
  clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp
  
clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
  clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -16,6 +16,7 @@
 
 
 _verbose = False
+_prefix_filecheck_ir_name = ''
 
 def parse_commandline_args(parser):
   parser.add_argument('--include-generated-funcs', action='store_true',
@@ -32,6 +33,8 @@
   help='Deactivate CHECK line generation from this point forward')
   parser.add_argument('--replace-function-regex', nargs='+', default=[],
   help='List of regular expressions to replace matching function names')
+  parser.add_argument('--prefix-filecheck-ir-name', default='',
+  help='Add a prefix to FileCheck IR value names to avoid conflicts with scripted names')
   args = parser.parse_args()
   global _verbose
   _verbose = args.verbose
@@ -53,6 +56,9 @@
 self.argparse_callback = argparse_callback
 self.path = test
 self.args = args
+if args.prefix_filecheck_ir_name:
+  global _prefix_filecheck_ir_name
+  _prefix_filecheck_ir_name = args.prefix_filecheck_ir_name
 self.argv = argv
 self.input_lines = input_lines
 self.run_lines = find_run_lines(test, self.input_lines)
@@ -512,11 +518,21 @@
 def is_global_scope_ir_value_match(match):
 return nameless_values[get_idx_from_ir_value_match(match)].global_ir_prefix is not None
 
+# Return true if var clashes with the scripted FileCheck check_prefix.
+def may_clash_with_default_check_prefix_name(check_prefix, var):
+  return check_prefix and re.match(r'^' + check_prefix + r'[0-9]+?$', var, re.IGNORECASE)
+
 # Create a FileCheck variable name based on an IR name.
 def get_value_name(var, check_prefix):
   var = var.replace('!', '')
+  # This is a nameless value, prepend check_prefix.
   if var.isdigit():
 var = check_prefix + var
+  else:
+# This is a named value that clashes with the check_prefix, prepend with _prefix_filecheck_ir_name,
+# if it has been defined.
+if may_clash_with_default_check_prefix_name(check_prefix, var) and _prefix_filecheck_ir_name:
+  var = _prefix_filecheck_ir_name + var
   var = var.replace('.', '_')
   var = var.replace('-', '_')
   return var.upper()
@@ -546,8 +562,9 @@
 pre, check = get_ir_prefix_from_ir_value_match(match)
 var = get_name_from_ir_value_match(match)
 for nameless_value in nameless_values:
-if nameless_value.check_prefix and re.match(r'^' + nameless_value.check_prefix + r'[0-9]+?$', var, re.IGNORECASE):
-warn("Change IR value name '%s' to prevent possible conflict with scripted FileCheck name." % (var,))
+if may_clash_with_default_check_prefix_name(nameless_value.check_prefix, var):
+  warn("Change IR value name '%s' or use -prefix-ir-filecheck-name to prevent possible conflict"
+" with scripted FileCheck name." % (var,))
 key = (var, get_check_key_from_ir_value_match(match))
 is_local_def = is_local_def_ir_value_match(match)
 if is_local_def and key in vars_seen:
Index: clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
@@ -0,0 +1,8 @@
+## Test that CHECK lines generated avoid naming conflicts with FileCheck IR variables
+
+# RUN: cp %S/Inputs/resolve-tmp-conflict.cpp %t.cpp && %update_cc_test_checks --function-signature --prefix-filecheck-ir-name _ %t.cpp
+# RUN: diff -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
+
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.cpp
+# RUN: diff -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
Index: clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
@@ -0,0 +1,25 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --prefix-filecheck-ir-name _
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: define {{[^@]+}}@_Z3fooi
+// CHECK-SAME: (i32 [[A:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// C

[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-26 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan created this revision.
Herald added subscribers: dexonsmith, wenlei, okura, kuter, cmtice, martong, 
steven_wu, gbedwell, hiraditya, qcolombet, MatzeB.
Herald added a reviewer: bollu.
Herald added a reviewer: JDevlieghere.
Herald added a reviewer: andreadb.
Herald added a reviewer: jhenderson.
abhina.sreeskantharajan requested review of this revision.
Herald added subscribers: llvm-commits, lldb-commits, cfe-commits, bbn, MaskRay.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: sstefan1.
Herald added a reviewer: baziotis.
Herald added projects: clang, LLDB, LLVM, clang-tools-extra.

On SystemZ we need to open text files in text mode, but on Windows this may not 
be desirable if we want to suppress CRLF translation. This patch adds two new 
flags

- OF_CRLF which indicates that CRLF translation is used.
- OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses 
CRLF translation.

Major change in llvm/lib/Support/Windows/Path.inc to only set text mode if the 
OF_CRLF is set.

  if (Flags & OF_CRLF)
CrtOpenFlags |= _O_TEXT;




Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99426

Files:
  clang-tools-extra/clang-move/tool/ClangMove.cpp
  clang-tools-extra/modularize/ModuleAssistant.cpp
  clang-tools-extra/pp-trace/PPTrace.cpp
  clang/lib/ARCMigrate/PlistReporter.cpp
  clang/lib/Driver/Compilation.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/DependencyFile.cpp
  clang/lib/Frontend/DependencyGraph.cpp
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Frontend/HeaderIncludeGen.cpp
  clang/lib/Frontend/ModuleDependencyCollector.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/tools/clang-refactor/ClangRefactor.cpp
  clang/tools/driver/cc1as_main.cpp
  flang/lib/Frontend/CompilerInstance.cpp
  lld/COFF/DriverUtils.cpp
  lld/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp
  lldb/include/lldb/Utility/ReproducerProvider.h
  lldb/source/Utility/GDBRemote.cpp
  lldb/source/Utility/ReproducerProvider.cpp
  lldb/tools/lldb-server/LLDBServerUtilities.cpp
  llvm/include/llvm/Analysis/DOTGraphTraitsPass.h
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/CodeGen/RegAllocPBQP.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/LLVMRemarkStreamer.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/MC/MCParser/DarwinAsmParser.cpp
  llvm/lib/ProfileData/GCOV.cpp
  llvm/lib/ProfileData/SampleProfWriter.cpp
  llvm/lib/Support/FileCollector.cpp
  llvm/lib/Support/MemoryBuffer.cpp
  llvm/lib/Support/TimeProfiler.cpp
  llvm/lib/Support/Timer.cpp
  llvm/lib/Support/Unix/Program.inc
  llvm/lib/Support/Windows/Path.inc
  llvm/lib/Support/Windows/Program.inc
  llvm/lib/Transforms/IPO/Attributor.cpp
  llvm/lib/Transforms/IPO/LowerTypeTests.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/lib/Transforms/Utils/Debugify.cpp
  llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
  llvm/tools/dsymutil/dsymutil.cpp
  llvm/tools/llc/llc.cpp
  llvm/tools/lli/lli.cpp
  llvm/tools/llvm-cxxmap/llvm-cxxmap.cpp
  llvm/tools/llvm-dis/llvm-dis.cpp
  llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
  llvm/tools/llvm-exegesis/lib/BenchmarkResult.cpp
  llvm/tools/llvm-link/llvm-link.cpp
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-opt-report/OptReport.cpp
  llvm/tools/llvm-profdata/llvm-profdata.cpp
  llvm/tools/llvm-xray/xray-account.cpp
  llvm/tools/llvm-xray/xray-converter.cpp
  llvm/tools/llvm-xray/xray-extract.cpp
  llvm/tools/llvm-xray/xray-graph-diff.cpp
  llvm/tools/llvm-xray/xray-graph.cpp
  llvm/tools/opt/opt.cpp
  llvm/tools/verify-uselistorder/verify-uselistorder.cpp
  llvm/unittests/Support/Path.cpp
  polly/lib/Exchange/JSONExporter.cpp

Index: polly/lib/Exchange/JSONExporter.cpp
===
--- polly/lib/Exchange/JSONExporter.cpp
+++ polly/lib/Exchange/JSONExporter.cpp
@@ -178,7 +178,7 @@
 
   // Write to file.
   std::error_code EC;
-  ToolOutputFile F(FileName, EC, llvm::sys::fs::OF_Text);
+  ToolOutputFile F(FileName, EC, llvm::sys::fs::OF_TextWithCRLF);
 
   std::string FunctionName = S.getFunction().getName().str();
   errs() << "Writing JScop '" << S.getNameStr() << "' in function '"
Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1253,7 +1253,7 @@
   path::append(FilePathname, "test");
 
   {
-raw_fd_ostream File(FilePathname, EC, sys::fs::OF_Text);
+raw_fd_ostream File(FilePathname, EC, sys::fs::OF_TextWithCRLF);
 ASSERT_NO_ERROR(EC);
 File << '\n';
   }
Index: llvm/tools/verify-uselistorder/verify-uselistorder.cpp
===
--- llvm/tools/verify-uselistorder/verify-uselistorder.cpp
+++ llvm/tools/verify-

[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2021-03-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D73967#2653042 , @keryell wrote:

> An FPGA programmer is hitting this issue from your unit test:
>
>   c++
> signed _ExtInt(1) m; // expected-error{{signed _ExtInt must have a bit 
> size of at least 2}}
>
> Why do you not allow a type able to represent `{-1, 0}`?

At the time this feature was first being designed for WG14, I believe ones 
complement and sign magnitude integer representations were still allowed, so a 
signed 1-bit _ExtInt made no sense. That's no longer the case and so WG14 may 
be more interested in hearing about this if you have a compelling use case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967

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


[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

2021-03-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/docs/SYCLSupport.md:857
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't assign OpenCL generic address space to a declaration's type 
without
+explicit address space attribute. Similar to other single-source C++-based GPU

FYI OpenCL also deduced private and global address spaces. I suggest you change 
this to something like:


```
SYCL doesn't perform address space qualifier inference detailed in v3.0 s6.7.8: 
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference`.
```

Since the inference happens in the parsing as a final step (during `CodeGen`) 
instead, it would be good to add that certain variables are bind to the 
physical global memory segments i.e. globals, static locals, etc. You already 
have some info at the end of the paragraph.



Comment at: clang/docs/SYCLSupport.md:859
+explicit address space attribute. Similar to other single-source C++-based GPU
+programming modes like OpenMP/CUDA/HIP, SYCL uses clang's "default" address
+space for types with no address space attributes. During the lowering to LLVM

I think this implied from the statement above i.e. the address spaces are not 
inferred.

What might be important to describe is where other objects are bound to i.e. 
non-globals are bound to a private memory?  You could consider refering to 
OpenCL spec on that since I feel it might be fairly similar?





Comment at: clang/docs/SYCLSupport.md:861
+space for types with no address space attributes. During the lowering to LLVM
+IR, the default address space is mapped to the SPIR generic address space.
+Declarations are assigned to the relevant memory region depending on their

Ok this is an implementation details but from the language sematic it would be 
good to describe what logic you are expecting.

So `Default` address space is primarily used for C/C++ flat memory which means 
everything in standard C or C++ will be  in `Default` and this is where the 
local memory is allocated too.

```
When not specified otherwise, objects are allocated by default in a generic 
address space, which corresponds to the single address space of ISO/IEC 
9899:1999.

```
I am guessing this doesn't entirely apply to SYCL? I think this would be 
important to clarify so it is clear what your semantic of `Default` is. It 
would make sense to reference OpenCL generic address space or any other 
documentation if you want to be concise.



Comment at: clang/docs/SYCLSupport.md:863
+Declarations are assigned to the relevant memory region depending on their
+declaration context and pointers to them are cast to generic. This design has
+two important features: keeps the type system consistent with C++ on one hand

Ok, I suggested to lift this to where you describe the inference. It would be 
good to elaborate on what objects are bound to what memory segments. You might 
also refer to OpenCL spec since I believe the memory segments are fairly 
similar. 

Can you explain this point a bit more `and pointers to them are cast to 
generic`? Having an example might help too.



Comment at: clang/docs/SYCLSupport.md:864
+declaration context and pointers to them are cast to generic. This design has
+two important features: keeps the type system consistent with C++ on one hand
+and enable tools for emitting device code aligned with SPIR memory model (and

Ok, I would put the design goals to the top. 

Btw I am not sure this is the case "keeps the type system consistent with C++" 
since your semantic of default address spaces is different to C++. Perhaps you 
can elaborate more what it means...



Comment at: clang/docs/SYCLSupport.md:886
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:

I don't understand what is the message of this paragraph. The example compiles 
in accordance with OpenCL language semantic... Perhaps you can elaborate more.



Comment at: clang/docs/SYCLSupport.md:906
+
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes in SYCL mode:

I would suggest to move this table to the top and also as an introduction to 
make references to OpenCL memory model and address space qualifiers to make it 
clear that this is reused from OpenCL.



Comment at: clang/docs/SYCLSupport.md:919
+> **NOTE**: although SYCL device compiler supports
+`__attribute__((opencl_constant))`, the use of this attribute is limited within
+SYCL implementation. An OpenCL constant pointer can not be casted to a pointer

I am not sure what limited means? I would suggest being more specific and state 
something like that there is no bindi

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-03-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D89909#2652459 , @bader wrote:

> In D89909#2624284 , @aaron.ballman 
> wrote:
>
>> Based on the discussion so far, would these be acceptable steps to take?
>>
>> 0) Complete review on this patch for any technical concerns related to it 
>> and commit when it's ready (this unblocks some downstream needs quickly, 
>> hopefully).
>>
>> 1. @bader (or someone else on the SYCL team) creates a bare-bones SYCL 
>> documentation page that is quickly accepted as a placeholder for us to put 
>> more documentation.
>> 2. Each new SYCL related review that needs user-facing documentation outside 
>> of what the SYCL standard documents will update the Clang SYCL doc.
>> 3. @bader (or someone else on the SYCL team) writes address-space mapping 
>> documentation and adds it to the Clang SYCL doc.
>> 4. @bader (or someone else on the SYCL team) looks at other commits that 
>> have already gone into Clang to write missing documentation.
>>
>> Some of these steps can be done in parallel, of course. I recognize we could 
>> have the order be #1 -> #3 -> #0 (so the docs for this change are written as 
>> part of this patch), but my concern with that approach is that this patch is 
>> blocking other SYCL efforts (@bader can correct me if I'm wrong about this) 
>> and no one has identified a definite issue with it yet beyond the lack of 
>> Clang documentation.
>>
>> If those steps seem unreasonable or like I've totally missed the point on 
>> something, perhaps we could reach an understanding more quickly via a 
>> meeting (we could summarize the decisions from the meeting here so the 
>> community is aware of the end results)?
>
> @aaron.ballman, I've uploaded SYCL architecture design document with address 
> space section (https://reviews.llvm.org/D99190).
> I checked commits with SYCL functionality and we documented all extensions. 
> In particular `sycl_kernel` attribute mentioned above is documented here - 
> https://clang.llvm.org/docs/AttributeReference.html#sycl-kernel.
> Are there any other steps I should do or we can consider it to be done?
>
> Yesterday, we chatted offline and agreed that the main issue is missing 
> documentation for Clang extensions being added for SYCL. To address this 
> issue we are adding SYCL architecture design document, which we are going to 
> update along with adding new features.
>
> @Anastasia, @aaron.ballman, is there anything I can do for this patch to be 
> accepted?

I have provided my feedback regarding the address space section on the 
documentation review. I don't think I will be able to look at the other parts 
of documentation though. So if you would like to finalize the address spaces 
faster it might make sense to split it up into a separate review. This might 
also help to reduce the noise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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


[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-03-26 Thread Alexey Bader via Phabricator via cfe-commits
bader added a comment.

> Yesterday, we chatted offline and agreed that the main issue is missing 
> documentation for Clang extensions being added for SYCL. To address this 
> issue we are adding SYCL architecture design document, which we are going to 
> update along with adding new features.

I'd like to provide a bit more detailed summary. I think meeting was very 
useful with the following basic outcome:

- Need to add references to SYCL spec where applicable
- Need to update documentation where references are not enough, in particular:
  - C++ address space attributes used to implement SYCL address space behavior 
defined by the specification
  - main issue is missing documentation for Clang extensions being added for 
SYCL.
- @Anastasia needs some time to read all references/docs provided, some of them 
has been sent during the meeting

Do you agree on the list above or I missed anything?

This is what has been done already after the meeting based on the comments made:

- I've uploaded SYCL architecture design document with address space section 
(https://reviews.llvm.org/D99190) and added references to the specification 
sections describing address spaces.
- I checked commits with SYCL functionality and we documented all extensions. 
In particular `sycl_kernel` attribute mentioned above is documented here - 
https://clang.llvm.org/docs/AttributeReference.html#sycl-kernel.

I believe that currently this PR is in much better shape than it was and I 
think I addressed all critical missing items that have been mentioned.
Can you please review and let me know if anything missing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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


[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-03-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

Need to perform general analysis on SPMD kernels to correctly identify
the variables that should be globalized because of esacaping their
declaration context.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99432

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp

Index: clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
===
--- clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
+++ clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
@@ -28,16 +28,19 @@
 int main(int argc, char **argv) {
   int b[10], c[10], d[10];
 #pragma omp target teams map(tofrom:a)
+  {
+double escaped = 0;
 #pragma omp distribute parallel for firstprivate(b) lastprivate(c) if(a)
   for (int i= 0; i < argc; ++i)
-a = foo(&i) + foo(&a) + foo(&b[i]) + foo(&c[i]) + foo(&d[i]);
+a = foo(&i) + foo(&a) + foo(&b[i]) + foo(&c[i]) + foo(&d[i]) + escaped;
+  }
   return 0;
 }
 
 // SEQ: [[MEM_TY:%.+]] = type { [128 x i8] }
 // SEQ-DAG: [[SHARED_GLOBAL_RD:@.+]] = weak addrspace(3) global [[MEM_TY]] undef
 // SEQ-DAG: [[KERNEL_PTR:@.+]] = internal addrspace(3) global i8* undef
-// SEQ-DAG: [[KERNEL_SIZE:@.+]] = internal unnamed_addr constant i{{64|32}} 40
+// SEQ-DAG: [[KERNEL_SIZE:@.+]] = internal unnamed_addr constant i{{64|32}} 48
 // SEQ-DAG: [[KERNEL_SHARED:@.+]] = internal unnamed_addr constant i16 1
 // CHECK-DAG: @__omp_offloading_{{.*}}_main_[[LINE:l.+]]_exec_mode = weak constant i8 0
 
@@ -47,9 +50,10 @@
 // SEQ: call void @__kmpc_get_team_static_memory(i16 1, i8* addrspacecast (i8 addrspace(3)* getelementptr inbounds ([[MEM_TY]], [[MEM_TY]] addrspace(3)* [[SHARED_GLOBAL_RD]], i32 0, i32 0, i32 0) to i8*), i{{64|32}} [[SIZE]], i16 [[SHARED]], i8** addrspacecast (i8* addrspace(3)* [[KERNEL_PTR]] to i8**))
 // SEQ: [[PTR:%.+]] = load i8*, i8* addrspace(3)* [[KERNEL_PTR]],
 // SEQ: [[GEP:%.+]] = getelementptr inbounds i8, i8* [[PTR]], i{{64|32}} 0
-// PAR: [[GEP:%.+]] = call i8* @__kmpc_data_sharing_push_stack(i{{32|64}} 40, i16 1)
+// PAR: [[GEP:%.+]] = call i8* @__kmpc_data_sharing_push_stack(i{{32|64}} 48, i16 1)
 // CHECK: [[STACK:%.+]] = bitcast i8* [[GEP]] to %struct._globalized_locals_ty*
-// CHECK: getelementptr inbounds %struct._globalized_locals_ty, %struct._globalized_locals_ty* [[STACK]], i{{32|64}} 0, i{{32|64}} 0
+// CHECK-DAG: getelementptr inbounds %struct._globalized_locals_ty, %struct._globalized_locals_ty* [[STACK]], i{{32|64}} 0, i{{32|64}} 1
+// CHECK-DAG: getelementptr inbounds %struct._globalized_locals_ty, %struct._globalized_locals_ty* [[STACK]], i{{32|64}} 0, i{{32|64}} 0
 // CHECK-NOT: getelementptr inbounds %struct._globalized_locals_ty, %struct._globalized_locals_ty* [[STACK]],
 // CHECK: call void @__kmpc_for_static_init_4(
 
Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -229,6 +229,7 @@
   llvm::SmallDenseMap MappedDeclsFields;
   bool AllEscaped = false;
   bool IsForCombinedParallelRegion = false;
+  bool IsInSPMDKernel = false;
 
   void markAsEscaped(const ValueDecl *VD) {
 // Do not globalize declare target variables.
@@ -242,6 +243,9 @@
 // Variables captured by value must be globalized.
 if (auto *CSI = CGF.CapturedStmtInfo) {
   if (const FieldDecl *FD = CSI->lookup(cast(VD))) {
+// Do not globalize captured vars in SPMD mode.
+if (IsInSPMDKernel)
+  return;
 // Check if need to capture the variable that was already captured by
 // value in the outer region.
 if (!IsForCombinedParallelRegion) {
@@ -351,9 +355,10 @@
 
 public:
   CheckVarsEscapingDeclContext(CodeGenFunction &CGF,
-   ArrayRef TeamsReductions)
-  : CGF(CGF), EscapedDecls(TeamsReductions.begin(), TeamsReductions.end()) {
-  }
+   ArrayRef TeamsReductions,
+   bool IsInSPMDKernel = false)
+  : CGF(CGF), EscapedDecls(TeamsReductions.begin(), TeamsReductions.end()),
+IsInSPMDKernel(IsInSPMDKernel) {}
   virtual ~CheckVarsEscapingDeclContext() = default;
   void VisitDeclStmt(const DeclStmt *S) {
 if (!S)
@@ -1631,65 +1636,30 @@
 OpenMPDirectiveKind InnermostKind, const RegionCodeGenTy &CodeGen) {
   SourceLocation Loc = D.getBeginLoc();
 
-  const RecordDecl *GlobalizedRD = nullptr;
-  llvm::SmallVector LastPrivatesReductions;
-  llvm::SmallDenseMap MappedDeclsFields;
-  unsigned WarpSize = CGM.getTarget().getGridValue(llvm::omp::GV_Warp_Size);
-  // Globalize team reductions 

[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

Can we please always do the globalization, even in the `target teams distribute 
parallel for` case you need it if a thread shares the address of a local 
variable with the team and another thread uses it.
There is no argument other than "doesn't escape" that Clang can make to 
disprove globalization is needed, IMHO.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99432

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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan added a comment.

In D99363#2653201 , @aganea wrote:

> I'm just wondering if D96363  and all 
> attached subsequent patches shouldn't be reverted for now. This is a quite 
> trivial case uncovered by tests. On re-land, I would then add a test 
> validating the issue on Windows:
>
>   $ cat -A rewrite-includes-clang-cl.cpp
>   // REQUIRES: system-windows^M$
>   // RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c /Tp -^M$
>   ^M$
>   int foo();^M$
>   int bar();^M$
>   #define HELLO \^M$
> foo(); \^M$
> bar();^M$
>   ^M$
>   int main() {^M$
> HELLO^M$
> return 0;^M$
>   }^M$

There were a lot of similar patches so reverting all of them might be more work 
than isolating the change that caused it and reverting that. It seems that the 
patch you initially commented on did not contain the problematic change since 
reverting the change doesn't fix your issue. I created the following patch 
https://reviews.llvm.org/D99426 based on @rnk suggestion. I created a new flag 
for OF_TextWithCRLF on Windows and made sure my most recent text changes use 
the OF_Text flag while all other uses were changed to OF_TextWithCRLF. This 
should solve any CRLF issues that were introduced recently by my patches. If 
you have time, would you be able to test if that patch fixes your issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-03-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D99432#2653474 , @jdoerfert wrote:

> Can we please always do the globalization, even in the `target teams 
> distribute parallel for` case you need it if a thread shares the address of a 
> local variable with the team and another thread uses it.

Could you give a small example so I could better understand the problem? Shall 
we globalize the variable in SPMD mode if we pass it by reference/take address 
in any case?

> There is no argument other than "doesn't escape" that Clang can make to 
> disprove globalization is needed, IMHO.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99432

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


[clang] 8bc2c66 - [Utils] Add prefix parameter in update test checks to avoid FileCheck conflicts

2021-03-26 Thread Giorgis Georgakoudis via cfe-commits

Author: Giorgis Georgakoudis
Date: 2021-03-26T11:49:42-07:00
New Revision: 8bc2c662d9c0f241fb8538979f8db1af7f2e353e

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

LOG: [Utils] Add prefix parameter in update test checks to avoid FileCheck 
conflicts

IR values convert to check prefix FileCheck variables for IR checks. For 
example, nameless values, e.g., %0, convert to check prefix TMP FileCheck 
variables, e.g., [[TMP0:%.*]]. This check prefix may clash with named values 
that have the same name and that causes auto-generated tests to fail. Currently 
a warning is emitted to change the names of the IR values but this is not 
always possible, if for example they are generated by clang. Manual 
intervention to fix the FileCheck variable names is too tedious. This patch add 
a parameter to prefix conflicting FileCheck variable names with a user-provided 
string to automate the process.

Reviewed By: jdoerfert

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

Added: 
clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp

clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test

Modified: 
llvm/utils/UpdateTestChecks/common.py

Removed: 




diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp 
b/clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp
new file mode 100644
index ..d82490ea3c88
--- /dev/null
+++ b/clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu -emit-llvm %s 
-o - | FileCheck %s
+
+void foo(int a) {
+  int &tmp0 = a;
+  int &&tmp1 = 1;
+  tmp1 = a;
+  return;
+}

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
 
b/clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
new file mode 100644
index ..9a3c4580f4c1
--- /dev/null
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
@@ -0,0 +1,25 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --function-signature --prefix-filecheck-ir-name _
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu -emit-llvm %s 
-o - | FileCheck %s
+
+// CHECK-LABEL: define {{[^@]+}}@_Z3fooi
+// CHECK-SAME: (i32 [[A:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[_TMP0:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[_TMP1:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[REF_TMP:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 [[A]], i32* [[A_ADDR]], align 4
+// CHECK-NEXT:store i32* [[A_ADDR]], i32** [[_TMP0]], align 8
+// CHECK-NEXT:store i32 1, i32* [[REF_TMP]], align 4
+// CHECK-NEXT:store i32* [[REF_TMP]], i32** [[_TMP1]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = load i32*, i32** [[_TMP1]], align 8
+// CHECK-NEXT:store i32 [[TMP0]], i32* [[TMP1]], align 4
+// CHECK-NEXT:ret void
+//
+void foo(int a) {
+  int &tmp0 = a;
+  int &&tmp1 = 1;
+  tmp1 = a;
+  return;
+}

diff  --git a/clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test 
b/clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
new file mode 100644
index ..a802e1aeecd8
--- /dev/null
+++ b/clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
@@ -0,0 +1,8 @@
+## Test that CHECK lines generated avoid naming conflicts with FileCheck IR 
variables
+
+# RUN: cp %S/Inputs/resolve-tmp-conflict.cpp %t.cpp && %update_cc_test_checks 
--function-signature --prefix-filecheck-ir-name _ %t.cpp
+# RUN: 
diff  -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
+
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.cpp
+# RUN: 
diff  -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp

diff  --git a/llvm/utils/UpdateTestChecks/common.py 
b/llvm/utils/UpdateTestChecks/common.py
index 1940ac3e8153..45984751d6e7 100644
--- a/llvm/utils/UpdateTestChecks/common.py
+++ b/llvm/utils/UpdateTestChecks/common.py
@@ -16,6 +16,7 @@ class string:
 
 
 _verbose = False
+_prefix_filecheck_ir_name = ''
 
 def parse_commandline_args(parser):
   parser.add_argument('--include-generated-funcs', action='store_true',
@@ -32,6 +33,8 @@ def parse_commandline_args(parser):
   help='Deactivate CHECK line generation from this point 
forward')
   parser.add_argument('--replace-function-regex', nargs='+', default=[],
   help='List of regular expressions t

[PATCH] D99415: [Utils] Add prefix parameter in update test checks to avoid FileCheck conflicts

2021-03-26 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8bc2c662d9c0: [Utils] Add prefix parameter in update test 
checks to avoid FileCheck conflicts (authored by ggeorgakoudis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99415

Files:
  clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp
  
clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
  clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -16,6 +16,7 @@
 
 
 _verbose = False
+_prefix_filecheck_ir_name = ''
 
 def parse_commandline_args(parser):
   parser.add_argument('--include-generated-funcs', action='store_true',
@@ -32,6 +33,8 @@
   help='Deactivate CHECK line generation from this point forward')
   parser.add_argument('--replace-function-regex', nargs='+', default=[],
   help='List of regular expressions to replace matching function names')
+  parser.add_argument('--prefix-filecheck-ir-name', default='',
+  help='Add a prefix to FileCheck IR value names to avoid conflicts with scripted names')
   args = parser.parse_args()
   global _verbose
   _verbose = args.verbose
@@ -53,6 +56,9 @@
 self.argparse_callback = argparse_callback
 self.path = test
 self.args = args
+if args.prefix_filecheck_ir_name:
+  global _prefix_filecheck_ir_name
+  _prefix_filecheck_ir_name = args.prefix_filecheck_ir_name
 self.argv = argv
 self.input_lines = input_lines
 self.run_lines = find_run_lines(test, self.input_lines)
@@ -512,11 +518,21 @@
 def is_global_scope_ir_value_match(match):
 return nameless_values[get_idx_from_ir_value_match(match)].global_ir_prefix is not None
 
+# Return true if var clashes with the scripted FileCheck check_prefix.
+def may_clash_with_default_check_prefix_name(check_prefix, var):
+  return check_prefix and re.match(r'^' + check_prefix + r'[0-9]+?$', var, re.IGNORECASE)
+
 # Create a FileCheck variable name based on an IR name.
 def get_value_name(var, check_prefix):
   var = var.replace('!', '')
+  # This is a nameless value, prepend check_prefix.
   if var.isdigit():
 var = check_prefix + var
+  else:
+# This is a named value that clashes with the check_prefix, prepend with _prefix_filecheck_ir_name,
+# if it has been defined.
+if may_clash_with_default_check_prefix_name(check_prefix, var) and _prefix_filecheck_ir_name:
+  var = _prefix_filecheck_ir_name + var
   var = var.replace('.', '_')
   var = var.replace('-', '_')
   return var.upper()
@@ -546,8 +562,9 @@
 pre, check = get_ir_prefix_from_ir_value_match(match)
 var = get_name_from_ir_value_match(match)
 for nameless_value in nameless_values:
-if nameless_value.check_prefix and re.match(r'^' + nameless_value.check_prefix + r'[0-9]+?$', var, re.IGNORECASE):
-warn("Change IR value name '%s' to prevent possible conflict with scripted FileCheck name." % (var,))
+if may_clash_with_default_check_prefix_name(nameless_value.check_prefix, var):
+  warn("Change IR value name '%s' or use -prefix-ir-filecheck-name to prevent possible conflict"
+" with scripted FileCheck name." % (var,))
 key = (var, get_check_key_from_ir_value_match(match))
 is_local_def = is_local_def_ir_value_match(match)
 if is_local_def and key in vars_seen:
Index: clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/resolve-tmp-conflict.test
@@ -0,0 +1,8 @@
+## Test that CHECK lines generated avoid naming conflicts with FileCheck IR variables
+
+# RUN: cp %S/Inputs/resolve-tmp-conflict.cpp %t.cpp && %update_cc_test_checks --function-signature --prefix-filecheck-ir-name _ %t.cpp
+# RUN: diff -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
+
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.cpp
+# RUN: diff -u %S/Inputs/resolve-tmp-conflict.cpp.expected %t.cpp
Index: clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected
@@ -0,0 +1,25 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --prefix-filecheck-ir-name _
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: define {{[^@]+}}@_Z3fooi
+// CHECK-SAME: (

[PATCH] D99407: [clang][ItaniumMangle] Check SizeExpr for DependentSizedArrayType (PR49478)

2021-03-26 Thread Tommy Chiang via Phabricator via cfe-commits
oToToT added inline comments.



Comment at: clang/test/AST/ast-dump-array-json.cpp:6
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",

yaxunl wrote:
> I am not sure if this test tests the code you change since the mangled 
> variable name does not encode type.
I think this test my code. Or, at least, this test will trigger a runtime error 
in the latest clang without this patch when mangling `A::Test`.

Also, maybe I could try construct a test to mangle variable with element type 
if needed.

WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99407

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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

In D99363#2653476 , 
@abhina.sreeskantharajan wrote:

> In D99363#2653201 , @aganea wrote:
>
>> I'm just wondering if D96363  and all 
>> attached subsequent patches shouldn't be reverted for now. This is a quite 
>> trivial case uncovered by tests. On re-land, I would then add a test 
>> validating the issue on Windows:
>>
>>   $ cat -A rewrite-includes-clang-cl.cpp
>>   // REQUIRES: system-windows^M$
>>   // RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c /Tp -^M$
>>   ^M$
>>   int foo();^M$
>>   int bar();^M$
>>   #define HELLO \^M$
>> foo(); \^M$
>> bar();^M$
>>   ^M$
>>   int main() {^M$
>> HELLO^M$
>> return 0;^M$
>>   }^M$
>
> There were a lot of similar patches so reverting all of them might be more 
> work than isolating the change that caused it and reverting that. It seems 
> that the patch you initially commented on did not contain the problematic 
> change since reverting the change doesn't fix your issue.

Actually it is `git bisect` that pointed me to that patch :-)

> I created the following patch https://reviews.llvm.org/D99426 based on @rnk 
> suggestion. I created a new flag for OF_TextWithCRLF on Windows and made sure 
> my most recent text changes use the OF_Text flag while all other uses were 
> changed to OF_TextWithCRLF. This should solve any CRLF issues that were 
> introduced recently by my patches. If you have time, would you be able to 
> test if that patch fixes your issue?

Yes I will!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Everton Constantino via Phabricator via cfe-commits
everton.constantino created this revision.
everton.constantino added reviewers: anemet, rjmccall, rsmith, Bigcheese, fhahn.
Herald added subscribers: dexonsmith, tschuett, hiraditya.
everton.constantino requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, jdoerfert.
Herald added projects: clang, LLVM.

This patch creates a new builtin to support matrix multiply add. Currently when 
you do C = A*B + C you have the overhead of additional fadds. With this
builtin the accumulatores are loaded with the C matrix during the 
multiplication considerably reducing the ammount of operations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99433

Files:
  clang/docs/MatrixTypes.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/matrix-type-builtins.c
  clang/test/Sema/matrix-type-builtins.c
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/IR/MatrixBuilder.h
  llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp

Index: llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp
===
--- llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp
+++ llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp
@@ -511,6 +511,7 @@
 if (II)
   switch (II->getIntrinsicID()) {
   case Intrinsic::matrix_multiply:
+  case Intrinsic::matrix_multiply_add:
   case Intrinsic::matrix_transpose:
   case Intrinsic::matrix_column_major_load:
   case Intrinsic::matrix_column_major_store:
@@ -540,6 +541,7 @@
 
   Value *MatrixA;
   Value *MatrixB;
+  Value *MatrixC;
   Value *M;
   Value *N;
   Value *K;
@@ -547,6 +549,11 @@
   m_Value(MatrixA), m_Value(MatrixB), m_Value(M),
   m_Value(N), m_Value(K {
 Propagate = setShapeInfo(Inst, {M, K});
+  } else if (match(Inst,
+   m_Intrinsic(
+   m_Value(MatrixA), m_Value(MatrixB), m_Value(MatrixC),
+   m_Value(M), m_Value(N), m_Value(K {
+Propagate = setShapeInfo(Inst, {M, K});
   } else if (match(Inst, m_Intrinsic(
  m_Value(MatrixA), m_Value(M), m_Value(N {
 // Flip dimensions.
@@ -611,6 +618,7 @@
 
   Value *MatrixA;
   Value *MatrixB;
+  Value *MatrixC;
   Value *M;
   Value *N;
   Value *K;
@@ -622,7 +630,18 @@
 
 if (setShapeInfo(MatrixB, {N, K}))
   pushInstruction(MatrixB, WorkList);
+  } else if (match(V,
+   m_Intrinsic(
+   m_Value(MatrixA), m_Value(MatrixB), m_Value(MatrixC),
+   m_Value(M), m_Value(N), m_Value(K {
+if (setShapeInfo(MatrixA, {M, N}))
+  pushInstruction(MatrixA, WorkList);
 
+if (setShapeInfo(MatrixB, {N, K}))
+  pushInstruction(MatrixB, WorkList);
+
+if (setShapeInfo(MatrixC, {M, K}))
+  pushInstruction(MatrixC, WorkList);
   } else if (match(V, m_Intrinsic(
   m_Value(MatrixA), m_Value(M), m_Value(N {
 // Flip dimensions.
@@ -673,6 +692,7 @@
 
   switch (II->getIntrinsicID()) {
   case Intrinsic::matrix_multiply:
+  case Intrinsic::matrix_multiply_add:
   case Intrinsic::matrix_transpose:
   case Intrinsic::matrix_column_major_load:
   case Intrinsic::matrix_column_major_store:
@@ -769,6 +789,9 @@
 case Intrinsic::matrix_column_major_store:
   LowerColumnMajorStore(Inst);
   break;
+case Intrinsic::matrix_multiply_add:
+  LowerMultiplyAdd(Inst);
+  break;
 default:
   return false;
 }
@@ -1009,11 +1032,13 @@
 }
   }
 
-  /// Compute \p Result += \p A * \p B for input matrices with left-associating
-  /// addition.
+  /// Compute \p Result += \p A * \p B + \p ACC for input matrices with
+  /// left-associating addition.
+  template 
   void emitMatrixMultiply(MatrixTy &Result, const MatrixTy &A,
   const MatrixTy &B, bool AllowContraction,
-  IRBuilder<> &Builder, bool isTiled) {
+  IRBuilder<> &Builder, bool isTiled,
+  const MatrixTy *ACC = nullptr) {
 const unsigned VF = std::max(
 TTI.getRegisterBitWidth(TargetTransformInfo::RGK_FixedWidthVector)
 .getFixedSize() /
@@ -1030,20 +1055,25 @@
 unsigned NumComputeOps = 0;
 if (A.isColumnMajor()) {
   // Multiply columns from the first operand with scalars from the second
-  // operand. Then move along the K axes and accumulate the columns.  With
+  // operand. Then move along the K axes and accumulate the columns. With
   // this the adds can be vectorized without reassociat

[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

[Drive by] LLVM test missing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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


[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-03-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D89909#2653454 , @bader wrote:

>> Yesterday, we chatted offline and agreed that the main issue is missing 
>> documentation for Clang extensions being added for SYCL. To address this 
>> issue we are adding SYCL architecture design document, which we are going to 
>> update along with adding new features.
>
> I'd like to provide a bit more detailed summary. I think meeting was very 
> useful with the following basic outcome:
>
> - Need to add references to SYCL spec where applicable
> - Need to update documentation where references are not enough, in particular:
>   - C++ address space attributes used to implement SYCL address space 
> behavior defined by the specification
>   - main issue is missing documentation for Clang extensions being added for 
> SYCL.
> - @Anastasia needs some time to read all references/docs provided, some of 
> them has been sent during the meeting
>
> Do you agree on the list above or I missed anything?
>
> This is what has been done already after the meeting based on the comments 
> made:
>
> - I've uploaded SYCL architecture design document with address space section 
> (https://reviews.llvm.org/D99190) and added references to the specification 
> sections describing address spaces.
> - I checked commits with SYCL functionality and we documented all extensions. 
> In particular `sycl_kernel` attribute mentioned above is documented here - 
> https://clang.llvm.org/docs/AttributeReference.html#sycl-kernel.
>
> I believe that currently this PR is in much better shape than it was and I 
> think I addressed all critical missing items that have been mentioned.
> Can you please review and let me know if anything missing?

Thanks, your summary look fairly accurate to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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


[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Everton Constantino via Phabricator via cfe-commits
everton.constantino added a comment.

@jdoerfert Which tests do you have in mind? I added one for SEMA and one for 
CodeGen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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


[PATCH] D99425: [OpenCL] Fix parsing of opencl-c.h in CL 3.0

2021-03-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks! I would like to hold off committing this for a day or two to see 
if there is any input from @azabaznov or anyone else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99425

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


[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-03-26 Thread Deep Majumder via Phabricator via cfe-commits
RedDocMD marked an inline comment as done.
RedDocMD added a comment.

@NoQ, what do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

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


[clang] 706c1dc - [OpenCL][Docs] Minor update about C++ for OpenCL in UsersManual.

2021-03-26 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-03-26T19:24:07Z
New Revision: 706c1dc266d247232243b83a06a4904f527dc245

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

LOG: [OpenCL][Docs] Minor update about C++ for OpenCL in UsersManual.

Added: 


Modified: 
clang/docs/UsersManual.rst

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 7709556fbace..6c8d297e618f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -3237,6 +3237,18 @@ compiling ``.cl`` file ``-cl-std=clc++``, 
``-cl-std=CLC++``, ``-std=clc++`` or
 
  clang -cl-std=clc++ test.cl
 
+Alternatively, files with ``.clcpp`` extension are compiled with the C++ for 
OpenCL
+mode.
+
+   .. code-block:: console
+
+ clang test.clcpp
+
+C++ for OpenCL kernel sources can also be compiled online in drivers 
supporting 
+`cl_ext_cxx_for_opencl
+`_
+extension.
+
 Constructing and destroying global objects
 ^^
 



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


[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

Thanks for putting up the patch!

Do you think it would be possible to get the desired behavior without a new 
builtin? We should be able to combine the add with the initial multiply for 
each vector, as long as we have the right fast-math flags? IIUC reassociate 
should be enough.  So perhaps it would be possible to perform this optimization 
in `LowerMatrixIntrinsics` directly.  The user should then be able to use to 
enable the right fast-math flags locally using `pragma clang fp`, like below. 
Clang first needs to be updated to handle those pragmas properly for the matrix 
types.

  #pragma clang fp reassociate(on)
  C = A*B + C;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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


[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Everton Constantino via Phabricator via cfe-commits
everton.constantino added a comment.

@fhahn That was my first idea however its not as simple as it looks. I tried 
moving the adds but splats make it considerably harder to find a pattern that 
catches this and fuses the multiplies specially with bigger matrices. My real 
wish was to actually add a new IR instruction to handle matrices because the 
MADD is but a simple example of other more interesting optimizations that can 
be done, like using matrix associative properties to reduce the number of 
calculations. I found that path too complicated however and I opted for a 
compromise at the moment. I wish to start writing some GEMM micro-kernels with 
this extension and this builtin was the shortest path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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


[PATCH] D96853: [clang][AVR] Support variable decorator '__flash'

2021-03-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D96853#2577172 , @benshi001 wrote:

> In D96853#2577133 , @aykevl wrote:
>
>> I am not very familiar with Clang so I can't say much about it. Although I 
>> wonder whether a macro is the right way to implement this? Is there 
>> something similar in other targets? (GPUs tend to have lots of address 
>> spaces, you could take a look there).
>
> A macro definition is the simplest way, an alias to 
> `__attribute__((address_space(0)))`. I do not find any other easy way for a 
> plain keyword `__flash`.

Ok, macro could be a reasonable direction. This is how clang implements address 
spaces for CUDA. Another option is adding a keyword. OpenCL implements address 
spaces this way. You can't add a target-specific keyword but considering that 
it start with "__" it should be reasonable to add this to C/C++ mode. You could 
for example align with gcc implementation.

I am guessing this will only be supported by 1 target in clang? Then target 
address spaces make sense otherwise you can also extend the language address 
space enum. Are you also planning to add `__flashN`?
 https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2995
+def err_qualifier_with_address_space : Error<
+  "qualifier '%select{const|volatile}0' %select{needed|invalid}1 "
+  "for variables in address space '%2'">;

Minor wording change:
```
qualifier '%select{const|volatile}0' is %select{needed|invalid}1
```

Could you not use the same parameter in select twice i.e.

```
qualifier '%select{const|volatile}0' is %select{needed|invalid}0
```
?


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

https://reviews.llvm.org/D96853

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


[PATCH] D99436: [OPENMP]Fix PR49366: crash on VLAs in task untied regions.

2021-03-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

We need to capture the local variables into a record in task untied
regions but clang does not support record with VLA data members.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99436

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/OpenMP/task_messages.cpp
  clang/test/OpenMP/taskloop_loop_messages.cpp

Index: clang/test/OpenMP/taskloop_loop_messages.cpp
===
--- clang/test/OpenMP/taskloop_loop_messages.cpp
+++ clang/test/OpenMP/taskloop_loop_messages.cpp
@@ -691,7 +691,7 @@
 
 void test_loop_eh() {
   const int N = 100;
-  float a[N], b[N], c[N];
+  float a[N], b[N], c[N]; // expected-note {{declared here}}
 #pragma omp parallel
 #pragma omp taskloop
   for (int i = 0; i < 10; i++) {
@@ -729,6 +729,13 @@
   void g() { throw 0; }
 };
   }
+// expected-error@+5 {{variable length arrays are not supported in OpenMP tasking regions with 'untied' clause}}
+// expected-note@+4 {{read of non-constexpr variable 'c' is not allowed in a constant expression}}
+#pragma omp taskloop untied
+  {
+  for (int i = 0; i < 10; ++i)
+int array[(int)c[0]];
+  }
 }
 
 void test_loop_firstprivate_lastprivate() {
Index: clang/test/OpenMP/task_messages.cpp
===
--- clang/test/OpenMP/task_messages.cpp
+++ clang/test/OpenMP/task_messages.cpp
@@ -173,7 +173,7 @@
   int &b = a;
   S sa;
   S &sb = sa;
-  int r;
+  int r; // expected-note {{declared here}}
 #pragma omp task { // expected-warning {{extra tokens at the end of '#pragma omp task' are ignored}}
   foo();
 #pragma omp task( // expected-warning {{extra tokens at the end of '#pragma omp task' are ignored}}
@@ -330,6 +330,12 @@
 // expected-error@+1 {{directive '#pragma omp task' cannot contain more than one 'mergeable' clause}}
 #pragma omp task mergeable mergeable
   ++r;
+// expected-error@+4 {{variable length arrays are not supported in OpenMP tasking regions with 'untied' clause}}
+// expected-note@+3 {{read of non-const variable 'r' is not allowed in a constant expression}}
+#pragma omp task untied
+  {
+int array[r];
+  }
   volatile omp_event_handle_t evt;
   omp_event_handle_t sevt;
   const omp_event_handle_t cevt = evt;
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2417,6 +2417,9 @@
   } else if (isSFINAEContext()) {
 VLADiag = diag::err_vla_in_sfinae;
 VLAIsError = true;
+  } else if (getLangOpts().OpenMP && isInOpenMPTaskUntiedContext()) {
+VLADiag = diag::err_openmp_vla_in_task_untied;
+VLAIsError = true;
   } else {
 VLADiag = diag::ext_vla;
 VLAIsError = false;
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -174,6 +174,7 @@
 bool HasMutipleLoops = false;
 const Decl *PossiblyLoopCounter = nullptr;
 bool NowaitRegion = false;
+bool UntiedRegion = false;
 bool CancelRegion = false;
 bool LoopStart = false;
 bool BodyComplete = false;
@@ -841,6 +842,15 @@
   return Parent->NowaitRegion;
 return false;
   }
+  /// Marks current region as untied (it has a 'untied' clause).
+  void setUntiedRegion(bool IsUntied = true) {
+getTopOfStack().UntiedRegion = IsUntied;
+  }
+  /// Return true if current region is untied.
+  bool isUntiedRegion() const {
+const SharingMapTy *Top = getTopOfStackOrNull();
+return Top ? Top->UntiedRegion : false;
+  }
   /// Marks parent region as cancel region.
   void setParentCancelRegion(bool Cancel = true) {
 if (SharingMapTy *Parent = getSecondOnStackOrNull())
@@ -2154,6 +2164,11 @@
   return DSAStack->getNestingLevel();
 }
 
+bool Sema::isInOpenMPTaskUntiedContext() const {
+  return isOpenMPTaskingDirective(DSAStack->getCurrentDirective()) &&
+ DSAStack->isUntiedRegion();
+}
+
 bool Sema::isInOpenMPTargetExecutionDirective() const {
   return (isOpenMPTargetExecutionDirective(DSAStack->getCurrentDirective()) &&
   !DSAStack->isClauseParsingMode()) ||
@@ -14513,6 +14528,7 @@
 
 OMPClause *Sema::ActOnOpenMPUntiedClause(SourceLocation StartLoc,
  SourceLocation EndLoc) {
+  DSAStack->setUntiedRegion();
   return new (Context) OMPUntiedClause(StartLoc, EndLoc);
 }
 
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -10492,6 +10492,10 @

[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D99433#2653528 , 
@everton.constantino wrote:

> @jdoerfert Which tests do you have in mind? I added one for SEMA and one for 
> CodeGen.

Tests for everything you placed in `llvm/`. Your tests are all in `clang/`.




Comment at: llvm/include/llvm/IR/MatrixBuilder.h:152
+  }
+
   /// Create a llvm.matrix.multiply call, multiplying matrixes \p LHS and \p

This code is not tested, as far as I can tell. Or is it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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


[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-03-26 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D99433#2653586 , 
@everton.constantino wrote:

> @fhahn That was my first idea however its not as simple as it looks. I tried 
> moving the adds but splats make it considerably harder to find a pattern that 
> catches this and fuses the multiplies specially with bigger matrices. My real 
> wish was to actually add a new IR instruction to handle matrices because the 
> MADD is but a simple example of other more interesting optimizations that can 
> be done, like using matrix associative properties to reduce the number of 
> calculations. I found that path too complicated however and I opted for a 
> compromise at the moment. I wish to start writing some GEMM micro-kernels 
> with this extension and this builtin was the shortest path.

Could you elaborate on the splats that make this tricky? Before the matrix 
lowering, there should be no splats: https://godbolt.org/z/r941xsc6b. I was 
thinking of detecting the multiply/add before we do the actual lowering, e.g. 
like it is already done for `{load, load} ->multiply->store` chains in 
`LowerMatrixMultiplyFused ` 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp#L1346

Before the matrix lowering, there should be no splats:   
https://godbolt.org/z/r941xsc6b

It might still be convenient to have a separate multiply-add intrinsic for 
matrixes, because then we could just replace `fadd( @matrix.multiply() , X)` 
before lowering. But I am not sure how scalable this will be (I don't think we 
want too many intrinsics), so perhaps we could keep track of bundles of 
instructions to lower together in general. But I don't think we need this for 
the initial optimization to start with.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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


[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

2021-03-26 Thread Brad Smith via Phabricator via cfe-commits
brad added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");

glaubitz wrote:
> glaubitz wrote:
> > ro wrote:
> > > glaubitz wrote:
> > > > jrtc27 wrote:
> > > > > This doesn't need changing, we can define more things than GCC to 
> > > > > keep it simple.
> > > > Well, my original intent was to match GCC to make sure we're 100% 
> > > > compatible and I would like to keep it that way.
> > > I agree with Jessica here: you're creating a complicated maze for no real 
> > > gain.  Besides, have you checked what `gcc` on the BSDs really does?  
> > > They often neglect to get their changes upstream and what's in the gcc 
> > > repo doesn't necessarily represent what they actually use.
> > Yes, I have verified that GCC behaves the exact same way as this change and 
> > I don't see any reason not to mimic the exact same behavior in clang for 
> > maximum compatibility.
> FWIW, I meant GCC on the various BSDs. I do not think it's a wise idea to 
> have clang deviate from what GCC does as only this way we can guarantee that 
> everything that compiles with GCC will compile with clang.
> Besides, have you checked what `gcc` on the BSDs really does?  They often 
> neglect to get their changes upstream and what's in the gcc repo doesn't 
> necessarily represent what they actually use.

What is upstream is what we do. There are no local patches that change behavior 
in this particular area.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98574

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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2021-03-26 Thread Ronan Keryell via Phabricator via cfe-commits
keryell added a comment.

In D73967#2653250 , @erichkeane wrote:

> 



>> It comes from an FPGA tool programmer who knows about HLS *and* modern C++, 
>> so probably a very rare specie. :-)
>> The typical FPGA programmer and tool writer is often more focused on C, so 
>> knows barely nothing about generic programming.



> Our FPGA team DOES know HLS and (most of) modern C++, they are the 
> implementers of 
> https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html.

"Uses untimed ANSI C++ as the golden design source": is this pre ISO C++98? :-)
Perhaps you should put ISO C++ with some version number there.

Kidding aside, the HLS world comes historically from the C world and thus 
solves problem in the `#pragma` and `__attribute__`. And there is some value in 
this for customers not wanting to dive into C++ and just having minimal change 
to the code besides these `#pragma`. But a the same time it is done with a lot 
of atrocities on the type system when extending this to C++...

> That said, I can see potential value (though the SFINAE to get the unsigned 
> vs signed seems easy enough), but would suggest either the WG14 paper, or to 
> suggest it to the authors of the WG14 paper and see what they say.  Feel free 
> to include me in the chain.

I am not following at all the WG14 papers. I have enough pain just running 
after the C++ papers... :-( But I might have a look on this one...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967

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


[clang] 7e0cc45 - [SystemZ][z/OS] Save strings for CC_PRINT env vars

2021-03-26 Thread Muiez Ahmed via cfe-commits

Author: Sean Perry
Date: 2021-03-26T16:38:36-04:00
New Revision: 7e0cc45ced230b4ef3a9d8eaedfbe92e75f21916

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

LOG: [SystemZ][z/OS] Save strings for CC_PRINT env vars

The contents of the string returned by getenv() is not guaranteed across calls 
to getenv(). The code to handle the CC_PRINT etc env vars calls getenv() and 
saves the results in just a char *. The string returned by getenv() needs to be 
copied and saved. Switching the type of the strings from char * to std::string 
will do this and manage the alloated memory.

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

Added: 


Modified: 
clang/include/clang/Driver/Driver.h
clang/lib/Driver/Compilation.cpp
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/tools/driver/driver.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index 54c20620910b3..469c000c952ca 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -157,16 +157,16 @@ class Driver {
   std::string HostBits, HostMachine, HostSystem, HostRelease;
 
   /// The file to log CC_PRINT_PROC_STAT_FILE output to, if enabled.
-  const char *CCPrintStatReportFilename;
+  std::string CCPrintStatReportFilename;
 
   /// The file to log CC_PRINT_OPTIONS output to, if enabled.
-  const char *CCPrintOptionsFilename;
+  std::string CCPrintOptionsFilename;
 
   /// The file to log CC_PRINT_HEADERS output to, if enabled.
-  const char *CCPrintHeadersFilename;
+  std::string CCPrintHeadersFilename;
 
   /// The file to log CC_LOG_DIAGNOSTICS output to, if enabled.
-  const char *CCLogDiagnosticsFilename;
+  std::string CCLogDiagnosticsFilename;
 
   /// A list of inputs and their types for the given arguments.
   typedef SmallVector, 16>

diff  --git a/clang/lib/Driver/Compilation.cpp 
b/clang/lib/Driver/Compilation.cpp
index d330557390804..f28c23a59940d 100644
--- a/clang/lib/Driver/Compilation.cpp
+++ b/clang/lib/Driver/Compilation.cpp
@@ -170,10 +170,11 @@ int Compilation::ExecuteCommand(const Command &C,
 
 // Follow gcc implementation of CC_PRINT_OPTIONS; we could also cache the
 // output stream.
-if (getDriver().CCPrintOptions && getDriver().CCPrintOptionsFilename) {
+if (getDriver().CCPrintOptions &&
+!getDriver().CCPrintOptionsFilename.empty()) {
   std::error_code EC;
   OwnedStream.reset(new llvm::raw_fd_ostream(
-  getDriver().CCPrintOptionsFilename, EC,
+  getDriver().CCPrintOptionsFilename.c_str(), EC,
   llvm::sys::fs::OF_Append | llvm::sys::fs::OF_Text));
   if (EC) {
 getDriver().Diag(diag::err_drv_cc_print_options_failure)

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 0918ea455811c..171d3d5b5b88c 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -135,14 +135,13 @@ Driver::Driver(StringRef ClangExecutable, StringRef 
TargetTriple,
 : Diags(Diags), VFS(std::move(VFS)), Mode(GCCMode),
   SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone), LTOMode(LTOK_None),
   ClangExecutable(ClangExecutable), SysRoot(DEFAULT_SYSROOT),
-  DriverTitle(Title), CCPrintStatReportFilename(nullptr),
-  CCPrintOptionsFilename(nullptr), CCPrintHeadersFilename(nullptr),
-  CCLogDiagnosticsFilename(nullptr), CCCPrintBindings(false),
-  CCPrintOptions(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCPrintProcessStats(false),
-  TargetTriple(TargetTriple), CCCGenericGCCName(""), Saver(Alloc),
-  CheckInputsExist(true), GenReproducer(false),
-  SuppressMissingInputWarning(false) {
+  DriverTitle(Title), CCPrintStatReportFilename(), 
CCPrintOptionsFilename(),
+  CCPrintHeadersFilename(), CCLogDiagnosticsFilename(),
+  CCCPrintBindings(false), CCPrintOptions(false), CCPrintHeaders(false),
+  CCLogDiagnostics(false), CCGenDiagnostics(false),
+  CCPrintProcessStats(false), TargetTriple(TargetTriple),
+  CCCGenericGCCName(""), Saver(Alloc), CheckInputsExist(true),
+  GenReproducer(false), SuppressMissingInputWarning(false) {
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)
 this->VFS = llvm::vfs::getRealFileSystem();
@@ -4057,7 +4056,7 @@ void Driver::BuildJobs(Compilation &C) const {
   else
 LinkingOutput = getDefaultImageName();
 
-  if (!CCPrintStatReportFilename) {
+  if (CCPrintStatReportFilename.empty()) {
 using namespace llvm;
 // Human readable output.
 outs() << sys::path::filename(Cmd.getExecutable()) << ": "
@@ -4080,7 +4079,7 @@ void Driver::BuildJobs(Compilation &C) const {
 << '\n';

[PATCH] D98554: Save strings for CC_PRINT env vars

2021-03-26 Thread Muiez Ahmed via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7e0cc45ced23: [SystemZ][z/OS] Save strings for CC_PRINT env 
vars (authored by SeanP, committed by muiez).

Changed prior to commit:
  https://reviews.llvm.org/D98554?vs=332836&id=333625#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98554

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Compilation.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/tools/driver/driver.cpp

Index: clang/tools/driver/driver.cpp
===
--- clang/tools/driver/driver.cpp
+++ clang/tools/driver/driver.cpp
@@ -244,25 +244,28 @@
 }
 
 static void SetBackdoorDriverOutputsFromEnvVars(Driver &TheDriver) {
-  // Handle CC_PRINT_OPTIONS and CC_PRINT_OPTIONS_FILE.
-  TheDriver.CCPrintOptions = !!::getenv("CC_PRINT_OPTIONS");
-  if (TheDriver.CCPrintOptions)
-TheDriver.CCPrintOptionsFilename = ::getenv("CC_PRINT_OPTIONS_FILE");
-
-  // Handle CC_PRINT_HEADERS and CC_PRINT_HEADERS_FILE.
-  TheDriver.CCPrintHeaders = !!::getenv("CC_PRINT_HEADERS");
-  if (TheDriver.CCPrintHeaders)
-TheDriver.CCPrintHeadersFilename = ::getenv("CC_PRINT_HEADERS_FILE");
-
-  // Handle CC_LOG_DIAGNOSTICS and CC_LOG_DIAGNOSTICS_FILE.
-  TheDriver.CCLogDiagnostics = !!::getenv("CC_LOG_DIAGNOSTICS");
-  if (TheDriver.CCLogDiagnostics)
-TheDriver.CCLogDiagnosticsFilename = ::getenv("CC_LOG_DIAGNOSTICS_FILE");
-
-  // Handle CC_PRINT_PROC_STAT and CC_PRINT_PROC_STAT_FILE.
-  TheDriver.CCPrintProcessStats = !!::getenv("CC_PRINT_PROC_STAT");
-  if (TheDriver.CCPrintProcessStats)
-TheDriver.CCPrintStatReportFilename = ::getenv("CC_PRINT_PROC_STAT_FILE");
+  auto CheckEnvVar = [](const char *EnvOptSet, const char *EnvOptFile,
+std::string &OptFile) {
+bool OptSet = !!::getenv(EnvOptSet);
+if (OptSet) {
+  if (const char *Var = ::getenv(EnvOptFile))
+OptFile = Var;
+}
+return OptSet;
+  };
+
+  TheDriver.CCPrintOptions =
+  CheckEnvVar("CC_PRINT_OPTIONS", "CC_PRINT_OPTIONS_FILE",
+  TheDriver.CCPrintOptionsFilename);
+  TheDriver.CCPrintHeaders =
+  CheckEnvVar("CC_PRINT_HEADERS", "CC_PRINT_HEADERS_FILE",
+  TheDriver.CCPrintHeadersFilename);
+  TheDriver.CCLogDiagnostics =
+  CheckEnvVar("CC_LOG_DIAGNOSTICS", "CC_LOG_DIAGNOSTICS_FILE",
+  TheDriver.CCLogDiagnosticsFilename);
+  TheDriver.CCPrintProcessStats =
+  CheckEnvVar("CC_PRINT_PROC_STAT", "CC_PRINT_PROC_STAT_FILE",
+  TheDriver.CCPrintStatReportFilename);
 }
 
 static void FixupDiagPrefixExeName(TextDiagnosticPrinter *DiagClient,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5108,8 +5108,9 @@
 
   if (D.CCPrintHeaders && !D.CCGenDiagnostics) {
 CmdArgs.push_back("-header-include-file");
-CmdArgs.push_back(D.CCPrintHeadersFilename ? D.CCPrintHeadersFilename
-   : "-");
+CmdArgs.push_back(!D.CCPrintHeadersFilename.empty()
+  ? D.CCPrintHeadersFilename.c_str()
+  : "-");
 CmdArgs.push_back("-sys-header-deps");
   }
   Args.AddLastArg(CmdArgs, options::OPT_P);
@@ -5117,8 +5118,9 @@
 
   if (D.CCLogDiagnostics && !D.CCGenDiagnostics) {
 CmdArgs.push_back("-diagnostic-log-file");
-CmdArgs.push_back(D.CCLogDiagnosticsFilename ? D.CCLogDiagnosticsFilename
- : "-");
+CmdArgs.push_back(!D.CCLogDiagnosticsFilename.empty()
+  ? D.CCLogDiagnosticsFilename.c_str()
+  : "-");
   }
 
   // Give the gen diagnostics more chances to succeed, by avoiding intentional
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -135,14 +135,13 @@
 : Diags(Diags), VFS(std::move(VFS)), Mode(GCCMode),
   SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone), LTOMode(LTOK_None),
   ClangExecutable(ClangExecutable), SysRoot(DEFAULT_SYSROOT),
-  DriverTitle(Title), CCPrintStatReportFilename(nullptr),
-  CCPrintOptionsFilename(nullptr), CCPrintHeadersFilename(nullptr),
-  CCLogDiagnosticsFilename(nullptr), CCCPrintBindings(false),
-  CCPrintOptions(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCPrintProcessStats(false),
-  TargetTriple(TargetTriple), CCCGenericGCCName(""), Saver(Alloc),
-  CheckInputsExist(true), GenReproducer(false),
-  SuppressMissingInputWarning(false) {
+  DriverTitle(Title), CCPrintStatReportFilename(), CCPrintOptionsFilename(),
+  

[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-26 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

This touches a lot of files. I am a bit worried that it would not be easy for a 
contributor to know OF_TextWithCRLF is needed to make SystemZ happy.

> On SystemZ we need to open text files in text mode,

Why can't it be served without CRLF translation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D99407: [clang][ItaniumMangle] Check SizeExpr for DependentSizedArrayType (PR49478)

2021-03-26 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/test/AST/ast-dump-array-json.cpp:6
+
+// CHECK: "mangledName": "_ZN1A4TestE",
+// CHECK: "mangledName": "_ZN1A4TestE",

oToToT wrote:
> yaxunl wrote:
> > I am not sure if this test tests the code you change since the mangled 
> > variable name does not encode type.
> I think this test my code. Or, at least, this test will trigger a runtime 
> error in the latest clang without this patch when mangling `A::Test`.
> 
> Also, maybe I could try construct a test to mangle variable with element type 
> if needed.
> 
> WDYT?
I would like to see a test that verifies the `A_` mangling is produced.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99407

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


[PATCH] D99445: [OPENMP]Fix PR49052: Clang crashed when compiling target code with assert(0).

2021-03-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

Need to insert a basic block during generation of the target region to
avoid crash for the GPU to be able always calling a cleanup action.
This cleanup action is required for the correct emission of the target
region for the GPU.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99445

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp


Index: clang/test/OpenMP/nvptx_target_codegen.cpp
===
--- clang/test/OpenMP/nvptx_target_codegen.cpp
+++ clang/test/OpenMP/nvptx_target_codegen.cpp
@@ -394,6 +394,12 @@
   return f;
 }
 
+extern void assert(int) throw() __attribute__((__noreturn__));
+void unreachable_call() {
+#pragma omp target
+assert(0);
+}
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+static.+347}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
@@ -632,6 +638,12 @@
 // CHECK: [[RES:%.+]] = load i32, i32* [[RET]],
 // CHECK: ret i32 [[RES]]
 
+// CHECK: define {{.*}}void {{@__omp_offloading_.+unreachable_call.+l399}}()
+// CHECK: call void @{{.*}}assert{{.*}}(i32 0)
+// CHECK: unreachable
+// CHECK: call void @__kmpc_kernel_deinit(i16 1)
+// CHECK: ret void
+
 // CHECK-LABEL: define {{.*}}void 
{{@__omp_offloading_.+template.+l331}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5742,6 +5742,7 @@
 CGF.CGM.getOpenMPRuntime().adjustTargetSpecificDataForLambdas(CGF, S);
 
   CGF.EmitStmt(S.getCapturedStmt(OMPD_target)->getCapturedStmt());
+  CGF.EnsureInsertPoint();
 }
 
 void CodeGenFunction::EmitOMPTargetDeviceFunction(CodeGenModule &CGM,


Index: clang/test/OpenMP/nvptx_target_codegen.cpp
===
--- clang/test/OpenMP/nvptx_target_codegen.cpp
+++ clang/test/OpenMP/nvptx_target_codegen.cpp
@@ -394,6 +394,12 @@
   return f;
 }
 
+extern void assert(int) throw() __attribute__((__noreturn__));
+void unreachable_call() {
+#pragma omp target
+assert(0);
+}
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+static.+347}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
@@ -632,6 +638,12 @@
 // CHECK: [[RES:%.+]] = load i32, i32* [[RET]],
 // CHECK: ret i32 [[RES]]
 
+// CHECK: define {{.*}}void {{@__omp_offloading_.+unreachable_call.+l399}}()
+// CHECK: call void @{{.*}}assert{{.*}}(i32 0)
+// CHECK: unreachable
+// CHECK: call void @__kmpc_kernel_deinit(i16 1)
+// CHECK: ret void
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l331}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5742,6 +5742,7 @@
 CGF.CGM.getOpenMPRuntime().adjustTargetSpecificDataForLambdas(CGF, S);
 
   CGF.EmitStmt(S.getCapturedStmt(OMPD_target)->getCapturedStmt());
+  CGF.EnsureInsertPoint();
 }
 
 void CodeGenFunction::EmitOMPTargetDeviceFunction(CodeGenModule &CGM,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-26 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan added a comment.

In D99426#2653725 , @MaskRay wrote:

> This touches a lot of files. I am a bit worried that it would not be easy for 
> a contributor to know OF_TextWithCRLF is needed to make SystemZ happy.
>
>> On SystemZ we need to open text files in text mode,
>
> Why can't it be served without CRLF translation?

So this is a quick summary of the problem we're facing: 
On SystemZ, we can accept both OF_Text or OF_TextWithCRLF, it makes no 
difference. However, there are many text files that are marked as 
binary/OF_None to suppress CRLF translation on Windows. (e.g. patches like this 
one https://reviews.llvm.org/rGe78a7a0ecddc747129512fabf4836e22d1805f00). On 
SystemZ we need the text files to be marked as text and have made patches in 
the past to do so (e.g. https://reviews.llvm.org/D67696). These efforts are 
conflicting with each other, so Reid suggested this solution where we create a 
new flag that will set text mode and turn on CRLF translation on Windows 
platform. Then we will be able to mark all remaining text files with OF_Text 
and not turn on CRLF translation for Windows.

I agree this patch is touching a lot of files,  I can maybe do the opposite and 
create a flag called OF_TextWithoutCRLF. I'm open to any new solutions to this 
problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D97513: Add ConfigVersion.cmake files

2021-03-26 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added inline comments.
Herald added a subscriber: dcaballe.



Comment at: lld/cmake/modules/LLDConfigVersion.cmake.in:1
+set(PACKAGE_VERSION "@PACKAGE_VERSION@")
+

Did you consider using `write_basic_package_version_file` instead of adding 
these files?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97513

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


[PATCH] D97513: Add ConfigVersion.cmake files

2021-03-26 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added inline comments.



Comment at: lld/cmake/modules/LLDConfigVersion.cmake.in:1
+set(PACKAGE_VERSION "@PACKAGE_VERSION@")
+

steveire wrote:
> Did you consider using `write_basic_package_version_file` instead of adding 
> these files?
Ah, sorry, I see you did and wrote a comment about it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97513

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


[PATCH] D99445: [OPENMP]Fix PR49052: Clang crashed when compiling target code with assert(0).

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99445

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


[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-26 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D99426#2653869 , 
@abhina.sreeskantharajan wrote:

> In D99426#2653725 , @MaskRay wrote:
>
>> This touches a lot of files. I am a bit worried that it would not be easy 
>> for a contributor to know OF_TextWithCRLF is needed to make SystemZ happy.
>>
>>> On SystemZ we need to open text files in text mode,
>>
>> Why can't it be served without CRLF translation?
>
> So this is a quick summary of the problem we're facing: 
> On SystemZ, we can accept both OF_Text or OF_TextWithCRLF, it makes no 
> difference. However, there are many text files that are marked as 
> binary/OF_None to suppress CRLF translation on Windows. (e.g. patches like 
> this one 
> https://reviews.llvm.org/rGe78a7a0ecddc747129512fabf4836e22d1805f00). On 
> SystemZ we need the text files to be marked as text and have made patches in 
> the past to do so (e.g. https://reviews.llvm.org/D67696). These efforts are 
> conflicting with each other, so Reid suggested this solution where we create 
> a new flag that will set text mode and turn on CRLF translation on Windows 
> platform. Then we will be able to mark all remaining text files with OF_Text 
> and not turn on CRLF translation for Windows.
>
> I agree this patch is touching a lot of files,  I can maybe do the opposite 
> and create a flag called OF_TextWithoutCRLF. I'm open to any new solutions to 
> this problem.

Hmm. I am still confused after seeting 
rGe78a7a0ecddc747129512fabf4836e22d1805f00 
 (does it 
imply that using OF_None on Windows is fine?)
If `OF_None` is used on SystemZ, does that regress functionality?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D96853: [clang][AVR] Support variable decorator '__flash'

2021-03-26 Thread Ben Shi via Phabricator via cfe-commits
benshi001 added a comment.



> I am guessing this will only be supported by 1 target in clang? Then target 
> address spaces make sense otherwise you can also extend the language address 
> space enum. Are you also planning to add `__flashN`?
>  https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

Yes. I will add `__flashN` in another patch.


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

https://reviews.llvm.org/D96853

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


[PATCH] D99297: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a subscriber: tra.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM, @tra might have input on the cuda change but it seems reasonable and we 
can do that post commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99297

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


[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-03-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D99432#2653483 , @ABataev wrote:

> In D99432#2653474 , @jdoerfert wrote:
>
>> Can we please always do the globalization, even in the `target teams 
>> distribute parallel for` case you need it if a thread shares the address of 
>> a local variable with the team and another thread uses it.
>
> Could you give a small example so I could better understand the problem?

I didn't fine my old example, this should do though:
https://godbolt.org/z/En7To6xEW

On the host or host offload I see:
Mine: 0, Other: 42

On a GPU I see:
CUDA error: Error when synchronizing stream. stream = 0x4294db40, async 
info ptr = 0x7fffdd939838
CUDA error: an illegal memory access was encountered

> Shall we globalize the variable in SPMD mode if we pass it by reference/take 
> address in any case?

Yes. I think that is strictly speaking necessary. We should commit it together 
with the patches that "undo" globalization though.

>> There is no argument other than "doesn't escape" that Clang can make to 
>> disprove globalization is needed, IMHO.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99432

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


[PATCH] D97513: Add ConfigVersion.cmake files

2021-03-26 Thread Alex Reinking via Phabricator via cfe-commits
alexreinking updated this revision to Diff 333657.
alexreinking added a comment.

Uses write_basic_package_version_file


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

https://reviews.llvm.org/D97513

Files:
  clang/cmake/modules/CMakeLists.txt
  flang/cmake/modules/CMakeLists.txt
  lld/CMakeLists.txt
  lld/cmake/modules/CMakeLists.txt
  mlir/CMakeLists.txt
  mlir/cmake/modules/CMakeLists.txt
  polly/CMakeLists.txt
  polly/cmake/CMakeLists.txt

Index: polly/cmake/CMakeLists.txt
===
--- polly/cmake/CMakeLists.txt
+++ polly/cmake/CMakeLists.txt
@@ -67,10 +67,17 @@
 
 # PollyConfig holds the target definitions and general settings, PollyExports
 # the imported locations
+include(CMakePackageConfigHelpers)
+
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/PollyConfig.cmake.in
   ${POLLY_CONFIG_CMAKE_DIR}/PollyConfig.cmake
   @ONLY)
+write_basic_package_version_file(
+  "${POLLY_CONFIG_CMAKE_DIR}/PollyConfigVersion.cmake"
+  VERSION "${POLLY_VERSION}"
+  COMPATIBILITY SameMinorVersion
+)
 
 file(GENERATE
   OUTPUT ${POLLY_CONFIG_CMAKE_DIR}/${POLLY_EXPORTS_FILE_NAME}
@@ -120,6 +127,11 @@
   ${CMAKE_CURRENT_SOURCE_DIR}/PollyConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/PollyConfig.cmake
   @ONLY)
+write_basic_package_version_file(
+  "${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/PollyConfigVersion.cmake"
+  VERSION "${POLLY_VERSION}"
+  COMPATIBILITY SameMinorVersion
+)
 file(GENERATE OUTPUT
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${POLLY_EXPORTS_FILE_NAME}
   CONTENT "${POLLY_EXPORTS}")
@@ -128,6 +140,7 @@
   install(
 FILES
 "${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/PollyConfig.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/PollyConfigVersion.cmake"
 "${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${POLLY_EXPORTS_FILE_NAME}"
 DESTINATION "${POLLY_INSTALL_PACKAGE_DIR}")
 endif ()
Index: polly/CMakeLists.txt
===
--- polly/CMakeLists.txt
+++ polly/CMakeLists.txt
@@ -5,6 +5,7 @@
 
   # Where is LLVM installed?
   find_package(LLVM CONFIG REQUIRED)
+  set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
   set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${LLVM_CMAKE_DIR})
   include(HandleLLVMOptions)
   include(AddLLVM)
@@ -48,6 +49,14 @@
 set(POLLY_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
 set(POLLY_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
 
+# Compute the Polly version from the LLVM version.
+string(REGEX MATCH "([0-9]+)\\.([0-9]+)(\\.([0-9]+))?" POLLY_VERSION ${PACKAGE_VERSION})
+message(STATUS "Polly version: ${POLLY_VERSION}")
+
+set(POLLY_VERSION_MAJOR "${CMAKE_MATCH_1}")
+set(POLLY_VERSION_MINOR "${CMAKE_MATCH_2}")
+set(POLLY_VERSION_PATCH "${CMAKE_MATCH_4}")  # Using 4 instead of 3 skips the dot before the patch number.
+
 # Add path for custom modules
 set(CMAKE_MODULE_PATH
   ${CMAKE_MODULE_PATH}
Index: mlir/cmake/modules/CMakeLists.txt
===
--- mlir/cmake/modules/CMakeLists.txt
+++ mlir/cmake/modules/CMakeLists.txt
@@ -17,6 +17,8 @@
 get_property(MLIR_TRANSLATION_LIBS GLOBAL PROPERTY MLIR_TRANSLATION_LIBS)
 
 # Generate MlirConfig.cmake for the build tree.
+include(CMakePackageConfigHelpers)
+
 set(MLIR_CONFIG_CMAKE_DIR "${mlir_cmake_builddir}")
 set(MLIR_CONFIG_LLVM_CMAKE_DIR "${llvm_cmake_builddir}")
 set(MLIR_CONFIG_EXPORTS_FILE "\${MLIR_CMAKE_DIR}/MLIRTargets.cmake")
@@ -28,6 +30,11 @@
   ${CMAKE_CURRENT_SOURCE_DIR}/MLIRConfig.cmake.in
   ${mlir_cmake_builddir}/MLIRConfig.cmake
   @ONLY)
+write_basic_package_version_file(
+  "${mlir_cmake_builddir}/MLIRConfigVersion.cmake"
+  VERSION "${MLIR_VERSION}"
+  COMPATIBILITY SameMinorVersion
+)
 set(MLIR_CONFIG_CMAKE_DIR)
 set(MLIR_CONFIG_LLVM_CMAKE_DIR)
 set(MLIR_CONFIG_EXPORTS_FILE)
@@ -63,6 +70,11 @@
   ${CMAKE_CURRENT_SOURCE_DIR}/MLIRConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/MLIRConfig.cmake
   @ONLY)
+write_basic_package_version_file(
+  "${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/MLIRConfigVersion.cmake"
+  VERSION "${MLIR_VERSION}"
+  COMPATIBILITY SameMinorVersion
+)
 set(MLIR_CONFIG_CODE)
 set(MLIR_CONFIG_CMAKE_DIR)
 set(MLIR_CONFIG_LLVM_CMAKE_DIR)
@@ -80,6 +92,7 @@
 
   install(FILES
 ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/MLIRConfig.cmake
+${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/MLIRConfigVersion.cmake
 ${CMAKE_CURRENT_SOURCE_DIR}/AddMLIR.cmake
 DESTINATION ${MLIR_INSTALL_PACKAGE_DIR}
 COMPONENT mlir-cmake-exports)
Index: mlir/CMakeLists.txt
===
--- mlir/CMakeLists.txt
+++ mlir/CMakeLists.txt
@@ -23,6 +23,8 @@
   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY
 "${CMAKE_CURRENT_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}")
   set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/bin")
+
+  set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
 endif()
 
 set(MLIR_MAIN_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR}  )
@@ -33,6 +35,14 @@
 set(MLIR_INCLUDE_DIR ${