[PATCH] D79548: Fix false positive with warning -Wnon-c-typedef-for-linkage

2020-05-06 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

Looks good, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79548



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


[PATCH] D79548: Fix false positive with warning -Wnon-c-typedef-for-linkage

2020-05-06 Thread Richard Trieu via Phabricator via cfe-commits
rtrieu created this revision.
rtrieu added a reviewer: rsmith.
Herald added a project: clang.

Fix false positives for -Wnon-c-typedef-for-linkage

Implicit methods for structs can confuse the warning, so exclude checking the 
Decl's that are implicit.  Implicit Decl's for lambdas still need to be 
checked, so skipping all implicit Decl's won't work.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79548

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/anonymous-struct.cpp


Index: clang/test/SemaCXX/anonymous-struct.cpp
===
--- clang/test/SemaCXX/anonymous-struct.cpp
+++ clang/test/SemaCXX/anonymous-struct.cpp
@@ -133,3 +133,20 @@
 int arr[ ? 1 : 2];
   } C; // expected-note {{by this typedef}}
 }
+
+namespace ImplicitDecls {
+  struct Destructor { ~Destructor() {} };
+  typedef struct {} Empty;
+
+  typedef struct {
+Destructor x;
+  } A;
+
+  typedef struct {
+Empty E;
+  } B;
+
+  typedef struct {
+const Empty E;
+  } C;
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -4425,8 +4425,11 @@
 isa(D))
   continue;
 auto *MemberRD = dyn_cast(D);
-if (!MemberRD)
+if (!MemberRD) {
+  if (D->isImplicit())
+continue;
   return {NonCLikeKind::OtherMember, D->getSourceRange()};
+}
 
 //  -- contain a lambda-expression,
 if (MemberRD->isLambda())


Index: clang/test/SemaCXX/anonymous-struct.cpp
===
--- clang/test/SemaCXX/anonymous-struct.cpp
+++ clang/test/SemaCXX/anonymous-struct.cpp
@@ -133,3 +133,20 @@
 int arr[ ? 1 : 2];
   } C; // expected-note {{by this typedef}}
 }
+
+namespace ImplicitDecls {
+  struct Destructor { ~Destructor() {} };
+  typedef struct {} Empty;
+
+  typedef struct {
+Destructor x;
+  } A;
+
+  typedef struct {
+Empty E;
+  } B;
+
+  typedef struct {
+const Empty E;
+  } C;
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -4425,8 +4425,11 @@
 isa(D))
   continue;
 auto *MemberRD = dyn_cast(D);
-if (!MemberRD)
+if (!MemberRD) {
+  if (D->isImplicit())
+continue;
   return {NonCLikeKind::OtherMember, D->getSourceRange()};
+}
 
 //  -- contain a lambda-expression,
 if (MemberRD->isLambda())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79477: [clang-tidy] Add --use-color command line option and UseColor option to control colors in diagnostics

2020-05-06 Thread hyd-dev via Phabricator via cfe-commits
hyd-dev updated this revision to Diff 262541.
hyd-dev retitled this revision from "[clang-tidy] Add --color-diagnostics 
command line option and ColorDiagnostics option to control colors in 
diagnostics" to "[clang-tidy] Add --use-color command line option and UseColor 
option to control colors in diagnostics".
hyd-dev edited the summary of this revision.
hyd-dev added a comment.

Rename `clang-tools-extra/test/clang-tidy/infrastructure/color-diagnostics.cpp` 
to `clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp`.


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

https://reviews.llvm.org/D79477

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.h
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
  clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
@@ -76,6 +76,7 @@
   User: user1
   ExtraArgs: ['arg1', 'arg2']
   ExtraArgsBefore: ['arg-before1', 'arg-before2']
+  UseColor: false
   )");
   ASSERT_TRUE(!!Options1);
   llvm::ErrorOr Options2 = parseConfiguration(R"(
@@ -85,6 +86,7 @@
   User: user2
   ExtraArgs: ['arg3', 'arg4']
   ExtraArgsBefore: ['arg-before3', 'arg-before4']
+  UseColor: true
   )");
   ASSERT_TRUE(!!Options2);
   ClangTidyOptions Options = Options1->mergeWith(*Options2, 0);
@@ -98,6 +100,8 @@
   EXPECT_EQ("arg-before1,arg-before2,arg-before3,arg-before4",
 llvm::join(Options.ExtraArgsBefore->begin(),
Options.ExtraArgsBefore->end(), ","));
+  ASSERT_TRUE(Options.UseColor.hasValue());
+  EXPECT_TRUE(*Options.UseColor);
 }
 
 class TestCheck : public ClangTidyCheck {
Index: clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
@@ -0,0 +1,28 @@
+// RUN: clang-tidy -dump-config | FileCheck %s
+// RUN: clang-tidy -dump-config -use-color | FileCheck -check-prefix=CHECK-CONFIG-COLOR %s
+// RUN: clang-tidy -dump-config -use-color=false | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
+// RUN: clang-tidy -config='UseColor: true' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-COLOR %s
+// RUN: clang-tidy -config='UseColor: false' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
+// RUN: clang-tidy -help | FileCheck -check-prefix=CHECK-OPT-PRESENT %s
+
+// REQUIRES: ansi-escape-sequences
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color=false %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color %s | FileCheck -check-prefix=CHECK-COLOR %s
+
+// CHECK-NOT: UseColor
+// CHECK-CONFIG-NO-COLOR: UseColor: false
+// CHECK-CONFIG-COLOR: UseColor: true
+// CHECK-OPT-PRESENT: --use-color
+
+class Base {
+public:
+  virtual ~Base() = 0;
+};
+
+class Delivered : public Base {
+public:
+  virtual ~Delivered() = default;
+  // CHECK-NO-COLOR: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-COLOR: {{.\[0;1;35m}}warning: {{.\[0m}}{{.\[1m}}prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+};
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -229,6 +229,13 @@
cl::value_desc("filename"),
cl::cat(ClangTidyCategory));
 
+static cl::opt UseColor("use-color", cl::desc(R"(
+Use colors in diagnostics. If not set, colors
+will be used if the terminal connected to
+standard output supports colors.
+)"),
+  cl::init(false), cl::cat(ClangTidyCategory));
+
 namespace clang {
 namespace tidy {
 
@@ -291,6 +298,8 @@
 OverrideOptions.SystemHeaders = SystemHeaders;
   if (FormatStyle.getNumOccurrences() > 0)
 OverrideOptions.FormatStyle = FormatStyle;
+  if (UseColor.getNumOccurrences() > 0)
+OverrideOptions.UseColor = UseColor;
 
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
Index: clang-tools-extra/clang-tidy/ClangTidyOptions.h
===
--- 

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-05-06 Thread Aaron Smith via Phabricator via cfe-commits
asmith added a comment.

really happy for native bfloat support!




Comment at: clang/include/clang/AST/ASTContext.h:965
   CanQualType HalfTy; // [OpenCL 6.1.1.1], ARM NEON
+  CanQualType BFloat16Ty; // ARM NEON
   CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3

Maybe the comment is unnecessary. I can imagine other targets besides ARM NEON 
using BFloat



Comment at: clang/include/clang/AST/Type.h:1982
   bool isFloat16Type() const;  // C11 extension ISO/IEC TS 18661
+  bool isBFloat16Type() const; // ARM BFloat
   bool isFloat128Type() const;

don't think this comment adds anything




Comment at: clang/lib/AST/ASTContext.cpp:5907
   case BuiltinType::Float128:   return Float128Rank;
+  case BuiltinType::BFloat16: return BFloat16Rank;
   }

extra spaces



Comment at: clang/lib/AST/ItaniumMangle.cpp:3186
 case BuiltinType::Half:  EltName = "float16_t";break;
+case BuiltinType::BFloat16:  EltName = "bfloat16x1_t";break;
 default:

Add a space before break and on the line above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D79477: [clang-tidy] Add --color-diagnostics command line option and ColorDiagnostics option to control colors in diagnostics

2020-05-06 Thread hyd-dev via Phabricator via cfe-commits
hyd-dev updated this revision to Diff 262537.
hyd-dev added a comment.

Rename `--color-diagnostics` and `ColorDiagnostics` to `--use-color` and 
`UseColor`.  Also, improve the comment of `UseColor` option and the help text 
of `--use-color`, and add `cl::init(false)` to `cl::opt UseColor`.


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

https://reviews.llvm.org/D79477

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.h
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/color-diagnostics.cpp
  clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
@@ -76,6 +76,7 @@
   User: user1
   ExtraArgs: ['arg1', 'arg2']
   ExtraArgsBefore: ['arg-before1', 'arg-before2']
+  UseColor: false
   )");
   ASSERT_TRUE(!!Options1);
   llvm::ErrorOr Options2 = parseConfiguration(R"(
@@ -85,6 +86,7 @@
   User: user2
   ExtraArgs: ['arg3', 'arg4']
   ExtraArgsBefore: ['arg-before3', 'arg-before4']
+  UseColor: true
   )");
   ASSERT_TRUE(!!Options2);
   ClangTidyOptions Options = Options1->mergeWith(*Options2, 0);
@@ -98,6 +100,8 @@
   EXPECT_EQ("arg-before1,arg-before2,arg-before3,arg-before4",
 llvm::join(Options.ExtraArgsBefore->begin(),
Options.ExtraArgsBefore->end(), ","));
+  ASSERT_TRUE(Options.UseColor.hasValue());
+  EXPECT_TRUE(*Options.UseColor);
 }
 
 class TestCheck : public ClangTidyCheck {
Index: clang-tools-extra/test/clang-tidy/infrastructure/color-diagnostics.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/color-diagnostics.cpp
@@ -0,0 +1,28 @@
+// RUN: clang-tidy -dump-config | FileCheck %s
+// RUN: clang-tidy -dump-config -use-color | FileCheck -check-prefix=CHECK-CONFIG-COLOR %s
+// RUN: clang-tidy -dump-config -use-color=false | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
+// RUN: clang-tidy -config='UseColor: true' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-COLOR %s
+// RUN: clang-tidy -config='UseColor: false' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
+// RUN: clang-tidy -help | FileCheck -check-prefix=CHECK-OPT-PRESENT %s
+
+// REQUIRES: ansi-escape-sequences
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color=false %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color %s | FileCheck -check-prefix=CHECK-COLOR %s
+
+// CHECK-NOT: UseColor
+// CHECK-CONFIG-NO-COLOR: UseColor: false
+// CHECK-CONFIG-COLOR: UseColor: true
+// CHECK-OPT-PRESENT: --use-color
+
+class Base {
+public:
+  virtual ~Base() = 0;
+};
+
+class Delivered : public Base {
+public:
+  virtual ~Delivered() = default;
+  // CHECK-NO-COLOR: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-COLOR: {{.\[0;1;35m}}warning: {{.\[0m}}{{.\[1m}}prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+};
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -229,6 +229,13 @@
cl::value_desc("filename"),
cl::cat(ClangTidyCategory));
 
+static cl::opt UseColor("use-color", cl::desc(R"(
+Use colors in diagnostics. If not set, colors
+will be used if the terminal connected to
+standard output supports colors.
+)"),
+  cl::init(false), cl::cat(ClangTidyCategory));
+
 namespace clang {
 namespace tidy {
 
@@ -291,6 +298,8 @@
 OverrideOptions.SystemHeaders = SystemHeaders;
   if (FormatStyle.getNumOccurrences() > 0)
 OverrideOptions.FormatStyle = FormatStyle;
+  if (UseColor.getNumOccurrences() > 0)
+OverrideOptions.UseColor = UseColor;
 
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
Index: clang-tools-extra/clang-tidy/ClangTidyOptions.h
===
--- clang-tools-extra/clang-tidy/ClangTidyOptions.h
+++ clang-tools-extra/clang-tidy/ClangTidyOptions.h
@@ -126,6 +126,9 @@
   /// apply this config file on top of the parent one. If false or missing,
   /// only this configuration file will be used.
   

[PATCH] D62368: Add vendor identity check for Hygon Dhyana processor in Scudo

2020-05-06 Thread Jinke Fan via Phabricator via cfe-commits
fanjinke updated this revision to Diff 262529.
fanjinke retitled this revision from "Add support for Hygon Dhyana processor" 
to "Add vendor identity check for Hygon Dhyana processor in Scudo".
fanjinke edited the summary of this revision.
fanjinke added a comment.

Changelog:
v3:
Remove the changes in cpuid.h that have already been committed in [1].

[1]: https://reviews.llvm.org/D78874


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62368

Files:
  compiler-rt/lib/scudo/scudo_utils.cpp
  compiler-rt/lib/scudo/standalone/checksum.cpp


Index: compiler-rt/lib/scudo/standalone/checksum.cpp
===
--- compiler-rt/lib/scudo/standalone/checksum.cpp
+++ compiler-rt/lib/scudo/standalone/checksum.cpp
@@ -31,6 +31,13 @@
 #define bit_SSE4_2 bit_SSE42 // clang and gcc have different defines.
 #endif
 
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */
+#define signature_HYGON_ebx 0x6f677948
+#define signature_HYGON_edx 0x6e65476e
+#define signature_HYGON_ecx 0x656e6975
+#endif
+
 bool hasHardwareCRC32() {
   u32 Eax, Ebx = 0, Ecx = 0, Edx = 0;
   __get_cpuid(0, , , , );
@@ -39,7 +46,10 @@
(Ecx == signature_INTEL_ecx);
   const bool IsAMD = (Ebx == signature_AMD_ebx) && (Edx == signature_AMD_edx) 
&&
  (Ecx == signature_AMD_ecx);
-  if (!IsIntel && !IsAMD)
+  const bool IsHygon = (Ebx == signature_HYGON_ebx) &&
+   (Edx == signature_HYGON_edx) &&
+   (Ecx == signature_HYGON_ecx);
+  if (!IsIntel && !IsAMD && !IsHygon)
 return false;
   __get_cpuid(1, , , , );
   return !!(Ecx & bit_SSE4_2);
Index: compiler-rt/lib/scudo/scudo_utils.cpp
===
--- compiler-rt/lib/scudo/scudo_utils.cpp
+++ compiler-rt/lib/scudo/scudo_utils.cpp
@@ -62,6 +62,14 @@
 # ifndef bit_SSE4_2
 #  define bit_SSE4_2 bit_SSE42  // clang and gcc have different defines.
 # endif
+
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */
+#define signature_HYGON_ebx 0x6f677948
+#define signature_HYGON_edx 0x6e65476e
+#define signature_HYGON_ecx 0x656e6975
+#endif
+
 bool hasHardwareCRC32() {
   u32 Eax, Ebx, Ecx, Edx;
   __get_cpuid(0, , , , );
@@ -71,7 +79,10 @@
   const bool IsAMD = (Ebx == signature_AMD_ebx) &&
  (Edx == signature_AMD_edx) &&
  (Ecx == signature_AMD_ecx);
-  if (!IsIntel && !IsAMD)
+  const bool IsHygon = (Ebx == signature_HYGON_ebx) &&
+   (Edx == signature_HYGON_edx) &&
+   (Ecx == signature_HYGON_ecx);
+  if (!IsIntel && !IsAMD && !IsHygon)
 return false;
   __get_cpuid(1, , , , );
   return !!(Ecx & bit_SSE4_2);


Index: compiler-rt/lib/scudo/standalone/checksum.cpp
===
--- compiler-rt/lib/scudo/standalone/checksum.cpp
+++ compiler-rt/lib/scudo/standalone/checksum.cpp
@@ -31,6 +31,13 @@
 #define bit_SSE4_2 bit_SSE42 // clang and gcc have different defines.
 #endif
 
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */
+#define signature_HYGON_ebx 0x6f677948
+#define signature_HYGON_edx 0x6e65476e
+#define signature_HYGON_ecx 0x656e6975
+#endif
+
 bool hasHardwareCRC32() {
   u32 Eax, Ebx = 0, Ecx = 0, Edx = 0;
   __get_cpuid(0, , , , );
@@ -39,7 +46,10 @@
(Ecx == signature_INTEL_ecx);
   const bool IsAMD = (Ebx == signature_AMD_ebx) && (Edx == signature_AMD_edx) &&
  (Ecx == signature_AMD_ecx);
-  if (!IsIntel && !IsAMD)
+  const bool IsHygon = (Ebx == signature_HYGON_ebx) &&
+   (Edx == signature_HYGON_edx) &&
+   (Ecx == signature_HYGON_ecx);
+  if (!IsIntel && !IsAMD && !IsHygon)
 return false;
   __get_cpuid(1, , , , );
   return !!(Ecx & bit_SSE4_2);
Index: compiler-rt/lib/scudo/scudo_utils.cpp
===
--- compiler-rt/lib/scudo/scudo_utils.cpp
+++ compiler-rt/lib/scudo/scudo_utils.cpp
@@ -62,6 +62,14 @@
 # ifndef bit_SSE4_2
 #  define bit_SSE4_2 bit_SSE42  // clang and gcc have different defines.
 # endif
+
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */
+#define signature_HYGON_ebx 0x6f677948
+#define signature_HYGON_edx 0x6e65476e
+#define signature_HYGON_ecx 0x656e6975
+#endif
+
 bool hasHardwareCRC32() {
   u32 Eax, Ebx, Ecx, Edx;
   __get_cpuid(0, , , , );
@@ -71,7 +79,10 @@
   const bool IsAMD = (Ebx == signature_AMD_ebx) &&
  (Edx == signature_AMD_edx) &&
  (Ecx == signature_AMD_ecx);
-  if (!IsIntel && !IsAMD)
+  const bool IsHygon = (Ebx == signature_HYGON_ebx) &&
+   (Edx == signature_HYGON_edx) &&
+

[PATCH] D79059: Fix and re-submit D78534 - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-06 Thread Shoaib Meenai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0c9230dad169: Reland [libclang] Install both libclang.a and 
libclang.so when… (authored by zhuhan0, committed by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D79059?vs=262506=262530#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79059

Files:
  clang/cmake/modules/AddClang.cmake


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -45,7 +45,7 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED;INSTALL_WITH_TOOLCHAIN"
+"SHARED;STATIC;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -81,7 +81,10 @@
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+
+  if(ARG_SHARED AND ARG_STATIC)
+set(LIBTYPE SHARED STATIC)
+  elseif(ARG_SHARED)
 set(LIBTYPE SHARED)
   else()
 # llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
@@ -99,38 +102,45 @@
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
-  if(TARGET ${name})
-target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
-
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
-  set(export_to_clangtargets)
-  if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-set(export_to_clangtargets EXPORT ClangTargets)
-set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
-  endif()
+  set(libs ${name})
+  if(ARG_SHARED AND ARG_STATIC)
+list(APPEND libs ${name}_static)
+  endif()
 
-  install(TARGETS ${name}
-COMPONENT ${name}
-${export_to_clangtargets}
-LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-RUNTIME DESTINATION bin)
-
-  if (NOT LLVM_ENABLE_IDE)
-add_llvm_install_targets(install-${name}
- DEPENDS ${name}
- COMPONENT ${name})
+  foreach(lib ${libs})
+if(TARGET ${lib})
+  target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
+
+  if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
+set(export_to_clangtargets)
+if(${lib} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+"clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+NOT LLVM_DISTRIBUTION_COMPONENTS)
+  set(export_to_clangtargets EXPORT ClangTargets)
+  set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
+endif()
+
+install(TARGETS ${lib}
+  COMPONENT ${lib}
+  ${export_to_clangtargets}
+  LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION bin)
+
+if (NOT LLVM_ENABLE_IDE)
+  add_llvm_install_targets(install-${lib}
+   DEPENDS ${lib}
+   COMPONENT ${lib})
+endif()
+
+set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${lib})
   endif()
-
-  set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${name})
+  set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${lib})
+else()
+  # Add empty "phony" target
+  add_custom_target(${lib})
 endif()
-set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name})
-  else()
-# Add empty "phony" target
-add_custom_target(${name})
-  endif()
+  endforeach()
 
   set_target_properties(${name} PROPERTIES FOLDER "Clang libraries")
   set_clang_windows_version_resource_properties(${name})


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -45,7 +45,7 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED;INSTALL_WITH_TOOLCHAIN"
+"SHARED;STATIC;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -81,7 +81,10 @@
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+
+  if(ARG_SHARED AND ARG_STATIC)
+set(LIBTYPE SHARED STATIC)
+  elseif(ARG_SHARED)
 set(LIBTYPE SHARED)
   else()
 # llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
@@ -99,38 +102,45 @@
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
-  if(TARGET ${name})
-target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
-
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
-  set(export_to_clangtargets)
-  

[PATCH] D79059: Fix and re-submit D78534 - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-06 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

Committed. Please let me know of any buildbot failure emails you receive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79059



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


[clang] 0c9230d - Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-06 Thread Shoaib Meenai via cfe-commits

Author: Han Zhu
Date: 2020-05-06T19:33:58-07:00
New Revision: 0c9230dad1692bc3d8f1ce2dddae413a115f2532

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

LOG: Reland [libclang] Install both libclang.a and libclang.so when 
LIBCLANG_BUILD_STATIC=ON

f8990feb125a enabled installing PIC version of both libclang.a and
libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC
build when LLVM_ENABLE_PIC=OFF with the following error:

```
CMake Error at
/b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123
(target_compile_definitions):
target_compile_definitions called with non-compilable target type
```

This is because as the code loops through ${name} and ${name}_static, it
introduced a side effect, which is adding an empty libclang_static to
targets. Later target_compile_definitions is called on libclang_static.
That function requires that target must have been created by a command
such as add_executable() or add_library(), so it crashed.

The solution is to not naively loop through both libclang and
libclang_static, but only the ones that are actually added by
llvm_add_library(). Here's the library build type to library target name
mapping:

| SHARED only | libclang |
| STATIC only | libclang |
| SHARED and STATIC | libclang and libclang_static |

So only when SHARED and STATIC are both set should we loop through two
targets. Explicitly parse the STATIC argument and set the list
accordingly.

Reviewed By: smeenai

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

Added: 


Modified: 
clang/cmake/modules/AddClang.cmake

Removed: 




diff  --git a/clang/cmake/modules/AddClang.cmake 
b/clang/cmake/modules/AddClang.cmake
index c1bb386de6f7..704278a0e93b 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -45,7 +45,7 @@ endmacro()
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED;INSTALL_WITH_TOOLCHAIN"
+"SHARED;STATIC;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -81,7 +81,10 @@ macro(add_clang_library name)
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+
+  if(ARG_SHARED AND ARG_STATIC)
+set(LIBTYPE SHARED STATIC)
+  elseif(ARG_SHARED)
 set(LIBTYPE SHARED)
   else()
 # llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
@@ -99,38 +102,45 @@ macro(add_clang_library name)
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
-  if(TARGET ${name})
-target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
-
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
-  set(export_to_clangtargets)
-  if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-set(export_to_clangtargets EXPORT ClangTargets)
-set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
-  endif()
+  set(libs ${name})
+  if(ARG_SHARED AND ARG_STATIC)
+list(APPEND libs ${name}_static)
+  endif()
 
-  install(TARGETS ${name}
-COMPONENT ${name}
-${export_to_clangtargets}
-LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-RUNTIME DESTINATION bin)
-
-  if (NOT LLVM_ENABLE_IDE)
-add_llvm_install_targets(install-${name}
- DEPENDS ${name}
- COMPONENT ${name})
+  foreach(lib ${libs})
+if(TARGET ${lib})
+  target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
+
+  if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
+set(export_to_clangtargets)
+if(${lib} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+"clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+NOT LLVM_DISTRIBUTION_COMPONENTS)
+  set(export_to_clangtargets EXPORT ClangTargets)
+  set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
+endif()
+
+install(TARGETS ${lib}
+  COMPONENT ${lib}
+  ${export_to_clangtargets}
+  LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION bin)
+
+if (NOT LLVM_ENABLE_IDE)
+  add_llvm_install_targets(install-${lib}
+   DEPENDS ${lib}
+   COMPONENT ${lib})
+endif()
+
+set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${lib})
   endif()
-
-  set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${name})
+  set_property(GLOBAL APPEND PROPERTY 

[PATCH] D79059: Fix and re-submit D78534 - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-06 Thread Han Zhu via Phabricator via cfe-commits
zhuhan0 added a comment.

@smeenai Yes please. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79059



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


[PATCH] D79531: Make -Wnonportable-include-path ignore drive case on Windows.

2020-05-06 Thread Nico Weber via Phabricator via cfe-commits
thakis marked an inline comment as done.
thakis added inline comments.



Comment at: clang/lib/Lex/PPDirectives.cpp:2118
+// given drive letter case as correct for the purpose of this warning.
+SmallString<128> FixedDriveRealPath;
+if (llvm::sys::path::is_absolute(Name) &&

rnk wrote:
> It seems like trySimplifyPath could check if it is checking the case of the 
> first component on Windows, and that would hide the complexity from the main 
> Preprocessor::HandleHeaderIncludeOrImport implementation. It also saves a 
> string copy for every include.
Not easily, since that walks the path backwards. Includes are almost never 
absolute, so this also almost never does a string copy and it's imho a bit 
simpler this way.

I agree pulling out the code for this warning into its own function is a good 
idea though.


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

https://reviews.llvm.org/D79531



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


[PATCH] D79504: [Clang] Wrong return type of atomic_is_lock_free

2020-05-06 Thread kamlesh kumar via Phabricator via cfe-commits
kamleshbhalui updated this revision to Diff 262518.
kamleshbhalui added a comment.

Addressed @rsmith concerns.


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

https://reviews.llvm.org/D79504

Files:
  clang/include/clang/Basic/Builtins.def
  clang/test/CodeGen/atomic-ops.c
  clang/test/CodeGen/big-atomic-ops.c


Index: clang/test/CodeGen/big-atomic-ops.c
===
--- clang/test/CodeGen/big-atomic-ops.c
+++ clang/test/CodeGen/big-atomic-ops.c
@@ -198,20 +198,20 @@
 int lock_free(struct Incomplete *incomplete) {
   // CHECK: @lock_free
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 3, i8* null)
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 3, i8* null)
   __c11_atomic_is_lock_free(3);
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 16, i8* {{.*}}@sixteen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 16, i8* 
{{.*}}@sixteen{{.*}})
   __atomic_is_lock_free(16, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 17, i8* {{.*}}@seventeen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 17, i8* 
{{.*}}@seventeen{{.*}})
   __atomic_is_lock_free(17, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, incomplete);
 
   char cs[20];
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, cs+1);
 
   // CHECK-NOT: call
Index: clang/test/CodeGen/atomic-ops.c
===
--- clang/test/CodeGen/atomic-ops.c
+++ clang/test/CodeGen/atomic-ops.c
@@ -343,20 +343,20 @@
 int lock_free(struct Incomplete *incomplete) {
   // CHECK-LABEL: @lock_free
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 3, i8* null)
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 3, i8* null)
   __c11_atomic_is_lock_free(3);
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 16, i8* {{.*}}@sixteen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 16, i8* 
{{.*}}@sixteen{{.*}})
   __atomic_is_lock_free(16, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 17, i8* {{.*}}@seventeen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 17, i8* 
{{.*}}@seventeen{{.*}})
   __atomic_is_lock_free(17, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 4, {{.*}})
   __atomic_is_lock_free(4, incomplete);
 
   char cs[20];
-  // CHECK: call i32 @__atomic_is_lock_free(i32 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 4, {{.*}})
   __atomic_is_lock_free(4, cs+1);
 
   // CHECK-NOT: call
Index: clang/include/clang/Basic/Builtins.def
===
--- clang/include/clang/Basic/Builtins.def
+++ clang/include/clang/Basic/Builtins.def
@@ -724,7 +724,7 @@
 ATOMIC_BUILTIN(__c11_atomic_fetch_min, "v.", "t")
 BUILTIN(__c11_atomic_thread_fence, "vi", "n")
 BUILTIN(__c11_atomic_signal_fence, "vi", "n")
-BUILTIN(__c11_atomic_is_lock_free, "iz", "n")
+BUILTIN(__c11_atomic_is_lock_free, "bz", "n")
 
 // GNU atomic builtins.
 ATOMIC_BUILTIN(__atomic_load, "v.", "t")
@@ -753,8 +753,8 @@
 BUILTIN(__atomic_clear, "vvD*i", "n")
 BUILTIN(__atomic_thread_fence, "vi", "n")
 BUILTIN(__atomic_signal_fence, "vi", "n")
-BUILTIN(__atomic_always_lock_free, "izvCD*", "n")
-BUILTIN(__atomic_is_lock_free, "izvCD*", "n")
+BUILTIN(__atomic_always_lock_free, "bzvCD*", "n")
+BUILTIN(__atomic_is_lock_free, "bzvCD*", "n")
 
 // OpenCL 2.0 atomic builtins.
 ATOMIC_BUILTIN(__opencl_atomic_init, "v.", "t")


Index: clang/test/CodeGen/big-atomic-ops.c
===
--- clang/test/CodeGen/big-atomic-ops.c
+++ clang/test/CodeGen/big-atomic-ops.c
@@ -198,20 +198,20 @@
 int lock_free(struct Incomplete *incomplete) {
   // CHECK: @lock_free
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 3, i8* null)
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 3, i8* null)
   __c11_atomic_is_lock_free(3);
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 16, i8* {{.*}}@sixteen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 16, i8* {{.*}}@sixteen{{.*}})
   __atomic_is_lock_free(16, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 17, i8* {{.*}}@seventeen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 17, i8* {{.*}}@seventeen{{.*}})
   __atomic_is_lock_free(17, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, incomplete);
 
   char cs[20];
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, cs+1);
 
   // CHECK-NOT: call
Index: 

[PATCH] D79534: [clang][WebAssembly] Only expose wait and notify builtins with atomics

2020-05-06 Thread Sam Clegg via Phabricator via cfe-commits
sbc100 accepted this revision.
sbc100 added a comment.
This revision is now accepted and ready to land.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79534



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


[PATCH] D74262: [clang-offload-bundler] Enable handling of partially-linked fat objects

2020-05-06 Thread George Rokos via Phabricator via cfe-commits
grokos abandoned this revision.
grokos added a comment.

The partial linking scheme has been found to not work correctly in all cases 
(it fails when we have libraries with device code only). A new patch will be 
uploaded which will be based on archive extraction.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74262



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


[PATCH] D79274: Fix template class debug info for Visual Studio visualizers

2020-05-06 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp:10
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null 
-fms-compatibility | \
+// RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: 
"\([^"]*\)".*/"\1"/' | \

Why choose fms-compatibility? Does it have a side effect of raising the default 
standard version?



Comment at: clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp:12
+// RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: 
"\([^"]*\)".*/"\1"/' | \
+// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=MSCOMPAT
 

Any reason not to reuse `--check-prefix=UNQUAL`? This should be the same as the 
first RUN line, with a different standard.


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

https://reviews.llvm.org/D79274



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


[PATCH] D79531: Make -Wnonportable-include-path ignore drive case on Windows.

2020-05-06 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/lib/Lex/PPDirectives.cpp:2118
+// given drive letter case as correct for the purpose of this warning.
+SmallString<128> FixedDriveRealPath;
+if (llvm::sys::path::is_absolute(Name) &&

It seems like trySimplifyPath could check if it is checking the case of the 
first component on Windows, and that would hide the complexity from the main 
Preprocessor::HandleHeaderIncludeOrImport implementation. It also saves a 
string copy for every include.


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

https://reviews.llvm.org/D79531



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


[PATCH] D79534: [clang][WebAssembly] Only expose wait and notify builtins with atomics

2020-05-06 Thread Thomas Lively via Phabricator via cfe-commits
tlively created this revision.
tlively added reviewers: aheejin, sunfish.
Herald added subscribers: cfe-commits, jfb, jgravelle-google, sbc100, dschuff.
Herald added a project: clang.

Since the underlying wait and notify instructions are only available
when the atomics feature is enabled, it only makes sense to expose
their builtin functions when atomics are enabled.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79534

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/test/CodeGen/builtins-wasm.c


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature 
+unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature 
+exception-handling -target-feature +bulk-memory -flax-vector-conversions=none 
-O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
-// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature 
+exception-handling -target-feature +bulk-memory -flax-vector-conversions=none 
-O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
-// RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | 
FileCheck %s -check-prefixes MISSING-SIMD
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature 
+unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature 
+exception-handling -target-feature +bulk-memory -target-feature +atomics 
-flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s 
-check-prefixes WEBASSEMBLY,WEBASSEMBLY32
+// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature 
+exception-handling -target-feature +bulk-memory -target-feature +atomics 
-flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s 
-check-prefixes WEBASSEMBLY,WEBASSEMBLY64
+// RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
 
 // SIMD convenience types
 typedef char i8x16 __attribute((vector_size(16)));
Index: clang/include/clang/Basic/BuiltinsWebAssembly.def
===
--- clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -45,9 +45,9 @@
 TARGET_BUILTIN(__builtin_wasm_rethrow_in_catch, "v", "r", "exception-handling")
 
 // Atomic wait and notify.
-BUILTIN(__builtin_wasm_atomic_wait_i32, "ii*iLLi", "n")
-BUILTIN(__builtin_wasm_atomic_wait_i64, "iLLi*LLiLLi", "n")
-BUILTIN(__builtin_wasm_atomic_notify, "Uii*Ui", "n")
+TARGET_BUILTIN(__builtin_wasm_atomic_wait_i32, "ii*iLLi", "n", "atomics")
+TARGET_BUILTIN(__builtin_wasm_atomic_wait_i64, "iLLi*LLiLLi", "n", "atomics")
+TARGET_BUILTIN(__builtin_wasm_atomic_notify, "Uii*Ui", "n", "atomics")
 
 // Trapping fp-to-int conversions
 BUILTIN(__builtin_wasm_trunc_s_i32_f32, "if", "nc")


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature +unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
-// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature +unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
-// RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature +unimplemented-simd128 -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
+// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature +unimplemented-simd128 

[PATCH] D79059: Fix and re-submit D78534 - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-06 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

Do you need me to commit this for you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79059



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


[PATCH] D79059: Fix and re-submit D78534 - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-06 Thread Han Zhu via Phabricator via cfe-commits
zhuhan0 updated this revision to Diff 262506.
zhuhan0 added a comment.

Address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79059

Files:
  clang/cmake/modules/AddClang.cmake

Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -45,7 +45,7 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED;INSTALL_WITH_TOOLCHAIN"
+"SHARED;STATIC;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -81,7 +81,10 @@
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+
+  if(ARG_SHARED AND ARG_STATIC)
+set(LIBTYPE SHARED STATIC)
+  elseif(ARG_SHARED)
 set(LIBTYPE SHARED)
   else()
 # llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
@@ -99,39 +102,46 @@
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
-  if(TARGET ${name})
-target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
-
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
-  set(export_to_clangtargets)
-  if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-set(export_to_clangtargets EXPORT ClangTargets)
-set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
-  endif()
-
-  install(TARGETS ${name}
-COMPONENT ${name}
-${export_to_clangtargets}
-LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-RUNTIME DESTINATION bin)
-
-  if (NOT LLVM_ENABLE_IDE)
-add_llvm_install_targets(install-${name}
- DEPENDS ${name}
- COMPONENT ${name})
-  endif()
-
-  set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${name})
-endif()
-set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name})
-  else()
-# Add empty "phony" target
-add_custom_target(${name})
+  set(libs ${name})
+  if(ARG_SHARED AND ARG_STATIC)
+list(APPEND libs ${name}_static)
   endif()
 
+  foreach(lib ${libs})
+if(TARGET ${lib})
+  target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
+
+  if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
+set(export_to_clangtargets)
+if(${lib} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+"clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+NOT LLVM_DISTRIBUTION_COMPONENTS)
+  set(export_to_clangtargets EXPORT ClangTargets)
+  set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
+endif()
+
+install(TARGETS ${lib}
+  COMPONENT ${lib}
+  ${export_to_clangtargets}
+  LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION bin)
+
+if (NOT LLVM_ENABLE_IDE)
+  add_llvm_install_targets(install-${lib}
+   DEPENDS ${lib}
+   COMPONENT ${lib})
+endif()
+
+set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${lib})
+  endif()
+  set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${lib})
+else()
+  # Add empty "phony" target
+  add_custom_target(${lib})
+endif()
+  endforeach()
+
   set_target_properties(${name} PROPERTIES FOLDER "Clang libraries")
   set_clang_windows_version_resource_properties(${name})
 endmacro(add_clang_library)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79531: Make -Wnonportable-include-path ignore drive case on Windows.

2020-05-06 Thread Nico Weber via Phabricator via cfe-commits
thakis created this revision.
thakis added a reviewer: hans.
Herald added subscribers: llvm-commits, mgorny.
Herald added a project: LLVM.

See PR45812 for motivation.

No explicit test since I couldn't figure out how to get the
current disk drive in lower case into a form in lit where I could
mkdir it and cd to it. But the change does have test coverage in
that I can remove the case normalization in lit, and tests failed
on several bots (and for me locally if in a pwd with a lower-case
drive) without that normalization prior to this change.


https://reviews.llvm.org/D79531

Files:
  clang/lib/Lex/PPDirectives.cpp
  llvm/cmake/modules/AddLLVM.cmake


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -1499,7 +1499,6 @@
   "def path(p):\n"
   "if not p: return ''\n"
   "p = os.path.join(os.path.dirname(os.path.abspath(__file__)), p)\n"
-  "if os.name == 'nt' and os.path.isabs(p): return p[0].upper() + p[1:]\n"
   "return p\n"
   )
 
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2104,6 +2104,27 @@
 StringRef RealPathName = File->getFileEntry().tryGetRealPathName();
 SmallVector Components(llvm::sys::path::begin(Name),
   llvm::sys::path::end(Name));
+#if defined(_WIN32)
+// -Wnonportable-include-path is designed to diagnose includes using
+// case even on systems with a case-insensitive file system.
+// On Windows, RealPathName always starts with an upper-case drive
+// letter for absolute paths, but Name might start with either
+// case depending on if `cd c:\foo` or `cd C:\foo` was used.
+// ("foo" will always have on-disk case, no matter which case was
+// used in the cd command). To not emit this warning solely for
+// the drive letter, whose case is dependent on if `cd` is used
+// with upper- or lower-case drive letters, always consider the
+// given drive letter case as correct for the purpose of this warning.
+SmallString<128> FixedDriveRealPath;
+if (llvm::sys::path::is_absolute(Name) &&
+llvm::sys::path::is_absolute(RealPathName) &&
+toLowercase(Name[0]) == toLowercase(RealPathName[0]) &&
+isLowercase(Name[0]) != isLowercase(RealPathName[0])) {
+  assert(Components.size() >= 3 && "should have drive, backslash, name");
+  FixedDriveRealPath = (Name.substr(0, 1) + RealPathName.substr(1)).str();
+  RealPathName = FixedDriveRealPath;
+}
+#endif
 
 if (trySimplifyPath(Components, RealPathName)) {
   SmallString<128> Path;


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -1499,7 +1499,6 @@
   "def path(p):\n"
   "if not p: return ''\n"
   "p = os.path.join(os.path.dirname(os.path.abspath(__file__)), p)\n"
-  "if os.name == 'nt' and os.path.isabs(p): return p[0].upper() + p[1:]\n"
   "return p\n"
   )
 
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2104,6 +2104,27 @@
 StringRef RealPathName = File->getFileEntry().tryGetRealPathName();
 SmallVector Components(llvm::sys::path::begin(Name),
   llvm::sys::path::end(Name));
+#if defined(_WIN32)
+// -Wnonportable-include-path is designed to diagnose includes using
+// case even on systems with a case-insensitive file system.
+// On Windows, RealPathName always starts with an upper-case drive
+// letter for absolute paths, but Name might start with either
+// case depending on if `cd c:\foo` or `cd C:\foo` was used.
+// ("foo" will always have on-disk case, no matter which case was
+// used in the cd command). To not emit this warning solely for
+// the drive letter, whose case is dependent on if `cd` is used
+// with upper- or lower-case drive letters, always consider the
+// given drive letter case as correct for the purpose of this warning.
+SmallString<128> FixedDriveRealPath;
+if (llvm::sys::path::is_absolute(Name) &&
+llvm::sys::path::is_absolute(RealPathName) &&
+toLowercase(Name[0]) == toLowercase(RealPathName[0]) &&
+isLowercase(Name[0]) != isLowercase(RealPathName[0])) {
+  assert(Components.size() >= 3 && "should have drive, backslash, name");
+  FixedDriveRealPath = (Name.substr(0, 1) + RealPathName.substr(1)).str();
+  RealPathName = FixedDriveRealPath;
+}
+#endif
 
 if (trySimplifyPath(Components, RealPathName)) {
   SmallString<128> Path;
___
cfe-commits 

[PATCH] D79511: [ObjC] Add compatibility mode for type checking of qualified id block parameters.

2020-05-06 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added inline comments.



Comment at: clang/test/SemaObjC/block-type-safety.m:170
+genericBlockWithParam = blockWithParam;
+blockWithParam = genericBlockWithParam; // expected-error {{incompatible 
block pointer types assigning to 'void (^)(NSAllArray *)' from 'void 
(^)(id)'}}
+return 0;

jyknight wrote:
> It seems a shame to disallow this assignment in the compatibility mode, when 
> it ought to be allowed.
> 
> Perhaps it would be better to allow both directions for parameters when the 
> compatibility flag is set? (That is: the compat mode flag would only cause 
> the compiler to allow _more_ things than it otherwise should.)
> 
> 
Hmm, sounds like an interesting idea. It can make the transitioning to the new 
compiler version less disruptive. Need to think more if it has any undesirable 
consequences. So far my only objection is that it makes things less consistent. 
But given the current state of block type checking that argument isn't 
particularly compelling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79511



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


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-06 Thread Evandro Menezes via Phabricator via cfe-commits
evandro added a comment.

In D78129#2023772 , @joelkevinjones 
wrote:

>   list UnsupportedFeatures = !listconcat(SVEUnsupported.F, 
> PAUnsupported.F);
>


Agree.  Methinks that this is easier to read.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129



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


[PATCH] D79274: Fix template class debug info for Visual Studio visualizers

2020-05-06 Thread Adrian McCarthy via Phabricator via cfe-commits
amccarth updated this revision to Diff 262499.
amccarth added a comment.

Updated an existing test.  Thanks for the pointer; I had gotten myself 
completely confused about the organization of the test directories.


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

https://reviews.llvm.org/D79274

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp


Index: clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp
===
--- clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp
+++ clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp
@@ -1,11 +1,15 @@
 // RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
-// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null -std=c++98 | \
 // RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: 
"\([^"]*\)".*/"\1"/' | \
 // RUN:FileCheck %s --check-prefix=CHECK --check-prefix=UNQUAL
 // RUN: %clang_cc1 -fblocks -debug-info-kind=line-tables-only -gcodeview 
-emit-llvm %s \
-// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null -std=c++98 | \
 // RUN:grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | \
 // RUN:FileCheck %s --check-prefix=CHECK --check-prefix=QUAL
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null 
-fms-compatibility | \
+// RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: 
"\([^"]*\)".*/"\1"/' | \
+// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=MSCOMPAT
 
 void freefunc() { }
 // CHECK-DAG: "freefunc"
@@ -96,3 +100,7 @@
 ClassTemplate > f;
 // This will only show up in normal debug builds.
 // UNQUAL-DAG: "ClassTemplate >"
+
+// Without -std=c++98, the nested template ends with ">>" instead of "> >".
+// We need to ensure -fms-compatibility keeps the space.
+// MSCOMPAT-DAG: "ClassTemplate >"
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -231,9 +231,12 @@
   // If we're emitting codeview, it's important to try to match MSVC's naming 
so
   // that visualizers written for MSVC will trigger for our class names. In
   // particular, we can't have spaces between arguments of standard templates
-  // like basic_string and vector.
-  if (CGM.getCodeGenOpts().EmitCodeView)
+  // like basic_string and vector, but we must have spaces between consecutive
+  // angle brackets that close nested template argument lists.
+  if (CGM.getCodeGenOpts().EmitCodeView) {
 PP.MSVCFormatting = true;
+PP.SplitTemplateClosers = true;
+  }
 
   // Apply -fdebug-prefix-map.
   PP.Callbacks = 


Index: clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp
===
--- clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp
+++ clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp
@@ -1,11 +1,15 @@
 // RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
-// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null -std=c++98 | \
 // RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | \
 // RUN:FileCheck %s --check-prefix=CHECK --check-prefix=UNQUAL
 // RUN: %clang_cc1 -fblocks -debug-info-kind=line-tables-only -gcodeview -emit-llvm %s \
-// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null -std=c++98 | \
 // RUN:grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | \
 // RUN:FileCheck %s --check-prefix=CHECK --check-prefix=QUAL
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null -fms-compatibility | \
+// RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | \
+// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=MSCOMPAT
 
 void freefunc() { }
 // CHECK-DAG: "freefunc"
@@ -96,3 +100,7 @@
 ClassTemplate > f;
 // This will only show up in normal debug builds.
 // UNQUAL-DAG: "ClassTemplate >"
+
+// Without -std=c++98, the nested template ends with ">>" instead of "> >".
+// We need to ensure -fms-compatibility keeps the space.
+// MSCOMPAT-DAG: "ClassTemplate >"
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -231,9 +231,12 @@
   // If we're emitting codeview, it's important to try to match MSVC's naming so
   // that 

[PATCH] D79274: Fix template class debug info for Visual Studio visualizers

2020-05-06 Thread Adrian McCarthy via Phabricator via cfe-commits
amccarth added a comment.

Updated test to validate the change.


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

https://reviews.llvm.org/D79274



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-06 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter marked 2 inline comments as done.
CaseyCarter added a comment.

Format issues addressed.




Comment at: 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp:33
 struct DummyIt {
-  typedef std::forward_iterator_tag iterator_category;
-  typedef ValueType value_type;
-  typedef std::ptrdiff_t difference_type;
-  typedef ValueType* pointer;
-  typedef Reference reference;
+typedef std::forward_iterator_tag iterator_category;
+typedef ValueType value_type;

dexonsmith wrote:
> You seem to be changing from 2-space indent (the usual practice for LLVM) to 
> 4-space indent here.  I don't know if that's intentional, but if it's the 
> right thing to do please do so in a separate commit to avoid adding noise to 
> this patch.
Intentional - 4-space is the predominant indent in this file - but misguided. 
Thank you for the rundown of general formatting policy.


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

https://reviews.llvm.org/D79343



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


[PATCH] D79522: Allow -fsanitize-minimal-runtime with memtag sanitizer.

2020-05-06 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc accepted this revision.
pcc added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79522



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-06 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter updated this revision to Diff 262494.
CaseyCarter added a comment.

clang-format new/changed sections of code per policy.


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

https://reviews.llvm.org/D79343

Files:
  
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
  
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp


Index: 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
===
--- 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
+++ 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
@@ -35,6 +35,8 @@
   typedef std::ptrdiff_t difference_type;
   typedef ValueType* pointer;
   typedef Reference reference;
+
+  Reference operator*() const;
 };
 
 template 
Index: 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
===
--- 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
+++ 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
@@ -16,10 +16,20 @@
 
 #include 
 #include 
+#include 
 
 #include "test_macros.h"
 #include "test_iterators.h"
 
+#if TEST_STD_VER > 17
+template 
+void test_single_pass(It i, It x) {
+  std::move_iterator r(std::move(i));
+  r++;
+  assert(std::move(r).base() == x);
+}
+#endif
+
 template 
 void
 test(It i, It x)
@@ -33,7 +43,11 @@
 int main(int, char**)
 {
 char s[] = "123";
+#if TEST_STD_VER > 17
+test_single_pass(input_iterator(s), input_iterator(s + 1));
+#else
 test(input_iterator(s), input_iterator(s+1));
+#endif
 test(forward_iterator(s), forward_iterator(s+1));
 test(bidirectional_iterator(s), bidirectional_iterator(s+1));
 test(random_access_iterator(s), random_access_iterator(s+1));


Index: libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
===
--- libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
+++ libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
@@ -35,6 +35,8 @@
   typedef std::ptrdiff_t difference_type;
   typedef ValueType* pointer;
   typedef Reference reference;
+
+  Reference operator*() const;
 };
 
 template 
Index: libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
===
--- libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
+++ libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
@@ -16,10 +16,20 @@
 
 #include 
 #include 
+#include 
 
 #include "test_macros.h"
 #include "test_iterators.h"
 
+#if TEST_STD_VER > 17
+template 
+void test_single_pass(It i, It x) {
+  std::move_iterator r(std::move(i));
+  r++;
+  assert(std::move(r).base() == x);
+}
+#endif
+
 template 
 void
 test(It i, It x)
@@ -33,7 +43,11 @@
 int main(int, char**)
 {
 char s[] = "123";
+#if TEST_STD_VER > 17
+test_single_pass(input_iterator(s), input_iterator(s + 1));
+#else
 test(input_iterator(s), input_iterator(s+1));
+#endif
 test(forward_iterator(s), forward_iterator(s+1));
 test(bidirectional_iterator(s), bidirectional_iterator(s+1));
 test(random_access_iterator(s), random_access_iterator(s+1));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79526: [CUDA][HIP] Workaround for resolving host device function against wrong-sided function

2020-05-06 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added reviewers: tra, rjmccall.

https://reviews.llvm.org/D77954 caused regressions due to diagnostics in 
implicit
host device functions.

The implicit host device functions are often functions in system headers forced 
to be device host by pragmas.

Some of them are valid host device functions that can be emitted in both host 
and device compilation.

Some of them are valid host functions but invalid device functions. In device 
compilation they incur
diagnostics. However as long as these diagnostics are deferred and these 
functions are not emitted
this is fine.

Before D77954 , in host device callers, host 
device candidates are not favored against wrong-sided candidates,
which preserves the overloading resolution result as if the caller and the 
candidates are host functions.
This makes sure the callee does not cause other issues, e.g. type mismatch, 
const-ness issues, etc. If the
selected function is a host device function, then it is a viable callee. If the 
selected function is a host
function, then the caller is not a valid host device function, and it results 
in a diagnostic but it can be deferred.

The problem is that we have to give host device candidates equal preference 
with wrong-sided candidates. If
the users really intend to favor host device candidate against wrong-sided 
candidate, they cannot get the
expected selection.

Ideally we should be able to defer all diagnostics for functions not sure to be 
emitted. In that case we can
have correct preference. If diagnostics occur due to overloading resolution 
change, as long as the function
is not emitted, it is fine.

Unfortunately it is not a trivial work to defer all diagnostics. Even deferring 
only overloading resolution related
diagnostics is not a simple work.

For now, it seems the most feasible workaround is to treat implicit host device 
function and explicit host
device function differently. Basically for implicit host device functions, keep 
the old behavior, i.e. give
host device candidates and wrong-sided candidates equal preference. For 
explicit host device functions,
favor host device candidates against wrong-sided candidates.

The rationale is that explicit host device functions are blessed by the user to 
be valid host device functions,
that is, they should not cause diagnostics in both host and device compilation. 
If diagnostics occur, user is
able to fix them. However, there is no guarantee that implicit host device 
function can be compiled in
device compilation, therefore we need to preserve its overloading resolution in 
device compilation.


https://reviews.llvm.org/D79526

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaCUDA.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/function-overload.cu

Index: clang/test/SemaCUDA/function-overload.cu
===
--- clang/test/SemaCUDA/function-overload.cu
+++ clang/test/SemaCUDA/function-overload.cu
@@ -463,3 +463,30 @@
 void foo() {
   __test();
 }
+
+// Test resolving implicit host device candidate vs wrong-sided candidate.
+// Implicit host device caller choose implicit host device candidate and
+// wrong-sided candidate with equal preference.
+#ifdef __CUDA_ARCH__
+namespace ImplicitHostDeviceVsWrongSided {
+inline double callee(double x);
+#pragma clang force_cuda_host_device begin
+inline void callee(int x);
+inline double implicit_hd_caller() {
+  return callee(1.0);
+}
+#pragma clang force_cuda_host_device end
+}
+
+// Test resolving explicit host device candidate vs. wrong-sided candidate.
+// Explicit host device caller favors host device candidate against wrong-sided
+// candidate.
+namespace ExplicitHostDeviceVsWrongSided {
+inline double callee(double x);
+inline __host__ __device__ void callee(int x);
+inline __host__ __device__ double explicit_hd_caller() {
+  return callee(1.0);
+  // expected-error@-1 {{cannot initialize return object of type 'double' with an rvalue of type 'void'}}
+}
+}
+#endif
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -9517,11 +9517,28 @@
   // in global variable initializers once proper context is added.
   if (S.getLangOpts().CUDA && Cand1.Function && Cand2.Function) {
 if (FunctionDecl *Caller = dyn_cast(S.CurContext)) {
-  auto P1 = S.IdentifyCUDAPreference(Caller, Cand1.Function);
-  auto P2 = S.IdentifyCUDAPreference(Caller, Cand2.Function);
+  bool IsCallerImplicitHD = false;
+  bool IsCand1ImplicitHD = false;
+  bool IsCand2ImplicitHD = false;
+  S.IdentifyCUDATarget(Caller, /*IgnoreImplicitHD=*/false,
+   );
+  auto P1 =
+  S.IdentifyCUDAPreference(Caller, Cand1.Function, );
+  auto P2 =
+  S.IdentifyCUDAPreference(Caller, Cand2.Function, );
   assert(P1 != 

[PATCH] D79525: [Sema] require -fcf-runtime-abi= for __NSConstantString

2020-05-06 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers created this revision.
nickdesaulniers added a reviewer: compnerd.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

commit 81a650ee87eb ("Driver,CodeGen: introduce support for Swift CFString 
layout")
r345222

added support for implicit typedefs for __NSConstantString, used for
the runtime ABI for CoreFoundation, which can be set via -fcf-runtime-abi=.

This implicit typdef pollutes the global namespace for code that's not
targeting CoreFoundation platforms. As such, require -fcf-runtime-abi=
to be used, and disallow the creation of the typedef for C code that
does not specify.

This is most visable dumping ASTs when debugging.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79525

Files:
  clang/lib/Sema/Sema.cpp
  clang/test/AST/ast-dump-file-line-json.c
  clang/test/AST/ast-dump-record-definition-data-json.cpp
  clang/test/AST/ast-dump-records-json.cpp
  clang/test/AST/ast-dump-template-decls-json.cpp
  clang/test/CodeGen/cf-runtime-abi.c

Index: clang/test/CodeGen/cf-runtime-abi.c
===
--- clang/test/CodeGen/cf-runtime-abi.c
+++ clang/test/CodeGen/cf-runtime-abi.c
@@ -1,7 +1,3 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx -S -emit-llvm -o - %s | FileCheck %s -check-prefix CHECK-OBJC
-// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -S -emit-llvm -o - %s | FileCheck %s -check-prefix CHECK-OBJC-LLP64
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -S -emit-llvm -o - %s | FileCheck %s -check-prefix CHECK-OBJC
-
 // RUN: %clang_cc1 -triple x86_64-apple-macosx -fcf-runtime-abi=objc -S -emit-llvm -o - %s | FileCheck %s -check-prefix CHECK-OBJC
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fcf-runtime-abi=objc -S -emit-llvm -o - %s | FileCheck %s -check-prefix CHECK-OBJC-LLP64
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fcf-runtime-abi=objc -S -emit-llvm -o - %s | FileCheck %s -check-prefix CHECK-OBJC
Index: clang/test/AST/ast-dump-template-decls-json.cpp
===
--- clang/test/AST/ast-dump-template-decls-json.cpp
+++ clang/test/AST/ast-dump-template-decls-json.cpp
@@ -120,34 +120,6 @@
 // CHECK-NEXT: "end": {}
 // CHECK-NEXT:},
 // CHECK-NEXT:"isImplicit": true,
-// CHECK-NEXT:"name": "__NSConstantString",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "__NSConstantString_tag"
-// CHECK-NEXT:},
-// CHECK-NEXT:"inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "RecordType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "__NSConstantString_tag"
-// CHECK-NEXT:  },
-// CHECK-NEXT:  "decl": {
-// CHECK-NEXT:   "id": "0x{{.*}}",
-// CHECK-NEXT:   "kind": "CXXRecordDecl",
-// CHECK-NEXT:   "name": "__NSConstantString_tag"
-// CHECK-NEXT:  }
-// CHECK-NEXT: }
-// CHECK-NEXT:]
-// CHECK-NEXT:   },
-// CHECK-NEXT:   {
-// CHECK-NEXT:"id": "0x{{.*}}",
-// CHECK-NEXT:"kind": "TypedefDecl",
-// CHECK-NEXT:"loc": {},
-// CHECK-NEXT:"range": {
-// CHECK-NEXT: "begin": {},
-// CHECK-NEXT: "end": {}
-// CHECK-NEXT:},
-// CHECK-NEXT:"isImplicit": true,
 // CHECK-NEXT:"name": "__builtin_ms_va_list",
 // CHECK-NEXT:"type": {
 // CHECK-NEXT: "qualType": "char *"
Index: clang/test/AST/ast-dump-records-json.cpp
===
--- clang/test/AST/ast-dump-records-json.cpp
+++ clang/test/AST/ast-dump-records-json.cpp
@@ -88,11 +88,6 @@
 // using --filters=CXXRecordDecl
 
 
-// CHECK:  "kind": "CXXRecordDecl",
-// CHECK-NEXT:  "name": "__NSConstantString_tag"
-// CHECK-NEXT: }
-
-
 // CHECK:  "kind": "CXXRecordDecl",
 // CHECK-NEXT:  "name": "__va_list_tag"
 // CHECK-NEXT: }
Index: clang/test/AST/ast-dump-record-definition-data-json.cpp
===
--- clang/test/AST/ast-dump-record-definition-data-json.cpp
+++ clang/test/AST/ast-dump-record-definition-data-json.cpp
@@ -128,11 +128,6 @@
 // using --filters=CXXRecordDecl
 
 
-// CHECK:  "kind": "CXXRecordDecl",
-// CHECK-NEXT:  "name": "__NSConstantString_tag"
-// CHECK-NEXT: }
-
-
 // CHECK:  "kind": "CXXRecordDecl",
 // CHECK-NEXT:  "name": "__va_list_tag"
 // CHECK-NEXT: }
Index: clang/test/AST/ast-dump-file-line-json.c
===
--- clang/test/AST/ast-dump-file-line-json.c
+++ clang/test/AST/ast-dump-file-line-json.c
@@ -75,34 +75,6 @@
 // CHECK-NEXT: "end": {}
 // CHECK-NEXT:},
 // CHECK-NEXT:"isImplicit": true,
-// CHECK-NEXT:"name": "__NSConstantString",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "struct __NSConstantString_tag"
-// CHECK-NEXT:},
-// CHECK-NEXT:"inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "RecordType",
-// 

[PATCH] D79279: Allow volatile parameters to __builtin_mem{cpy,move,set}

2020-05-06 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

Here's the RFC: http://lists.llvm.org/pipermail/cfe-dev/2020-May/065385.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79279



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


[PATCH] D79054: [NFC] Improve doc string to mention that paths in diff are used as-is

2020-05-06 Thread Christopher Tetreault via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a77b958e250: [NFC] Improve doc string to mention that paths 
in diff are used as-is (authored by ctetreau).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79054

Files:
  clang/tools/clang-format/clang-format-diff.py


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -13,9 +13,13 @@
 lines. This is useful to reformat all the lines touched by a specific patch.
 Example usage for git/svn users:
 
-  git diff -U0 --no-color HEAD^ | clang-format-diff.py -p1 -i
+  git diff -U0 --no-color --relative HEAD^ | clang-format-diff.py -p1 -i
   svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i
 
+It should be noted that the filename contained in the diff is used unmodified
+to determine the source file to update. Users calling this script directly
+should be careful to ensure that the path in the diff is correct relative to 
the
+current working directory.
 """
 from __future__ import absolute_import, division, print_function
 


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -13,9 +13,13 @@
 lines. This is useful to reformat all the lines touched by a specific patch.
 Example usage for git/svn users:
 
-  git diff -U0 --no-color HEAD^ | clang-format-diff.py -p1 -i
+  git diff -U0 --no-color --relative HEAD^ | clang-format-diff.py -p1 -i
   svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i
 
+It should be noted that the filename contained in the diff is used unmodified
+to determine the source file to update. Users calling this script directly
+should be careful to ensure that the path in the diff is correct relative to the
+current working directory.
 """
 from __future__ import absolute_import, division, print_function
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5a77b95 - [NFC] Improve doc string to mention that paths in diff are used as-is

2020-05-06 Thread Christopher Tetreault via cfe-commits

Author: Christopher Tetreault
Date: 2020-05-06T15:20:05-07:00
New Revision: 5a77b958e250fbf156474b42ccf5a82e8a36db72

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

LOG: [NFC] Improve doc string to mention that paths in diff are used as-is

Summary:
Add --relative to the suggested git-diff one liner. If the user does not
pass this argument, then git will produce a diff with the path relative
to the repository root. If the user's working directory is not the
repository root, then clang-format will complain that the file is not
found. The --relative argument makes git produce a diff with the files
relative to the working directory.

Add note to doc string to warn users about the fact that filenames
embedded in the diff are used as-is with no attempts to "do what they
mean, not what they say"

Reviewers: djasper, alexfh, efriedma, klimek, thakis

Reviewed By: efriedma

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/tools/clang-format/clang-format-diff.py

Removed: 




diff  --git a/clang/tools/clang-format/clang-format-
diff .py b/clang/tools/clang-format/clang-format-
diff .py
index 24c6f4ae456c..5977ab056515 100755
--- a/clang/tools/clang-format/clang-format-
diff .py
+++ b/clang/tools/clang-format/clang-format-
diff .py
@@ -13,9 +13,13 @@
 lines. This is useful to reformat all the lines touched by a specific patch.
 Example usage for git/svn users:
 
-  git 
diff  -U0 --no-color HEAD^ | clang-format-
diff .py -p1 -i
+  git 
diff  -U0 --no-color --relative HEAD^ | clang-format-
diff .py -p1 -i
   svn 
diff  --
diff -cmd=
diff  -x-U0 | clang-format-
diff .py -i
 
+It should be noted that the filename contained in the 
diff  is used unmodified
+to determine the source file to update. Users calling this script directly
+should be careful to ensure that the path in the 
diff  is correct relative to the
+current working directory.
 """
 from __future__ import absolute_import, division, print_function
 



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


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-06 Thread Joel Jones via Phabricator via cfe-commits
joelkevinjones added a comment.

I don't think it makes sense to combine two unrelated things SVE and PA support 
into a combined thing. Since we already have UnsupportedFeatures in every 
sub-target .td file, I think it would be better to instead have:

  def PAUnsupported : AArch64Unsupported {
let F = [HasPA];
  }

and modify each .td file to have

  list UnsupportedFeatures = !listconcat(SVEUnsupported.F, 
PAUnsupported.F);


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-06 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D79343#2023658 , @CaseyCarter wrote:

> I'm not going to reformat *only* my additions per the clang-format 
> instructions - that would be silly - and I suspect that folks would 
> clang-format all of the tests if they actually wanted them formatted, so I 
> won't format the entire file, either.


I'm not sure how the `libcxx/` maintainers feel, but clang-formatting just the 
changes is the operating procedure in `llvm/` and `clang/`.  Here's a script 
that makes it easy:
https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
I believe there's also a `git-clang-format` script checked in that you can 
leverage by adding it to your `PATH`.

The rules change regularly in subtle ways, usually because of fixes/regressions 
in `clang-format`, sometimes due to changes in policy.  We don't do a mass 
reformat of the entire codebase on every commit though, instead we just update 
the lines that are being changed, edging things "closer".  Maybe it would be 
better to do a mass reformat on policy changes but we haven't done that 
historically.

If a file is drastically out-of-whack, it's an option to reformat it in a 
separate format-only commit before making a change (never the same commit as a 
change because that makes it hard to see what changed).

Not trying to impose rules on libc++, just providing some context; I suspect 
these new linters are broadly following the procedure from LLVM and Clang.




Comment at: 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp:33
 struct DummyIt {
-  typedef std::forward_iterator_tag iterator_category;
-  typedef ValueType value_type;
-  typedef std::ptrdiff_t difference_type;
-  typedef ValueType* pointer;
-  typedef Reference reference;
+typedef std::forward_iterator_tag iterator_category;
+typedef ValueType value_type;

You seem to be changing from 2-space indent (the usual practice for LLVM) to 
4-space indent here.  I don't know if that's intentional, but if it's the right 
thing to do please do so in a separate commit to avoid adding noise to this 
patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79343



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


[PATCH] D60193: [OpenCL] Added addrspace_cast operator

2020-05-06 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked 4 inline comments as done.
Anastasia added inline comments.



Comment at: lib/Sema/SemaCast.cpp:279
+  case tok::kw_addrspace_cast:
+if (!TypeDependent) {
+  Op.CheckAddrspaceCast();

mantognini wrote:
> Still learning here, so could you/someone tell me if I understood things 
> correctly? :)
> 
> The type is "dependent" when templates are involved, right? And, here, when 
> we don't know all the concrete types we defer the checking to a later 
> compiler phase? And that later compiler phase would be implemented by 
> "TreeTransform", right?
Precisely!



Comment at: lib/Sema/SemaCast.cpp:285
+return Op.complete(CXXAddrspaceCastExpr::Create(Context, Op.ResultType,
+Op.ValueKind, Op.SrcExpr.get(),
+  DestTInfo,

mantognini wrote:
> The formatting looks a bit funny here.
I agree, I just matched the style of the old code to keep it coherent. Although 
perhaps I should rather adhere to the current style?



Comment at: lib/Sema/SemaCast.cpp:2319
  unsigned ) {
   if (!Self.getLangOpts().OpenCL)
 // FIXME: As compiler doesn't have any information about overlapping addr

mantognini wrote:
> Just to make sure I understand things correctly: `OpenCL` is true when 
> dealing with C or C++ mode for OpenCL, right?
Precisely! 



Comment at: lib/Sema/SemaCast.cpp:2338
   auto DestPointeeType = DestPtrType->getPointeeType();
   if (SrcPointeeType.getAddressSpace() == DestPointeeType.getAddressSpace())
 return TC_NotApplicable;

mantognini wrote:
> Wouldn't this limit usage of the cast unnecessarily? I'm thinking this could 
> be transformed to a NOP, which could be beneficial to make (template) code 
> simpler to write.
I am not sure what you mean. I have added the test for templates and it caught 
a bug in lib/AST/Expr.cpp with assert condition.

However, now that I think about this more, I believe we should allow compiling 
this?

```
__private int* i;
addrspace_cast(i);
```

Currently it outputs an error.


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

https://reviews.llvm.org/D60193



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


[clang] 16c800b - [X86] Remove support for Y0 constraint as an alias for Yz in inline assembly.

2020-05-06 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2020-05-06T14:58:53-07:00
New Revision: 16c800b8b7155b531b53da0ca18b81980ac6a45b

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

LOG: [X86] Remove support for Y0 constraint as an alias for Yz in inline 
assembly.

Neither gcc or icc support this. Split out from D79472. I want
to remove more, but it looks like icc does support some things
gcc doesn't and I need to double check our internal test suites.

Added: 


Modified: 
clang/lib/Basic/Targets/X86.cpp
clang/test/CodeGen/x86-GCC-inline-asm-Y-constraints.c
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/test/MC/X86/x86-GCC-inline-asm-Y-constraints.ll

Removed: 




diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index bd0777d88821..f4fd5c5835d9 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -1691,8 +1691,7 @@ bool X86TargetInfo::validateAsmConstraint(
 switch (*Name) {
 default:
   return false;
-case 'z':
-case '0': // First SSE register.
+case 'z': // First SSE register.
 case '2':
 case 't': // Any SSE register, when SSE2 is enabled.
 case 'i': // Any SSE register, when SSE2 and inter-unit moves enabled.
@@ -1897,7 +1896,6 @@ bool X86TargetInfo::validateOperandSize(const 
llvm::StringMap ,
 case 'k':
   return Size <= 64;
 case 'z':
-case '0':
   // XMM0/YMM/ZMM0
   if (FeatureMap.lookup("avx512f"))
 // ZMM0 can be used if target supports AVX512F.
@@ -1971,7 +1969,6 @@ std::string X86TargetInfo::convertConstraint(const char 
*) const {
 case 'i':
 case 't':
 case 'z':
-case '0':
 case '2':
   // "^" hints llvm that this is a 2 letter constraint.
   // "Constraint++" is used to promote the string iterator

diff  --git a/clang/test/CodeGen/x86-GCC-inline-asm-Y-constraints.c 
b/clang/test/CodeGen/x86-GCC-inline-asm-Y-constraints.c
index 0e1e69cd2459..07bd045677db 100644
--- a/clang/test/CodeGen/x86-GCC-inline-asm-Y-constraints.c
+++ b/clang/test/CodeGen/x86-GCC-inline-asm-Y-constraints.c
@@ -54,15 +54,3 @@ void f_Yz(__m128 x, __m128 y, __m128 z)
   :"+Yi"(z),"=Yz" (x)
   :"Yi" (y) );
 }
-
-// CHECK-LABEL: f_Y0
-void f_Y0(__m128 x, __m128 y, __m128 z)
-  {
-  // CHECK: vpaddq
-  // CHECK-SAME: "=^Yi,=^Y0,^Yi,0,~{dirflag},~{fpsr},~{flags}"
-  __asm__ volatile ("vpaddq %0,%2,%1\n\t"
-  "vpaddq %1,%0,%2\n\t"
-  :"+Yi"(z),"=Y0" (x)
-  :"Yi" (y) );
-}
-

diff  --git a/llvm/lib/Target/X86/X86ISelLowering.cpp 
b/llvm/lib/Target/X86/X86ISelLowering.cpp
index 5105ea2776ef..dc546d580475 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -48016,7 +48016,6 @@ X86TargetLowering::getConstraintType(StringRef 
Constraint) const {
   default:
 break;
   case 'z':
-  case '0':
 return C_Register;
   case 'i':
   case 'm':
@@ -48080,7 +48079,6 @@ TargetLowering::ConstraintWeight
 return CW_Invalid;
   // XMM0
   case 'z':
-  case '0':
 if (((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1()) ||
 ((type->getPrimitiveSizeInBits() == 256) && Subtarget.hasAVX()) ||
 ((type->getPrimitiveSizeInBits() == 512) && Subtarget.hasAVX512()))
@@ -48551,7 +48549,6 @@ X86TargetLowering::getRegForInlineAsmConstraint(const 
TargetRegisterInfo *TRI,
   if (!Subtarget.hasMMX()) break;
   return std::make_pair(0U, ::VR64RegClass);
 case 'z':
-case '0':
   if (!Subtarget.hasSSE1()) break;
   switch (VT.SimpleTy) {
   default: break;

diff  --git a/llvm/test/MC/X86/x86-GCC-inline-asm-Y-constraints.ll 
b/llvm/test/MC/X86/x86-GCC-inline-asm-Y-constraints.ll
index 0b80ea6b1579..d0b88a04bd29 100644
--- a/llvm/test/MC/X86/x86-GCC-inline-asm-Y-constraints.ll
+++ b/llvm/test/MC/X86/x86-GCC-inline-asm-Y-constraints.ll
@@ -67,17 +67,3 @@ entry:
   ret void
 }
 
-; Function Attrs: nounwind
-define void @f_Y0(<4 x float> %x, <4 x float> %y, <4 x float> %z) {
-; xmm0 SSE register
-; CHECK-LABEL: f_Y0:
-; CHECK: ## InlineAsm Start
-; CHECK-NEXT:vpaddq %xmm{{[0-9]+}}, %xmm{{[0-9]+}}, %xmm0
-; CHECK-NEXT:vpaddq %xmm0, %xmm{{[0-9]+}}, %xmm{{[0-9]+}}
-; CHECK: ## InlineAsm End
-
-entry:
-  %0 = tail call { <4 x float>, <4 x float> } asm sideeffect "vpaddq 
$0,$2,$1\0A\09vpaddq $1,$0,$2\0A\09", 
"=^Yi,=^Y0,^Yi,0,~{dirflag},~{fpsr},~{flags}"(<4 x float> %y, <4 x float> %z)
-  ret void
-}
-



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


[PATCH] D79522: Allow -fsanitize-minimal-runtime with memtag sanitizer.

2020-05-06 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis created this revision.
eugenis added a reviewer: pcc.
Herald added a subscriber: cryptoad.
Herald added a project: clang.

MemTag does not have any runtime at the moment, it's strictly code
instrumentation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79522

Files:
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/fsanitize.c


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -781,6 +781,10 @@
 // CHECK-UBSAN-MINIMAL: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
 // CHECK-UBSAN-MINIMAL: "-fsanitize-minimal-runtime"
 
+// RUN: %clang -target aarch64-linux-android -march=armv8-a+memtag 
-fsanitize=memtag -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MEMTAG-MINIMAL
+// CHECK-MEMTAG-MINIMAL: "-fsanitize=memtag"
+// CHECK-MEMTAG-MINIMAL: "-fsanitize-minimal-runtime"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize=function -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-UBSAN-FUNCTION-MINIMAL
 // CHECK-UBSAN-FUNCTION-MINIMAL: error: invalid argument '-fsanitize=function' 
not allowed with '-fsanitize-minimal-runtime'
 
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -68,7 +68,8 @@
 SanitizerKind::CFIMFCall | SanitizerKind::CFIDerivedCast |
 SanitizerKind::CFIUnrelatedCast;
 static const SanitizerMask CompatibleWithMinimalRuntime =
-TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack;
+TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack |
+SanitizerKind::MemTag;
 
 enum CoverageFeature {
   CoverageFunc = 1 << 0,


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -781,6 +781,10 @@
 // CHECK-UBSAN-MINIMAL: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
 // CHECK-UBSAN-MINIMAL: "-fsanitize-minimal-runtime"
 
+// RUN: %clang -target aarch64-linux-android -march=armv8-a+memtag -fsanitize=memtag -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MEMTAG-MINIMAL
+// CHECK-MEMTAG-MINIMAL: "-fsanitize=memtag"
+// CHECK-MEMTAG-MINIMAL: "-fsanitize-minimal-runtime"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize=function -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-FUNCTION-MINIMAL
 // CHECK-UBSAN-FUNCTION-MINIMAL: error: invalid argument '-fsanitize=function' not allowed with '-fsanitize-minimal-runtime'
 
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -68,7 +68,8 @@
 SanitizerKind::CFIMFCall | SanitizerKind::CFIDerivedCast |
 SanitizerKind::CFIUnrelatedCast;
 static const SanitizerMask CompatibleWithMinimalRuntime =
-TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack;
+TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack |
+SanitizerKind::MemTag;
 
 enum CoverageFeature {
   CoverageFunc = 1 << 0,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79515: [CUDA] Enable existing builtins for PTX7.0 as well.

2020-05-06 Thread Artem Belevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG314f99e7d42d: [CUDA] Enable existing builtins for PTX7.0 as 
well. (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79515

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -6,6 +6,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx65 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -6,6 +6,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx65 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74813: Function block naming - add hash of parameter type to end of block name

2020-05-06 Thread Alex Borcan via Phabricator via cfe-commits
alexbdv added a comment.

@dexonsmith  @erik.pilkington  The change is final now, could we get this in ?


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

https://reviews.llvm.org/D74813



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


[PATCH] D60193: [OpenCL] Added addrspace_cast operator

2020-05-06 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D60193#1549806 , @mantognini wrote:

> When compiling this I get the following warning:
>
>   clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1213:10: warning: enumeration 
> value 'CXXAddrspaceCastExprClass' not handled in switch
>
>
> The fix is probably to just add the missing case with the other 
> `*CastExprClass` cases.
>
> There's also a similar warning for `clang/tools/libclang/CXCursor.cpp:132`.


I had to add some more bits to CIndex to make it work!


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

https://reviews.llvm.org/D60193



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


[PATCH] D60193: [OpenCL] Added addrspace_cast operator

2020-05-06 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 262479.
Anastasia added a subscriber: jeroen.dobbelaere.
Anastasia added a comment.
Herald added subscribers: martong, arphaman.

Sorry for long latency. I have rebased the patch to the current master and 
addressed the comments from @mantognini too.


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

https://reviews.llvm.org/D60193

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/CodeGenOpenCLCXX/addrspace_cast.cl
  clang/test/Index/cxx.cl
  clang/test/SemaOpenCLCXX/addrspace_cast.cl
  clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXCursor.cpp

Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -491,6 +491,10 @@
 K = CXCursor_CXXFunctionalCastExpr;
 break;
 
+  case Stmt::CXXAddrspaceCastExprClass:
+K = CXCursor_CXXAddrspaceCastExpr;
+break;
+
   case Stmt::CXXTypeidExprClass:
 K = CXCursor_CXXTypeidExpr;
 break;
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5237,6 +5237,8 @@
 return cxstring::createRef("CXXConstCastExpr");
   case CXCursor_CXXFunctionalCastExpr:
 return cxstring::createRef("CXXFunctionalCastExpr");
+  case CXCursor_CXXAddrspaceCastExpr:
+return cxstring::createRef("CXXAddrspaceCastExpr");
   case CXCursor_CXXTypeidExpr:
 return cxstring::createRef("CXXTypeidExpr");
   case CXCursor_CXXBoolLiteralExpr:
Index: clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=clc++ -pedantic -verify -ast-dump | FileCheck %s
+
+// expected-no-diagnostics
+
+//CHECK:`-FunctionDecl {{.*}} bar 'void (__global int *__private)'
+//CHECK:  |-ParmVarDecl {{.*}} used gl '__global int *__private'
+//CHECK:  `-VarDecl {{.*}} gen '__generic int *__private' cinit
+//CHECK:`-CXXAddrspaceCastExpr {{.*}} '__generic int *' addrspace_cast<__generic int *> 
+//CHECK:  `-DeclRefExpr {{.*}} '__global int *__private' lvalue ParmVar {{.*}} 'gl' '__global int *__private'
+
+void bar(global int *gl) {
+  int *gen = addrspace_cast(gl);
+}
Index: clang/test/SemaOpenCLCXX/addrspace_cast.cl
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace_cast.cl
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=clc++ -pedantic -verify -fsyntax-only
+
+void foo(global int *gl, const global int *gl_const, global int _ref) {
+  //FIXME: Diagnostics can be improved to be more specific in some cases.
+  float *gen_fl = addrspace_cast(gl); //expected-error{{addrspace_cast from '__global int *__private' to '__generic float *' is not allowed}}
+
+  int i = addrspace_cast(gl); //expected-error{{addrspace_cast from '__global int *__private' to 'int' is not allowed}}
+
+  int *gen = addrspace_cast(*gl); //expected-error{{addrspace_cast from '__global int' to '__generic int *' is not allowed}}
+
+  local int *loc = addrspace_cast(gl); //expected-error{{addrspace_cast from '__global int *__private' to '__local int *' converts between mismatching address spaces}}
+
+  int *gen2 = addrspace_cast(gl_const); //expected-error{{addrspace_cast from 'const __global int *__private' to '__generic int *' is not allowed}}
+
+  //FIXME: Do we expect this behavior? This will get cast successfully as reinterpret_cast.
+  int _ref = addrspace_cast(gl_ref); //expected-error{{addrspace_cast from '__global int' to '__generic int &' is not allowed}}
+}
+
+template 
+void test_temp(__global int *par) {
+  T *var1 = addrspace_cast(par);
+  __private T *var2 = addrspace_cast<__private T 

[PATCH] D79054: [NFC] Improve doc string to mention that paths in diff are used as-is

2020-05-06 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79054



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


[clang] 314f99e - [CUDA] Enable existing builtins for PTX7.0 as well.

2020-05-06 Thread Artem Belevich via cfe-commits

Author: Artem Belevich
Date: 2020-05-06T14:24:21-07:00
New Revision: 314f99e7d42ded663386190a54b5831dc4a6f3c1

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

LOG: [CUDA] Enable existing builtins for PTX7.0 as well.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsNVPTX.def
clang/test/CodeGen/builtins-nvptx-ptx60.cu

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsNVPTX.def 
b/clang/include/clang/Basic/BuiltinsNVPTX.def
index 96455753ae4d..759c91290a60 100644
--- a/clang/include/clang/Basic/BuiltinsNVPTX.def
+++ b/clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@ TARGET_BUILTIN(__imma_m8n8k32_st_c_i32, "vi*iC*UiIi", "", 
AND(SM_75,PTX63))
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")

diff  --git a/clang/test/CodeGen/builtins-nvptx-ptx60.cu 
b/clang/test/CodeGen/builtins-nvptx-ptx60.cu
index f6af9de6e8d7..ad5c48ef1662 100644
--- a/clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ b/clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -6,6 +6,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx65 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 



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


[clang] 9bb9ff0 - [X86] Remove incomplete support for 'Y' has an inline assembly constraint by itself.

2020-05-06 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2020-05-06T14:23:04-07:00
New Revision: 9bb9ff09573cf9178341f76a97e2a85b99cc7ae1

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

LOG: [X86] Remove incomplete support for 'Y' has an inline assembly constraint 
by itself.

Y is the start of several 2 letter constraints, but we also had
partial support to recognize it by itself. But it doesn't look
like it can get through clang as a single letter so the backend
support for this was effectively dead.

Added: 


Modified: 
clang/lib/Basic/Targets/X86.cpp
llvm/lib/Target/X86/X86ISelLowering.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index b0fecd6fd1c1..bd0777d88821 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -1916,7 +1916,7 @@ bool X86TargetInfo::validateOperandSize(const 
llvm::StringMap ,
 return false;
   break;
 }
-LLVM_FALLTHROUGH;
+break;
   case 'v':
   case 'x':
 if (FeatureMap.lookup("avx512f"))

diff  --git a/llvm/lib/Target/X86/X86ISelLowering.cpp 
b/llvm/lib/Target/X86/X86ISelLowering.cpp
index 0a2376a2e00d..5105ea2776ef 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -47980,7 +47980,6 @@ X86TargetLowering::getConstraintType(StringRef 
Constraint) const {
 case 'y':
 case 'x':
 case 'v':
-case 'Y':
 case 'l':
 case 'k': // AVX512 masking registers.
   return C_RegisterClass;
@@ -48073,13 +48072,10 @@ TargetLowering::ConstraintWeight
 if (type->isX86_MMXTy() && Subtarget.hasMMX())
   weight = CW_SpecificReg;
 break;
-  case 'Y': {
-unsigned Size = StringRef(constraint).size();
-// Pick 'i' as the next char as 'Yi' and 'Y' are synonymous, when matching 
'Y'
-char NextChar = Size == 2 ? constraint[1] : 'i';
-if (Size > 2)
+  case 'Y':
+if (StringRef(constraint).size() != 2)
   break;
-switch (NextChar) {
+switch (constraint[1]) {
   default:
 return CW_Invalid;
   // XMM0
@@ -48100,7 +48096,7 @@ TargetLowering::ConstraintWeight
 if (type->isX86_MMXTy() && Subtarget.hasMMX())
   return weight;
 return CW_Invalid;
-  // Any SSE reg when ISA >= SSE2, same as 'Y'
+  // Any SSE reg when ISA >= SSE2, same as 'x'
   case 'i':
   case 't':
   case '2':
@@ -48108,9 +48104,7 @@ TargetLowering::ConstraintWeight
   return CW_Invalid;
 break;
 }
-// Fall through (handle "Y" constraint).
-LLVM_FALLTHROUGH;
-  }
+break;
   case 'v':
 if ((type->getPrimitiveSizeInBits() == 512) && Subtarget.hasAVX512())
   weight = CW_Register;
@@ -48192,8 +48186,6 @@ LowerXConstraint(EVT ConstraintVT) const {
   // FP X constraints get lowered to SSE1/2 registers if available, otherwise
   // 'f' like normal targets.
   if (ConstraintVT.isFloatingPoint()) {
-if (Subtarget.hasSSE2())
-  return "Y";
 if (Subtarget.hasSSE1())
   return "x";
   }
@@ -48492,9 +48484,6 @@ X86TargetLowering::getRegForInlineAsmConstraint(const 
TargetRegisterInfo *TRI,
 case 'y':   // MMX_REGS if MMX allowed.
   if (!Subtarget.hasMMX()) break;
   return std::make_pair(0U, ::VR64RegClass);
-case 'Y':   // SSE_REGS if SSE2 allowed
-  if (!Subtarget.hasSSE2()) break;
-  LLVM_FALLTHROUGH;
 case 'v':
 case 'x':   // SSE_REGS if SSE1 allowed or AVX_REGS if AVX allowed
   if (!Subtarget.hasSSE1()) break;
@@ -48557,7 +48546,7 @@ X86TargetLowering::getRegForInlineAsmConstraint(const 
TargetRegisterInfo *TRI,
 case 'i':
 case 't':
 case '2':
-  return getRegForInlineAsmConstraint(TRI, "Y", VT);
+  return getRegForInlineAsmConstraint(TRI, "x", VT);
 case 'm':
   if (!Subtarget.hasMMX()) break;
   return std::make_pair(0U, ::VR64RegClass);



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-06 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter added a comment.

I'm not going to reformat *only* my additions per the clang-format instructions 
- that would be silly - and I suspect that folks would clang-format all of the 
tests if they actually wanted them formatted, so I won't format the entire 
file, either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79343



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


[PATCH] D79515: [CUDA] Enable existing builtins for PTX7.0 as well.

2020-05-06 Thread Artem Belevich via Phabricator via cfe-commits
tra updated this revision to Diff 262473.
tra added a comment.

Updates test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79515

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -6,6 +6,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx65 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -6,6 +6,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx65 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

2020-05-06 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.



> You could adapt that code to not break before the second `TT_AttributeSquare` 
> in `[[` or `]]`; this will have the same effect and generalize.

sounds good... let me try that change and see if we like it better


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79401



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


[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-06 Thread Steve Canon via Phabricator via cfe-commits
scanon added a comment.

TS18661-5 is quite vague on what the intended semantics for the pragma are.

These pragmas are intended to be bindings of clause 10.4 of IEEE 754, which is 
also pretty wishy-washy on the whole, but it's worth noting that clause 10 is 
titled *expression evaluation* specifically. The relevant text here is:

> A language standard should also define, and require implementations to 
> provide, attributes that allow and disallow value-changing optimizations, 
> separately or collectively, for a block. These optimizations might include, 
> but are not limited to:
>  ― Applying the associative or distributive laws.
>  ― Synthesis of a fusedMultiplyAdd operation from a multiplication and an 
> addition.
>  ― Synthesis of a formatOf operation from an operation and a conversion of 
> the result of the 40 operation.
>  ― Use of wider intermediate results in expression evaluation.

So IEEE-754 appears to view this as being "just like" contraction. (Note that 
this is all under a "should", so #yolo).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D79510: [PATCH] When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures

2020-05-06 Thread Melanie Blower via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe5578013b199: When pragma FENV_ACCESS is ignored do not 
modify Sema.CurFPFeatures Bug… (authored by mibintc).

Changed prior to commit:
  https://reviews.llvm.org/D79510?vs=262434=262467#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79510

Files:
  clang/lib/Parse/ParsePragma.cpp
  clang/test/CodeGen/fp-floatcontrol-pragma.cpp
  clang/test/Parser/fp-floatcontrol-syntax.cpp


Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -30,14 +30,15 @@
 //  document the warning
 #ifdef FAST
 // expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring 
pragma}}
-#pragma STDC FENV_ACCESS ON // expected-error{{'#pragma STDC FENV_ACCESS ON' 
is illegal when precise is disabled}}
+#pragma STDC FENV_ACCESS ON
 #else
 #pragma STDC FENV_ACCESS ON // expected-warning{{pragma STDC FENV_ACCESS ON is 
not supported, ignoring pragma}}
 #endif
 #ifdef STRICT
 #pragma float_control(precise, off) // expected-error {{'#pragma 
float_control(precise, off)' is illegal when except is enabled}}
 #else
-#pragma float_control(precise, off) // expected-error {{'#pragma 
float_control(precise, off)' is illegal when fenv_access is enabled}}
+// Currently FENV_ACCESS cannot be enabled by pragma, skip error check
+#pragma float_control(precise, off) // not-expected-error {{'#pragma 
float_control(precise, off)' is illegal when fenv_access is enabled}}
 #endif
 
 #pragma float_control(precise, on)
Index: clang/test/CodeGen/fp-floatcontrol-pragma.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-pragma.cpp
+++ clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -verify -DFENV_ON=1 -triple x86_64-linux-gnu -emit-llvm -o 
- %s | FileCheck %s
 
 float fff(float x, float y) {
 // CHECK-LABEL: define float @_Z3f{{.*}}
@@ -38,6 +39,7 @@
   }
   return z;
 }
+
 float fma_test1(float a, float b, float c) {
 // CHECK-LABEL define float @_Z9fma_test1fff{{.*}}
 #pragma float_control(precise, on)
@@ -45,3 +47,15 @@
   //CHECK: fmuladd
   return x;
 }
+
+#if FENV_ON
+// expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring 
pragma}}
+#pragma STDC FENV_ACCESS ON
+#endif
+// CHECK-LABEL: define {{.*}}callt{{.*}}
+
+void callt() {
+  volatile float z;
+  z = z * z;
+//CHECK: = fmul float
+}
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -108,6 +108,7 @@
  return;
 if (OOS == tok::OOS_ON) {
   PP.Diag(Tok, diag::warn_stdc_fenv_access_not_supported);
+  return;
 }
 
 MutableArrayRef 
Toks(PP.getPreprocessorAllocator().Allocate(1),


Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -30,14 +30,15 @@
 //  document the warning
 #ifdef FAST
 // expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
-#pragma STDC FENV_ACCESS ON // expected-error{{'#pragma STDC FENV_ACCESS ON' is illegal when precise is disabled}}
+#pragma STDC FENV_ACCESS ON
 #else
 #pragma STDC FENV_ACCESS ON // expected-warning{{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
 #endif
 #ifdef STRICT
 #pragma float_control(precise, off) // expected-error {{'#pragma float_control(precise, off)' is illegal when except is enabled}}
 #else
-#pragma float_control(precise, off) // expected-error {{'#pragma float_control(precise, off)' is illegal when fenv_access is enabled}}
+// Currently FENV_ACCESS cannot be enabled by pragma, skip error check
+#pragma float_control(precise, off) // not-expected-error {{'#pragma float_control(precise, off)' is illegal when fenv_access is enabled}}
 #endif
 
 #pragma float_control(precise, on)
Index: clang/test/CodeGen/fp-floatcontrol-pragma.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-pragma.cpp
+++ clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -verify -DFENV_ON=1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
 
 float fff(float x, float y) {
 // CHECK-LABEL: define float @_Z3f{{.*}}
@@ -38,6 +39,7 @@
   }
   return z;
 }
+
 float fma_test1(float a, float b, float c) {
 // CHECK-LABEL define float @_Z9fma_test1fff{{.*}}
 #pragma 

[PATCH] D79515: [CUDA] Enable existing builtins for PTX7.0 as well.

2020-05-06 Thread Tim Shen via Phabricator via cfe-commits
timshen accepted this revision.
timshen added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/CodeGen/builtins-nvptx-ptx60.cu:6
 // RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
-// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
 // RUN:-S -emit-llvm -o - -x cuda %s \

Keep ptx65 as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79515



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


[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-06 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

The ISO C proposal is here 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2407.pdf but the details are 
in the IEEE standards documents.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D79511: [ObjC] Add compatibility mode for type checking of qualified id block parameters.

2020-05-06 Thread James Y Knight via Phabricator via cfe-commits
jyknight added inline comments.



Comment at: clang/test/SemaObjC/block-type-safety.m:170
+genericBlockWithParam = blockWithParam;
+blockWithParam = genericBlockWithParam; // expected-error {{incompatible 
block pointer types assigning to 'void (^)(NSAllArray *)' from 'void 
(^)(id)'}}
+return 0;

It seems a shame to disallow this assignment in the compatibility mode, when it 
ought to be allowed.

Perhaps it would be better to allow both directions for parameters when the 
compatibility flag is set? (That is: the compat mode flag would only cause the 
compiler to allow _more_ things than it otherwise should.)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79511



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


[clang] e557801 - When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures

2020-05-06 Thread Melanie Blower via cfe-commits

Author: Melanie Blower
Date: 2020-05-06T13:18:59-07:00
New Revision: e5578013b199e142864cbf374b4a143e5d0c184a

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

LOG: When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures
Bug reported by @uabelho against reviews.llvm.org/D72841

Reviewers: rjmccall

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

Added: 


Modified: 
clang/lib/Parse/ParsePragma.cpp
clang/test/CodeGen/fp-floatcontrol-pragma.cpp
clang/test/Parser/fp-floatcontrol-syntax.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParsePragma.cpp b/clang/lib/Parse/ParsePragma.cpp
index 8adf978a8e13..828d429e6969 100644
--- a/clang/lib/Parse/ParsePragma.cpp
+++ b/clang/lib/Parse/ParsePragma.cpp
@@ -108,6 +108,7 @@ struct PragmaSTDC_FENV_ACCESSHandler : public PragmaHandler 
{
  return;
 if (OOS == tok::OOS_ON) {
   PP.Diag(Tok, diag::warn_stdc_fenv_access_not_supported);
+  return;
 }
 
 MutableArrayRef 
Toks(PP.getPreprocessorAllocator().Allocate(1),

diff  --git a/clang/test/CodeGen/fp-floatcontrol-pragma.cpp 
b/clang/test/CodeGen/fp-floatcontrol-pragma.cpp
index caaab3ca4f84..773cfcdd2829 100644
--- a/clang/test/CodeGen/fp-floatcontrol-pragma.cpp
+++ b/clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -verify -DFENV_ON=1 -triple x86_64-linux-gnu -emit-llvm -o 
- %s | FileCheck %s
 
 float fff(float x, float y) {
 // CHECK-LABEL: define float @_Z3f{{.*}}
@@ -38,6 +39,7 @@ float check_precise(float x, float y) {
   }
   return z;
 }
+
 float fma_test1(float a, float b, float c) {
 // CHECK-LABEL define float @_Z9fma_test1fff{{.*}}
 #pragma float_control(precise, on)
@@ -45,3 +47,15 @@ float fma_test1(float a, float b, float c) {
   //CHECK: fmuladd
   return x;
 }
+
+#if FENV_ON
+// expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring 
pragma}}
+#pragma STDC FENV_ACCESS ON
+#endif
+// CHECK-LABEL: define {{.*}}callt{{.*}}
+
+void callt() {
+  volatile float z;
+  z = z * z;
+//CHECK: = fmul float
+}

diff  --git a/clang/test/Parser/fp-floatcontrol-syntax.cpp 
b/clang/test/Parser/fp-floatcontrol-syntax.cpp
index a7303720e6c4..4bdc34dd5ee0 100644
--- a/clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ b/clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -30,14 +30,15 @@ double b = 1.0;
 //  document the warning
 #ifdef FAST
 // expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring 
pragma}}
-#pragma STDC FENV_ACCESS ON // expected-error{{'#pragma STDC FENV_ACCESS ON' 
is illegal when precise is disabled}}
+#pragma STDC FENV_ACCESS ON
 #else
 #pragma STDC FENV_ACCESS ON // expected-warning{{pragma STDC FENV_ACCESS ON is 
not supported, ignoring pragma}}
 #endif
 #ifdef STRICT
 #pragma float_control(precise, off) // expected-error {{'#pragma 
float_control(precise, off)' is illegal when except is enabled}}
 #else
-#pragma float_control(precise, off) // expected-error {{'#pragma 
float_control(precise, off)' is illegal when fenv_access is enabled}}
+// Currently FENV_ACCESS cannot be enabled by pragma, skip error check
+#pragma float_control(precise, off) // not-expected-error {{'#pragma 
float_control(precise, off)' is illegal when fenv_access is enabled}}
 #endif
 
 #pragma float_control(precise, on)



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


[PATCH] D69088: [Lex] #pragma clang transform

2020-05-06 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

In D69088#2023114 , @kbarton wrote:

> @Meinersbur I missed the RFC and discussion on the cfe-dev mailing list. 
> Could you post a link here so that it's included in the history?


See the collection of links in a previous comment: 
https://reviews.llvm.org/D69088#1715025

In particular, you seem to look for this: 
https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html . However, there 
was no response to that RFC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69088



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


[PATCH] D71687: Fix full loop unrolling initialization in new pass manager

2020-05-06 Thread Eric Christopher via Phabricator via cfe-commits
echristo marked 6 inline comments as done.
echristo added a comment.

OK, ready again :)




Comment at: llvm/test/Transforms/LoopUnroll/FullUnroll.ll:4-6
+; We don't end up deleting the loop, but we remove everything inside of it so 
checking for any
+; reasonable instruction from the original loop will work.
+; CHECK-NOT: br i1

chandlerc wrote:
> Make sure it is in the correct function at least, and maybe after the label 
> for the loop header?
Got it. There's not a lot of function left at the end:

define void @walrus() local_unnamed_addr #0 {
entry:
  br label %for.cond.preheader

for.cond.preheader:   ; preds = 
%for.cond.preheader, %entry
  br label %for.cond.preheader
}



Comment at: llvm/test/Transforms/LoopUnroll/FullUnroll.ll:12-17
+; Function Attrs: noinline optnone uwtable
+define dso_local void @_Z3Runv() #0 {
+entry:
+  call void @_Z6Helperv()
+  ret void
+}

chandlerc wrote:
> Are both functions needed?
I thought so, but apparently not :)



Comment at: llvm/test/Transforms/LoopUnroll/FullUnroll.ll:19-20
+
+; Function Attrs: noinline nounwind optnone uwtable
+define linkonce_odr dso_local void @_Z6Helperv() #1 comdat {
+entry:

chandlerc wrote:
> Nit, but minimize and clean this function up a touch?
> 
> At the least, removing all the target features seems valuable, and I'd give 
> things stable names instead of numbered values.
Got it. Most things have stable names, only a few temporaries have numbered 
names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71687



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


[PATCH] D71687: Fix full loop unrolling initialization in new pass manager

2020-05-06 Thread Eric Christopher via Phabricator via cfe-commits
echristo updated this revision to Diff 262458.
echristo added a comment.

Update and reduce testcase a bit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71687

Files:
  clang/test/Misc/loop-opt-setup.c
  llvm/lib/Passes/PassBuilder.cpp
  llvm/test/Transforms/LoopUnroll/FullUnroll.ll
  llvm/tools/opt/NewPMDriver.cpp

Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -100,6 +100,11 @@
  "the OptimizerLast extension point into default pipelines"),
 cl::Hidden);
 
+// Individual pipeline tuning options.
+static cl::opt DisableLoopUnrolling(
+"new-pm-disable-loop-unrolling",
+cl::desc("Disable loop unrolling in all relevant passes"), cl::init(false));
+
 extern cl::opt PGOKindFlag;
 extern cl::opt ProfileFile;
 extern cl::opt CSPGOKindFlag;
@@ -260,6 +265,10 @@
   SI.registerCallbacks(PIC);
 
   PipelineTuningOptions PTO;
+  // LoopUnrolling defaults on to true and DisableLoopUnrolling is initialized
+  // to false above so we shouldn't necessarily need to check whether or not the
+  // option has been enabled.
+  PTO.LoopUnrolling = !DisableLoopUnrolling;
   PTO.Coroutines = Coroutines;
   PassBuilder PB(TM, PTO, P, );
   registerEPCallbacks(PB, VerifyEachPass, DebugPM);
Index: llvm/test/Transforms/LoopUnroll/FullUnroll.ll
===
--- /dev/null
+++ llvm/test/Transforms/LoopUnroll/FullUnroll.ll
@@ -0,0 +1,73 @@
+; RUN: opt -passes='default' -disable-verify --mtriple x86_64-pc-linux-gnu -new-pm-disable-loop-unrolling=true \
+; RUN: -S -o - %s | FileCheck %s
+
+; This checks that the loop full unroller will fire in the new pass manager
+; when forced via #pragma in the source (or annotation in the code).
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; Function Attrs: noinline nounwind optnone uwtable
+define void @walrus() #0 {
+; We don't end up deleting the loop, merely turning it infinite, but we remove
+; everything inside of it so checking for a conditional branch will work.
+; CHECK-LABEL: entry
+; CHECK-NOT: br i1
+entry:
+  %nodes = alloca [5 x i32*], align 16
+  %num_active = alloca i32, align 4
+  %i = alloca i32, align 4
+  store i32 5, i32* %num_active, align 4
+  br label %while.cond
+
+while.cond:   ; preds = %for.end, %entry
+  %0 = load i32, i32* %num_active, align 4
+  %tobool = icmp ne i32 %0, 0
+  br i1 %tobool, label %while.body, label %while.end
+
+while.body:   ; preds = %while.cond
+  store i32 0, i32* %i, align 4
+  br label %for.cond
+
+for.cond: ; preds = %for.inc, %while.body
+  %1 = load i32, i32* %i, align 4
+  %cmp = icmp slt i32 %1, 5
+  br i1 %cmp, label %for.body, label %for.end
+
+for.body: ; preds = %for.cond
+  %2 = load i32, i32* %i, align 4
+  %idxprom = sext i32 %2 to i64
+  %arrayidx = getelementptr inbounds [5 x i32*], [5 x i32*]* %nodes, i64 0, i64 %idxprom
+  %3 = load i32*, i32** %arrayidx, align 8
+  %tobool1 = icmp ne i32* %3, null
+  br i1 %tobool1, label %if.then, label %if.end
+
+if.then:  ; preds = %for.body
+  %4 = load i32, i32* %num_active, align 4
+  %dec = add nsw i32 %4, -1
+  store i32 %dec, i32* %num_active, align 4
+  br label %if.end
+
+if.end:   ; preds = %if.then, %for.body
+  br label %for.inc
+
+for.inc:  ; preds = %if.end
+  %5 = load i32, i32* %i, align 4
+  %inc = add nsw i32 %5, 1
+  store i32 %inc, i32* %i, align 4
+  br label %for.cond, !llvm.loop !1
+
+for.end:  ; preds = %for.cond
+  br label %while.cond
+
+while.end:; preds = %while.cond
+  ret void
+}
+
+attributes #0 = { noinline nounwind optnone uwtable }
+
+!llvm.module.flags = !{!0}
+!llvm.ident = !{!1}
+
+!0 = !{i32 1, !"wchar_size", i32 4}
+!1 = distinct !{!1, !2}
+!2 = !{!"llvm.loop.unroll.full"}
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -503,12 +503,13 @@
   LPM2.addPass(LoopDeletionPass());
   // Do not enable unrolling in PreLinkThinLTO phase during sample PGO
   // because it changes IR to makes profile annotation in back compile
-  // inaccurate.
-  if ((Phase != ThinLTOPhase::PreLink || !PGOOpt ||
-   PGOOpt->Action != PGOOptions::SampleUse) &&
-  PTO.LoopUnrolling)
+  // inaccurate. The normal unroller doesn't pay attention to forced full unroll
+  // attributes so we need to make sure and allow 

[PATCH] D79510: [PATCH] When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures

2020-05-06 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79510



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


[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-05-06 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

I also tried to compare the exploded graphs, but unfortunately the rewriter 
Python script crashed on them.


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

https://reviews.llvm.org/D77229



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


[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-06 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

That's actually really interesting.  Is there a paper describing the desired 
model in more detail?

I think the natural interpretation of this pragma is to say that the specific 
operations written within the pragma are considered to be associative and are 
therefore allowed to be re-associated with other associative operators.  
However, that might not be the committee's formal interpretation, given how 
contraction works.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-06 Thread Wei Zhao via Phabricator via cfe-commits
wxz2020 added a comment.

I can confirm your findings, basically as long as we comment out the new 
instructions, it will be OK to build.

Agree with your changes 1), 2) and 3).

4. this seems does not matter to build, as long as we comment out the new 
instructions in 5), setting it "1" or "0", both are OK. they all can be compiled

5. if we comment out these instructions, then we will not be able to schedule 
them efficiently in the instruction scheduler. I know in other models or 
earlier versions, they could be treated as NOP, but in our new machine, they do 
have a timing effect, 7 cycles to finish. Any way to represent this in .md?

Thanks a lot for the help,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129



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


[PATCH] D72281: [Matrix] Add matrix type to Clang.

2020-05-06 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In D72281#2023111 , @fhahn wrote:

> Ah right, thanks for clarifying. I think I managed to fix the remaining 
> problems. Previously the patch did not handle DependentSizedMatrixTypes with 
> non-dependent constant dimensions properly (e.g. a DependentSizedMatrixType 
> could have one dependent and one non-dependent dimension). That's a 
> difference to DependentSizedArrayType. Now the example works as expected 
> (I've etxended it a bit). Cases like the one below are rejected
>
>   template 
>   using matrix = T __attribute__((matrix_type(R, C)));
>   
>   template 
>   void use_matrix(matrix ) {}
>   // expected-note@-1 {{candidate function [with T = float, R = 10]}}
>   
>   template 
>   void use_matrix(matrix ) {}
>   // expected-note@-1 {{candidate function [with T = float, C = 10]}}
>   
>   void test_ambigous_deduction1() {
> matrix m;
> use_matrix(m);
> // expected-error@-1 {{call to 'use_matrix' is ambiguous}}
>   }


Yeah, that looks right to reject.




Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2109
+if (!RowExprTemplateParam || !ColumnExprTemplateParam)
+  return Sema::TDK_Success;
+

fhahn wrote:
> rjmccall wrote:
> > fhahn wrote:
> > > rjmccall wrote:
> > > > You should just do this right.  If you can find a template parameter in 
> > > > the parameter's row/column expression, you have to try to deduce it, 
> > > > and short-circuit if that fails.  Deduction is order-agnostic, so don't 
> > > > worry about that.
> > > > 
> > > > Also, you need to handle DependentSizedMatrixTypes here in order to get 
> > > > function template partial ordering right.  Pattern the code on how 
> > > > DependentSizedArrayTypes would handle it.
> > > Thanks, I've re-structured the code along the lines of the code for 
> > > DependentSizedArrayType
> > Could you extract a lambda helper function that does the common logic for 
> > the rows/columns values?  It's probably cleanest to pass in a rows/cols 
> > flag instead of trying to abstract more than that.
> > 
> > If you do that, you'll also fix the bug where you're using ColumnNTTP in 
> > the rows case. :)
> I wanted to make sure that's the right direction before opening too much time 
> on refactoring :) The fact that we have to use different accessors makes 
> things a bit tricky I think, but I've added a lambda (which takes the 
> accessors as lambdas as well.
> 
Please use `llvm::function_ref` here.  Or you could even use a member function 
pointer, up to you.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2085
+
+  unsigned SubTDF = TDF & TDF_IgnoreQualifiers;
+

Is this ignore-qualifiers thing copied from arrays?  If so, it's probably 
array-specific; qualified array types are a bit odd in the language.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2122
+  return Sema::TDK_NonDeducedMismatch;
+  }
+

I think I see what you're trying to do here, but you're missing a check.  When 
the parameter expression is instantiation-dependent but not directly a 
parameter reference (in the standard: "[a] non-type template argument or an 
array bound in which a subexpression references a template parameter"), this is 
a non-deduced context and shouldn't lead to deduction failure.  You should move 
the `getDeducedParameterFromExpr` call into this helper and then do the logic 
like this:

- If the parameter expression is not instantiation-dependent, then return 
success if the argument expression is non-dependent and evaluates to the same 
constant, otherwise return a mismatch.
- If the parameter expression is not a deducible parameter, then return success 
because this is a non-deduced context.
- Otherwise do the rest of the logic below.

Test case for this is something like `N + 1` as a row/column bound.  You can't 
deduce from that, but you can potentially deduce from other places in the type.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2143
+return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,
+ DimExpr, Info, Deduced);
+} else if (const ConstantMatrixType *ConstantMatrixArg =

I'm curious why this extra check is necessary vs. just calling 
`DeduceNonTypeTemplateArgument` with `DimExpr` unconditionally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D79515: [CUDA] Enable existing builtins for PTX7.0 as well.

2020-05-06 Thread Artem Belevich via Phabricator via cfe-commits
tra created this revision.
tra added a reviewer: timshen.
Herald added subscribers: sanjoy.google, bixia, yaxunl, jholewinski.
Herald added a project: clang.

I've missed PXT7.0 in D79449 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79515

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -3,7 +3,7 @@
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
-// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -3,7 +3,7 @@
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
-// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-fcuda-is-device -target-feature +ptx70 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -34,7 +34,9 @@
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
 #pragma push_macro("PTX65")
-#define PTX65 "ptx65"
+#pragma push_macro("PTX70")
+#define PTX70 "ptx70"
+#define PTX65 "ptx65|" PTX70
 #define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
@@ -731,3 +733,4 @@
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
 #pragma pop_macro("PTX65")
+#pragma pop_macro("PTX70")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] dc4e25d - [CodeGen][ObjC] Don't try to retain a __unsafe_unretained ARC pointer

2020-05-06 Thread Akira Hatanaka via cfe-commits

Author: Akira Hatanaka
Date: 2020-05-06T12:47:17-07:00
New Revision: dc4e25d4f238afb171aacb3774e1162c69574a0a

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

LOG: [CodeGen][ObjC] Don't try to retain a __unsafe_unretained ARC pointer
passed to __builtin_os_log_format to extend its lifetime to the end of
its enclosing block

Extend only lifetimes of pointers returned by function calls or message
sends instead. In the long term, we should lifetime-extend pointers in
more complex expressions and non-ARC objects (e.g., C++ temporaries)
too.

rdar://problem/61846261

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGenObjC/os_log.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index f5530aac6085..112a0ee7752f 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -1340,13 +1340,24 @@ RValue CodeGenFunction::emitBuiltinOSLogFormat(const 
CallExpr ) {
 } else if (const Expr *TheExpr = Item.getExpr()) {
   ArgVal = EmitScalarExpr(TheExpr, /*Ignore*/ false);
 
-  // If this is a retainable type, push a lifetime-extended cleanup to
-  // ensure the lifetime of the argument is extended to the end of the
-  // enclosing block scope.
-  // FIXME: We only have to do this if the argument is a temporary, which
-  //gets released after the full expression.
+  // If a temporary object that requires destruction after the full
+  // expression is passed, push a lifetime-extended cleanup to extend its
+  // lifetime to the end of the enclosing block scope.
+  auto LifetimeExtendObject = [&](const Expr *E) {
+E = E->IgnoreParenCasts();
+// Extend lifetimes of objects returned by function calls and message
+// sends.
+
+// FIXME: We should do this in other cases in which temporaries are
+//created including arguments of non-ARC types (e.g., C++
+//temporaries).
+if (isa(E) || isa(E))
+  return true;
+return false;
+  };
+
   if (TheExpr->getType()->isObjCRetainableType() &&
-  getLangOpts().ObjCAutoRefCount) {
+  getLangOpts().ObjCAutoRefCount && LifetimeExtendObject(TheExpr)) {
 assert(getEvaluationKind(TheExpr->getType()) == TEK_Scalar &&
"Only scalar can be a ObjC retainable type");
 if (!isa(ArgVal)) {

diff  --git a/clang/test/CodeGenObjC/os_log.m b/clang/test/CodeGenObjC/os_log.m
index 4e70ef3e7574..6f9db76dcc9e 100644
--- a/clang/test/CodeGenObjC/os_log.m
+++ b/clang/test/CodeGenObjC/os_log.m
@@ -9,6 +9,11 @@
 
 // rdar://problem/24528966
 
+@interface C
+- (id)m0;
++ (id)m1;
+@end
+
 @class NSString;
 extern __attribute__((visibility("default"))) NSString *GenString();
 
@@ -53,10 +58,10 @@
   // CHECK-O0: %[[V1:.*]] = bitcast %[[TY0]]* %[[CALL]] to i8*
   // CHECK-O0: %[[V2:.*]] = notail call i8* 
@llvm.objc.retainAutoreleasedReturnValue(i8* %[[V1]])
   // CHECK-O0: %[[V3:.*]] = bitcast i8* %[[V2]] to %[[TY0]]*
-  // CHECK-O0: %[[V4:.*]] = bitcast %0* %[[V3]] to i8*
+  // CHECK-O0: %[[V4:.*]] = bitcast %{{.*}}* %[[V3]] to i8*
   // CHECK-O0: %[[V5:.*]] = call i8* @llvm.objc.retain(i8* %[[V4]])
-  // CHECK-O0: %[[V6:.*]] = bitcast i8* %[[V5]] to %0*
-  // CHECK-O0: %[[V7:.*]] = ptrtoint %0* %[[V6]] to i64
+  // CHECK-O0: %[[V6:.*]] = bitcast i8* %[[V5]] to %{{.*}}*
+  // CHECK-O0: %[[V7:.*]] = ptrtoint %{{.*}}* %[[V6]] to i64
   // CHECK-O0: call void @__os_log_helper_1_2_1_8_64(i8* %[[V0]], i64 %[[V7]])
   // CHECK-O0: %[[V5:.*]] = bitcast %[[TY0]]* %[[V3]] to i8*
   // CHECK-O0-NOT: call void (...) @llvm.objc.clang.arc.use({{.*}}
@@ -94,8 +99,7 @@
 // CHECK-NEWPM: %[[V2:.*]] = notail call i8* 
@llvm.objc.retainAutoreleasedReturnValue(i8* %[[V1]])
 // CHECK-NEWPM: %[[V3:.*]] = tail call i8* @llvm.objc.retain(i8* %[[V2]])
 // CHECK-NEWPM: %[[V4:.*]] = ptrtoint i8* %[[V3]] to i64
-// CHECK-NEWPM: %[[V5:.*]] = tail call i8* @llvm.objc.retain(i8* %[[V0]])
-// CHECK-NEWPM: %[[V6:.*]] = ptrtoint i8* %[[V5]] to i64
+// CHECK-NEWPM: %[[V6:.*]] = ptrtoint i8* %[[V0]] to i64
 // CHECK-NEWPM: %[[ARGDATA_I:.*]] = getelementptr i8, i8* %[[BUF]], i64 4
 // CHECK-NEWPM: %[[ARGDATACAST_I:.*]] = bitcast i8* %[[ARGDATA_I]] to i64*
 // CHECK-NEWPM: store i64 %[[V4]], i64* %[[ARGDATACAST_I]], align 1
@@ -104,8 +108,6 @@
 // CHECK-NEWPM: store i64 %[[V6]], i64* %[[ARGDATACAST4_I]], align 1
 // CHECK-NEWPM: tail call void @llvm.objc.release(i8* %[[V2]])
 // CHECK-NEWPM: tail call void @os_log_pack_send(i8* nonnull %[[BUF]])
-// CHECK-NEWPM: tail call void (...) @llvm.objc.clang.arc.use(i8* %[[V5]])
-// CHECK-NEWPM: tail call void @llvm.objc.release(i8* %[[V5]])
 // CHECK-NEWPM: tail call void (...) 

[PATCH] D78869: clang-format: Add ControlStatementsExceptForEachMacros option to SpaceBeforeParens

2020-05-06 Thread Daan De Meyer via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf21c704553a8: clang-format: Add 
ControlStatementsExceptForEachMacros option to… (authored by DaanDeMeyer).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78869

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -972,6 +972,17 @@
"  UNKNOWN_FORACH(Item * item, itemlist) {}\n"
"}");
 
+  FormatStyle Style = getLLVMStyle();
+  Style.SpaceBeforeParens =
+  FormatStyle::SBPO_ControlStatementsExceptForEachMacros;
+  verifyFormat("void f() {\n"
+   "  foreach(Item *item, itemlist) {}\n"
+   "  Q_FOREACH(Item *item, itemlist) {}\n"
+   "  BOOST_FOREACH(Item *item, itemlist) {}\n"
+   "  UNKNOWN_FORACH(Item * item, itemlist) {}\n"
+   "}",
+   Style);
+
   // As function-like macros.
   verifyFormat("#define foreach(x, y)\n"
"#define Q_FOREACH(x, y)\n"
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2900,6 +2900,10 @@
 if ((Left.is(tok::r_paren) && Left.is(TT_AttributeParen)) ||
 (Left.is(tok::r_square) && Left.is(TT_AttributeSquare)))
   return true;
+if (Style.SpaceBeforeParens ==
+FormatStyle::SBPO_ControlStatementsExceptForEachMacros &&
+Left.is(TT_ForEachMacro))
+  return false;
 return Line.Type == LT_ObjCDecl || Left.is(tok::semi) ||
(Style.SpaceBeforeParens != FormatStyle::SBPO_Never &&
 (Left.isOneOf(tok::pp_elif, tok::kw_for, tok::kw_while,
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -329,6 +329,8 @@
 IO.enumCase(Value, "Never", FormatStyle::SBPO_Never);
 IO.enumCase(Value, "ControlStatements",
 FormatStyle::SBPO_ControlStatements);
+IO.enumCase(Value, "ControlStatementsExceptForEachMacros",
+FormatStyle::SBPO_ControlStatementsExceptForEachMacros);
 IO.enumCase(Value, "NonEmptyParentheses",
 FormatStyle::SBPO_NonEmptyParentheses);
 IO.enumCase(Value, "Always", FormatStyle::SBPO_Always);
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1983,6 +1983,17 @@
 ///}
 /// \endcode
 SBPO_ControlStatements,
+/// Same as ``SBPO_ControlStatements`` except this option doesn't apply to
+/// ForEach macros. This is useful in projects where ForEach macros are 
+/// treated as function calls instead of control statements. 
+/// \code
+///void f() {
+///  Q_FOREACH(...) {
+///f();
+///  }
+///}
+/// \endcode
+SBPO_ControlStatementsExceptForEachMacros,
 /// Put a space before opening parentheses only if the parentheses are not
 /// empty i.e. '()'
 /// \code
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -2336,6 +2336,19 @@
  }
}
 
+  * ``SBPO_ControlStatementsExceptForEachMacros`` (in configuration: 
``ControlStatementsExceptForEachMacros``)
+Same as ``SBPO_ControlStatements`` except this option doesn't apply to
+ForEach macros. This is useful in projects where ForEach macros are
+treated as function calls instead of control statements.
+
+.. code-block:: c++
+
+   void f() {
+ Q_FOREACH(...) {
+   f();
+ }
+   }
+
   * ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
 Put a space before opening parentheses only if the parentheses are not
 empty i.e. '()'


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -972,6 +972,17 @@
"  UNKNOWN_FORACH(Item * item, itemlist) {}\n"
"}");
 
+  FormatStyle Style = getLLVMStyle();
+  Style.SpaceBeforeParens =
+  FormatStyle::SBPO_ControlStatementsExceptForEachMacros;
+  verifyFormat("void f() {\n"
+   "  foreach(Item *item, itemlist) {}\n"
+   "  

[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-06 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

BTW there is a proposal 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2421.pdf at the ISO C meeting 
to support some new floating point pragmas including 
#pragma STDC FENV_ALLOW_ASSOCIATIVE_LAW on-off-switch
The committee wants to see an implementation(s) to ensure that it's viable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-05-06 Thread Kalle Huttunen via Phabricator via cfe-commits
khuttun added a comment.

Any comments on this? Is this checker something that could be part of 
clang-tidy?


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

https://reviews.llvm.org/D46317



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


[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

2020-05-06 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

I posted a patch to fix the bug reported by @uabelho here 
https://reviews.llvm.org/D79510

@rjmccall I used check-clang and check-all on D71841 
 from my linux x86-64 server before 
submitting, and the testing was clear. Maybe your branch has some calls to 
create BinaryOperator that isn't passing FPFeatures with the correct 
value--related to D76384 .  My sandbox is 
showing this

  %add = fadd nsz float %0, %1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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


[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

2020-05-06 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added a comment.

I think we should never break apart the two `[[` and `]]` of attributes.
Running that example with `-debug` shows that we consider breaking between the 
two `[` tokens a valid possibility.

- `C=1` means breaking before the token is OK, which is probably computed by 
`TokenAnnotator::canBreakBefore`:

  % bin/clang-format -debug ~/test.cc
  Line(0, FSC=0): void[T=85, OC=0] identifier[T=85, OC=5] coloncolon[T=85, 
OC=22] identifier[T=85, OC=24] l_paren[T=85, OC=50] l_square[T=85, OC=51] 
l_square[T=85, OC=52] identifier[T=85, OC=53] r_square[T=85, OC=65] 
r_square[T=85, OC=66] const[T=85, OC=68] identifier[T=85, OC=74] less[T=85, 
OC=84] identifier[T=85, OC=85] greater[T=85, OC=98] amp[T=85, OC=99] 
identifier[T=85, OC=101] identifier[T=85, OC=51] r_paren[T=85, OC=59] 
l_brace[T=21, OC=61] 
  Line(0, FSC=0): r_brace[T=85, OC=0] 
  Line(0, FSC=0): eof[T=85, OC=0] 
  Run 0...
  AnnotatedTokens(L=0):
   M=0 C=0 T=Unknown S=1 B=0 BK=0 P=0 Name=void L=4 PPK=2 FakeLParens= 
FakeRParens=0 II=0x219c910 Text='void'
   M=0 C=1 T=FunctionDeclarationName S=1 B=0 BK=0 P=80 Name=identifier L=22 
PPK=2 FakeLParens= FakeRParens=0 II=0x21d8210 Text='SomeLongClassName'
   M=0 C=0 T=Unknown S=0 B=0 BK=0 P=23 Name=coloncolon L=24 PPK=2 FakeLParens= 
FakeRParens=0 II=0x0 Text='::'
   M=0 C=1 T=Unknown S=0 B=0 BK=0 P=520 Name=identifier L=50 PPK=2 FakeLParens= 
FakeRParens=0 II=0x21d8258 Text='ALongMethodNameInThatClass'
   M=0 C=0 T=Unknown S=0 B=0 BK=0 P=23 Name=l_paren L=51 PPK=1 FakeLParens= 
FakeRParens=0 II=0x0 Text='('
   M=0 C=1 T=AttributeSquare S=0 B=0 BK=0 P=140 Name=l_square L=52 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text='['
   M=0 C=1 T=AttributeSquare S=0 B=0 BK=0 P=79 Name=l_square L=53 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text='['
   M=0 C=0 T=Unknown S=0 B=0 BK=0 P=99 Name=identifier L=65 PPK=2 FakeLParens= 
FakeRParens=0 II=0x21d8290 Text='maybe_unused'
   M=0 C=0 T=AttributeSquare S=0 B=0 BK=0 P=83 Name=r_square L=66 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text=']'
   M=0 C=0 T=AttributeSquare S=0 B=0 BK=0 P=63 Name=r_square L=67 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text=']'
   M=0 C=0 T=Unknown S=1 B=0 BK=0 P=43 Name=const L=73 PPK=2 FakeLParens= 
FakeRParens=0 II=0x219c3e8 Text='const'
   M=0 C=0 T=Unknown S=1 B=0 BK=0 P=43 Name=identifier L=84 PPK=2 FakeLParens= 
FakeRParens=0 II=0x21d82c8 Text='shared_ptr'
   M=0 C=0 T=TemplateOpener S=0 B=0 BK=0 P=50 Name=less L=85 PPK=2 FakeLParens= 
FakeRParens=0 II=0x0 Text='<'
   M=0 C=1 T=Unknown S=0 B=0 BK=0 P=380 Name=identifier L=98 PPK=2 FakeLParens= 
FakeRParens=0 II=0x21d8300 Text='ALongTypeName'
   M=0 C=0 T=TemplateCloser S=0 B=0 BK=0 P=290 Name=greater L=99 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text='>'
   M=0 C=1 T=PointerOrReference S=1 B=0 BK=0 P=230 Name=amp L=101 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text='&'
   M=0 C=1 T=StartOfName S=0 B=0 BK=0 P=240 Name=identifier L=120 PPK=2 
FakeLParens= FakeRParens=0 II=0x21d8340 Text='argumentNameForThat'
   M=0 C=1 T=StartOfName S=1 B=0 BK=0 P=150 Name=identifier L=129 PPK=2 
FakeLParens= FakeRParens=0 II=0x21d8378 Text='LongType'
   M=0 C=0 T=Unknown S=0 B=0 BK=0 P=43 Name=r_paren L=130 PPK=2 FakeLParens= 
FakeRParens=0 II=0x0 Text=')'
   M=0 C=0 T=FunctionLBrace S=1 B=0 BK=1 P=23 Name=l_brace L=132 PPK=2 
FakeLParens= FakeRParens=0 II=0x0 Text='{'
  

You could adapt that code to not break before the second `TT_AttributeSquare` 
in `[[` or `]]`; this will have the same effect and generalize.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79401



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


[PATCH] D78869: clang-format: Add ControlStatementsExceptForEachMacros option to SpaceBeforeParens

2020-05-06 Thread Daan De Meyer via Phabricator via cfe-commits
DaanDeMeyer added a comment.

I pushed the commit to github. Thanks for the help!


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

https://reviews.llvm.org/D78869



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


[PATCH] D79496: [clangd] Fix AddUsing tweak for out-of-line functions.

2020-05-06 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

thanks.




Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:2673
+void foo::fun() {
+  one::two::f^f();
+})cpp",

IIUC, before this patch, the using was added inside the above namespace `foo`, 
the code was still valid after applying the tweak.

There is no enclosing namespace for `foo::fun()`, so we will insert the using 
at the first top-level decl. It seems that we will break the code if the 
`one::two::ff` decl is defined in the main file (not the `test.hpp`), e.g.

```
// using one::two::ff will be inserted here, which is not valid
namespace one {
namespace two {
void ff();
}
}

namespace foo { void fun(); }
void foo::fun() {...}
```

this case was working before the patch, and now is broken after this patch. It 
is not a common case, probably ok for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79496



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


[PATCH] D78933: [analyzer] RangeConstraintManager optimizations in comparison expressions

2020-05-06 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:588
+  // AnyX2 means that two expressions marked as `Any` are met in code,
+  // and there is a special column for that, for example:
+  // if (x >= y)

ASDenysPetrov wrote:
> xazax.hun wrote:
> > xazax.hun wrote:
> > > ASDenysPetrov wrote:
> > > > xazax.hun wrote:
> > > > > I have really hard time processing how to interpret `AnyX2`.
> > > > > 
> > > > > For example in the code below:
> > > > > ```
> > > > >if (x >= y)
> > > > >  if (x != y)
> > > > >if (x <= y)
> > > > >  return false
> > > > > ```
> > > > > 
> > > > > ```
> > > > >if (x >= y)
> > > > >  if (x == y)
> > > > >if (x <= y)
> > > > >  return true
> > > > > ```
> > > > > 
> > > > > We would get different results for `<=`. So I do not really get how I 
> > > > > should read the `AnyX2` column.
> > > > I'm sorry for the obscure explanation. I was really thinking about how 
> > > > to explain it more clear.
> > > > Let's consider this code:
> > > > ```
> > > > if (x >= y)
> > > >   if (x != y)
> > > > if (x <= y)
> > > > ```
> > > > If 'x >= y' is //true//, then following `x <= y` is  `Any` ( can be 
> > > > //true// or //false// ). //See table in the summary.//
> > > > If 'x != y' is //true//, then following `x <= y` is  `Any` ( can be 
> > > > //true// or //false// ).
> > > > If 'x >= y && x != y' is //true//, then following `x <= y` is `False` 
> > > > only (it means that we previously met two Any states, what I've called 
> > > > as **AnyX2**).
> > > > 
> > > > 
> > > > 
> > > > 
> > > Could you tell me how the reasoning would be different for 
> > > ```
> > > if (x >= y)
> > >   if (x == y)
> > > if (x <= y)
> > > ```
> > > ?
> > Oh never mind, after `x == y` the `x <= y` would be `true`. But still, I 
> > find this logic hard to explain, understand, and prove correct.
> > I'd like to see at least some informal reasoning why will it always work. 
> > Also, if someone would like to extend this table in the future (e.g. with 
> > operator <=>), how to make it in such a way that does not break this logic.
> When I was creating a table it was just 6x6 without AnyX2 column. It should 
> tell of what RangeSet we shall return (true, false or empty). It covers cases 
> with only **one** preceding condition.
> Then I found that **two** certain sequential conditions can also tell us what 
> happen to the next condition. And those two conditions happened to be 
> described as `Any` in the table. Thus I deduced one more column for this 
> purpose.
> In other words:
> ```
> if (x >= y) // 3. Aha, we found `x >= y`, which is also `Any` for `x <= 
> y` in the table
>   if (x != y)   // 2. Aha, we found `x == y`, which is `Any` for `x <= y` in 
> the table
> if (x <= y) // 1. Reasoning a RangeSet about this `x <= y`
> // 4. OK, we found two `Any` states. Let's look at the value in `AnyX2` 
> column for `x <= y`.
> // 5. The value is `False`, so return `FalseRangeSet`, assuming CSA 
> builds false branch only.
> ```
> You can substitute any other row from the table and corresponding 
> Any-comparisons.
> Honestly, I don’t know how else to explain this. :)
> >I find this logic hard to explain, understand, and prove correct.
> If you come up with it, It becomes really easy and clear. You'll see. But I 
> agree that AnyX2 can be changed to something more obvious.
Ok, in the meantime I revisited the algorithm and I think now I understand why 
does it work.
I think the main observation I missed was the following:  **Every row has 
exactly two `Any` entries, so we only need to think about one combination per 
row.** I think originally I interpreted your matrix wrong (the transposed one) 
and it did not really add up.
So I think you should document the fact that each row has exactly two unknown 
cases. But for each of the rows, if we have both facts, we can actually 
evaluate the current operator.

The goal is that if someone wants to extend this code later on (e.g. if the 
standard committee introduces a new operator that we handle), the next person 
should be able to modify this algorithm without breaking the existing code. So 
as you can see, adding a new column/row could break this invariant of having 
exactly 2 unknowns in each row rendering this code incorrect. This is why it is 
important, to explain what makes the algorithm work.

I might miss something, but I do not really see test cases that are covering 
these.

I think some renaming might also help others understanding what is going on:
1) Capitalize variable names, for example, `tristate`.
2) Chose a bit more descriptive names. `tristate` from the previous example 
describes the type of the variable. But variable names should describe their 
contents rather than their type. It can be `Result` in case it describes the 
result of the operation. I think in 3-valued logic we tend to use `Unknown` 

[PATCH] D66831: [ObjC] Fix type checking for qualified id block parameters.

2020-05-06 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added a comment.

Patch for the suggested compatibility flag is available at 
https://reviews.llvm.org/D79511


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66831



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


[PATCH] D79510: [PATCH] When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures

2020-05-06 Thread Melanie Blower via Phabricator via cfe-commits
mibintc marked 2 inline comments as done.
mibintc added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:111
   PP.Diag(Tok, diag::warn_stdc_fenv_access_not_supported);
+  return;
 }

Modified this to return instead of making changes which will ultimately modify 
the floating point state



Comment at: clang/test/CodeGen/fp-floatcontrol-pragma.cpp:61
+  z = z * z;
+//CHECK: = fmul float
+}

I used a modified version of @uabelho 's test. I verified that before this bug 
fix a constrained intrinsic was being created for this multiply.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79510



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


[PATCH] D79504: [Clang] Wrong return type of atomic_is_lock_free

2020-05-06 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

In D79504#2023274 , @rsmith wrote:

> Clang's `` uses the builtin as follows:
>
>   #define atomic_is_lock_free(obj) __c11_atomic_is_lock_free(sizeof(*(obj)))
>
>
> ... which, combined with the builtin returning `int`, results in a call 
> having the wrong type. So there's definitely a bug *somewhere*.
>
> I think what happened here is: the return type of the GCC 
> `__atomic_is_lock_free` / `__atomic_always_lock_free` builtins was `int` in 
> GCC 4.6 and earlier, and changed to `_Bool` in GCC 4.7 and later. Clang's 
> implementation followed GCC's behavior at the time, so returned `int`, and 
> no-one noticed that GCC changed its behavior in version 4.7. So we still 
> provide the old GCC behavior.
>
> Then, when `__c11_atomic_is_lock_free` was added, it got an `int` return type 
> as (I think) a copy-paste error. The `__c11` builtins are intended to exactly 
> match the semantics of the C11 atomic functions, so this was always wrong.
>
> I think we should make this change, to all three affected builtin functions.


This sounds sensible to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79504



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


[PATCH] D79186: [OPENMP]Consider 'omp_null_allocator' as a predefined allocator.

2020-05-06 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.

LGTM.

In D79186#2016893 , @ABataev wrote:

> In D79186#2016737 , @jdoerfert wrote:
>
> > In D79186#2013689 , @ABataev wrote:
> >
> > > In D79186#2013603 , @jdoerfert 
> > > wrote:
> > >
> > > > What would you think about moving the allocator definitions to 
> > > > OMPKinds.def instead of listing them explicitly? As far as I can tell 
> > > > we really only distinguish between predefined and user allocators, 
> > > > right?
> > >
> > >
> > > They also are used to find the base type 'omp_allocator_handle_t`. Also, 
> > > what do you mean saying `instead of listing them explicitly`? Anyway, you 
> > > will need to list all the predefined allocators to be able to distinguish 
> > > predefined and user-defined allocators.
> >
> >
> > Sure. But we can list them once in OMPKinds.def and the use a macro 
> > wherever we need all their names (or other information).
>
>
> It should be a different patch.


Sure. You want to look into this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79186



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


[PATCH] D79511: [ObjC] Add compatibility mode for type checking of qualified id block parameters.

2020-05-06 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai created this revision.
vsapsai added reviewers: arphaman, dexonsmith.
Herald added subscribers: ributzka, jkorous.
Herald added a project: clang.

Commit 73152a2ec20766ac45673a129bf1f5fc97ca9bbe fixed type checking for
blocks with qualified id parameters. But there are existing APIs in
Apple SDKs relying on the old type checking behavior. Specifically,
these are APIs using NSItemProviderCompletionHandler in
Foundation/NSItemProvider.h. To keep existing code working and to allow
developers to use affected APIs introduce a compatibility mode that
enables the previous type checking. This mode is enabled only on Darwin
platforms.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79511

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/CC1Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/darwin-objc-options.m
  clang/test/SemaObjC/block-type-safety.m

Index: clang/test/SemaObjC/block-type-safety.m
===
--- clang/test/SemaObjC/block-type-safety.m
+++ clang/test/SemaObjC/block-type-safety.m
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -fblocks -Wno-objc-root-class %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -Wno-objc-root-class \
+// RUN:   -fcompatibility-qualified-id-block-type-checking -DCOMPATIBILITY_QUALIFIED_ID_TYPE_CHECKING=1 %s
 // test for block type safety.
 
 @interface Super  @end
@@ -132,6 +134,7 @@
 @interface NSAllArray (FooConformance) 
 @end
 
+#ifndef COMPATIBILITY_QUALIFIED_ID_TYPE_CHECKING
 int test5() {
 // Returned value is used outside of a block, so error on changing
 // a return type to a more general than expected.
@@ -149,6 +152,25 @@
 blockWithParam = genericBlockWithParam;
 return 0;
 }
+#else
+// In Apple SDK APIs using NSItemProviderCompletionHandler require to work with
+// blocks that have parameters more specific than in method signatures. As
+// explained in non-compatibility test above, it is not safe in general. But
+// to keep existing code working we support a compatibility mode that uses
+// previous type checking.
+int test5() {
+NSAllArray *(^block)(id);
+id  (^genericBlock)(id);
+genericBlock = block;
+block = genericBlock; // expected-error {{incompatible block pointer types assigning to 'NSAllArray *(^)(id)' from 'id (^)(id)'}}
+
+void (^blockWithParam)(NSAllArray *);
+void (^genericBlockWithParam)(id);
+genericBlockWithParam = blockWithParam;
+blockWithParam = genericBlockWithParam; // expected-error {{incompatible block pointer types assigning to 'void (^)(NSAllArray *)' from 'void (^)(id)'}}
+return 0;
+}
+#endif
 
 // rdar://10798770
 typedef int NSInteger;
Index: clang/test/Driver/darwin-objc-options.m
===
--- clang/test/Driver/darwin-objc-options.m
+++ clang/test/Driver/darwin-objc-options.m
@@ -40,3 +40,9 @@
 
 // Don't crash with an unexpected target triple.
 // RUN: %clang -target i386-apple-ios7 -S -### %s
+
+// Add -fcompatibility-qualified-id-block-type-checking only on Darwin.
+// RUN: %clang -target x86_64-apple-darwin10 -### %s 2>&1 | FileCheck --check-prefix=DARWIN_COMPATIBILITY %s
+// RUN: %clang -target x86_64-linux-gnu -### %s 2>&1 | FileCheck --check-prefix=OTHER_COMPATIBILITY %s
+// DARWIN_COMPATIBILITY: -fcompatibility-qualified-id-block-type-checking
+// OTHER_COMPATIBILITY-NOT: -fcompatibility-qualified-id-block-type-checking
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3371,6 +3371,9 @@
   }
 
   Opts.BranchTargetEnforcement = Args.hasArg(OPT_mbranch_target_enforce);
+
+  Opts.CompatibilityQualifiedIdBlockParamTypeChecking =
+  Args.hasArg(OPT_fcompatibility_qualified_id_block_param_type_checking);
 }
 
 static bool isStrictlyPreprocessorAction(frontend::ActionKind Action) {
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2374,6 +2374,10 @@
 OS << "-target-sdk-version=" << SDKInfo->getVersion();
 CC1Args.push_back(DriverArgs.MakeArgString(OS.str()));
   }
+
+  // Enable compatibility mode for NSItemProviderCompletionHandler in
+  // Foundation/NSItemProvider.h.
+  CC1Args.push_back("-fcompatibility-qualified-id-block-type-checking");
 }
 
 DerivedArgList *
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -8499,10 +8499,14 @@
   RHSOPT->isObjCQualifiedIdType());
   }
 
-  if (LHSOPT->isObjCQualifiedIdType() || 

[clang] f21c704 - clang-format: Add ControlStatementsExceptForEachMacros option to SpaceBeforeParens

2020-05-06 Thread Daan De Meyer via cfe-commits

Author: Daan De Meyer
Date: 2020-05-06T20:59:24+02:00
New Revision: f21c704553a8af7012eaf1ab777e2aa1a55cc86d

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

LOG: clang-format: Add ControlStatementsExceptForEachMacros option to 
SpaceBeforeParens

Summary: systemd recently added a clang-format file. One issue I
encountered in using clang-format on systemd is that systemd does
not add a space before the parens of their foreach macros but
clang-format always adds a space. This does not seem to be
configurable in clang-format. This revision adds the
ControlStatementsExceptForEachMacros option to SpaceBeforeParens
which puts a space before all control statement parens except
ForEach macros. This drastically reduces the amount of changes
when running clang-format on systemd's source code.

Reviewers: MyDeveloperDay, krasimir, mitchell-stellar

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang-format, #clang

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index ce26b06bf171..3ea503a592ac 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -2336,6 +2336,19 @@ the configuration (without a prefix: ``Auto``).
  }
}
 
+  * ``SBPO_ControlStatementsExceptForEachMacros`` (in configuration: 
``ControlStatementsExceptForEachMacros``)
+Same as ``SBPO_ControlStatements`` except this option doesn't apply to
+ForEach macros. This is useful in projects where ForEach macros are
+treated as function calls instead of control statements.
+
+.. code-block:: c++
+
+   void f() {
+ Q_FOREACH(...) {
+   f();
+ }
+   }
+
   * ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
 Put a space before opening parentheses only if the parentheses are not
 empty i.e. '()'

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 011cf599d526..f8f2903dde57 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -1983,6 +1983,17 @@ struct FormatStyle {
 ///}
 /// \endcode
 SBPO_ControlStatements,
+/// Same as ``SBPO_ControlStatements`` except this option doesn't apply to
+/// ForEach macros. This is useful in projects where ForEach macros are 
+/// treated as function calls instead of control statements. 
+/// \code
+///void f() {
+///  Q_FOREACH(...) {
+///f();
+///  }
+///}
+/// \endcode
+SBPO_ControlStatementsExceptForEachMacros,
 /// Put a space before opening parentheses only if the parentheses are not
 /// empty i.e. '()'
 /// \code

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 961cb92ebd40..1fd7d613f9fb 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -329,6 +329,8 @@ struct 
ScalarEnumerationTraits {
 IO.enumCase(Value, "Never", FormatStyle::SBPO_Never);
 IO.enumCase(Value, "ControlStatements",
 FormatStyle::SBPO_ControlStatements);
+IO.enumCase(Value, "ControlStatementsExceptForEachMacros",
+FormatStyle::SBPO_ControlStatementsExceptForEachMacros);
 IO.enumCase(Value, "NonEmptyParentheses",
 FormatStyle::SBPO_NonEmptyParentheses);
 IO.enumCase(Value, "Always", FormatStyle::SBPO_Always);

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 734dbdc1b6f3..408f68e35418 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -2900,6 +2900,10 @@ bool TokenAnnotator::spaceRequiredBetween(const 
AnnotatedLine ,
 if ((Left.is(tok::r_paren) && Left.is(TT_AttributeParen)) ||
 (Left.is(tok::r_square) && Left.is(TT_AttributeSquare)))
   return true;
+if (Style.SpaceBeforeParens ==
+FormatStyle::SBPO_ControlStatementsExceptForEachMacros &&
+Left.is(TT_ForEachMacro))
+  return false;
 return Line.Type == LT_ObjCDecl || Left.is(tok::semi) ||
(Style.SpaceBeforeParens != FormatStyle::SBPO_Never &&
 (Left.isOneOf(tok::pp_elif, tok::kw_for, tok::kw_while,

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 9fdf2e728472..aba209b4252d 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -972,6 +972,17 @@ 

[PATCH] D79510: [PATCH] When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures

2020-05-06 Thread Melanie Blower via Phabricator via cfe-commits
mibintc created this revision.
mibintc added reviewers: uabelho, rjmccall, erichkeane.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Bug reported by @uabelho against reviews.llvm.org/D72841 

pragma STDC FENV_ACCESS ON is ignored, but the floating point state maintained 
in Sema.CurFPFeatures was modified to show that
fenv_access was enabled, this caused llvm constrained intrinsics to be created 
which is erroneous. This is a small patch to avoid modifying the state.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79510

Files:
  clang/lib/Parse/ParsePragma.cpp
  clang/test/CodeGen/fp-floatcontrol-pragma.cpp
  clang/test/Parser/fp-floatcontrol-syntax.cpp


Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -30,14 +30,15 @@
 //  document the warning
 #ifdef FAST
 // expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring 
pragma}}
-#pragma STDC FENV_ACCESS ON // expected-error{{'#pragma STDC FENV_ACCESS ON' 
is illegal when precise is disabled}}
+#pragma STDC FENV_ACCESS ON
 #else
 #pragma STDC FENV_ACCESS ON // expected-warning{{pragma STDC FENV_ACCESS ON is 
not supported, ignoring pragma}}
 #endif
 #ifdef STRICT
 #pragma float_control(precise, off) // expected-error {{'#pragma 
float_control(precise, off)' is illegal when except is enabled}}
 #else
-#pragma float_control(precise, off) // expected-error {{'#pragma 
float_control(precise, off)' is illegal when fenv_access is enabled}}
+// Currently FENV_ACCESS cannot be enabled by pragma, skip error check
+#pragma float_control(precise, off) // not-expected-error {{'#pragma 
float_control(precise, off)' is illegal when fenv_access is enabled}}
 #endif
 
 #pragma float_control(precise, on)
Index: clang/test/CodeGen/fp-floatcontrol-pragma.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-pragma.cpp
+++ clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -verify -DFENV_ON=1 -triple x86_64-linux-gnu -emit-llvm -o 
- %s | FileCheck %s
 
 float fff(float x, float y) {
 // CHECK-LABEL: define float @_Z3f{{.*}}
@@ -38,6 +39,7 @@
   }
   return z;
 }
+
 float fma_test1(float a, float b, float c) {
 // CHECK-LABEL define float @_Z9fma_test1fff{{.*}}
 #pragma float_control(precise, on)
@@ -45,3 +47,16 @@
   //CHECK: fmuladd
   return x;
 }
+
+#if FENV_ON
+// expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring 
pragma}}
+#pragma STDC FENV_ACCESS ON
+#endif
+// CHECK-LABEL: define {{.*}}callt{{.*}}
+
+void callt()
+{
+  volatile float z;
+  z = z * z;
+//CHECK: = fmul float
+}
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -108,6 +108,7 @@
  return;
 if (OOS == tok::OOS_ON) {
   PP.Diag(Tok, diag::warn_stdc_fenv_access_not_supported);
+  return;
 }
 
 MutableArrayRef 
Toks(PP.getPreprocessorAllocator().Allocate(1),


Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -30,14 +30,15 @@
 //  document the warning
 #ifdef FAST
 // expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
-#pragma STDC FENV_ACCESS ON // expected-error{{'#pragma STDC FENV_ACCESS ON' is illegal when precise is disabled}}
+#pragma STDC FENV_ACCESS ON
 #else
 #pragma STDC FENV_ACCESS ON // expected-warning{{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
 #endif
 #ifdef STRICT
 #pragma float_control(precise, off) // expected-error {{'#pragma float_control(precise, off)' is illegal when except is enabled}}
 #else
-#pragma float_control(precise, off) // expected-error {{'#pragma float_control(precise, off)' is illegal when fenv_access is enabled}}
+// Currently FENV_ACCESS cannot be enabled by pragma, skip error check
+#pragma float_control(precise, off) // not-expected-error {{'#pragma float_control(precise, off)' is illegal when fenv_access is enabled}}
 #endif
 
 #pragma float_control(precise, on)
Index: clang/test/CodeGen/fp-floatcontrol-pragma.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-pragma.cpp
+++ clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -verify -DFENV_ON=1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
 
 float fff(float x, float y) {
 // CHECK-LABEL: define float 

[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-05-06 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware marked an inline comment as done.
baloghadamsoftware added a comment.

F11870916: correct.txt 

F11870922: incorrect.txt 

See the difference between the correct (master branch) and the incorrect (my 
attempt) outputs.




Comment at: clang/lib/StaticAnalyzer/Core/Store.cpp:472
+  break;
+}
+

Probably this loop could be written better, without `break` at the end, but for 
now it des what it should do. For captured parameters of functions and blocks 
we must look for the original `CallExpr` and `LocationContext`. If it does not 
exist (we analyze the block of the lambda top-level) we revert to `VarRegion` 
since the captured parameters are simple variales for the block or lambda. 
However, we cannot do this if the block or lambda is not analyzed top-level, 
thus the approach I use above seems to be the correct one. However, this 
completely breaks the test `objc-radar17039661.m`. Even order of the 
`postCall()` hooks is changed and the test fails because it cannot find the 
bug. I try to attach the two different outputs annotated by debug printouts. 
@NoQ, do you have an idea what could be wrong here? First I thought on 
`BlockDataRegion`s where it seems I have to duplicate lots of code and also 
change the capture interface to also enable `ParamRegions` for the captures. 
However, in this case it does not seem to play a role.


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

https://reviews.llvm.org/D77229



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


[PATCH] D79054: [NFC] Improve doc string to mention that paths in diff are used as-is

2020-05-06 Thread Christopher Tetreault via Phabricator via cfe-commits
ctetreau added a comment.

In D79054#2018912 , @efriedma wrote:

> We should probably encourage people to use git-clang-format with git 
> repositories.  It naturally doesn't have this sort of fragility because it 
> integrates with the repository more tightly.


That may be a better choice for me personally, but other version control 
systems exist, and this is a tool with broader appeal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79054



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


[PATCH] D79325: [clang-format] [PR42164] Add Option to Break before While

2020-05-06 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir marked an inline comment as done.
krasimir added inline comments.



Comment at: clang/lib/Format/Format.cpp:691
+/*SplitEmptyRecord=*/true,
+/*SplitEmptyNamespace=*/true};
   switch (Style.BreakBeforeBraces) {

Awesome!



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2170
 parseBlock(/*MustBeDeclaration=*/false);
-if (Style.BraceWrapping.IndentBraces)
+if (Style.BraceWrapping.IndentBraces || Style.BraceWrapping.BeforeWhile)
   addUnwrappedLine();

Why not remove `Style.BraceWrapping.IndentBraces`? 
- should be a no-op for GNU style, 
- other styles don't IndentBraces, 
- we can add a sentence in the release notes that previously IndentBraces 
implied the new "BeforeWhile" option, and now you just have to set it if you're 
using a custom GNU-like style.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79325



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


[PATCH] D79054: [NFC] Improve doc string to mention that paths in diff are used as-is

2020-05-06 Thread Christopher Tetreault via Phabricator via cfe-commits
ctetreau updated this revision to Diff 262433.
ctetreau added a comment.

address code review issues


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79054

Files:
  clang/tools/clang-format/clang-format-diff.py


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -13,9 +13,13 @@
 lines. This is useful to reformat all the lines touched by a specific patch.
 Example usage for git/svn users:
 
-  git diff -U0 --no-color HEAD^ | clang-format-diff.py -p1 -i
+  git diff -U0 --no-color --relative HEAD^ | clang-format-diff.py -p1 -i
   svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i
 
+It should be noted that the filename contained in the diff is used unmodified
+to determine the source file to update. Users calling this script directly
+should be careful to ensure that the path in the diff is correct relative to 
the
+current working directory.
 """
 from __future__ import absolute_import, division, print_function
 


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -13,9 +13,13 @@
 lines. This is useful to reformat all the lines touched by a specific patch.
 Example usage for git/svn users:
 
-  git diff -U0 --no-color HEAD^ | clang-format-diff.py -p1 -i
+  git diff -U0 --no-color --relative HEAD^ | clang-format-diff.py -p1 -i
   svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i
 
+It should be noted that the filename contained in the diff is used unmodified
+to determine the source file to update. Users calling this script directly
+should be careful to ensure that the path in the diff is correct relative to the
+current working directory.
 """
 from __future__ import absolute_import, division, print_function
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79504: [Clang] Wrong return type of atomic_is_lock_free

2020-05-06 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Clang's `` uses the builtin as follows:

  #define atomic_is_lock_free(obj) __c11_atomic_is_lock_free(sizeof(*(obj)))

... which, combined with the builtin returning `int`, results in a call having 
the wrong type. So there's definitely a bug *somewhere*.

I think what happened here is: the return type of the GCC 
`__atomic_is_lock_free` / `__atomic_always_lock_free` builtins was `int` in GCC 
4.6 and earlier, and changed to `_Bool` in GCC 4.7 and later. Clang's 
implementation followed GCC's behavior at the time, so returned `int`, and 
no-one noticed that GCC changed its behavior in version 4.7. So we still 
provide the old GCC behavior.

Then, when `__c11_atomic_is_lock_free` was added, it got an `int` return type 
as (I think) a copy-paste error. The `__c11` builtins are intended to exactly 
match the semantics of the C11 atomic functions, so this was always wrong.

I think we should make this change, to all three affected builtin functions.




Comment at: clang/include/clang/Basic/Builtins.def:756
 BUILTIN(__atomic_signal_fence, "vi", "n")
 BUILTIN(__atomic_always_lock_free, "izvCD*", "n")
+BUILTIN(__atomic_is_lock_free, "bzvCD*", "n")

This one is also wrong, and should return *bool*.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79504



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


[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-05-06 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 262430.
baloghadamsoftware added a comment.

Fixed and error in `call_once.cpp` but stuck with debugging of 
`objc-radar17039661.m`.


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

https://reviews.llvm.org/D77229

Files:
  clang/include/clang/StaticAnalyzer/Checkers/SValExplainer.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/Regions.def
  clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/InvalidatedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MismatchedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/lib/StaticAnalyzer/Core/Store.cpp
  clang/test/Analysis/container-modeling.cpp
  clang/test/Analysis/explain-svals.cpp
  clang/test/Analysis/iterator-modeling.cpp
  clang/test/Analysis/temporaries.cpp

Index: clang/test/Analysis/temporaries.cpp
===
--- clang/test/Analysis/temporaries.cpp
+++ clang/test/Analysis/temporaries.cpp
@@ -890,12 +890,9 @@
 public:
   ~C() {
 glob = 1;
-// FIXME: Why is destructor not inlined in C++17
 clang_analyzer_checkInlined(true);
 #ifdef TEMPORARY_DTORS
-#if __cplusplus < 201703L
-// expected-warning@-3{{TRUE}}
-#endif
+// expected-warning@-2{{TRUE}}
 #endif
   }
 };
@@ -914,16 +911,11 @@
   // temporaries returned from functions, so we took the wrong branch.
   coin && is(get()); // no-crash
   if (coin) {
-// FIXME: Why is destructor not inlined in C++17
 clang_analyzer_eval(glob);
 #ifdef TEMPORARY_DTORS
-#if __cplusplus < 201703L
-// expected-warning@-3{{TRUE}}
-#else
-// expected-warning@-5{{UNKNOWN}}
-#endif
+// expected-warning@-2{{TRUE}}
 #else
-// expected-warning@-8{{UNKNOWN}}
+// expected-warning@-4{{UNKNOWN}}
 #endif
   } else {
 // The destructor is not called on this branch.
Index: clang/test/Analysis/iterator-modeling.cpp
===
--- clang/test/Analysis/iterator-modeling.cpp
+++ clang/test/Analysis/iterator-modeling.cpp
@@ -1862,7 +1862,7 @@
 void clang_analyzer_printState();
 
 void print_state(std::vector ) {
-  const auto i0 = V.cbegin();
+  auto i0 = V.cbegin();
   clang_analyzer_printState();
 
 // CHECK:  "checker_messages": [
@@ -1871,7 +1871,8 @@
 // CHECK-NEXT: "i0 : Valid ; Container == SymRegion{reg_$[[#]] & V>} ; Offset == conj_$[[#]]{long, LC[[#]], S[[#]], #[[#]]}"
 // CHECK-NEXT:   ]}
 
-  const auto i1 = V.cend();
+  ++i0;
+  auto i1 = V.cend();
   clang_analyzer_printState();
   
 // CHECK:  "checker_messages": [
@@ -1879,4 +1880,6 @@
 // CHECK-NEXT: "Iterator Positions :",
 // CHECK-NEXT: "i1 : Valid ; Container == SymRegion{reg_$[[#]] & V>} ; Offset == conj_$[[#]]{long, LC[[#]], S[[#]], #[[#]]}"
 // CHECK-NEXT:   ]}
+
+  --i1;
 }
Index: clang/test/Analysis/explain-svals.cpp
===
--- clang/test/Analysis/explain-svals.cpp
+++ clang/test/Analysis/explain-svals.cpp
@@ -93,6 +93,6 @@
 } // end of anonymous namespace
 
 void test_6() {
-  clang_analyzer_explain(conjure_S()); // expected-warning-re^lazily frozen compound value of temporary object constructed at statement 'conjure_S\(\)'$
+  clang_analyzer_explain(conjure_S()); // expected-warning-re^lazily frozen compound value of parameter 0 of function 'clang_analyzer_explain\(\)'$
   clang_analyzer_explain(conjure_S().z); // expected-warning-re^value derived from \(symbol of type 'int' conjured at statement 'conjure_S\(\)'\) for field 'z' of temporary object constructed at statement 'conjure_S\(\)'$
 }
Index: clang/test/Analysis/container-modeling.cpp
===
--- clang/test/Analysis/container-modeling.cpp
+++ clang/test/Analysis/container-modeling.cpp
@@ -17,7 +17,7 @@
 void clang_analyzer_warnIfReached();
 
 void begin(const std::vector ) {
-  V.begin();
+  const auto i0 = V.begin();
 
   clang_analyzer_denote(clang_analyzer_container_begin(V), "$V.begin()");
   clang_analyzer_express(clang_analyzer_container_begin(V)); // expected-warning{{$V.begin()}}
@@ -25,7 +25,7 @@
 }
 
 void end(const std::vector ) {
-  V.end();
+  const auto i0 = V.end();
 
   

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-06 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2405
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, tok::l_square) ||
  ((Style.Language == FormatStyle::LK_Java ||

Just to make sure I follow -- at this point why can't we check for the more 
specific `TT_AttributeSquare` instead of the general `tok::l_square` (if that's 
available, not sure when it gets computed) (`isOneOf` accepts both `tok::`'s 
and `TT_`'s). 

Ditto for the new `tok::l_square` below.


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

https://reviews.llvm.org/D79354



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


[PATCH] D79293: [clang-format] [PR45218] Fix an issue where < and > and >> in a for loop gets incorrectly interpreted at a TemplateOpener/Closer

2020-05-06 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added a comment.

I think these examples are too ambiguous for clang-format to try and format 
correctly.
Sadly for C++, correctly distinguishing between `>>`, the binary operator, and 
`>>`, the sequence of two closing template brackets, requires semantic 
analysis, I believe.
Such heuristics are very brittle, e.g. this patch fixes `if (i < x >> 1)` but 
regresses this:

  % cat ~/test.cc
  bool f() {
if (w>, 1>::t) return true;
  }
  % bin/clang-format ~/test.cc 
  bool f() {
if (w < u < v < x >>, 1 > ::t)
  return true;
  }
  % 

We can of course enumerate a fixed set of patterns where we apply such fixes 
fixes, but I'm not sure how much is that worth.
I think clang-format's current approach to choose to interpret as a template, 
even if silly at times, is reasonable.
A way to deal with `if (i < x >> 1)` is to give clang-format a hint e.g. `if (i 
< (x >> 1))`. You can ~always surround an expression with braces, but if 
clang-format guesses incorrectly two template closers as a binary operator, I 
can't think of a good way to force it to stop.


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

https://reviews.llvm.org/D79293



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


[PATCH] D79495: [Sema] Allow function attribute patchable_function_entry on aarch64_be

2020-05-06 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D79495#2023108 , @nickdesaulniers 
wrote:

> @MaskRay can you please cherry pick this to release-10? cc @tstellar


Already done. 
https://github.com/llvm/llvm-project/commit/98f9f73f6d2367aa8001c4d16de9d3b347febb08

Verified with `check-clang` (there are two test/Driver/riscv* failures which 
are unrelated)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79495



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


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-06 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

Since debugging on phabricator is a bit difficult, I took the patch and had a 
little play. Now I actually remember seeing this before. I think the way this 
works is that when you describe new instructions (PA in this case) that other 
models don't have, they start complaining about incomplete models when they 
have set `let CompleteModel = 1`

I got things compiling with these changes:

1. leave all existing models untouched, revert those changes,

2. remove that predicate HasPA that you added,

3. Change this:

>   def SVEUnsupported : AArch64Unsupported {
>   let F = [HasSVE, HasSVE2, HasSVE2AES, HasSVE2SM4, HasSVE2SHA3,
>   -   HasSVE2BitPerm];
>   +   HasSVE2BitPerm, HasPA];
>   }



4. In your new model set:

>   let CompleteModel =   0;
>   list UnsupportedFeatures = SVEUnsupported.F;



5. This is where the problem is, comment out these descriptions in your model:

>   //def : InstRW<[THX3T110Write_7Cyc_I1],
>   //(instrs AUTDA, AUTDB, AUTDZA, AUTDZB, AUTIA, AUTIA1716, 
> AUTIASP,
>   //AUTIAZ, AUTIB, AUTIB1716, AUTIBSP, AUTIBZ, AUTIZA, 
> AUTIZB,
>   //PACDA, PACDB, PACDZA, PACDZB, PACGA, PACIA, PACIA1716,
>   //PACIASP, PACIAZ, PACIB, PACIB1716, PACIBSP, PACIBZ,
>   //PACIZA, PACIZB, XPACD, XPACI, XPACLRI)>;

I have never really looked into these instructions, and quick grep doesn't show 
any descriptions for some. For example, AUTDA doesn't exist. The others look 
aliases, perhaps they need a different treatment, or a regexp, I don't know, 
but perhaps you can take it from here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129



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


[PATCH] D74387: [SYCL] Defer __float128 type usage diagnostics

2020-05-06 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D74387#1992682 , @Fznamznon wrote:

> Okay, seems like OpenMP needs unsupported types diagnosing as well. I'm 
> trying to adapt this patch for OpenMP, but it doesn't work out of the box 
> because it diagnoses memcpy like operations, so with the current patch the 
> code like this will cause diagnostics:
>
>struct T {
>  char a;
>  __float128 f;
>  char c;
>  T() : a(12), f(15) {}
>   }
>  
>   #pragma omp declare target
>   T a = T();
>   #pragma omp end declare target
>
>
> It happens because member initialization in the constructor is still usage of 
> `f` field which is marked unavailable because of type. I'm not sure that it 
> is possible to understand how the unavailable declaration is used in the 
> place where diagnostic about usage of unavailable declaration is actually 
> emitted, so I will probably need some other place/solution for it.
>
> @jdoerfert , could you please help to understand how the diagnostic should 
> work for OpenMP cases? Or you probably have some spec/requirements for it?
>  Understanding what exactly is needed will help with the implementation, I 
> guess.


I missed this update, sorry.

I don't think we have a spec wording for this, it is up to the implementations.

In the example, a diagnostic is actually fine (IMHO). You cannot assign 15 to 
the __float128 on the device. It doesn't work. The following code however 
should go through without diagnostic:

  struct T {
 char a;
 __float128 f;
 char c;
 T() : a(12), c(15) {}
  }

and it should translate to

  struct T {
 char a;
 alignas(host_float128_alignment) char[16] __unavailable_f;
 char c;
 T() : a(12), c(15) {}
  }

Do you have other questions or examples we should discuss?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74387



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


[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-06 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks updated this revision to Diff 262426.
aeubanks added a comment.

Revert back to initial patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79445

Files:
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1016,8 +1016,11 @@
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, false})));
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
@@ -1236,12 +1239,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager ) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager ) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager , PassBuilder::OptimizationLevel Level) 
{
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager ,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1016,8 +1016,11 @@
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, false})));
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
@@ -1236,12 +1239,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager ) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager ) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager , PassBuilder::OptimizationLevel Level) {
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager ,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79504: [Clang] Wrong return type of atomic_is_lock_free

2020-05-06 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

Just a guess, but maybe the return type was intended to match what a C 
implementation does with `atomic_is_lock_free` as a macro: 
https://en.cppreference.com/w/c/atomic/atomic_is_lock_free
If so, maybe the expectation is that a macro could define `atomic_is_lock_free` 
using `__atomic_is_lock_free`, and expect something compatible with `_Bool`?
In C++ we use `__atomic_is_lock_free ` in inlined functions, so `int` to `bool` 
is fine.

In other words, the builtin can return `int` just fine, but we should consider 
how we expect library implementations to use them before changing the return 
type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79504



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


[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

2020-05-06 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

The "indeterminate file position" case is now handled separately and is always 
error. The current implementation looks to be wrong because the indeterminate 
position is set at `fread` when a **FEOF** error is produced. This can be 
solved probably only with more state splits, because feof and ferror flags have 
more different behavior and can not be handled together the same way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78374



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


[PATCH] D79423: [analyzer][NFC] StdLibraryFunctionsChecker: Add empty Signatures

2020-05-06 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

Probably something like `IsCStdLibraryFunction` can be included in the 
signature, and empty signature is allowed only for functions that are in a C 
standard library.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79423



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


[PATCH] D72281: [Matrix] Add matrix type to Clang.

2020-05-06 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2112
+  llvm::APSInt ArgRows(S.Context.getTypeSize(S.Context.IntTy),
+   ConstantMatrixArg->getNumRows());
+  Result = DeduceNonTypeTemplateArgument(

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > Oh, and this needs to use `size_t`; not just the value but the type of a 
> > > non-type template parameter can be deduced, so you should use an 
> > > appropriate type.  Test case for this deduction is `template  
> > > void foo(matrix);` or something like that, with a check that 
> > > `decltype(R)` is `size_t` (which you can do in any number of ways).
> > Could we be even more permissive? If we fix it to size_t, template 
> > arguments with integer types like int or unsigned would be rejected.  Could 
> > we relax that to NTTP type, to allow different integer types that are 
> > implicitly convertible? We might need an extra check that the known number 
> > of rows/columns does not exceed the bit width of NTTP's type.
> Unfortunately, template argument deduction requires the template parameter 
> type to match the type of the argument value exactly, so you get exactly one 
> type.  Given that language rule, the natural type to use is `size_t`, which 
> is the same type that constant array bounds are considered to have.   If C++ 
> wants to weaken this language rule, they should do so uniformly; it does not 
> make sense for us to use a weaker rule just for this specific extension.
Thanks for the explanation! I've updated the code to just allow size_t.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D72281: [Matrix] Add matrix type to Clang.

2020-05-06 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 262413.
fhahn marked 2 inline comments as done.
fhahn added a comment.

Fix template deduction.

In D72281#2022004 , @rjmccall wrote:

> > The type of m1 matches the matrix argument in all 3 definitions of 
> > use_matrix and for some reason the return type is not used to disambiguate 
> > the definitions:
>
> C++ does not have the ability to use return types to disambiguate function 
> calls.
>
> > I am not sure where things are going wrong unfortunately. The matrix 
> > argument deduction should mirror the code for types like 
> > DependentSizedArrayType. Do you have any idea what could be missing?
>
> This is what function template partial ordering is supposed to do.  You'll 
> see that it works if you replace the definition of `matrix` to use array 
> types:


Ah right, thanks for clarifying. I think I managed to fix the remaining 
problems. Previously the patch did not handle DependentSizedMatrixTypes with 
non-dependent constant dimensions properly (e.g. a DependentSizedMatrixType 
could have one dependent and one non-dependent dimension). That's a difference 
to DependentSizedArrayType. Now the example works as expected (I've etxended it 
a bit). Cases like the one below are rejected

  template 
  using matrix = T __attribute__((matrix_type(R, C)));
  
  template 
  void use_matrix(matrix ) {}
  // expected-note@-1 {{candidate function [with T = float, R = 10]}}
  
  template 
  void use_matrix(matrix ) {}
  // expected-note@-1 {{candidate function [with T = float, C = 10]}}
  
  void test_ambigous_deduction1() {
matrix m;
use_matrix(m);
// expected-error@-1 {{call to 'use_matrix' is ambiguous}}
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/debug-info-matrix-types.c
  clang/test/CodeGen/matrix-type.c
  clang/test/CodeGenCXX/matrix-type.cpp
  clang/test/Parser/matrix-type-disabled.c
  clang/test/SemaCXX/matrix-type.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1795,6 +1795,8 @@
 DEFAULT_TYPELOC_IMPL(DependentSizedExtVector, Type)
 DEFAULT_TYPELOC_IMPL(Vector, Type)
 DEFAULT_TYPELOC_IMPL(ExtVector, VectorType)
+DEFAULT_TYPELOC_IMPL(ConstantMatrix, MatrixType)
+DEFAULT_TYPELOC_IMPL(DependentSizedMatrix, MatrixType)
 DEFAULT_TYPELOC_IMPL(FunctionProto, FunctionType)
 DEFAULT_TYPELOC_IMPL(FunctionNoProto, FunctionType)
 DEFAULT_TYPELOC_IMPL(Record, TagType)
Index: clang/test/SemaCXX/matrix-type.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/matrix-type.cpp
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -fsyntax-only -pedantic -fenable-matrix -std=c++11 -verify -triple x86_64-apple-darwin %s
+
+using matrix_double_t = double __attribute__((matrix_type(6, 6)));
+using matrix_float_t = float __attribute__((matrix_type(6, 6)));
+using matrix_int_t = int __attribute__((matrix_type(6, 6)));
+
+void matrix_var_dimensions(int Rows, unsigned Columns, char C) {
+  using matrix1_t = int __attribute__((matrix_type(Rows, 1)));// expected-error{{matrix_type attribute requires an integer constant}}
+  using matrix2_t = int __attribute__((matrix_type(1, Columns))); // expected-error{{matrix_type attribute requires an integer constant}}
+  using matrix3_t = int __attribute__((matrix_type(C, C)));   // expected-error{{matrix_type attribute 

[PATCH] D69088: [Lex] #pragma clang transform

2020-05-06 Thread Kit Barton via Phabricator via cfe-commits
kbarton added a comment.

@Meinersbur I missed the RFC and discussion on the cfe-dev mailing list. Could 
you post a link here so that it's included in the history?

I don't have any opposition to this, and it seems that you have addressed all 
the comments from reviewers. So, unless there was something that came up from 
the RFC discussion (which I doubt, since you just pinged the patch), I think 
this is good to land. However, I'm not really in a position to approve the 
patch since the implementation is well out of my domain of expertise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69088



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


[PATCH] D79000: [clang-format] C# property formatting can be controlled by config options

2020-05-06 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

I think this is OK as-is.

@MyDeveloperDay's suggestion of adding AfterProperty to the BraceWrapping style 
makes sense.
However I think in this case it is natural to use the same style for these 
properties and for methods (functions) until we have a reason to allow for 
divergence.
This MS example 

 illustrates how close such "property blocks" match "function body blocks": if 
you squint, add an `()` before the property block and sprinkle semicolons 
inside it, it looks like a method.
The fact that we only need this specifically for C# properties makes it a bit 
niche.
I'd rather be lazy about BraceWrapping.AfterProperty and add it later, as need 
arises.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79000



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


[PATCH] D78869: clang-format: Add ControlStatementsExceptForEachMacros option to SpaceBeforeParens

2020-05-06 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

In D78869#2022850 , @mitchell-stellar 
wrote:

> I often:


I develop and run on windows (using a cygwin shell), but with visual studio 
compiler (configured with CMake for ninja)

  0.5  after doing git add of the files, I do `git clang-format` just to be 
sure  (adding any files that are modified)

> 1. Commit the change to my local repo, following the style of previous commit 
> messages for clang-format.

So I have a script which gets the commit message

  get_commit_message.sh
  
  echo '{ "revision_id": '${1:1}' }' | arc call-conduit --conduit-uri 
https://reviews.llvm.org/ --conduit-token  
differential.getcommitmessage | /usr/bin/jq -r ".response"
  ---

This will fetch the commit message from Phabricator that I should use. (you 
need to get a phabricator-token from your profile->settings)

  git fetch  && git pull --rebase --autostash

> 2. Build and run the clang-format tests and make sure they pass.
> 3. Pull, rebase, and push. (Linear history is enforced.)
> 4. Build and run the clang-format tests again just in case. (Optional)



5. I try to run the lit tests too. (in clang/tests/Format)
6. I check the documentation if any rst files are changed  ( 
/usr/bin/sphinx-build -n ./docs ./html)

  // assuming no new changes.. git push


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

https://reviews.llvm.org/D78869



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


[PATCH] D79495: [Sema] Allow function attribute patchable_function_entry on aarch64_be

2020-05-06 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a subscriber: tstellar.
nickdesaulniers added a comment.

@MaskRay can you please cherry pick this to release-10? cc @tstellar


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79495



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


[PATCH] D79504: [Clang] Wrong return type of atomic_is_lock_free

2020-05-06 Thread kamlesh kumar via Phabricator via cfe-commits
kamleshbhalui created this revision.
kamleshbhalui added reviewers: aaron.ballman, rsmith.
Herald added subscribers: cfe-commits, jfb.
Herald added a project: clang.
kamleshbhalui added a reviewer: rnk.

Fixing the return type of atomic_is_lock_free as per
https://en.cppreference.com/w/c/atomic/atomic_is_lock_free


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79504

Files:
  clang/include/clang/Basic/Builtins.def
  clang/test/CodeGen/atomic-ops.c
  clang/test/CodeGen/big-atomic-ops.c


Index: clang/test/CodeGen/big-atomic-ops.c
===
--- clang/test/CodeGen/big-atomic-ops.c
+++ clang/test/CodeGen/big-atomic-ops.c
@@ -198,20 +198,20 @@
 int lock_free(struct Incomplete *incomplete) {
   // CHECK: @lock_free
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 3, i8* null)
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 3, i8* null)
   __c11_atomic_is_lock_free(3);
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 16, i8* {{.*}}@sixteen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 16, i8* 
{{.*}}@sixteen{{.*}})
   __atomic_is_lock_free(16, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 17, i8* {{.*}}@seventeen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 17, i8* 
{{.*}}@seventeen{{.*}})
   __atomic_is_lock_free(17, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, incomplete);
 
   char cs[20];
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, cs+1);
 
   // CHECK-NOT: call
Index: clang/test/CodeGen/atomic-ops.c
===
--- clang/test/CodeGen/atomic-ops.c
+++ clang/test/CodeGen/atomic-ops.c
@@ -343,20 +343,20 @@
 int lock_free(struct Incomplete *incomplete) {
   // CHECK-LABEL: @lock_free
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 3, i8* null)
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 3, i8* null)
   __c11_atomic_is_lock_free(3);
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 16, i8* {{.*}}@sixteen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 16, i8* 
{{.*}}@sixteen{{.*}})
   __atomic_is_lock_free(16, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 17, i8* {{.*}}@seventeen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 17, i8* 
{{.*}}@seventeen{{.*}})
   __atomic_is_lock_free(17, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i32 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 4, {{.*}})
   __atomic_is_lock_free(4, incomplete);
 
   char cs[20];
-  // CHECK: call i32 @__atomic_is_lock_free(i32 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i32 4, {{.*}})
   __atomic_is_lock_free(4, cs+1);
 
   // CHECK-NOT: call
Index: clang/include/clang/Basic/Builtins.def
===
--- clang/include/clang/Basic/Builtins.def
+++ clang/include/clang/Basic/Builtins.def
@@ -724,7 +724,7 @@
 ATOMIC_BUILTIN(__c11_atomic_fetch_min, "v.", "t")
 BUILTIN(__c11_atomic_thread_fence, "vi", "n")
 BUILTIN(__c11_atomic_signal_fence, "vi", "n")
-BUILTIN(__c11_atomic_is_lock_free, "iz", "n")
+BUILTIN(__c11_atomic_is_lock_free, "bz", "n")
 
 // GNU atomic builtins.
 ATOMIC_BUILTIN(__atomic_load, "v.", "t")
@@ -754,7 +754,7 @@
 BUILTIN(__atomic_thread_fence, "vi", "n")
 BUILTIN(__atomic_signal_fence, "vi", "n")
 BUILTIN(__atomic_always_lock_free, "izvCD*", "n")
-BUILTIN(__atomic_is_lock_free, "izvCD*", "n")
+BUILTIN(__atomic_is_lock_free, "bzvCD*", "n")
 
 // OpenCL 2.0 atomic builtins.
 ATOMIC_BUILTIN(__opencl_atomic_init, "v.", "t")


Index: clang/test/CodeGen/big-atomic-ops.c
===
--- clang/test/CodeGen/big-atomic-ops.c
+++ clang/test/CodeGen/big-atomic-ops.c
@@ -198,20 +198,20 @@
 int lock_free(struct Incomplete *incomplete) {
   // CHECK: @lock_free
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 3, i8* null)
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 3, i8* null)
   __c11_atomic_is_lock_free(3);
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 16, i8* {{.*}}@sixteen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 16, i8* {{.*}}@sixteen{{.*}})
   __atomic_is_lock_free(16, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 17, i8* {{.*}}@seventeen{{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 17, i8* {{.*}}@seventeen{{.*}})
   __atomic_is_lock_free(17, );
 
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   __atomic_is_lock_free(4, incomplete);
 
   char cs[20];
-  // CHECK: call i32 @__atomic_is_lock_free(i64 4, {{.*}})
+  // CHECK: call zeroext i1 @__atomic_is_lock_free(i64 4, {{.*}})
   

  1   2   3   >