[PATCH] D53125: Detect Clear Linux and apply Clear's default linker options

2018-10-10 Thread Thiago Macieira via Phabricator via cfe-commits
thiagomacieira updated this revision to Diff 169151.
thiagomacieira added a comment.

Oops, add the missing portion of the unit test (the part that actually tests).


https://reviews.llvm.org/D53125

Files:
  include/clang/Driver/Distro.h
  lib/Driver/Distro.cpp
  lib/Driver/ToolChains/Linux.cpp
  unittests/Driver/DistroTest.cpp

Index: unittests/Driver/DistroTest.cpp
===
--- unittests/Driver/DistroTest.cpp
+++ unittests/Driver/DistroTest.cpp
@@ -302,4 +302,19 @@
   ASSERT_FALSE(ArchLinux.IsDebian());
 }
 
+TEST(DistroTest, DetectClearLinux) {
+  vfs::InMemoryFileSystem ClearLinuxFileSystem;
+  ClearLinuxFileSystem.addFile("/usr/lib/os-release", 0,
+  llvm::MemoryBuffer::getMemBuffer("NAME=\"Clear Linux OS\"\n"
+   "VERSION=1\n"
+   "ID=clear-linux-os\n"
+   "VERSION_ID=25530\n"
+   "PRETTY_NAME=\"Clear Linux OS\"\n"
+   "ANSI_COLOR=\"1;35\"\n"
+   "HOME_URL=\"https://clearlinux.org\"\n;
+   "SUPPORT_URL=\"https://clearlinux.org\"\n;
+   "BUG_REPORT_URL=\"mailto:d...@lists.clearlinux.org\"\n"
+   "PRIVACY_POLICY_URL=\"http://www.intel.com/privacy\"\n;));
+}
+
 } // end anonymous namespace
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -229,16 +229,19 @@
 
   Distro Distro(D.getVFS());
 
-  if (Distro.IsAlpineLinux()) {
+  if (Distro.IsAlpineLinux() || Distro.IsClearLinux()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("now");
   }
 
-  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux()) {
+  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux() || Distro.IsClearLinux()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("relro");
   }
 
+  if (Distro.IsClearLinux())
+ExtraOpts.push_back("--copy-dt-needed-entries");
+
   if (GCCInstallation.getParentLibPath().find("opt/rh/devtoolset") !=
   StringRef::npos)
 // With devtoolset on RHEL, we want to add a bin directory that is relative
@@ -283,7 +286,7 @@
   ExtraOpts.push_back("--build-id");
 #endif
 
-  if (IsAndroid || Distro.IsOpenSUSE())
+  if (IsAndroid || Distro.IsOpenSUSE() || Distro.IsClearLinux())
 ExtraOpts.push_back("--enable-new-dtags");
 
   // The selection of paths to try here is designed to match the patterns which
Index: lib/Driver/Distro.cpp
===
--- lib/Driver/Distro.cpp
+++ lib/Driver/Distro.cpp
@@ -136,6 +136,19 @@
   if (VFS.exists("/etc/arch-release"))
 return Distro::ArchLinux;
 
+  File = VFS.getBufferForFile("/usr/lib/os-release");
+  if (File) {
+StringRef Data = File.get()->getBuffer();
+SmallVector Lines;
+Data.split(Lines, "\n");
+Distro::DistroType Version = Distro::UnknownDistro;
+for (StringRef Line : Lines)
+  if (Version == Distro::UnknownDistro && Line.startswith("ID="))
+Version = llvm::StringSwitch(Line.substr(3))
+  .Case("clear-linux-os", Distro::ClearLinux);
+return Version;
+  }
+
   return Distro::UnknownDistro;
 }
 
Index: include/clang/Driver/Distro.h
===
--- include/clang/Driver/Distro.h
+++ include/clang/Driver/Distro.h
@@ -28,6 +28,7 @@
 // the first and last known member in the family, e.g. IsRedHat().
 AlpineLinux,
 ArchLinux,
+ClearLinux,
 DebianLenny,
 DebianSqueeze,
 DebianWheezy,
@@ -122,6 +123,10 @@
 return DistroVal == AlpineLinux;
   }
 
+  bool IsClearLinux() const {
+return DistroVal == ClearLinux;
+  }
+
   /// @}
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D51762: First part of the calendar stuff

2018-10-10 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.
Herald added a subscriber: arphaman.

What's with all the XFAIL's?




Comment at: 
test/std/utilities/time/time.cal/time.cal.ymwd/time.cal.ymwd.members/ctor.sys_days.pass.cpp:10
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+// XFAIL
+

What?



Comment at: 
test/std/utilities/time/time.cal/time.cal.ymwd/time.cal.ymwd.members/ctor.sys_days.pass.cpp:41
+
+//  ASSERT_NOEXCEPT(year_month_weekday{std::declval()});
+

What's this test doing?



Comment at: 
test/std/utilities/time/time.cal/time.cal.ymwdlast/time.cal.ymwdlast.nonmembers/streaming.pass.cpp:10
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+// XFAIL
+

What?


https://reviews.llvm.org/D51762



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


[PATCH] D53125: Detect Clear Linux and apply Clear's default linker options

2018-10-10 Thread Thiago Macieira via Phabricator via cfe-commits
thiagomacieira created this revision.
thiagomacieira added reviewers: mgorny, erichkeane.
Herald added subscribers: cfe-commits, srhines.

/usr/lib/os-release is the official path of /etc/os-release (the latter is 
usually a symlink to the former)


Repository:
  rC Clang

https://reviews.llvm.org/D53125

Files:
  include/clang/Driver/Distro.h
  lib/Driver/Distro.cpp
  lib/Driver/ToolChains/Linux.cpp
  unittests/Driver/DistroTest.cpp

Index: unittests/Driver/DistroTest.cpp
===
--- unittests/Driver/DistroTest.cpp
+++ unittests/Driver/DistroTest.cpp
@@ -302,4 +302,19 @@
   ASSERT_FALSE(ArchLinux.IsDebian());
 }
 
+TEST(DistroTest, DetectClearLinux) {
+  vfs::InMemoryFileSystem ClearLinuxFileSystem;
+  ClearLinuxFileSystem.addFile("/usr/lib/os-release", 0,
+  llvm::MemoryBuffer::getMemBuffer("NAME=\"Clear Linux OS\"\n"
+   "VERSION=1\n"
+   "ID=clear-linux-os\n"
+   "VERSION_ID=25530\n"
+   "PRETTY_NAME=\"Clear Linux OS\"\n"
+   "ANSI_COLOR=\"1;35\"\n"
+   "HOME_URL=\"https://clearlinux.org\"\n;
+   "SUPPORT_URL=\"https://clearlinux.org\"\n;
+   "BUG_REPORT_URL=\"mailto:d...@lists.clearlinux.org\"\n"
+   "PRIVACY_POLICY_URL=\"http://www.intel.com/privacy\"\n;));
+}
+
 } // end anonymous namespace
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -229,16 +229,19 @@
 
   Distro Distro(D.getVFS());
 
-  if (Distro.IsAlpineLinux()) {
+  if (Distro.IsAlpineLinux() || Distro.IsClearLinux()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("now");
   }
 
-  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux()) {
+  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux() || Distro.IsClearLinux()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("relro");
   }
 
+  if (Distro.IsClearLinux())
+ExtraOpts.push_back("--copy-dt-needed-entries");
+
   if (GCCInstallation.getParentLibPath().find("opt/rh/devtoolset") !=
   StringRef::npos)
 // With devtoolset on RHEL, we want to add a bin directory that is relative
@@ -283,7 +286,7 @@
   ExtraOpts.push_back("--build-id");
 #endif
 
-  if (IsAndroid || Distro.IsOpenSUSE())
+  if (IsAndroid || Distro.IsOpenSUSE() || Distro.IsClearLinux())
 ExtraOpts.push_back("--enable-new-dtags");
 
   // The selection of paths to try here is designed to match the patterns which
Index: lib/Driver/Distro.cpp
===
--- lib/Driver/Distro.cpp
+++ lib/Driver/Distro.cpp
@@ -136,6 +136,19 @@
   if (VFS.exists("/etc/arch-release"))
 return Distro::ArchLinux;
 
+  File = VFS.getBufferForFile("/usr/lib/os-release");
+  if (File) {
+StringRef Data = File.get()->getBuffer();
+SmallVector Lines;
+Data.split(Lines, "\n");
+Distro::DistroType Version = Distro::UnknownDistro;
+for (StringRef Line : Lines)
+  if (Version == Distro::UnknownDistro && Line.startswith("ID="))
+Version = llvm::StringSwitch(Line.substr(3))
+  .Case("clear-linux-os", Distro::ClearLinux);
+return Version;
+  }
+
   return Distro::UnknownDistro;
 }
 
Index: include/clang/Driver/Distro.h
===
--- include/clang/Driver/Distro.h
+++ include/clang/Driver/Distro.h
@@ -28,6 +28,7 @@
 // the first and last known member in the family, e.g. IsRedHat().
 AlpineLinux,
 ArchLinux,
+ClearLinux,
 DebianLenny,
 DebianSqueeze,
 DebianWheezy,
@@ -122,6 +123,10 @@
 return DistroVal == AlpineLinux;
   }
 
+  bool IsClearLinux() const {
+return DistroVal == ClearLinux;
+  }
+
   /// @}
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D53100: clang: Add ARCTargetInfo

2018-10-10 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.

Thanks, LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D53100



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


[PATCH] D52673: [HIP] Remove disabled irif library

2018-10-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks!


https://reviews.llvm.org/D52673



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


[PATCH] D53121: [Driver] Add defaults for Android ARM FPUs.

2018-10-10 Thread Stephen Hines via Phabricator via cfe-commits
srhines added a comment.

This LGTM, but we should wait to hear from Kristof before submitting.


Repository:
  rC Clang

https://reviews.llvm.org/D53121



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


[PATCH] D53109: [Driver] Default Android toolchains to libc++.

2018-10-10 Thread Stephen Hines via Phabricator via cfe-commits
srhines accepted this revision.
srhines added a comment.
This revision is now accepted and ready to land.

Really cool! Thanks for making everything easier to use out-of-the-box.


Repository:
  rC Clang

https://reviews.llvm.org/D53109



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


[PATCH] D53115: [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsics

2018-10-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: lib/Sema/SemaChecking.cpp:1754
+  // argument here. Any constant would be converted to a register of
+  // the form S1_2_C3_C4_5. Let the hardware throw an exception for incorrect
+  // registers. This matches MSVC behavior.

I agree we shouldn't try to figure out whether the register is valid, but we 
probably want a range check anyway: if the value is greater than 0x7FFF, it 
can't be encoded.


https://reviews.llvm.org/D53115



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


[PATCH] D53121: [Driver] Add defaults for Android ARM FPUs.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert added a comment.

Related to this but something I was less sure we should do: Android no longer 
supports ARMv5. Should we make `arm-linux-androideabi` targets auto pull up to 
armv7 if there's no `-march` flag?


Repository:
  rC Clang

https://reviews.llvm.org/D53121



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


[PATCH] D53121: [Driver] Add defaults for Android ARM FPUs.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert created this revision.
danalbert added reviewers: srhines, pirama.
Herald added a reviewer: javed.absar.
Herald added subscribers: chrib, kristof.beyls.

Android mandates that devices have at least vfpv3-d16 until
Marshmallow and NEON after that. Still honor the user's decision, but
raise the defaults for Android targets.


Repository:
  rC Clang

https://reviews.llvm.org/D53121

Files:
  lib/Driver/ToolChains/Arch/ARM.cpp
  test/Driver/arm-mfpu.c


Index: test/Driver/arm-mfpu.c
===
--- test/Driver/arm-mfpu.c
+++ test/Driver/arm-mfpu.c
@@ -364,3 +364,56 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+
+// RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s
+// CHECK-ARM5-ANDROID-FP-DEFAULT: "-target-feature" "+soft-float"
+// CHECK-ARM5-ANDROID-FP-DEFAULT: "-target-feature" "+soft-float-abi"
+// CHECK-ARM5-ANDROID-FP-DEFAULT-NOT: "-target-feature" "+d16"
+// CHECK-ARM5-ANDROID-FP-DEFAULT-NOT: "-target-feature" "+vfp3"
+// CHECK-ARM5-ANDROID-FP-DEFAULT-NOT: "-target-feature" "+vfp4"
+// CHECK-ARM5-ANDROID-FP-DEFAULT-NOT: "-target-feature" "+fp-armv8"
+// CHECK-ARM5-ANDROID-FP-DEFAULT-NOT: "-target-feature" "+neon"
+// CHECK-ARM5-ANDROID-FP-DEFAULT-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target armv7-linux-androideabi21 %s -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-ARM-ANDROID-L-FP-DEFAULT %s
+// CHECK-ARM-ANDROID-L-FP-DEFAULT-NOT: "-target-feature" "+soft-float"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT: "-target-feature" "+soft-float-abi"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT: "-target-feature" "+d16"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT: "-target-feature" "+vfp3"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT-NOT: "-target-feature" "+vfp4"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT-NOT: "-target-feature" "+fp-armv8"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT-NOT: "-target-feature" "+neon"
+// CHECK-ARM-ANDROID-L-FP-DEFAULT-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target armv7-linux-androideabi21 -mfpu=neon %s -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-ARM-ANDROID-L-FP-NEON %s
+// CHECK-ARM-ANDROID-L-FP-NEON-NOT: "-target-feature" "+soft-float"
+// CHECK-ARM-ANDROID-L-FP-NEON: "-target-feature" "+soft-float-abi"
+// CHECK-ARM-ANDROID-L-FP-NEON: "-target-feature" "+vfp3"
+// CHECK-ARM-ANDROID-L-FP-NEON-NOT: "-target-feature" "+vfp4"
+// CHECK-ARM-ANDROID-L-FP-NEON-NOT: "-target-feature" "+fp-armv8"
+// CHECK-ARM-ANDROID-L-FP-NEON: "-target-feature" "+neon"
+// CHECK-ARM-ANDROID-L-FP-NEON-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target armv7-linux-androideabi23 %s -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-ARM-ANDROID-M-FP-DEFAULT %s
+// CHECK-ARM-ANDROID-M-FP-DEFAULT-NOT: "-target-feature" "+soft-float"
+// CHECK-ARM-ANDROID-M-FP-DEFAULT: "-target-feature" "+soft-float-abi"
+// CHECK-ARM-ANDROID-M-FP-DEFAULT: "-target-feature" "+vfp3"
+// CHECK-ARM-ANDROID-M-FP-DEFAULT-NOT: "-target-feature" "+vfp4"
+// CHECK-ARM-ANDROID-M-FP-DEFAULT-NOT: "-target-feature" "+fp-armv8"
+// CHECK-ARM-ANDROID-M-FP-DEFAULT: "-target-feature" "+neon"
+// CHECK-ARM-ANDROID-M-FP-DEFAULT-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target armv7-linux-androideabi23 %s -mfpu=vfp3-d16 -### -c 
2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-ARM-ANDROID-M-FP-D16 %s
+// CHECK-ARM-ANDROID-M-FP-D16-NOT: "-target-feature" "+soft-float"
+// CHECK-ARM-ANDROID-M-FP-D16: "-target-feature" "+soft-float-abi"
+// CHECK-ARM-ANDROID-M-FP-D16: "-target-feature" "+d16"
+// CHECK-ARM-ANDROID-M-FP-D16: "-target-feature" "+vfp3"
+// CHECK-ARM-ANDROID-M-FP-D16-NOT: "-target-feature" "+vfp4"
+// CHECK-ARM-ANDROID-M-FP-D16-NOT: "-target-feature" "+fp-armv8"
+// CHECK-ARM-ANDROID-M-FP-D16-NOT: "-target-feature" "+neon"
+// CHECK-ARM-ANDROID-M-FP-D16-NOT: "-target-feature" "+crypto"
Index: lib/Driver/ToolChains/Arch/ARM.cpp
===
--- lib/Driver/ToolChains/Arch/ARM.cpp
+++ lib/Driver/ToolChains/Arch/ARM.cpp
@@ -357,6 +357,12 @@
 checkARMCPUName(D, CPUArg, Args, CPUName, ArchName, Features, Triple);
   }
 
+  unsigned ArchVersion;
+  if (ArchName.empty())
+  ArchVersion = getARMSubArchVersionNumber(Triple);
+  else
+  ArchVersion = llvm::ARM::parseArchVersion(ArchName);
+
   // Add CPU features for generic CPUs
   if (CPUName == "native") {
 llvm::StringMap HostFeatures;
@@ -378,6 +384,13 @@
   Features);
   } else if (FPUArg) {
 getARMFPUFeatures(D, FPUArg, Args, FPUArg->getValue(), Features);
+  } else if (Triple.isAndroid() && ArchVersion >= 7) {
+// Android mandates minimum FPU requirements based on OS version.
+const char *AndroidFPU =
+Triple.isAndroidVersionLT(23) ? "vfpv3-d16" : "neon";
+if 

[PATCH] D53118: [Driver] Fix --hash-style choice for Android.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert created this revision.
danalbert added reviewers: srhines, pirama.

Android supports GNU style hashes as of Marshmallow, so we should be
generating both styles for pre-M targets and GNU hashes for newer
targets.


Repository:
  rC Clang

https://reviews.llvm.org/D53118

Files:
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/linux-ld.c


Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -975,6 +975,20 @@
 // CHECK-MIPS64EL-REDHAT: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld.so.1"
 // CHECK-MIPS64EL-REDHAT-NOT: "-dynamic-linker" 
"{{.*}}/lib{{(64)?}}/ld-musl-mipsel.so.1"
 // CHECK-MIPS64EL-REDHAT-NOT: "--hash-style={{gnu|both}}"
+
+// Check that we pass --hash-style=both for pre-M Android versions and
+// --hash-style=gnu for newer Android versions.
+// RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-linux-android21 \
+// RUN:   | FileCheck --check-prefix=CHECK-ANDROID-HASH-STYLE-L %s
+// CHECK-ANDROID-HASH-STYLE-L: "{{.*}}ld{{(.exe)?}}"
+// CHECK-ANDROID-HASH-STYLE-L: "--hash-style=both"
+//
+// RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-linux-android23 \
+// RUN:   | FileCheck --check-prefix=CHECK-ANDROID-HASH-STYLE-M %s
+// CHECK-ANDROID-HASH-STYLE-M: "{{.*}}ld{{(.exe)?}}"
+// CHECK-ANDROID-HASH-STYLE-M: "--hash-style=gnu"
 //
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-unknown-linux-gnu \
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -264,15 +264,18 @@
   // and the MIPS ABI require .dynsym to be sorted in different ways.
   // .gnu.hash needs symbols to be grouped by hash code whereas the MIPS
   // ABI requires a mapping between the GOT and the symbol table.
-  // Android loader does not support .gnu.hash.
+  // Android loader does not support .gnu.hash until API 23.
   // Hexagon linker/loader does not support .gnu.hash
-  if (!IsMips && !IsAndroid && !IsHexagon) {
+  if (!IsMips && !IsHexagon) {
 if (Distro.IsRedhat() || Distro.IsOpenSUSE() || Distro.IsAlpineLinux() ||
-(Distro.IsUbuntu() && Distro >= Distro::UbuntuMaverick))
+(Distro.IsUbuntu() && Distro >= Distro::UbuntuMaverick) ||
+(IsAndroid && !Triple.isAndroidVersionLT(23)))
   ExtraOpts.push_back("--hash-style=gnu");
 
-if (Distro.IsDebian() || Distro.IsOpenSUSE() || Distro == 
Distro::UbuntuLucid ||
-Distro == Distro::UbuntuJaunty || Distro == Distro::UbuntuKarmic)
+if (Distro.IsDebian() || Distro.IsOpenSUSE() ||
+Distro == Distro::UbuntuLucid || Distro == Distro::UbuntuJaunty ||
+Distro == Distro::UbuntuKarmic ||
+(IsAndroid && Triple.isAndroidVersionLT(23)))
   ExtraOpts.push_back("--hash-style=both");
   }
 


Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -975,6 +975,20 @@
 // CHECK-MIPS64EL-REDHAT: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld.so.1"
 // CHECK-MIPS64EL-REDHAT-NOT: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld-musl-mipsel.so.1"
 // CHECK-MIPS64EL-REDHAT-NOT: "--hash-style={{gnu|both}}"
+
+// Check that we pass --hash-style=both for pre-M Android versions and
+// --hash-style=gnu for newer Android versions.
+// RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-linux-android21 \
+// RUN:   | FileCheck --check-prefix=CHECK-ANDROID-HASH-STYLE-L %s
+// CHECK-ANDROID-HASH-STYLE-L: "{{.*}}ld{{(.exe)?}}"
+// CHECK-ANDROID-HASH-STYLE-L: "--hash-style=both"
+//
+// RUN: %clang %s -### -o %t.o 2>&1 \
+// RUN: --target=armv7-linux-android23 \
+// RUN:   | FileCheck --check-prefix=CHECK-ANDROID-HASH-STYLE-M %s
+// CHECK-ANDROID-HASH-STYLE-M: "{{.*}}ld{{(.exe)?}}"
+// CHECK-ANDROID-HASH-STYLE-M: "--hash-style=gnu"
 //
 // RUN: %clang %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-unknown-linux-gnu \
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -264,15 +264,18 @@
   // and the MIPS ABI require .dynsym to be sorted in different ways.
   // .gnu.hash needs symbols to be grouped by hash code whereas the MIPS
   // ABI requires a mapping between the GOT and the symbol table.
-  // Android loader does not support .gnu.hash.
+  // Android loader does not support .gnu.hash until API 23.
   // Hexagon linker/loader does not support .gnu.hash
-  if (!IsMips && !IsAndroid && !IsHexagon) {
+  if (!IsMips && !IsHexagon) {
 if (Distro.IsRedhat() || Distro.IsOpenSUSE() || Distro.IsAlpineLinux() ||
-(Distro.IsUbuntu() && Distro >= Distro::UbuntuMaverick))
+(Distro.IsUbuntu() && Distro >= Distro::UbuntuMaverick) ||
+(IsAndroid && !Triple.isAndroidVersionLT(23)))
   

[PATCH] D53117: [Driver] Default to `-z now` and `-z relro` on Android.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert created this revision.
danalbert added reviewers: srhines, pirama.

RTLD_LAZY is not supported on Android (though failing to use `-z now`
will work since it is assumed by the loader).

  

RelRO is required.


Repository:
  rC Clang

https://reviews.llvm.org/D53117

Files:
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/linux-ld.c


Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -1241,6 +1241,8 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ANDROID %s
 // CHECK-ANDROID: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-ANDROID: "-z" "now"
+// CHECK-ANDROID: "-z" "relro"
 // CHECK-ANDROID: "--enable-new-dtags"
 // CHECK-ANDROID: "{{.*}}{{/|}}crtbegin_dynamic.o"
 // CHECK-ANDROID: "-L[[SYSROOT]]/usr/lib"
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -229,12 +229,13 @@
 
   Distro Distro(D.getVFS());
 
-  if (Distro.IsAlpineLinux()) {
+  if (Distro.IsAlpineLinux() || Triple.isAndroid()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("now");
   }
 
-  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux()) {
+  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux() ||
+  Triple.isAndroid()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("relro");
   }


Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -1241,6 +1241,8 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ANDROID %s
 // CHECK-ANDROID: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-ANDROID: "-z" "now"
+// CHECK-ANDROID: "-z" "relro"
 // CHECK-ANDROID: "--enable-new-dtags"
 // CHECK-ANDROID: "{{.*}}{{/|}}crtbegin_dynamic.o"
 // CHECK-ANDROID: "-L[[SYSROOT]]/usr/lib"
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -229,12 +229,13 @@
 
   Distro Distro(D.getVFS());
 
-  if (Distro.IsAlpineLinux()) {
+  if (Distro.IsAlpineLinux() || Triple.isAndroid()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("now");
   }
 
-  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux()) {
+  if (Distro.IsOpenSUSE() || Distro.IsUbuntu() || Distro.IsAlpineLinux() ||
+  Triple.isAndroid()) {
 ExtraOpts.push_back("-z");
 ExtraOpts.push_back("relro");
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D53009: [WebAssembly] Saturating float-to-int builtins

2018-10-10 Thread Thomas Lively via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC344205: [WebAssembly] Saturating float-to-int builtins 
(authored by tlively, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D53009?vs=168738=169132#toc

Repository:
  rC Clang

https://reviews.llvm.org/D53009

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

Index: include/clang/Basic/BuiltinsWebAssembly.def
===
--- include/clang/Basic/BuiltinsWebAssembly.def
+++ include/clang/Basic/BuiltinsWebAssembly.def
@@ -39,6 +39,16 @@
 BUILTIN(__builtin_wasm_atomic_wait_i64, "iLLi*LLiLLi", "n")
 BUILTIN(__builtin_wasm_atomic_notify, "Uii*i", "n")
 
+// Saturating fp-to-int conversions
+BUILTIN(__builtin_wasm_trunc_saturate_s_i32_f32, "if", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i32_f32, "if", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_i32_f64, "id", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i32_f64, "id", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_i64_f32, "LLif", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i64_f32, "LLif", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_i64_f64, "LLid", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i64_f64, "LLid", "nc")
+
 // SIMD builtins
 BUILTIN(__builtin_wasm_extract_lane_s_i8x16, "iV16cIi", "nc")
 BUILTIN(__builtin_wasm_extract_lane_u_i8x16, "iV16cIi", "nc")
@@ -81,4 +91,9 @@
 BUILTIN(__builtin_wasm_sqrt_f32x4, "V4fV4f", "nc")
 BUILTIN(__builtin_wasm_sqrt_f64x2, "V2dV2d", "nc")
 
+BUILTIN(__builtin_wasm_trunc_saturate_s_v4i32_v4f32, "V4iV4f", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_v4i32_v4f32, "V4iV4f", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_v2i64_v2f64, "V2LLiV2d", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_v2i64_v2f64, "V2LLiV2d", "nc")
+
 #undef BUILTIN
Index: test/CodeGen/builtins-wasm.c
===
--- test/CodeGen/builtins-wasm.c
+++ test/CodeGen/builtins-wasm.c
@@ -83,6 +83,54 @@
   // WEBASSEMBLY64: call i32 @llvm.wasm.atomic.notify(i32* %{{.*}}, i32 %{{.*}})
 }
 
+int trunc_saturate_s_i32_f32(float f) {
+  return __builtin_wasm_trunc_saturate_s_i32_f32(f);
+  // WEBASSEMBLY: call i32 @llvm.wasm.trunc.saturate.signed.i32.f32(float %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+int trunc_saturate_u_i32_f32(float f) {
+  return __builtin_wasm_trunc_saturate_u_i32_f32(f);
+  // WEBASSEMBLY: call i32 @llvm.wasm.trunc.saturate.unsigned.i32.f32(float %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+int trunc_saturate_s_i32_f64(double f) {
+  return __builtin_wasm_trunc_saturate_s_i32_f64(f);
+  // WEBASSEMBLY: call i32 @llvm.wasm.trunc.saturate.signed.i32.f64(double %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+int trunc_saturate_u_i32_f64(double f) {
+  return __builtin_wasm_trunc_saturate_u_i32_f64(f);
+  // WEBASSEMBLY: call i32 @llvm.wasm.trunc.saturate.unsigned.i32.f64(double %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+long long trunc_saturate_s_i64_f32(float f) {
+  return __builtin_wasm_trunc_saturate_s_i64_f32(f);
+  // WEBASSEMBLY: call i64 @llvm.wasm.trunc.saturate.signed.i64.f32(float %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+long long trunc_saturate_u_i64_f32(float f) {
+  return __builtin_wasm_trunc_saturate_u_i64_f32(f);
+  // WEBASSEMBLY: call i64 @llvm.wasm.trunc.saturate.unsigned.i64.f32(float %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+long long trunc_saturate_s_i64_f64(double f) {
+  return __builtin_wasm_trunc_saturate_s_i64_f64(f);
+  // WEBASSEMBLY: call i64 @llvm.wasm.trunc.saturate.signed.i64.f64(double %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+long long trunc_saturate_u_i64_f64(double f) {
+  return __builtin_wasm_trunc_saturate_u_i64_f64(f);
+  // WEBASSEMBLY: call i64 @llvm.wasm.trunc.saturate.unsigned.i64.f64(double %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
 int extract_lane_s_i8x16(i8x16 v) {
   return __builtin_wasm_extract_lane_s_i8x16(v, 13);
   // WEBASSEMBLY: extractelement <16 x i8> %v, i32 13
@@ -300,3 +348,27 @@
   // WEBASSEMBLY: call <2 x double> @llvm.sqrt.v2f64(<2 x double> %x)
   // WEBASSEMBLY: ret
 }
+
+i32x4 trunc_saturate_s_v4i32_v4f32(f32x4 f) {
+  return __builtin_wasm_trunc_saturate_s_v4i32_v4f32(f);
+  // WEBASSEMBLY: call <4 x i32> @llvm.wasm.trunc.saturate.signed.v4i32.v4f32(<4 x float> %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+i32x4 trunc_saturate_u_v4i32_v4f32(f32x4 f) {
+  return __builtin_wasm_trunc_saturate_u_v4i32_v4f32(f);
+  // WEBASSEMBLY: call <4 x i32> @llvm.wasm.trunc.saturate.unsigned.v4i32.v4f32(<4 x float> %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+i64x2 trunc_saturate_s_v2i64_v2f64(f64x2 f) {
+  return __builtin_wasm_trunc_saturate_s_v2i64_v2f64(f);
+  // WEBASSEMBLY: call <2 x i64> @llvm.wasm.trunc.saturate.signed.v2i64.v2f64(<2 x double> %f)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+i64x2 trunc_saturate_u_v2i64_v2f64(f64x2 f) {
+  return __builtin_wasm_trunc_saturate_u_v2i64_v2f64(f);
+  // WEBASSEMBLY: call <2 x i64> 

r344205 - [WebAssembly] Saturating float-to-int builtins

2018-10-10 Thread Thomas Lively via cfe-commits
Author: tlively
Date: Wed Oct 10 17:07:55 2018
New Revision: 344205

URL: http://llvm.org/viewvc/llvm-project?rev=344205=rev
Log:
[WebAssembly] Saturating float-to-int builtins

Summary: Depends on D53007 and D53004.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, kristina, cfe-commits

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

Modified:
cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/builtins-wasm.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def?rev=344205=344204=344205=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def Wed Oct 10 17:07:55 
2018
@@ -39,6 +39,16 @@ BUILTIN(__builtin_wasm_atomic_wait_i32,
 BUILTIN(__builtin_wasm_atomic_wait_i64, "iLLi*LLiLLi", "n")
 BUILTIN(__builtin_wasm_atomic_notify, "Uii*i", "n")
 
+// Saturating fp-to-int conversions
+BUILTIN(__builtin_wasm_trunc_saturate_s_i32_f32, "if", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i32_f32, "if", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_i32_f64, "id", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i32_f64, "id", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_i64_f32, "LLif", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i64_f32, "LLif", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_i64_f64, "LLid", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_i64_f64, "LLid", "nc")
+
 // SIMD builtins
 BUILTIN(__builtin_wasm_extract_lane_s_i8x16, "iV16cIi", "nc")
 BUILTIN(__builtin_wasm_extract_lane_u_i8x16, "iV16cIi", "nc")
@@ -81,4 +91,9 @@ BUILTIN(__builtin_wasm_abs_f64x2, "V2dV2
 BUILTIN(__builtin_wasm_sqrt_f32x4, "V4fV4f", "nc")
 BUILTIN(__builtin_wasm_sqrt_f64x2, "V2dV2d", "nc")
 
+BUILTIN(__builtin_wasm_trunc_saturate_s_v4i32_v4f32, "V4iV4f", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_v4i32_v4f32, "V4iV4f", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_s_v2i64_v2f64, "V2LLiV2d", "nc")
+BUILTIN(__builtin_wasm_trunc_saturate_u_v2i64_v2f64, "V2LLiV2d", "nc")
+
 #undef BUILTIN

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=344205=344204=344205=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Oct 10 17:07:55 2018
@@ -12456,6 +12456,30 @@ Value *CodeGenFunction::EmitWebAssemblyB
 Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_atomic_notify);
 return Builder.CreateCall(Callee, {Addr, Count});
   }
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_s_i32_f32:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_s_i32_f64:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_s_i64_f32:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_s_i64_f64:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_s_v4i32_v4f32:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_s_v2i64_v2f64: {
+Value *Src = EmitScalarExpr(E->getArg(0));
+llvm::Type *ResT = ConvertType(E->getType());
+Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_trunc_saturate_signed,
+ {ResT, Src->getType()});
+return Builder.CreateCall(Callee, {Src});
+  }
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_u_i32_f32:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_u_i32_f64:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_u_i64_f32:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_u_i64_f64:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_u_v4i32_v4f32:
+  case WebAssembly::BI__builtin_wasm_trunc_saturate_u_v2i64_v2f64: {
+Value *Src = EmitScalarExpr(E->getArg(0));
+llvm::Type *ResT = ConvertType(E->getType());
+Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_trunc_saturate_unsigned,
+ {ResT, Src->getType()});
+return Builder.CreateCall(Callee, {Src});
+  }
   case WebAssembly::BI__builtin_wasm_extract_lane_s_i8x16:
   case WebAssembly::BI__builtin_wasm_extract_lane_u_i8x16:
   case WebAssembly::BI__builtin_wasm_extract_lane_s_i16x8:

Modified: cfe/trunk/test/CodeGen/builtins-wasm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-wasm.c?rev=344205=344204=344205=diff
==
--- cfe/trunk/test/CodeGen/builtins-wasm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-wasm.c Wed Oct 10 17:07:55 2018
@@ -83,6 +83,54 @@ unsigned int atomic_notify(int *addr, in
   // WEBASSEMBLY64: call i32 @llvm.wasm.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
 }
 
+int trunc_saturate_s_i32_f32(float f) {
+  return __builtin_wasm_trunc_saturate_s_i32_f32(f);
+  // WEBASSEMBLY: 

[PATCH] D53115: [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsics

2018-10-10 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang updated this revision to Diff 169127.

https://reviews.llvm.org/D53115

Files:
  include/clang/Basic/BuiltinsAArch64.def
  lib/CodeGen/CGBuiltin.cpp
  lib/Headers/intrin.h
  lib/Sema/SemaChecking.cpp
  test/CodeGen/arm64-microsoft-status-reg.cpp
  test/Sema/builtins-microsoft-arm64.c

Index: test/Sema/builtins-microsoft-arm64.c
===
--- test/Sema/builtins-microsoft-arm64.c
+++ test/Sema/builtins-microsoft-arm64.c
@@ -7,3 +7,9 @@
   __getReg(-1); // expected-error-re {{argument value {{.*}} is outside the valid range}}
   __getReg(32); // expected-error-re {{argument value {{.*}} is outside the valid range}}
 }
+
+void check_ReadWriteStatusReg(int v) {
+  int x;
+  _ReadStatusReg(x); // expected-error {{argument to '_ReadStatusReg' must be a constant integer}}
+  _WriteStatusReg(x, v); // expected-error {{argument to '_WriteStatusReg' must be a constant integer}}
+}
Index: test/CodeGen/arm64-microsoft-status-reg.cpp
===
--- /dev/null
+++ test/CodeGen/arm64-microsoft-status-reg.cpp
@@ -0,0 +1,117 @@
+// RUN: %clang_cc1 -triple arm64-windows -fms-compatibility -emit-llvm -S \
+// RUN: -o - %s | FileCheck %s -check-prefix CHECK-ASM
+
+// RUN: %clang_cc1 -triple arm64-windows -fms-compatibility -emit-llvm \
+// RUN: -o - %s | FileCheck %s -check-prefix CHECK-IR
+
+// From winnt.h
+#define ARM64_SYSREG(op0, op1, crn, crm, op2) \
+( ((op0 & 1) << 14) | \
+  ((op1 & 7) << 11) | \
+  ((crn & 15) << 7) | \
+  ((crm & 15) << 3) | \
+  ((op2 & 7) << 0) )
+
+#define ARM64_CNTVCTARM64_SYSREG(3,3,14, 0,2)  // Generic Timer counter register
+#define ARM64_PMCCNTR_EL0   ARM64_SYSREG(3,3, 9,13,0)  // Cycle Count Register [CP15_PMCCNTR]
+#define ARM64_PMSELR_EL0ARM64_SYSREG(3,3, 9,12,5)  // Event Counter Selection Register [CP15_PMSELR]
+#define ARM64_PMXEVCNTR_EL0 ARM64_SYSREG(3,3, 9,13,2)  // Event Count Register [CP15_PMXEVCNTR]
+#define ARM64_PMXEVCNTRn_EL0(n) ARM64_SYSREG(3,3,14, 8+((n)/8), (n)%8)// Direct Event Count Register [n/a]
+#define ARM64_TPIDR_EL0 ARM64_SYSREG(3,3,13, 0,2)  // Thread ID Register, User Read/Write [CP15_TPIDRURW]
+#define ARM64_TPIDRRO_EL0   ARM64_SYSREG(3,3,13, 0,3)  // Thread ID Register, User Read Only [CP15_TPIDRURO]
+#define ARM64_TPIDR_EL1 ARM64_SYSREG(3,0,13, 0,4)  // Thread ID Register, Privileged Only [CP15_TPIDRPRW]
+
+void check_ReadWriteStatusReg(int v) {
+  int ret;
+  ret = _ReadStatusReg(ARM64_CNTVCT);
+// CHECK-ASM: mrs x8, CNTVCT_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD2:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMCCNTR_EL0);
+// CHECK-ASM: mrs x8, PMCCNTR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD3:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMSELR_EL0);
+// CHECK-ASM: mrs x8, PMSELR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD4:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTR_EL0);
+// CHECK-ASM: mrs x8, PMXEVCNTR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD5:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(0));
+// CHECK-ASM: mrs x8, PMEVCNTR0_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD6:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(1));
+// CHECK-ASM: mrs x8, PMEVCNTR1_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD7:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(30));
+// CHECK-ASM: mrs x8, PMEVCNTR30_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD8:.*]])
+
+  ret = _ReadStatusReg(ARM64_TPIDR_EL0);
+// CHECK-ASM: mrs x8, TPIDR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD9:.*]])
+
+  ret = _ReadStatusReg(ARM64_TPIDRRO_EL0);
+// CHECK-ASM: mrs x8, TPIDRRO_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD10:.*]])
+
+  ret = _ReadStatusReg(ARM64_TPIDR_EL1);
+// CHECK-ASM: mrs x8, TPIDR_EL1
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD11:.*]])
+
+
+  _WriteStatusReg(ARM64_CNTVCT, v);
+// CHECK-ASM: msr S3_3_C14_C0_2, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD2:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMCCNTR_EL0, v);
+// CHECK-ASM: msr PMCCNTR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD3:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMSELR_EL0, v);
+// CHECK-ASM: msr PMSELR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD4:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMXEVCNTR_EL0, v);
+// CHECK-ASM: msr PMXEVCNTR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD5:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMXEVCNTRn_EL0(0), v);
+// CHECK-ASM: msr PMEVCNTR0_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD6:.*]], i64 {{%.*}})
+
+  

r344201 - Update documentation to indicate that profile remapping support is only

2018-10-10 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Oct 10 16:33:18 2018
New Revision: 344201

URL: http://llvm.org/viewvc/llvm-project?rev=344201=rev
Log:
Update documentation to indicate that profile remapping support is only
implemented for the new pass manager so far.

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=344201=344200=344201=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Wed Oct 10 16:33:18 2018
@@ -1858,6 +1858,12 @@ profile data matching the updated progra
 
 .. note::
 
+  Profile data remapping support is currently only implemented for LLVM's
+  new pass manager, which can be enabled with
+  ``-fexperimental-new-pass-manager``.
+
+.. note::
+
   Profile data remapping is currently only supported for C++ mangled names
   following the Itanium C++ ABI mangling scheme. This covers all C++ targets
   supported by Clang other than Windows.


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


Re: r344199 - Add a flag to remap manglings when reading profile data information.

2018-10-10 Thread Friedman, Eli via cfe-commits

On 10/10/2018 4:13 PM, Richard Smith via cfe-commits wrote:

Author: rsmith
Date: Wed Oct 10 16:13:35 2018
New Revision: 344199

URL: http://llvm.org/viewvc/llvm-project?rev=344199=rev
Log:
Add a flag to remap manglings when reading profile data information.

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.


Should the documentation mention this limitation?

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

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


Re: [PATCH] D50901: [clang][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and signed checks

2018-10-10 Thread Filipe Cabecinhas via cfe-commits
LGTM on the clang side too.

Thank you,
 Filipe

On Wed, 10 Oct 2018 at 23:33, Richard Smith - zygoloid via Phabricator <
revi...@reviews.llvm.org> wrote:

> rsmith accepted this revision.
> rsmith added a comment.
> This revision is now accepted and ready to land.
>
> This looks good to me. Sounds like @filcab is intending on doing another
> round of review too, so it'd make sense to double-check there before
> committing.
>
>
>
> 
> Comment at: docs/UndefinedBehaviorSanitizer.rst:101
> + conversions - when either one, or both of the types are signed.
>   Issues caught by this sanitizer are not undefined behavior,
>   but are often unintentional.
> 
> this sanitizer -> these sanitizers
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D50901
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D50901: [clang][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and signed checks

2018-10-10 Thread Filipe Cabecinhas via Phabricator via cfe-commits
filcab added a comment.

LGTM on the clang side too.

Thank you,
Filipe


Repository:
  rC Clang

https://reviews.llvm.org/D50901



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


[PATCH] D53115: [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsics

2018-10-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Missing Sema changes?


Repository:
  rC Clang

https://reviews.llvm.org/D53115



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


r344199 - Add a flag to remap manglings when reading profile data information.

2018-10-10 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Oct 10 16:13:35 2018
New Revision: 344199

URL: http://llvm.org/viewvc/llvm-project?rev=344199=rev
Log:
Add a flag to remap manglings when reading profile data information.

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

Added:
cfe/trunk/test/CodeGenCXX/Inputs/profile-remap.map
cfe/trunk/test/CodeGenCXX/Inputs/profile-remap.proftext
cfe/trunk/test/CodeGenCXX/Inputs/profile-remap.samples
cfe/trunk/test/CodeGenCXX/profile-remap.cpp
Modified:
cfe/trunk/docs/ReleaseNotes.rst
cfe/trunk/docs/UsersManual.rst
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.h
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/clang_f_opts.c

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=344199=344198=344199=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Wed Oct 10 16:13:35 2018
@@ -46,6 +46,11 @@ sections with improvements to Clang's su
 Major New Features
 --
 
+- Clang supports use of a profile remapping file, which permits
+  profile data captured for one version of a program to be applied
+  when building another version where symbols have changed (for
+  example, due to renaming a class or namespace).
+  See the :doc:`UsersManual` for details.
 
 Improvements to Clang's diagnostics
 ^^^

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=344199=344198=344199=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Wed Oct 10 16:13:35 2018
@@ -1799,6 +1799,69 @@ In these cases, you can use the flag ``-
 Note that these flags should appear after the corresponding profile
 flags to have an effect.
 
+Profile remapping
+^
+
+When the program is compiled after a change that affects many symbol names,
+pre-existing profile data may no longer match the program. For example:
+
+ * switching from libstdc++ to libc++ will result in the mangled names of all
+   functions taking standard library types to change
+ * renaming a widely-used type in C++ will result in the mangled names of all
+   functions that have parameters involving that type to change
+ * moving from a 32-bit compilation to a 64-bit compilation may change the
+   underlying type of ``size_t`` and similar types, resulting in changes to
+   manglings
+
+Clang allows use of a profile remapping file to specify that such differences
+in mangled names should be ignored when matching the profile data against the
+program.
+
+.. option:: -fprofile-remapping-file=
+
+  Specifies a file containing profile remapping information, that will be
+  used to match mangled names in the profile data to mangled names in the
+  program.
+
+The profile remapping file is a text file containing lines of the form
+
+.. code-block::
+
+  fragmentkind fragment1 fragment2
+
+where ``fragmentkind`` is one of ``name``, ``type``, or ``encoding``,
+indicating whether the following mangled name fragments are
+<`name `>s,
+<`type `>s, or
+<`encoding 
`>s,
+respectively.
+
+Blank lines and lines starting with ``#`` are ignored.
+
+For example, to specify that ``absl::string_view`` and ``std::string_view``
+should be treated as equivalent when matching profile data, the following
+remapping file 

[PATCH] D52835: [Diagnostics] Check integer to floating point number implicit conversions

2018-10-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Probably should have a test for something like `float x = (__uint128_t)-1;`, to 
make sure we print something reasonable.




Comment at: lib/Sema/SemaChecking.cpp:10874
+  if (Target->isSpecificBuiltinType(BuiltinType::LongDouble))
+FloatSem = ::APFloat::x87DoubleExtended();
+

ASTContext::getFloatTypeSemantics.  (Your explicit computation here is both 
redundant and wrong.)


https://reviews.llvm.org/D52835



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


[PATCH] D53115: [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsics

2018-10-10 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang added inline comments.



Comment at: test/CodeGen/arm64-microsoft-status-reg.cpp:1
+// RUN: %clang_cc1 -triple arm64-windows -fms-compatibility -emit-llvm -S \
+// RUN: -o - %s | FileCheck %s -check-prefix CHECK-ASM

I had to create a new test file here as the existing file 
arm64-microsoft-intrinsics.cpp has a check for metadata and it seems I cannot 
have 2 different tests checking different metadata in the same test file.

If I understand correctly, when trying to match the metadata for one test the 
lit parser reaches the end of the generated IR and then cannot go up again to 
match the other checks.


Repository:
  rC Clang

https://reviews.llvm.org/D53115



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


[PATCH] D53115: [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsics

2018-10-10 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang added a comment.

_ReadStatusReg and _WriteStatusReg intrinsics take ARM64_REGNO as input. These 
are defined in https://www.codemachine.com/downloads/win10/winnt.h.
LLVM already has intrinsics to read/write status regs: 
__builtin_arm_rsr/__builtin_arm_wsr. But these take the string concatenation of 
the byte repesentation of a register (like "1:2:3:4:5"). So I convert 
ARM64_REGNO to this string format and invoke read_register/write_register 
intrinsics.


Repository:
  rC Clang

https://reviews.llvm.org/D53115



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


[PATCH] D53115: [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsics

2018-10-10 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang created this revision.
mgrang added reviewers: rnk, compnerd, mstorsjo, efriedma, TomTan, haripul.
Herald added a reviewer: javed.absar.
Herald added subscribers: chrib, kristof.beyls.

Repository:
  rC Clang

https://reviews.llvm.org/D53115

Files:
  include/clang/Basic/BuiltinsAArch64.def
  lib/CodeGen/CGBuiltin.cpp
  lib/Headers/intrin.h
  test/CodeGen/arm64-microsoft-status-reg.cpp

Index: test/CodeGen/arm64-microsoft-status-reg.cpp
===
--- /dev/null
+++ test/CodeGen/arm64-microsoft-status-reg.cpp
@@ -0,0 +1,117 @@
+// RUN: %clang_cc1 -triple arm64-windows -fms-compatibility -emit-llvm -S \
+// RUN: -o - %s | FileCheck %s -check-prefix CHECK-ASM
+
+// RUN: %clang_cc1 -triple arm64-windows -fms-compatibility -emit-llvm \
+// RUN: -o - %s | FileCheck %s -check-prefix CHECK-IR
+
+// From winnt.h
+#define ARM64_SYSREG(op0, op1, crn, crm, op2) \
+( ((op0 & 1) << 14) | \
+  ((op1 & 7) << 11) | \
+  ((crn & 15) << 7) | \
+  ((crm & 15) << 3) | \
+  ((op2 & 7) << 0) )
+
+#define ARM64_CNTVCTARM64_SYSREG(3,3,14, 0,2)  // Generic Timer counter register
+#define ARM64_PMCCNTR_EL0   ARM64_SYSREG(3,3, 9,13,0)  // Cycle Count Register [CP15_PMCCNTR]
+#define ARM64_PMSELR_EL0ARM64_SYSREG(3,3, 9,12,5)  // Event Counter Selection Register [CP15_PMSELR]
+#define ARM64_PMXEVCNTR_EL0 ARM64_SYSREG(3,3, 9,13,2)  // Event Count Register [CP15_PMXEVCNTR]
+#define ARM64_PMXEVCNTRn_EL0(n) ARM64_SYSREG(3,3,14, 8+((n)/8), (n)%8)// Direct Event Count Register [n/a]
+#define ARM64_TPIDR_EL0 ARM64_SYSREG(3,3,13, 0,2)  // Thread ID Register, User Read/Write [CP15_TPIDRURW]
+#define ARM64_TPIDRRO_EL0   ARM64_SYSREG(3,3,13, 0,3)  // Thread ID Register, User Read Only [CP15_TPIDRURO]
+#define ARM64_TPIDR_EL1 ARM64_SYSREG(3,0,13, 0,4)  // Thread ID Register, Privileged Only [CP15_TPIDRPRW]
+
+void check_ReadWriteStatusReg(int v) {
+  int ret;
+  ret = _ReadStatusReg(ARM64_CNTVCT);
+// CHECK-ASM: mrs x8, CNTVCT_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD2:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMCCNTR_EL0);
+// CHECK-ASM: mrs x8, PMCCNTR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD3:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMSELR_EL0);
+// CHECK-ASM: mrs x8, PMSELR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD4:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTR_EL0);
+// CHECK-ASM: mrs x8, PMXEVCNTR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD5:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(0));
+// CHECK-ASM: mrs x8, PMEVCNTR0_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD6:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(1));
+// CHECK-ASM: mrs x8, PMEVCNTR1_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD7:.*]])
+
+  ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(30));
+// CHECK-ASM: mrs x8, PMEVCNTR30_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD8:.*]])
+
+  ret = _ReadStatusReg(ARM64_TPIDR_EL0);
+// CHECK-ASM: mrs x8, TPIDR_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD9:.*]])
+
+  ret = _ReadStatusReg(ARM64_TPIDRRO_EL0);
+// CHECK-ASM: mrs x8, TPIDRRO_EL0
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD10:.*]])
+
+  ret = _ReadStatusReg(ARM64_TPIDR_EL1);
+// CHECK-ASM: mrs x8, TPIDR_EL1
+// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD11:.*]])
+
+
+  _WriteStatusReg(ARM64_CNTVCT, v);
+// CHECK-ASM: msr S3_3_C14_C0_2, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD2:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMCCNTR_EL0, v);
+// CHECK-ASM: msr PMCCNTR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD3:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMSELR_EL0, v);
+// CHECK-ASM: msr PMSELR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD4:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMXEVCNTR_EL0, v);
+// CHECK-ASM: msr PMXEVCNTR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD5:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMXEVCNTRn_EL0(0), v);
+// CHECK-ASM: msr PMEVCNTR0_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD6:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMXEVCNTRn_EL0(1), v);
+// CHECK-ASM: msr PMEVCNTR1_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD7:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_PMXEVCNTRn_EL0(30), v);
+// CHECK-ASM: msr PMEVCNTR30_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD8:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_TPIDR_EL0, v);
+// CHECK-ASM: msr TPIDR_EL0, x8
+// CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD9:.*]], i64 {{%.*}})
+
+  _WriteStatusReg(ARM64_TPIDRRO_EL0, v);
+// CHECK-ASM: msr TPIDRRO_EL0, 

[PATCH] D50766: Fix false positive unsequenced access and modification warning in array subscript expression.

2018-10-10 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.

Thanks, LGTM!

Are you interested in fixing the other cases for which p0145 tightened 
evaluation order (`.`, `->`, `.*`, `->*`, `<<`, `>>`, callee in a function 
call, assignment and compound assignment) too? =)


https://reviews.llvm.org/D50766



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


[PATCH] D50901: [clang][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and signed checks

2018-10-10 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.

This looks good to me. Sounds like @filcab is intending on doing another round 
of review too, so it'd make sense to double-check there before committing.




Comment at: docs/UndefinedBehaviorSanitizer.rst:101
+ conversions - when either one, or both of the types are signed.
  Issues caught by this sanitizer are not undefined behavior,
  but are often unintentional.

this sanitizer -> these sanitizers


Repository:
  rC Clang

https://reviews.llvm.org/D50901



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


[PATCH] D52835: [Diagnostics] Check integer to floating point number implicit conversions

2018-10-10 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

Any comments? Waiting for approval here to move focus on some other patches :)


https://reviews.llvm.org/D52835



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


[PATCH] D50766: Fix false positive unsequenced access and modification warning in array subscript expression.

2018-10-10 Thread Nicolas Lesser via Phabricator via cfe-commits
Rakete accepted this revision.
Rakete added a comment.
This revision is now accepted and ready to land.

Nevermind my last comment, I was tired. LGTM


https://reviews.llvm.org/D50766



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


r344190 - [AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals

2018-10-10 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Wed Oct 10 14:59:56 2018
New Revision: 344190

URL: http://llvm.org/viewvc/llvm-project?rev=344190=rev
Log:
[AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals

Summary:
In r340386 we added code to give static locals in inline functions
default visibility. Instead, we should use the "default" visibility
passed on the command line, which could be hidden or protected, as GCC
does.

Some code bases use both -fvisibility=hidden and
-fvisibility-inlines-hidden to hide inline functions of classes that are
explicitly marked with default visibility.

Fixes PR39236

Reviewers: hans, thakis

Subscribers: eraman, llvm-commits

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

Modified:
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=344190=344189=344190=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Wed Oct 10 14:59:56 2018
@@ -725,7 +725,7 @@ LinkageComputer::getLVForNamespaceScopeD
   // If we're paying attention to global visibility, apply
   // -finline-visibility-hidden if this is an inline method.
   if (useInlineVisibilityHidden(D))
-LV.mergeVisibility(HiddenVisibility, true);
+LV.mergeVisibility(HiddenVisibility, /*visibilityExplicit=*/false);
 }
   }
 
@@ -915,7 +915,7 @@ LinkageComputer::getLVForClassMember(con
 // Note that we do this before merging information about
 // the class visibility.
 if (!LV.isVisibilityExplicit() && useInlineVisibilityHidden(D))
-  LV.mergeVisibility(HiddenVisibility, true);
+  LV.mergeVisibility(HiddenVisibility, /*visibilityExplicit=*/false);
   }
 
   // If this class member has an explicit visibility attribute, the only
@@ -1265,14 +1265,24 @@ LinkageInfo LinkageComputer::getLVForLoc
 // If a function is hidden by -fvisibility-inlines-hidden option and
 // is not explicitly attributed as a hidden function,
 // we should not make static local variables in the function hidden.
+LV = getLVForDecl(FD, computation);
 if (isa(D) && useInlineVisibilityHidden(FD) &&
-!(!hasExplicitVisibilityAlready(computation) &&
-  getExplicitVisibility(FD, computation))) {
+!LV.isVisibilityExplicit()) {
   assert(cast(D)->isStaticLocal());
-  return LinkageInfo(VisibleNoLinkage, DefaultVisibility, false);
+  // If this was an implicitly hidden inline method, check again for
+  // explicit visibility on the parent class, and use that for static 
locals
+  // if present.
+  if (const auto *MD = dyn_cast(FD))
+LV = getLVForDecl(MD->getParent(), computation);
+  if (!LV.isVisibilityExplicit()) {
+Visibility globalVisibility =
+computation.isValueVisibility()
+? Context.getLangOpts().getValueVisibilityMode()
+: Context.getLangOpts().getTypeVisibilityMode();
+return LinkageInfo(VisibleNoLinkage, globalVisibility,
+   /*visibilityExplicit=*/false);
+  }
 }
-
-LV = getLVForDecl(FD, computation);
   }
   if (!isExternallyVisible(LV.getLinkage()))
 return LinkageInfo::none();

Modified: cfe/trunk/test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp?rev=344190=344189=344190=diff
==
--- cfe/trunk/test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp Wed Oct 
10 14:59:56 2018
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 
-fvisibility-inlines-hidden -emit-llvm -o - %s -O2 -disable-llvm-passes | 
FileCheck %s
 // RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -emit-llvm -o - %s 
-O2 -disable-llvm-passes | FileCheck -check-prefixes=CHECK-NO-VIH %s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -fvisibility hidden 
-fvisibility-inlines-hidden -emit-llvm -o - %s -O2 -disable-llvm-passes | 
FileCheck %s --check-prefix=CHECK-VIS-HIDDEN
+// RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -fvisibility 
protected -fvisibility-inlines-hidden -emit-llvm -o - %s -O2 
-disable-llvm-passes | FileCheck %s --check-prefix=CHECK-VIS-PROTECTED
 
 // When a function is hidden due to -fvisibility-inlines-hidden option, static 
local variables of the function should not be hidden by the option.
 
@@ -9,12 +11,15 @@
 // CHECK-DAG: @_ZZ11inline_funcvE3var = linkonce_odr global i32 0, comdat
 // CHECK-DAG: @_ZZ18inline_hidden_funcvE3var = linkonce_odr hidden global i32 
0, comdat
 // CHECK-DAG: @_ZZ19inline_default_funcvE3var = linkonce_odr global i32 0, 
comdat
+// 

[PATCH] D53052: [AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals

2018-10-10 Thread Reid Kleckner via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC344190: [AST] Use -fvisibility value when ignoring -fv-i-h* 
inline static locals (authored by rnk, committed by ).
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D53052?vs=169103=169104#toc

Repository:
  rC Clang

https://reviews.llvm.org/D53052

Files:
  lib/AST/Decl.cpp
  test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp

Index: test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp
===
--- test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp
+++ test/CodeGenCXX/visibility-inlines-hidden-staticvar.cpp
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -fvisibility-inlines-hidden -emit-llvm -o - %s -O2 -disable-llvm-passes | FileCheck %s
 // RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -emit-llvm -o - %s -O2 -disable-llvm-passes | FileCheck -check-prefixes=CHECK-NO-VIH %s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -fvisibility hidden -fvisibility-inlines-hidden -emit-llvm -o - %s -O2 -disable-llvm-passes | FileCheck %s --check-prefix=CHECK-VIS-HIDDEN
+// RUN: %clang_cc1 -triple i386-unknown-unknown -std=c++11 -fvisibility protected -fvisibility-inlines-hidden -emit-llvm -o - %s -O2 -disable-llvm-passes | FileCheck %s --check-prefix=CHECK-VIS-PROTECTED
 
 // When a function is hidden due to -fvisibility-inlines-hidden option, static local variables of the function should not be hidden by the option.
 
@@ -9,26 +11,63 @@
 // CHECK-DAG: @_ZZ11inline_funcvE3var = linkonce_odr global i32 0, comdat
 // CHECK-DAG: @_ZZ18inline_hidden_funcvE3var = linkonce_odr hidden global i32 0, comdat
 // CHECK-DAG: @_ZZ19inline_default_funcvE3var = linkonce_odr global i32 0, comdat
+// CHECK-DAG: @_ZZN13ExportedClass10inl_methodEvE3var = linkonce_odr global i32 0, comdat, align 4
 // CHECK-DAG: define i32 @_Z4funcv()
 // CHECK-DAG: define hidden i32 @_Z11hidden_funcv()
 // CHECK-DAG: define i32 @_Z12default_funcv()
 // CHECK-DAG: define linkonce_odr hidden i32 @_Z11inline_funcv()
 // CHECK-DAG: define linkonce_odr hidden i32 @_Z18inline_hidden_funcv()
 // CHECK-DAG: define linkonce_odr i32 @_Z19inline_default_funcv()
+// CHECK-DAG: define linkonce_odr hidden i32 @_ZN13ExportedClass10inl_methodEv({{.*}})
+// CHECK-DAG: define i32 @_ZN13ExportedClass10ext_methodEv({{.*}})
 
 // CHECK-NO-VIH-DAG: @_ZZ4funcvE3var = internal global i32 0
 // CHECK-NO-VIH-DAG: @_ZZ11hidden_funcvE3var = internal global i32 0
 // CHECK-NO-VIH-DAG: @_ZZ12default_funcvE3var = internal global i32 0
 // CHECK-NO-VIH-DAG: @_ZZ11inline_funcvE3var = linkonce_odr global i32 0, comdat
 // CHECK-NO-VIH-DAG: @_ZZ18inline_hidden_funcvE3var = linkonce_odr hidden global i32 0, comdat
 // CHECK-NO-VIH-DAG: @_ZZ19inline_default_funcvE3var = linkonce_odr global i32 0, comdat
+// CHECK-NO-VIH-DAG: @_ZZN13ExportedClass10inl_methodEvE3var = linkonce_odr global i32 0, comdat, align 4
 // CHECK-NO-VIH-DAG: define i32 @_Z4funcv()
 // CHECK-NO-VIH-DAG: define hidden i32 @_Z11hidden_funcv()
 // CHECK-NO-VIH-DAG: define i32 @_Z12default_funcv()
 // CHECK-NO-VIH-DAG: define linkonce_odr i32 @_Z11inline_funcv()
 // CHECK-NO-VIH-DAG: define linkonce_odr hidden i32 @_Z18inline_hidden_funcv()
 // CHECK-NO-VIH-DAG: define linkonce_odr i32 @_Z19inline_default_funcv()
+// CHECK-NO-VIH-DAG: define linkonce_odr i32 @_ZN13ExportedClass10inl_methodEv({{.*}})
+// CHECK-NO-VIH-DAG: define i32 @_ZN13ExportedClass10ext_methodEv({{.*}})
 
+// CHECK-VIS-HIDDEN-DAG: @_ZZ4funcvE3var = internal global i32 0
+// CHECK-VIS-HIDDEN-DAG: @_ZZ11hidden_funcvE3var = internal global i32 0
+// CHECK-VIS-HIDDEN-DAG: @_ZZ12default_funcvE3var = internal global i32 0
+// CHECK-VIS-HIDDEN-DAG: @_ZZ11inline_funcvE3var = linkonce_odr hidden global i32 0, comdat
+// CHECK-VIS-HIDDEN-DAG: @_ZZ18inline_hidden_funcvE3var = linkonce_odr hidden global i32 0, comdat
+// CHECK-VIS-HIDDEN-DAG: @_ZZ19inline_default_funcvE3var = linkonce_odr global i32 0, comdat
+// CHECK-VIS-HIDDEN-DAG: @_ZZN13ExportedClass10inl_methodEvE3var = linkonce_odr global i32 0, comdat, align 4
+// CHECK-VIS-HIDDEN-DAG: define hidden i32 @_Z4funcv()
+// CHECK-VIS-HIDDEN-DAG: define hidden i32 @_Z11hidden_funcv()
+// CHECK-VIS-HIDDEN-DAG: define i32 @_Z12default_funcv()
+// CHECK-VIS-HIDDEN-DAG: define linkonce_odr hidden i32 @_Z11inline_funcv()
+// CHECK-VIS-HIDDEN-DAG: define linkonce_odr hidden i32 @_Z18inline_hidden_funcv()
+// CHECK-VIS-HIDDEN-DAG: define linkonce_odr i32 @_Z19inline_default_funcv()
+// CHECK-VIS-HIDDEN-DAG: define linkonce_odr hidden i32 @_ZN13ExportedClass10inl_methodEv({{.*}})
+// CHECK-VIS-HIDDEN-DAG: define i32 @_ZN13ExportedClass10ext_methodEv({{.*}})
+
+// CHECK-VIS-PROTECTED-DAG: @_ZZ4funcvE3var = internal global i32 0
+// CHECK-VIS-PROTECTED-DAG: @_ZZ11hidden_funcvE3var = internal global i32 0
+// CHECK-VIS-PROTECTED-DAG: @_ZZ12default_funcvE3var = 

[PATCH] D53076: [analyzer] WIP: Enhance ConditionBRVisitor to write out more information

2018-10-10 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

In https://reviews.llvm.org/D53076#1260663, @george.karpenkov wrote:

> 1. Note that "Assuming X" directives are useful for the analyzer developers, 
> since they know that's where the checker makes arbitrary assumptions, but to 
> end users that mostly feels like noise ("Taking true branch" is there 
> already, why there should be "Assuming 'i' is > 0" as well?)


I believe that distinction between "Assuming..." (event piece, yellow bar in 
scan-build) and "Taking..." (control-flow piece, grey bar in scan-build, 
depicted with arrows //without text// in a number of other UIs) is useful for 
the users as well, not just for hackers. I agree that the distinction isn't 
obvious and for now this part of the UI is not very useful. But now that you're 
at it, i think it'd be better to fix this problem by making diagnostics more 
understandable rather than by simplifying out the distinction.

For example, in the `inline-plist.c`'s `bar()` on line 45, Static Analyzer 
indeed doesn't assume that `p` is equal to null; instead, Static Analyzer 
*knows* it for sure. There's no guess made here, and that's not an assumption 
that the user would need to agree or disagree with while looking at the report. 
Instead, it is an inevitable consequence of the previous events that occurred 
on this path. So i guess we could say something like "Knowing that 'p' is equal 
to null" or "'p' is inevitably null" and it should make the distinction 
apparent to the user. The user would notice that there's a change in the way 
we're talking about the fact.

The other reason why it's important is that those arbitrary assumptions are one 
of the fundamental weakness of the technique behind Static Analyzer: the user 
is indeed allowed to disagree with these assumptions and then mark the positive 
as false and suppress it with an assertion. In a code with a single branch such 
approach works fine because it is based on "presumption of no deadcode" (i.e., 
if there's an `if` in the code, both branches should be reached sometimes), but 
when there are N consequent branches, it is not necessary for all 2^N possible 
execution paths to be feasible: an O(N) number of paths can cover all the 
branches. But when it comes to actual facts that are inevitably true after the 
user has agreed with all previous assumptions on the path, the user can't 
disagree with those facts anymore, and that's an important piece of info to 
convey.

In https://reviews.llvm.org/D53076#1260663, @george.karpenkov wrote:

> 2. @NoQ do you know why the GDM comparison was there in the first place? The 
> commit was made by Ted in 2011, maybe constraint changes had to be reflected 
> in the GDM at that point (?)


It's likely that back then GDM only contained constraints and checker info (and 
program point kind guaranteed that checker info could not have changed). But 
that's not the case anymore (we have more core traits - dynamic type info, C++ 
constructor support, taint, etc.), so this code is definitely incorrect; not 
sure how often does it matter. In order to produce an actual correct logic, we 
probably need to add a method to `ConstraintManager` to ask whether constraints 
have changed between two states.


https://reviews.llvm.org/D53076



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


[PATCH] D53109: [Driver] Default Android toolchains to libc++.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert updated this revision to Diff 169097.
danalbert added a comment.

Fixed bad merge conflict resolution.


Repository:
  rC Clang

https://reviews.llvm.org/D53109

Files:
  lib/Driver/ToolChains/Linux.cpp
  lib/Driver/ToolChains/Linux.h
  test/Driver/android-ndk-standalone.cpp

Index: test/Driver/android-ndk-standalone.cpp
===
--- test/Driver/android-ndk-standalone.cpp
+++ test/Driver/android-ndk-standalone.cpp
@@ -2,21 +2,13 @@
 // toolchain.
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target arm-linux-androideabi21 -stdlib=libstdc++ \
+// RUN: -target arm-linux-androideabi21 \
 // RUN: -B%S/Inputs/basic_android_ndk_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
 // RUN:   | FileCheck  %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK: "-internal-isystem" "{{.*}}/include/c++/4.9"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
-// CHECK: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
-// CHECK: "-internal-isystem" "{{.*}}/include/c++/4.9/backward"
+// CHECK: "-internal-isystem" "{{.*}}/include/c++/v1"
 // CHECK: "-internal-isystem" "{{.*}}/sysroot/usr/local/include"
 // CHECK: "-internal-isystem" "[[RESOURCE_DIR]]{{(/|)}}include"
 // CHECK: "-internal-externc-isystem" "{{.*}}/sysroot/usr/include/arm-linux-androideabi"
@@ -49,21 +41,47 @@
 // CHECK-14: "-L{{.*}}/sysroot/usr/lib/arm-linux-androideabi"
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target armv7a-none-linux-androideabi21 -stdlib=libstdc++ \
+// RUN: -target arm-linux-androideabi21 -stdlib=libstdc++ \
+// RUN: -B%S/Inputs/basic_android_ndk_tree \
+// RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-STDCXX %s
+// CHECK-STDCXX: {{.*}}clang{{.*}}" "-cc1"
+// CHECK-STDCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
+// CHECK-STDCXX: "-internal-isystem" "{{.*}}/include/c++/4.9"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
+// CHECK-STDCXX: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
+// CHECK-STDCXX: "-internal-isystem" "{{.*}}/include/c++/4.9/backward"
+// CHECK-STDCXX: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/thumb"
+// CHECK-STDCXX: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/thumb"
+// CHECK-STDCXX: "-L{{.*}}/sysroot/usr/lib/arm-linux-androideabi/21"
+// CHECK-STDCXX: "-L{{.*}}/sysroot/usr/lib/arm-linux-androideabi"
+// CHECK-STDCXX: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/arm-linux-androideabi/lib"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/thumb"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target armv7a-none-linux-androideabi21 \
 // RUN: -B%S/Inputs/basic_android_ndk_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
 // RUN:   | FileCheck  

[PATCH] D53109: [Driver] Default Android toolchains to libc++.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert planned changes to this revision.
danalbert added a comment.

Oops, ignore this for a moment. Accidentally ran `check-cxx` instead of 
`check-clang`.


Repository:
  rC Clang

https://reviews.llvm.org/D53109



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


[PATCH] D50766: Fix false positive unsequenced access and modification warning in array subscript expression.

2018-10-10 Thread Nicolas Lesser via Phabricator via cfe-commits
Rakete added a comment.

Sorry, for some reason I didn't see your updates.

Can you add a test for C++17? Then your patch is good to go! :)


https://reviews.llvm.org/D50766



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


[PATCH] D53109: [Driver] Default Android toolchains to libc++.

2018-10-10 Thread Dan Albert via Phabricator via cfe-commits
danalbert created this revision.
danalbert added reviewers: srhines, pirama.
Herald added a reviewer: EricWF.

Repository:
  rC Clang

https://reviews.llvm.org/D53109

Files:
  lib/Driver/ToolChains/Linux.cpp
  lib/Driver/ToolChains/Linux.h
  test/Driver/android-ndk-standalone.cpp

Index: test/Driver/android-ndk-standalone.cpp
===
--- test/Driver/android-ndk-standalone.cpp
+++ test/Driver/android-ndk-standalone.cpp
@@ -2,21 +2,13 @@
 // toolchain.
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target arm-linux-androideabi21 -stdlib=libstdc++ \
+// RUN: -target arm-linux-androideabi21 \
 // RUN: -B%S/Inputs/basic_android_ndk_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
 // RUN:   | FileCheck  %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK: "-internal-isystem" "{{.*}}/include/c++/4.9"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
-// CHECK: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
-// CHECK-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
-// CHECK: "-internal-isystem" "{{.*}}/include/c++/4.9/backward"
+// CHECK: "-internal-isystem" "{{.*}}/include/c++/v1"
 // CHECK: "-internal-isystem" "{{.*}}/sysroot/usr/local/include"
 // CHECK: "-internal-isystem" "[[RESOURCE_DIR]]{{(/|)}}include"
 // CHECK: "-internal-externc-isystem" "{{.*}}/sysroot/usr/include/arm-linux-androideabi"
@@ -49,21 +41,47 @@
 // CHECK-14: "-L{{.*}}/sysroot/usr/lib/arm-linux-androideabi"
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target armv7a-none-linux-androideabi21 -stdlib=libstdc++ \
+// RUN: -target arm-linux-androideabi21 -stdlib=libstdc++ \
+// RUN: -B%S/Inputs/basic_android_ndk_tree \
+// RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-STDCXX %s
+// CHECK-STDCXX: {{.*}}clang{{.*}}" "-cc1"
+// CHECK-STDCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
+// CHECK-STDCXX: "-internal-isystem" "{{.*}}/include/c++/4.9"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
+// CHECK-STDCXX: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/armv7-a"
+// CHECK-STDCXX-NOT: "-internal-isystem" "{{.*}}/include/c++/4.9/arm-linux-androideabi/thumb"
+// CHECK-STDCXX: "-internal-isystem" "{{.*}}/include/c++/4.9/backward"
+// CHECK-STDCXX: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/thumb"
+// CHECK-STDCXX: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/thumb"
+// CHECK-STDCXX: "-L{{.*}}/sysroot/usr/lib/arm-linux-androideabi/21"
+// CHECK-STDCXX: "-L{{.*}}/sysroot/usr/lib/arm-linux-androideabi"
+// CHECK-STDCXX: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/arm-linux-androideabi/lib"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a/thumb"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/armv7-a"
+// CHECK-STDCXX-NOT: "-L{{.*}}/lib/gcc/arm-linux-androideabi/4.9/../{{[^ ]*}}/lib/thumb"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target armv7a-none-linux-androideabi21 \
 // RUN: -B%S/Inputs/basic_android_ndk_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_ndk_tree/sysroot \
 // RUN:   | FileCheck  

Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

2018-10-10 Thread Aaron Ballman via cfe-commits
On Wed, Oct 10, 2018 at 5:11 PM Zachary Turner  wrote:
>
> Yea, that’s actually another reason I suggest trying the Clang Power Tools 
> extension. It seems to have “won” in this area, and few people ever used the 
> LLVM one to begin with.

Given that this isn't being updated and it may not work, should this
be removed (with some public discussion in a more appropriate, new
thread) or left to bit rot? I can start the discussion and do the
removal if you agree that's the right approach here.

~Aaron

> On Wed, Oct 10, 2018 at 2:09 PM Aaron Ballman  wrote:
>>
>> On Wed, Oct 10, 2018 at 4:54 PM Zachary Turner  wrote:
>> >
>> > Honestly I hadn’t thought about this ever since the patch. Out of 
>> > curiosity, have you tried the clang power tools extension? I think it’s 
>> > more actively maintained and at this point probably even is good enough 
>> > that this one could just go away
>>
>> I've not tried either, truth be told. :-D This came up in GrammaTech
>> while I was reviewing someone's clang-tidy check for upstreaming.
>> Given how much I review clang-tidy checks on trunk, the fact that I
>> hadn't heard of this file surprised me so I did some code archaeology
>> and here we are. I don't have a strong opinion on whether this has
>> been superseded or not, but I probably should know whether clang-tidy
>> check authors are required to maintain this or not.
>>
>> Btw, I didn't see any bug reports about missing checks. In fact, the
>> only bug report I can find for clang-tidy-vs suggests it may not even
>> work. https://bugs.llvm.org/show_bug.cgi?id=34176
>>
>> ~Aaron
>>
>> > On Wed, Oct 10, 2018 at 1:52 PM Aaron Ballman  
>> > wrote:
>> >>
>> >> On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
>> >>  wrote:
>> >> >
>> >> > Author: zturner
>> >> > Date: Wed Sep  7 13:28:55 2016
>> >> > New Revision: 280840
>> >> >
>> >> > URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
>> >> > Log:
>> >> > Add a clang-tidy visual studio extension.
>> >> >
>> >> > For now this only adds the UI necessary to configure clang-tidy
>> >> > settings graphically, and it enables reading in and saving out
>> >> > of .clang-tidy files.  It does not actually run clang-tidy on
>> >> > any source files yet.
>> >>
>> >> Sorry to resurrect an old commit, but this commit added the following:
>> >>
>> >> Added: 
>> >> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
>> >> URL: 
>> >> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
>> >> ==
>> >> --- 
>> >> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
>> >> (added)
>> >> +++ 
>> >> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
>> >> Wed Sep  7 13:28:55 2016
>> >> @@ -0,0 +1,325 @@
>> >> +---
>> >> +Checks:
>> >> +   # This file should be updated when new checks are added, and
>> >> eventually we should
>> >> +   # generate this file automatically from the .rst files in clang-tidy.
>> >>
>> >> However, as best I can tell, this file is not reliably updated and is
>> >> currently *very* out of date (in fact, it's only been updated twice in
>> >> two years). You had mentioned in the review thread that you wanted to
>> >> think of a way to automate this from RST
>> >> (https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
>> >> you're still thinking on that and have a solution in mind? ;-)
>> >>
>> >> ~Aaron
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

2018-10-10 Thread Zachary Turner via cfe-commits
Yea, that’s actually another reason I suggest trying the Clang Power Tools
extension. It seems to have “won” in this area, and few people ever used
the LLVM one to begin with.
On Wed, Oct 10, 2018 at 2:09 PM Aaron Ballman 
wrote:

> On Wed, Oct 10, 2018 at 4:54 PM Zachary Turner  wrote:
> >
> > Honestly I hadn’t thought about this ever since the patch. Out of
> curiosity, have you tried the clang power tools extension? I think it’s
> more actively maintained and at this point probably even is good enough
> that this one could just go away
>
> I've not tried either, truth be told. :-D This came up in GrammaTech
> while I was reviewing someone's clang-tidy check for upstreaming.
> Given how much I review clang-tidy checks on trunk, the fact that I
> hadn't heard of this file surprised me so I did some code archaeology
> and here we are. I don't have a strong opinion on whether this has
> been superseded or not, but I probably should know whether clang-tidy
> check authors are required to maintain this or not.
>
> Btw, I didn't see any bug reports about missing checks. In fact, the
> only bug report I can find for clang-tidy-vs suggests it may not even
> work. https://bugs.llvm.org/show_bug.cgi?id=34176
>
> ~Aaron
>
> > On Wed, Oct 10, 2018 at 1:52 PM Aaron Ballman 
> wrote:
> >>
> >> On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
> >>  wrote:
> >> >
> >> > Author: zturner
> >> > Date: Wed Sep  7 13:28:55 2016
> >> > New Revision: 280840
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
> >> > Log:
> >> > Add a clang-tidy visual studio extension.
> >> >
> >> > For now this only adds the UI necessary to configure clang-tidy
> >> > settings graphically, and it enables reading in and saving out
> >> > of .clang-tidy files.  It does not actually run clang-tidy on
> >> > any source files yet.
> >>
> >> Sorry to resurrect an old commit, but this commit added the following:
> >>
> >> Added:
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> >> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
> >>
> ==
> >> ---
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> >> (added)
> >> +++
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> >> Wed Sep  7 13:28:55 2016
> >> @@ -0,0 +1,325 @@
> >> +---
> >> +Checks:
> >> +   # This file should be updated when new checks are added, and
> >> eventually we should
> >> +   # generate this file automatically from the .rst files in
> clang-tidy.
> >>
> >> However, as best I can tell, this file is not reliably updated and is
> >> currently *very* out of date (in fact, it's only been updated twice in
> >> two years). You had mentioned in the review thread that you wanted to
> >> think of a way to automate this from RST
> >> (https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
> >> you're still thinking on that and have a solution in mind? ;-)
> >>
> >> ~Aaron
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

2018-10-10 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.
Herald added a subscriber: arphaman.

This looks great, thanks!

In https://reviews.llvm.org/D36527#892395, @hamzasood wrote:

> Could you expand on your first point a bit more? Do you have an example that 
> shows the issue?


You have very little test coverage for the case where a lambda with explicit 
template parameters is used within another template. Eg, something like 
(untested):

  template constexpr T f() {
return []() { return V; }.operator()<12345>(); // expected-error {{no 
viable function}} expected-note {{candidate}}
  }
  static_assert(f() == 12345); // ok
  int *p = f(); // expected-note {{in instantiation of}}




Comment at: lib/AST/DeclCXX.cpp:1396-1397
+
+  return std::count_if(List->begin(), List->end(),
+   [](const NamedDecl *D) { return !D->isImplicit(); });
+}

Given that you've already assert-checked `is_partitioned`, maybe use a binary 
search here (eg, `lower_bound`)?



Comment at: lib/AST/DeclPrinter.cpp:107-108
 
-void printTemplateParameters(const TemplateParameterList *Params);
+void printTemplateParameters(const TemplateParameterList *Params,
+ bool OmitTemplateKW = false);
 void printTemplateArguments(const TemplateArgumentList ,

Nit: I'd prefer splitting this into two functions (one that prints 'template', 
calls the other, then prints a space, and the other to print the actual 
template parameters) rather than passing a boolean flag.



Comment at: lib/AST/ItaniumMangle.cpp:1710
+Out << "Ty";
+  }
+  else if (auto *Tn = dyn_cast(Decl)) {

No newline between `}` and `else`, please.



Comment at: lib/AST/ItaniumMangle.cpp:1752-1757
+const auto *List = Lambda->getGenericLambdaTemplateParameterList();
+assert(List && "Lambda says it has explicit template parameters, "
+   "but it doesn't have a template parameter list");
+for (auto It = List->begin(), End = It + ExplcitTemplateParamCount;
+ It != End;
+ ++It)

Might be nice to add an accessor that returns the range of explicit parameters. 
(The `if` surrounding this code would then also be redundant.)



Comment at: lib/Parse/ParseExprCXX.cpp:1139
+TemplateParams, LAngleLoc, RAngleLoc)) {
+  return ExprError();
+}

You need to do something here to leave the lambda scope that was pushed near 
the start of this function.



Comment at: unittests/AST/StmtPrinterTest.cpp:109
 
-::testing::AssertionResult
-PrintedStmtCXX98Matches(StringRef Code, const StatementMatcher ,
-StringRef ExpectedPrinted) {
-  std::vector Args;
-  Args.push_back("-std=c++98");
-  Args.push_back("-Wno-unused-value");
-  return PrintedStmtMatches(Code, Args, NodeMatch, ExpectedPrinted);
-}
-
-::testing::AssertionResult PrintedStmtCXX98Matches(
-  StringRef Code,
-  StringRef ContainingFunction,
-  StringRef ExpectedPrinted) {
-  std::vector Args;
-  Args.push_back("-std=c++98");
-  Args.push_back("-Wno-unused-value");
-  return PrintedStmtMatches(Code,
-Args,
-functionDecl(hasName(ContainingFunction),
- 
has(compoundStmt(has(stmt().bind("id"),
-ExpectedPrinted);
+enum class StdVer { CXX98, CXX11, CXX14, CXX17, CXX2a };
+

Please commit the refactoring portion of the changes to this file separately.


https://reviews.llvm.org/D36527



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


Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

2018-10-10 Thread Aaron Ballman via cfe-commits
On Wed, Oct 10, 2018 at 4:54 PM Zachary Turner  wrote:
>
> Honestly I hadn’t thought about this ever since the patch. Out of curiosity, 
> have you tried the clang power tools extension? I think it’s more actively 
> maintained and at this point probably even is good enough that this one could 
> just go away

I've not tried either, truth be told. :-D This came up in GrammaTech
while I was reviewing someone's clang-tidy check for upstreaming.
Given how much I review clang-tidy checks on trunk, the fact that I
hadn't heard of this file surprised me so I did some code archaeology
and here we are. I don't have a strong opinion on whether this has
been superseded or not, but I probably should know whether clang-tidy
check authors are required to maintain this or not.

Btw, I didn't see any bug reports about missing checks. In fact, the
only bug report I can find for clang-tidy-vs suggests it may not even
work. https://bugs.llvm.org/show_bug.cgi?id=34176

~Aaron

> On Wed, Oct 10, 2018 at 1:52 PM Aaron Ballman  wrote:
>>
>> On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
>>  wrote:
>> >
>> > Author: zturner
>> > Date: Wed Sep  7 13:28:55 2016
>> > New Revision: 280840
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
>> > Log:
>> > Add a clang-tidy visual studio extension.
>> >
>> > For now this only adds the UI necessary to configure clang-tidy
>> > settings graphically, and it enables reading in and saving out
>> > of .clang-tidy files.  It does not actually run clang-tidy on
>> > any source files yet.
>>
>> Sorry to resurrect an old commit, but this commit added the following:
>>
>> Added: 
>> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
>> URL: 
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
>> ==
>> --- 
>> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
>> (added)
>> +++ 
>> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
>> Wed Sep  7 13:28:55 2016
>> @@ -0,0 +1,325 @@
>> +---
>> +Checks:
>> +   # This file should be updated when new checks are added, and
>> eventually we should
>> +   # generate this file automatically from the .rst files in clang-tidy.
>>
>> However, as best I can tell, this file is not reliably updated and is
>> currently *very* out of date (in fact, it's only been updated twice in
>> two years). You had mentioned in the review thread that you wanted to
>> think of a way to automate this from RST
>> (https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
>> you're still thinking on that and have a solution in mind? ;-)
>>
>> ~Aaron
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

2018-10-10 Thread Zachary Turner via cfe-commits
Honestly I hadn’t thought about this ever since the patch. Out of
curiosity, have you tried the clang power tools extension? I think it’s
more actively maintained and at this point probably even is good enough
that this one could just go away
On Wed, Oct 10, 2018 at 1:52 PM Aaron Ballman 
wrote:

> On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
>  wrote:
> >
> > Author: zturner
> > Date: Wed Sep  7 13:28:55 2016
> > New Revision: 280840
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
> > Log:
> > Add a clang-tidy visual studio extension.
> >
> > For now this only adds the UI necessary to configure clang-tidy
> > settings graphically, and it enables reading in and saving out
> > of .clang-tidy files.  It does not actually run clang-tidy on
> > any source files yet.
>
> Sorry to resurrect an old commit, but this commit added the following:
>
> Added:
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> (added)
> +++
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> Wed Sep  7 13:28:55 2016
> @@ -0,0 +1,325 @@
> +---
> +Checks:
> +   # This file should be updated when new checks are added, and
> eventually we should
> +   # generate this file automatically from the .rst files in clang-tidy.
>
> However, as best I can tell, this file is not reliably updated and is
> currently *very* out of date (in fact, it's only been updated twice in
> two years). You had mentioned in the review thread that you wanted to
> think of a way to automate this from RST
> (https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
> you're still thinking on that and have a solution in mind? ;-)
>
> ~Aaron
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

2018-10-10 Thread Aaron Ballman via cfe-commits
On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
 wrote:
>
> Author: zturner
> Date: Wed Sep  7 13:28:55 2016
> New Revision: 280840
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
> Log:
> Add a clang-tidy visual studio extension.
>
> For now this only adds the UI necessary to configure clang-tidy
> settings graphically, and it enables reading in and saving out
> of .clang-tidy files.  It does not actually run clang-tidy on
> any source files yet.

Sorry to resurrect an old commit, but this commit added the following:

Added: 
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
==
--- 
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
(added)
+++ 
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
Wed Sep  7 13:28:55 2016
@@ -0,0 +1,325 @@
+---
+Checks:
+   # This file should be updated when new checks are added, and
eventually we should
+   # generate this file automatically from the .rst files in clang-tidy.

However, as best I can tell, this file is not reliably updated and is
currently *very* out of date (in fact, it's only been updated twice in
two years). You had mentioned in the review thread that you wanted to
think of a way to automate this from RST
(https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
you're still thinking on that and have a solution in mind? ;-)

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


[PATCH] D52773: clang-cl: Add /showFilenames option (PR31957)

2018-10-10 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.

lgtm




Comment at: lib/Driver/Job.cpp:319
+  if (PrintInputFilenames) {
+for (const char *Arg : InputFilenames)
+  llvm::outs() << llvm::sys::path::filename(Arg) << "\n";

Huh, a -cc1 action can have multiple inputs? Go figure.



Comment at: test/Driver/cl-showfilenames.c:7-8
+// multiple: cl-showfilenames.c
+// multiple-NEXT: wildcard1.c
+// multiple-NEXT: wildcard2.c

I think it'd be nice to have the test show that diagnostics come out 
interleaved between the filenames. You can use `#pragma message` in the input 
files or something else to create warnings.


https://reviews.llvm.org/D52773



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


[PATCH] D52193: RFC: [clang] Multithreaded compilation support

2018-10-10 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In https://reviews.llvm.org/D52193#1260933, @aganea wrote:

> I wrote a fully fledged crash reporting system which does that, so I know 
> that's possible. The tricky thing is to ensure 
> `Driver::generateCompilationDiagnostics()` doesn't touch potentially invalid 
> structures (if a crash occured) or allocate memory. The way around that is to 
> pre-allocate and pre-copy the structures that you will be accessing in the 
> case of a crash. But I don't see it as a hurdle in this case.


Our existing stack dumper breaks all kinds of rules in this area. It uses 
std::vectors to make the stack trace. As much as it pains me that it's not 110% 
correct, nobody has complained so far that they don't get stack traces from 
clang when it crashes asynchronously inside of malloc.

Nice, the numbers for avoiding -cc1 are pretty compelling. It would also make 
debugging easier. I'd love to never see that question again on cfe-dev.

To handle pre-processed source generation, the best idea I could come up with 
was to pre-allocate the "generate crash diagnostics" command line and then 
spawn off a child process in the signal/exception handler to the heavy lifting. 
We're not concerned about generating pre-processed source in cases of system 
low memory or instability, so the relative unreliability of creating a child 
process isn't a huge concern.


Repository:
  rC Clang

https://reviews.llvm.org/D52193



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


[PATCH] D52973: Add type_info predefined decl

2018-10-10 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In https://reviews.llvm.org/D52973#1259992, @mwasplund wrote:

> In https://reviews.llvm.org/D52973#1259909, @rsmith wrote:
>
> > Generally this looks good, but it needs an accompanying test.
>
>
> I was looking into that and trying to read up on the documentation for adding 
> tests. I think I understand the crazy comment RUN test invocation, but got 
> lost in the directory structure. Is there documentation on naming and placing 
> regression tests? At first glance it seems arbitrary to me if the file is 
> something like p6.cpp (which don't appear to be sequential) or 
> my-test-name.cpp.


The tests under test/CXX are organized by section and paragraph of the C++ 
standard (we also have subdirectories for TSes, which are organized likewise, 
and for DRs, which are organized by number). The tests outside test/CXX are 
organized by the relevant part or feature of the compiler. Since this is a 
modules-specific failure but it's not related to a specific part of the Modules 
TS (in fact, it's an interaction between an MSVC-compatibility hack and our 
Modules TS implementation), the best home for it is probably a test in 
test/Modules, which you can name after the behavior you're testing (eg, 
ms-compat-typeinfo.cpp or similar). All inputs to the test other than the main 
test file should go in test/Modules/Inputs, in a subdirectory named after the 
stem of the test file (eg, test/Modules/Inputs/ms-compat-typeinfo).


Repository:
  rC Clang

https://reviews.llvm.org/D52973



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


[PATCH] D52193: RFC: [clang] Multithreaded compilation support

2018-10-10 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

In https://reviews.llvm.org/D52193#1260862, @zturner wrote:

> I can try to get some timings from my machine.  How do we handle crash
>  recovery in the case where we don't spawn a child process?  I thought the
>  whole reason for spawning the cc1 driver as a separate process was so that
>  we could collect and report crash information in a nice way.  Not having
>  that seems like a heavy price to pay.


`clang.exe` has already a general exception handler (installed by 
`InitLLVM::InitLLVM/sys::PrintStackTraceOnErrorSignal`), which prints the 
callstack in case of a crash. So you wouldn't need the child process to do 
post-crash processing.

However, when running within a parent `clang.exe`, the parents calls 
`Driver::generateCompilationDiagnostics()` after a crash to create the repro 
(preprocessed source).

In a scenario where a single `clang.exe` is running (no child) we could modify 
`Driver::generateCompilationDiagnostics()` so it gets called from within the 
exception handler, and invoke a child process to collect the preprocessed 
source.

I wrote a fully fledged crash reporting system which does that, so I know 
that's possible. The tricky thing is to ensure 
`Driver::generateCompilationDiagnostics()` doesn't touch potentially invalid 
structures (if a crash occured) or allocate memory. The way around that is to 
pre-allocate and pre-copy the structures that you will be accessing in the case 
of a crash. But I don't see it as a hurdle in this case.


Repository:
  rC Clang

https://reviews.llvm.org/D52193



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


[PATCH] D52784: [ARM][AArch64] Pass through endianness flags to the GNU assembler

2018-10-10 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: lib/Driver/ToolChains/Gnu.cpp:543-549
+static const char* GetEndianArg(bool IsBigEndian, const ArgList ) {
+  if (Arg *A = Args.getLastArg(options::OPT_mlittle_endian,
+   options::OPT_mbig_endian)) {
+  IsBigEndian = !A->getOption().matches(options::OPT_mlittle_endian);
+  }
+  return (IsBigEndian) ? "-EB" : "-EL";
+}

If you passed `llvm::Triple` instead of `bool`, then I think you could do 
something like:

```
static const char* GetEndianArg(const llvm::Triple , const ArgList 
) {
  const bool IsBigEndian = triple == llvm::Triple::armeb ||
   triple == llvm::Triple::thumbeb ||
   triple == llvm::Triple::aarch64_be ||
   Args.getLastArg(options::OPT_mlittle_endian,
   
options::OPT_mbig_endian)->getOption().matches(options::OPT_mbig_endian);
  return IsBigEndian ? "-EB" : "-EL";
}
```

Might encapsulate the logic from the call sites better, but that's a minor nit.



Comment at: lib/Driver/ToolChains/Gnu.cpp:544-547
+  if (Arg *A = Args.getLastArg(options::OPT_mlittle_endian,
+   options::OPT_mbig_endian)) {
+  IsBigEndian = !A->getOption().matches(options::OPT_mlittle_endian);
+  }

Just so I understand this check, even if we didn't have a BE triple, we set 
`IsBigEndian` if `-mlittle-endian` was not set?  Is `-mlittle-endian` a default 
set flag, or does this set `"-EB"` even if no `-m*-endian` flag is specified (I 
think we want little-endian to be the default, and IIUC, this would change 
that)?


https://reviews.llvm.org/D52784



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


[PATCH] D53102: Support for the mno-tls-direct-seg-refs flag

2018-10-10 Thread Ruslan Nikolaev via Phabricator via cfe-commits
nruslan created this revision.
nruslan added reviewers: hans, craig.topper.
Herald added a subscriber: cfe-commits.

Allows to disable direct TLS segment access (%fs or %gs). GCC supports a 
similar flag, it can be useful in some circumstances, e.g. when a thread 
context block needs to be updated directly from user space. More info and 
specific use cases: https://bugs.llvm.org/show_bug.cgi?id=16145

There is another revision for LLVM as well.


Repository:
  rC Clang

https://reviews.llvm.org/D53102

Files:
  docs/ClangCommandLineReference.rst
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  lib/CodeGen/CGCall.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/indirect-tls-seg-refs.c
  test/Driver/indirect-tls-seg-refs.c

Index: test/Driver/indirect-tls-seg-refs.c
===
--- /dev/null
+++ test/Driver/indirect-tls-seg-refs.c
@@ -0,0 +1,7 @@
+// RUN: %clang -### %s 2>&1 | FileCheck %s -check-prefix=TLSDIRECT
+// RUN: %clang -### -mno-tls-direct-seg-refs -mtls-direct-seg-refs %s 2>&1 | FileCheck %s -check-prefix=TLSDIRECT
+// RUN: %clang -### -mtls-direct-seg-refs -mno-tls-direct-seg-refs %s 2>&1 | FileCheck %s -check-prefix=NO-TLSDIRECT
+// REQUIRES: clang-driver
+
+// NO-TLSDIRECT: -indirect-tls-seg-refs
+// TLSDIRECT-NOT: -indirect-tls-seg-refs
Index: test/CodeGen/indirect-tls-seg-refs.c
===
--- /dev/null
+++ test/CodeGen/indirect-tls-seg-refs.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -indirect-tls-seg-refs | FileCheck %s -check-prefix=NO-TLSDIRECT
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s -check-prefix=TLSDIRECT
+
+// NO-TLSDIRECT: attributes #{{[0-9]+}} = {{{.*}} "indirect-tls-seg-refs"
+// TLSDIRECT-NOT: attributes #{{[0-9]+}} = {{{.*}} "indirect-tls-seg-refs"
+
+void test1() {
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -614,6 +614,7 @@
   Opts.DisableLifetimeMarkers = Args.hasArg(OPT_disable_lifetimemarkers);
   Opts.DisableO0ImplyOptNone = Args.hasArg(OPT_disable_O0_optnone);
   Opts.DisableRedZone = Args.hasArg(OPT_disable_red_zone);
+  Opts.IndirectTlsSegRefs = Args.hasArg(OPT_indirect_tls_seg_refs);
   Opts.ForbidGuardVariables = Args.hasArg(OPT_fforbid_guard_variables);
   Opts.UseRegisterSizedBitfieldAccess = Args.hasArg(
 OPT_fuse_register_sized_bitfield_access);
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -1739,6 +1739,10 @@
   Args.hasArg(options::OPT_fapple_kext))
 CmdArgs.push_back("-disable-red-zone");
 
+  if (!Args.hasFlag(options::OPT_mtls_direct_seg_refs,
+  options::OPT_mno_tls_direct_seg_refs, true))
+CmdArgs.push_back("-indirect-tls-seg-refs");
+
   // Default to avoid implicit floating-point for kernel/kext code, but allow
   // that to be overridden with -mno-soft-float.
   bool NoImplicitFloat = (Args.hasArg(options::OPT_mkernel) ||
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1709,6 +1709,8 @@
 
   if (CodeGenOpts.DisableRedZone)
 FuncAttrs.addAttribute(llvm::Attribute::NoRedZone);
+  if (CodeGenOpts.IndirectTlsSegRefs)
+FuncAttrs.addAttribute("indirect-tls-seg-refs");
   if (CodeGenOpts.NoImplicitFloat)
 FuncAttrs.addAttribute(llvm::Attribute::NoImplicitFloat);
 
Index: include/clang/Frontend/CodeGenOptions.def
===
--- include/clang/Frontend/CodeGenOptions.def
+++ include/clang/Frontend/CodeGenOptions.def
@@ -62,6 +62,8 @@
 CODEGENOPT(DebugPassManager, 1, 0) ///< Prints debug information for the new
///< pass manager.
 CODEGENOPT(DisableRedZone, 1, 0) ///< Set when -mno-red-zone is enabled.
+CODEGENOPT(IndirectTlsSegRefs, 1, 0) ///< Set when -mno-tls-direct-seg-refs
+ ///< is specified.
 CODEGENOPT(DisableTailCalls  , 1, 0) ///< Do not emit tail calls.
 CODEGENOPT(NoEscapingBlockTailCalls, 1, 0) ///< Do not emit tail calls from
///< escaping blocks.
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -2006,6 +2006,8 @@
 def mno_pascal_strings : Flag<["-"], "mno-pascal-strings">,
   Alias;
 def mno_red_zone : Flag<["-"], "mno-red-zone">, Group;
+def mno_tls_direct_seg_refs : Flag<["-"], "mno-tls-direct-seg-refs">, Group,
+  HelpText<"Disable direct TLS access through segment registers">;

[PATCH] D53101: [ARC] Add option for enabling reduced register file mode

2018-10-10 Thread Tatyana Krasnukha via Phabricator via cfe-commits
tatyana-krasnukha created this revision.
tatyana-krasnukha added a reviewer: petecoup.
tatyana-krasnukha added a project: clang.
Herald added subscribers: cfe-commits, mgorny.
tatyana-krasnukha added a dependency: D53100: clang: Add ARCTargetInfo.

This option affects registers count for passing arguments.


Repository:
  rC Clang

https://reviews.llvm.org/D53101

Files:
  include/clang/Driver/Options.td
  lib/Basic/CMakeLists.txt
  lib/Basic/Targets.cpp
  lib/Basic/Targets/ARC.cpp
  lib/Basic/Targets/ARC.h
  lib/CodeGen/TargetInfo.cpp
  lib/Driver/CMakeLists.txt
  lib/Driver/ToolChains/Arch/ARC.cpp
  lib/Driver/ToolChains/Arch/ARC.h
  lib/Driver/ToolChains/Clang.cpp
  test/CodeGen/arc/arguments.c
  test/CodeGen/arc/struct-align.c
  test/CodeGen/target-data.c
  test/Driver/arc-target-features.c

Index: test/Driver/arc-target-features.c
===
--- test/Driver/arc-target-features.c
+++ test/Driver/arc-target-features.c
@@ -0,0 +1,5 @@
+// REQUIRES: arc-registered-target
+
+// RUN: %clang -target arc-unknown-unknown -### -S %s -mrf16 2>&1 | FileCheck %s -check-prefix=CHECK-RF16
+// CHECK-RF16: "-target-feature" "+rf16"
+// CHECK: #define __ARC_RF16__
Index: test/CodeGen/target-data.c
===
--- test/CodeGen/target-data.c
+++ test/CodeGen/target-data.c
@@ -151,6 +151,10 @@
 // RUN: %s | FileCheck %s -check-prefix=ARM-GNU
 // ARM-GNU: target datalayout = "e-m:e-p:32:32-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
 
+// RUN: %clang_cc1 -triple arc-unknown-unknown -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ARC
+// ARC: target datalayout = "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-f32:32:32-i64:32-f64:32-a:0:32-n32"
+
 // RUN: %clang_cc1 -triple hexagon-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=HEXAGON
 // HEXAGON: target datalayout = "e-m:e-p:32:32:32-a:0-n16:32-i64:64:64-i32:32:32-i16:16:16-i1:8:8-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v512:512:512-v1024:1024:1024-v2048:2048:2048"
Index: test/CodeGen/arc/struct-align.c
===
--- test/CodeGen/arc/struct-align.c
+++ test/CodeGen/arc/struct-align.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple arc-unknown-unknown %s -emit-llvm -o - \
+// RUN:   | FileCheck %s
+
+// 64-bit fields need only be 32-bit aligned for arc.
+
+typedef struct {
+  int aa;
+  double bb;
+} s1;
+
+// CHECK: define i32 @f1
+// CHECK: ret i32 12
+int f1() {
+  return sizeof(s1);
+}
+
+typedef struct {
+  int aa;
+  long long bb;
+} s2;
+// CHECK: define i32 @f2
+// CHECK: ret i32 12
+int f2() {
+  return sizeof(s2);
+}
+
Index: test/CodeGen/arc/arguments.c
===
--- test/CodeGen/arc/arguments.c
+++ test/CodeGen/arc/arguments.c
@@ -0,0 +1,135 @@
+// RUN: %clang_cc1 -triple arc-unknown-unknown %s -emit-llvm -o - \
+// RUN:   | FileCheck %s
+
+// Basic argument tests for ARC.
+
+// CHECK: define void @f0(i32 inreg %i, i32 inreg %j, i32 inreg %k.coerce0, i32 inreg %k.coerce1)
+void f0(int i, long j, long long k) {}
+
+typedef struct {
+  int aa;
+  int bb;
+} s1;
+// CHECK: define void @f1(i32 inreg %i.coerce0, i32 inreg %i.coerce1)
+void f1(s1 i) {}
+
+typedef struct {
+  char aa; char bb; char cc; char dd;
+} cs1;
+// CHECK: define void @cf1(i32 inreg %i.coerce)
+void cf1(cs1 i) {}
+
+typedef struct {
+  int cc;
+} s2;
+// CHECK: define void @f2(%struct.s2* noalias sret %agg.result)
+s2 f2() {
+  s2 foo;
+  return foo;
+}
+
+typedef struct {
+  int cc;
+  int dd;
+} s3;
+// CHECK: define void @f3(%struct.s3* noalias sret %agg.result)
+s3 f3() {
+  s3 foo;
+  return foo;
+}
+
+// CHECK: define void @f4(i32 inreg %i.coerce0, i32 inreg %i.coerce1)
+void f4(long long i) {}
+
+// CHECK: define void @f5(i8 inreg signext %a, i16 inreg signext %b)
+void f5(signed char a, short b) {}
+
+// CHECK: define void @f6(i8 inreg zeroext %a, i16 inreg zeroext %b)
+void f6(unsigned char a, unsigned short b) {}
+
+enum my_enum {
+  ENUM1,
+  ENUM2,
+  ENUM3,
+};
+// Enums should be treated as the underlying i32.
+// CHECK: define void @f7(i32 inreg %a)
+void f7(enum my_enum a) {}
+
+enum my_big_enum {
+  ENUM4 = 0x,
+};
+// Big enums should be treated as the underlying i64.
+// CHECK: define void @f8(i32 inreg %a.coerce0, i32 inreg %a.coerce1)
+void f8(enum my_big_enum a) {}
+
+union simple_union {
+  int a;
+  char b;
+};
+// Unions should be passed inreg.
+// CHECK: define void @f9(i32 inreg %s.coerce)
+void f9(union simple_union s) {}
+
+typedef struct {
+  int b4 : 4;
+  int b3 : 3;
+  int b8 : 8;
+} bitfield1;
+// Bitfields should be passed inreg.
+// CHECK: define void @f10(i32 inreg %bf1.coerce)
+void f10(bitfield1 bf1) {}
+
+// CHECK: define inreg { float, float } @cplx1(float inreg %r)
+_Complex float cplx1(float r) {
+  return r + 2.0fi;
+}
+
+// CHECK: define inreg { double, double } @cplx2(i32 

[PATCH] D52193: RFC: [clang] Multithreaded compilation support

2018-10-10 Thread Zachary Turner via Phabricator via cfe-commits
zturner added a comment.

I can try to get some timings from my machine.  How do we handle crash
recovery in the case where we don't spawn a child process?  I thought the
whole reason for spawning the cc1 driver as a separate process was so that
we could collect and report crash information in a nice way.  Not having
that seems like a heavy price to pay.


Repository:
  rC Clang

https://reviews.llvm.org/D52193



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


Re: [PATCH] D52193: RFC: [clang] Multithreaded compilation support

2018-10-10 Thread Zachary Turner via cfe-commits
I can try to get some timings from my machine.  How do we handle crash
recovery in the case where we don't spawn a child process?  I thought the
whole reason for spawning the cc1 driver as a separate process was so that
we could collect and report crash information in a nice way.  Not having
that seems like a heavy price to pay.

On Wed, Oct 10, 2018 at 11:34 AM Alexandre Ganea via Phabricator <
revi...@reviews.llvm.org> wrote:

> aganea added a comment.
>
> Updated tests again. This time I've closed all applications, all unused
> services, and tried to have a "clean" machine.
>
> New timings without the child `clang-cl.exe` being invoked (hacked from
> https://reviews.llvm.org/D52411). The test consists in building
> Clang+LLVM+LLD at r343846 using the compiler specified on each line of the
> table.
>
> **Config 1:** Intel Xeon Haswell 6 cores / 12 HW threads, 3.5 GHz, 15 MB
> cache, 128 GB RAM, SSD 550 MB/s (Windows 10 Fall Creators update 1709)
>
> __Ninja:__
>
> | MSVC 15.8.6 (cl + link)
>| 29 min 4 sec  |
> | clang-cl + lld-link 7.0 official release
> | 25 min 45 sec |
> | clang-cl + lld-link 8.0 r343846 //built with clang-cl 7.0 official//
> **(no child)** | **23 min 27 sec** |
> |
>
> **Config 2:** Intel Xeon Skylake 18 cores / 36 HW threads, x2 (Dual CPU),
> 72 HW threads total, 2.3 GHz, 24.75 MB cache each, 128 GB RAM, NVMe SSD 4.6
> GB/s (Windows 10 Fall Creators update 1709)
>
> __Ninja:__
>
> | MSVC 15.8.6 (cl + link)
>| 6 min 40 sec |
> | clang-cl + lld-link 7.0 official release
> | 6 min 24 sec |
> | clang-cl + lld-link 8.0 r343846 //built with clang-cl 7.0 official//
> **(no child)** | **5 min 10 sec** |
> |
>
> I'm wondering if the improvement is of the same order on Linux. I'd be
> interested to see your build times, out of curiosity? Can any of you try it
> with and without https://reviews.llvm.org/D52411?
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D52193
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D53076: [analyzer] WIP: Enhance ConditionBRVisitor to write out more information

2018-10-10 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added subscribers: baloghadamsoftware, whisperity.
Charusso added a comment.

In https://reviews.llvm.org/D53076#1260663, @george.karpenkov wrote:

> The change makes sense to me, but:
>
> 1. Note that "Assuming X" directives are useful for the analyzer developers, 
> since they know that's where the checker makes arbitrary assumptions, but to 
> end users that mostly feels like noise ("Taking true branch" is there 
> already, why there should be "Assuming 'i' is > 0" as well?)
> 2. @NoQ do you know why the GDM comparison was there in the first place? The 
> commit was made by Ted in 2011, maybe constraint changes had to be reflected 
> in the GDM at that point (?)


Based on @baloghadamsoftware's idea (https://reviews.llvm.org/D34508) the main 
goal is to print out trivial values for the Clang SA, but lot of time consuming 
nonsense for developers. As you mentioned it is bad to have multiple 
assumptions, but half of the reporters behave like that, and the other half 
does not print any/useful information.

That two separate project based on that current project: **create** the 
reports, and make the style identical, so that we could enhance them. The best 
example here is `test/Analysis/diagnostics/macros.cpp`: on line 27 you could 
see the message `Assuming the condition is true` but the upper conditions miss 
this report.


https://reviews.llvm.org/D53076



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


[PATCH] D53100: clang: Add ARCTargetInfo

2018-10-10 Thread Tatyana Krasnukha via Phabricator via cfe-commits
tatyana-krasnukha created this revision.
tatyana-krasnukha added reviewers: petecoup, rjmccall, rsmith.
tatyana-krasnukha added a project: clang.
Herald added subscribers: cfe-commits, mgorny.

This patch is an updated version of https://reviews.llvm.org/D43089 with 
changes in arguments classifying. If a calling convention item is not specified 
by ARC ABI, it follows Itanium C++ ABI.


Repository:
  rC Clang

https://reviews.llvm.org/D53100

Files:
  lib/Basic/CMakeLists.txt
  lib/Basic/Targets.cpp
  lib/Basic/Targets/ARC.cpp
  lib/Basic/Targets/ARC.h
  lib/CodeGen/TargetInfo.cpp
  test/CodeGen/arc/arguments.c
  test/CodeGen/arc/struct-align.c
  test/CodeGen/target-data.c

Index: test/CodeGen/target-data.c
===
--- test/CodeGen/target-data.c
+++ test/CodeGen/target-data.c
@@ -151,6 +151,10 @@
 // RUN: %s | FileCheck %s -check-prefix=ARM-GNU
 // ARM-GNU: target datalayout = "e-m:e-p:32:32-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
 
+// RUN: %clang_cc1 -triple arc-unknown-unknown -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=ARC
+// ARC: target datalayout = "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-f32:32:32-i64:32-f64:32-a:0:32-n32"
+
 // RUN: %clang_cc1 -triple hexagon-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=HEXAGON
 // HEXAGON: target datalayout = "e-m:e-p:32:32:32-a:0-n16:32-i64:64:64-i32:32:32-i16:16:16-i1:8:8-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v512:512:512-v1024:1024:1024-v2048:2048:2048"
Index: test/CodeGen/arc/struct-align.c
===
--- test/CodeGen/arc/struct-align.c
+++ test/CodeGen/arc/struct-align.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple arc-unknown-unknown %s -emit-llvm -o - \
+// RUN:   | FileCheck %s
+
+// 64-bit fields need only be 32-bit aligned for arc.
+
+typedef struct {
+  int aa;
+  double bb;
+} s1;
+
+// CHECK: define i32 @f1
+// CHECK: ret i32 12
+int f1() {
+  return sizeof(s1);
+}
+
+typedef struct {
+  int aa;
+  long long bb;
+} s2;
+// CHECK: define i32 @f2
+// CHECK: ret i32 12
+int f2() {
+  return sizeof(s2);
+}
+
Index: test/CodeGen/arc/arguments.c
===
--- test/CodeGen/arc/arguments.c
+++ test/CodeGen/arc/arguments.c
@@ -0,0 +1,135 @@
+// RUN: %clang_cc1 -triple arc-unknown-unknown %s -emit-llvm -o - \
+// RUN:   | FileCheck %s
+
+// Basic argument tests for ARC.
+
+// CHECK: define void @f0(i32 inreg %i, i32 inreg %j, i32 inreg %k.coerce0, i32 inreg %k.coerce1)
+void f0(int i, long j, long long k) {}
+
+typedef struct {
+  int aa;
+  int bb;
+} s1;
+// CHECK: define void @f1(i32 inreg %i.coerce0, i32 inreg %i.coerce1)
+void f1(s1 i) {}
+
+typedef struct {
+  char aa; char bb; char cc; char dd;
+} cs1;
+// CHECK: define void @cf1(i32 inreg %i.coerce)
+void cf1(cs1 i) {}
+
+typedef struct {
+  int cc;
+} s2;
+// CHECK: define void @f2(%struct.s2* noalias sret %agg.result)
+s2 f2() {
+  s2 foo;
+  return foo;
+}
+
+typedef struct {
+  int cc;
+  int dd;
+} s3;
+// CHECK: define void @f3(%struct.s3* noalias sret %agg.result)
+s3 f3() {
+  s3 foo;
+  return foo;
+}
+
+// CHECK: define void @f4(i32 inreg %i.coerce0, i32 inreg %i.coerce1)
+void f4(long long i) {}
+
+// CHECK: define void @f5(i8 inreg signext %a, i16 inreg signext %b)
+void f5(signed char a, short b) {}
+
+// CHECK: define void @f6(i8 inreg zeroext %a, i16 inreg zeroext %b)
+void f6(unsigned char a, unsigned short b) {}
+
+enum my_enum {
+  ENUM1,
+  ENUM2,
+  ENUM3,
+};
+// Enums should be treated as the underlying i32.
+// CHECK: define void @f7(i32 inreg %a)
+void f7(enum my_enum a) {}
+
+enum my_big_enum {
+  ENUM4 = 0x,
+};
+// Big enums should be treated as the underlying i64.
+// CHECK: define void @f8(i32 inreg %a.coerce0, i32 inreg %a.coerce1)
+void f8(enum my_big_enum a) {}
+
+union simple_union {
+  int a;
+  char b;
+};
+// Unions should be passed inreg.
+// CHECK: define void @f9(i32 inreg %s.coerce)
+void f9(union simple_union s) {}
+
+typedef struct {
+  int b4 : 4;
+  int b3 : 3;
+  int b8 : 8;
+} bitfield1;
+// Bitfields should be passed inreg.
+// CHECK: define void @f10(i32 inreg %bf1.coerce)
+void f10(bitfield1 bf1) {}
+
+// CHECK: define inreg { float, float } @cplx1(float inreg %r)
+_Complex float cplx1(float r) {
+  return r + 2.0fi;
+}
+
+// CHECK: define inreg { double, double } @cplx2(i32 inreg %r.coerce0, i32 inreg %r.coerce1)
+_Complex double cplx2(double r) {
+  return r + 2.0i;
+}
+
+// CHECK: define inreg { i32, i32 } @cplx3(i32 inreg %r)
+_Complex int cplx3(int r) {
+  return r + 2i;
+}
+
+// CHECK: define inreg { i64, i64 } @cplx4(i32 inreg %r.coerce0, i32 inreg %r.coerce1)
+_Complex long long cplx4(long long r) {
+  return r + 2i;
+}
+
+// CHECK: define inreg { i8, i8 } @cplx6(i8 inreg signext %r)
+_Complex signed char cplx6(signed char r) {
+  return r + 2i;
+}
+
+// CHECK: define inreg { i16, i16 } @cplx7(i16 

[PATCH] D52193: RFC: [clang] Multithreaded compilation support

2018-10-10 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

Updated tests again. This time I've closed all applications, all unused 
services, and tried to have a "clean" machine.

New timings without the child `clang-cl.exe` being invoked (hacked from 
https://reviews.llvm.org/D52411). The test consists in building Clang+LLVM+LLD 
at r343846 using the compiler specified on each line of the table.

**Config 1:** Intel Xeon Haswell 6 cores / 12 HW threads, 3.5 GHz, 15 MB cache, 
128 GB RAM, SSD 550 MB/s (Windows 10 Fall Creators update 1709)

__Ninja:__

| MSVC 15.8.6 (cl + link)   
  | 29 min 4 sec  |
| clang-cl + lld-link 7.0 official release  
  | 25 min 45 sec |
| clang-cl + lld-link 8.0 r343846 //built with clang-cl 7.0 official// **(no 
child)** | **23 min 27 sec** |
|

**Config 2:** Intel Xeon Skylake 18 cores / 36 HW threads, x2 (Dual CPU), 72 HW 
threads total, 2.3 GHz, 24.75 MB cache each, 128 GB RAM, NVMe SSD 4.6 GB/s 
(Windows 10 Fall Creators update 1709)

__Ninja:__

| MSVC 15.8.6 (cl + link)   
  | 6 min 40 sec |
| clang-cl + lld-link 7.0 official release  
  | 6 min 24 sec |
| clang-cl + lld-link 8.0 r343846 //built with clang-cl 7.0 official// **(no 
child)** | **5 min 10 sec** |
|

I'm wondering if the improvement is of the same order on Linux. I'd be 
interested to see your build times, out of curiosity? Can any of you try it 
with and without https://reviews.llvm.org/D52411?


Repository:
  rC Clang

https://reviews.llvm.org/D52193



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


[PATCH] D52984: [analyzer] Checker reviewer's checklist

2018-10-10 Thread Umann Kristóf via Phabricator via cfe-commits
Szelethus added a comment.

I noticed it too, it's already on my TODO list. Didn't look into the causes 
just yet though.


https://reviews.llvm.org/D52984



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


[PATCH] D52784: [ARM][AArch64] Pass through endianness flags to the GNU assembler

2018-10-10 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

I think we should pass these flags along to the linker, too. Not just the 
assembler.  Maybe within tools::gnutools::Linker::ConstructJob() within 
lib/Driver/ToolChains/Gnu.cpp?


https://reviews.llvm.org/D52784



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


[PATCH] D46027: [clang-tidy] Fix PR35824

2018-10-10 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

In https://reviews.llvm.org/D46027#1259989, @ZaMaZaN4iK wrote:

> What is the status of the PR?


I believe xazax doesnt have time to work further, you can commandeer if you 
want :)


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D46027



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


[PATCH] D52984: [analyzer] Checker reviewer's checklist

2018-10-10 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.
Herald added a subscriber: donat.nagy.

@Szelethus @xazax.hun Since you guys are looking into the website, do you know 
why the top bar has disappeared from all pages? (E.g. 
http://clang-analyzer.llvm.org/available_checks.html )


https://reviews.llvm.org/D52984



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


[PATCH] D53069: [analyzer][www] Update avaible_checks.html

2018-10-10 Thread Umann Kristóf via Phabricator via cfe-commits
Szelethus added a comment.

Well, the reason why I didn't add tests for these, is that I know so little of 
ObjC, I am not even sure when a test case begins and ends. I could go ahead and 
google something about the language, but for a site that advertises to find 
bugs, maybe someone with more expertise should do the explanation.

Can someone fill those couple bits in? I tried, but fell flat on my face.




Comment at: www/analyzer/available_checks.html:770
+(ObjC)
+Check for proper uses of Objective-C properties
+

george.karpenkov wrote:
> `proper uses` is not particularly descriptive?
Well, I copied it from the actual checker description :/ I genuinely have no 
idea how properties work in ObjC, so I can't really update it on my own.


https://reviews.llvm.org/D53069



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


[PATCH] D53069: [analyzer][www] Update avaible_checks.html

2018-10-10 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov requested changes to this revision.
george.karpenkov added a comment.
This revision now requires changes to proceed.
Herald added a subscriber: donat.nagy.

Great idea, thanks!

Should be good to go once examples are added, and implicit checks are removed.




Comment at: www/analyzer/available_checks.html:770
+(ObjC)
+Check for proper uses of Objective-C properties
+

`proper uses` is not particularly descriptive?



Comment at: www/analyzer/available_checks.html:884
+
+
+

Yep, not very useful without an example. I'm pretty sure the code and tests 
have one.



Comment at: www/analyzer/available_checks.html:988
 
+
+

Yeah, doesn't seem useful to the user.


https://reviews.llvm.org/D53069



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


r344159 - [clang] Fix failing attribute test on Windows

2018-10-10 Thread Louis Dionne via cfe-commits
Author: ldionne
Date: Wed Oct 10 10:37:37 2018
New Revision: 344159

URL: http://llvm.org/viewvc/llvm-project?rev=344159=rev
Log:
[clang] Fix failing attribute test on Windows

The test added in r344146 was failing because the ABI on Windows is
different, and that test includes ABI-specific details. The test now
harcodes which ABI to use so we can rely on those details.

Modified:
cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp

Modified: cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp?rev=344159=344158=344159=diff
==
--- cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp 
(original)
+++ cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp Wed Oct 
10 10:37:37 2018
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm %s -o - | 
FileCheck %s
 
 // PR39118
 // Make sure that attributes are properly applied to explicit template


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


[PATCH] D52676: [clang-format] tweaked another case of lambda formatting

2018-10-10 Thread Oleg Smolsky via Phabricator via cfe-commits
oleg.smolsky added a comment.

@djasper @klimek could you chime in please? This patch strives to cleanup a 
quirk in lambda formatting which pushes code too far to the right. Here is the 
problematic case:

  void f() {
something.something.something.Method(some_arg,
 [] {
 // the code here incurs
 // excessive wrapping
 // such as
 Method(
 some_med_arg,
 some_med_arg);
 some_var =
 some_expr + something;
});

Here everything is technically correct, yet the code looks bad due to excessive 
wrapping. Things look a lot better when the lambda body starts from a new line, 
which happens already in some cases. The patch this "from the next line" onto a 
few more cases.

The full discussion of the cases with @krasimir is above.

Thanks!


Repository:
  rC Clang

https://reviews.llvm.org/D52676



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


[PATCH] D52857: Deprecate 'set output foo' API of clang-query

2018-10-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

@steveire and I chatted over IRC and I wanted to capture another alternate 
proposal idea as part of the review (we did not reach agreement on this 
proposal, however). I've provided it side-by-side with the other proposals for 
comparison purposes.

  # Original proposal
  set dump-output true
  match foo(bar(baz())) # Uses one output format
  match bar(foo()) # Uses one output format
  set diag-output true
  set matcher-output true
  match foo(bar(baz())) # Uses all three output formats
  match bar(foo()) # Uses all three output formats
  set diag-output false
  set dump-output false
  match foo(bar(baz())) # Uses only matcher output
   
  # First Alternative
  set output dump
  match foo(bar(baz())) # Uses one output format
  match bar(foo()) # Uses one output format
  set output dump, diag, matcher
  match foo(bar(baz())) # Uses all three output formats
  match bar(foo()) # Uses all three output formats
  set output matcher
  match foo(bar(baz())) # Uses only matcher output
   
  # Second Alternative
  set output dump
  match foo(bar(baz())) # Uses one output format
  match bar(foo()) # Uses one output format
  set output diag toggle on
  set output matcher toggle on
  match foo(bar(baz())) # Uses all three output formats
  match bar(foo()) # Uses all three output formats
  set output matcher
  match foo(bar(baz())) # Uses only matcher output


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52857



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


[PATCH] D53076: [analyzer] WIP: Enhance ConditionBRVisitor to write out more information

2018-10-10 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

The change makes sense to me, but:

1. Note that "Assuming X" directives are useful for the analyzer developers, 
since they know that's where the checker makes arbitrary assumptions, but to 
end users that mostly feels like noise ("Taking true branch" is there already, 
why there should be "Assuming 'i' is > 0" as well?)

2. @NoQ do you know why the GDM comparison was there in the first place? The 
commit was made by Ted in 2011, maybe constraint changes had to be reflected in 
the GDM at that point (?)


https://reviews.llvm.org/D53076



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


[PATCH] D53046: [Sema] Fix an error-on-valid with friends and templates

2018-10-10 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL344157: [Sema] Fix a multiple definition bug with friends 
and templates (authored by epilk, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D53046?vs=168939=169037#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D53046

Files:
  cfe/trunk/include/clang/AST/DeclTemplate.h
  cfe/trunk/lib/AST/DeclTemplate.cpp
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/test/SemaCXX/friend-template-redecl.cpp

Index: cfe/trunk/lib/AST/DeclTemplate.cpp
===
--- cfe/trunk/lib/AST/DeclTemplate.cpp
+++ cfe/trunk/lib/AST/DeclTemplate.cpp
@@ -300,6 +300,42 @@
   return llvm::makeArrayRef(CommonPtr->InjectedArgs, Params->size());
 }
 
+void FunctionTemplateDecl::mergePrevDecl(FunctionTemplateDecl *Prev) {
+  using Base = RedeclarableTemplateDecl;
+
+  // If we haven't created a common pointer yet, then it can just be created
+  // with the usual method.
+  if (!Base::Common)
+return;
+
+  Common *ThisCommon = static_cast(Base::Common);
+  Common *PrevCommon = nullptr;
+  SmallVector PreviousDecls;
+  for (; Prev; Prev = Prev->getPreviousDecl()) {
+if (Prev->Base::Common) {
+  PrevCommon = static_cast(Prev->Base::Common);
+  break;
+}
+PreviousDecls.push_back(Prev);
+  }
+
+  // If the previous redecl chain hasn't created a common pointer yet, then just
+  // use this common pointer.
+  if (!PrevCommon) {
+for (auto *D : PreviousDecls)
+  D->Base::Common = ThisCommon;
+return;
+  }
+
+  // Ensure we don't leak any important state.
+  assert(ThisCommon->Specializations.size() == 0 &&
+ !ThisCommon->InstantiatedFromMember.getPointer() &&
+ !ThisCommon->InstantiatedFromMember.getInt() &&
+ "Can't merge incompatible declarations!");
+
+  Base::Common = PrevCommon;
+}
+
 //===--===//
 // ClassTemplateDecl Implementation
 //===--===//
Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -10022,11 +10022,17 @@
 if (FunctionTemplateDecl *OldTemplateDecl =
 dyn_cast(OldDecl)) {
   auto *OldFD = OldTemplateDecl->getTemplatedDecl();
-  NewFD->setPreviousDeclaration(OldFD);
-  adjustDeclContextForDeclaratorDecl(NewFD, OldFD);
   FunctionTemplateDecl *NewTemplateDecl
 = NewFD->getDescribedFunctionTemplate();
   assert(NewTemplateDecl && "Template/non-template mismatch");
+
+  // The call to MergeFunctionDecl above may have created some state in
+  // NewTemplateDecl that needs to be merged with OldTemplateDecl before we
+  // can add it as a redeclaration.
+  NewTemplateDecl->mergePrevDecl(OldTemplateDecl);
+
+  NewFD->setPreviousDeclaration(OldFD);
+  adjustDeclContextForDeclaratorDecl(NewFD, OldFD);
   if (NewFD->isCXXClassMember()) {
 NewFD->setAccess(OldTemplateDecl->getAccess());
 NewTemplateDecl->setAccess(OldTemplateDecl->getAccess());
Index: cfe/trunk/include/clang/AST/DeclTemplate.h
===
--- cfe/trunk/include/clang/AST/DeclTemplate.h
+++ cfe/trunk/include/clang/AST/DeclTemplate.h
@@ -1093,6 +1093,9 @@
   /// template.
   ArrayRef getInjectedTemplateArgs();
 
+  /// Merge our RedeclarableTemplateDecl::Common with \param Prev.
+  void mergePrevDecl(FunctionTemplateDecl *Prev);
+
   /// Create a function template node.
   static FunctionTemplateDecl *Create(ASTContext , DeclContext *DC,
   SourceLocation L,
Index: cfe/trunk/test/SemaCXX/friend-template-redecl.cpp
===
--- cfe/trunk/test/SemaCXX/friend-template-redecl.cpp
+++ cfe/trunk/test/SemaCXX/friend-template-redecl.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -std=c++17 -verify -emit-llvm-only %s
+
+// expected-no-diagnostics
+
+template  void bar(const T ) { foo(t); }
+
+template 
+struct HasFriend {
+  template 
+  friend void foo(const HasFriend ) noexcept(false);
+};
+
+template 
+void foo(const HasFriend ) noexcept(false) {}
+
+void f() {
+  HasFriend x;
+  foo(x);
+  bar(x);
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r344157 - [Sema] Fix a multiple definition bug with friends and templates

2018-10-10 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Wed Oct 10 10:17:51 2018
New Revision: 344157

URL: http://llvm.org/viewvc/llvm-project?rev=344157=rev
Log:
[Sema] Fix a multiple definition bug with friends and templates

The problem was that MergeFunctionDecl sometimes needs the injected template
arguments of a FunctionTemplateDecl, but is called before adding the new
template to the redecl chain. This leads to multiple common pointers in the same
redecl chain, each with their own identical instantiation. Fix this by merging
the the common state before inserting the new template into the redecl chain.

rdar://44810129

Differential revision: https://reviews.llvm.org/D53046

Added:
cfe/trunk/test/SemaCXX/friend-template-redecl.cpp
Modified:
cfe/trunk/include/clang/AST/DeclTemplate.h
cfe/trunk/lib/AST/DeclTemplate.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=344157=344156=344157=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Wed Oct 10 10:17:51 2018
@@ -1093,6 +1093,9 @@ public:
   /// template.
   ArrayRef getInjectedTemplateArgs();
 
+  /// Merge our RedeclarableTemplateDecl::Common with \param Prev.
+  void mergePrevDecl(FunctionTemplateDecl *Prev);
+
   /// Create a function template node.
   static FunctionTemplateDecl *Create(ASTContext , DeclContext *DC,
   SourceLocation L,

Modified: cfe/trunk/lib/AST/DeclTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclTemplate.cpp?rev=344157=344156=344157=diff
==
--- cfe/trunk/lib/AST/DeclTemplate.cpp (original)
+++ cfe/trunk/lib/AST/DeclTemplate.cpp Wed Oct 10 10:17:51 2018
@@ -300,6 +300,42 @@ ArrayRef FunctionTempl
   return llvm::makeArrayRef(CommonPtr->InjectedArgs, Params->size());
 }
 
+void FunctionTemplateDecl::mergePrevDecl(FunctionTemplateDecl *Prev) {
+  using Base = RedeclarableTemplateDecl;
+
+  // If we haven't created a common pointer yet, then it can just be created
+  // with the usual method.
+  if (!Base::Common)
+return;
+
+  Common *ThisCommon = static_cast(Base::Common);
+  Common *PrevCommon = nullptr;
+  SmallVector PreviousDecls;
+  for (; Prev; Prev = Prev->getPreviousDecl()) {
+if (Prev->Base::Common) {
+  PrevCommon = static_cast(Prev->Base::Common);
+  break;
+}
+PreviousDecls.push_back(Prev);
+  }
+
+  // If the previous redecl chain hasn't created a common pointer yet, then 
just
+  // use this common pointer.
+  if (!PrevCommon) {
+for (auto *D : PreviousDecls)
+  D->Base::Common = ThisCommon;
+return;
+  }
+
+  // Ensure we don't leak any important state.
+  assert(ThisCommon->Specializations.size() == 0 &&
+ !ThisCommon->InstantiatedFromMember.getPointer() &&
+ !ThisCommon->InstantiatedFromMember.getInt() &&
+ "Can't merge incompatible declarations!");
+
+  Base::Common = PrevCommon;
+}
+
 
//===--===//
 // ClassTemplateDecl Implementation
 
//===--===//

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=344157=344156=344157=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Wed Oct 10 10:17:51 2018
@@ -10022,11 +10022,17 @@ bool Sema::CheckFunctionDeclaration(Scop
 if (FunctionTemplateDecl *OldTemplateDecl =
 dyn_cast(OldDecl)) {
   auto *OldFD = OldTemplateDecl->getTemplatedDecl();
-  NewFD->setPreviousDeclaration(OldFD);
-  adjustDeclContextForDeclaratorDecl(NewFD, OldFD);
   FunctionTemplateDecl *NewTemplateDecl
 = NewFD->getDescribedFunctionTemplate();
   assert(NewTemplateDecl && "Template/non-template mismatch");
+
+  // The call to MergeFunctionDecl above may have created some state in
+  // NewTemplateDecl that needs to be merged with OldTemplateDecl before we
+  // can add it as a redeclaration.
+  NewTemplateDecl->mergePrevDecl(OldTemplateDecl);
+
+  NewFD->setPreviousDeclaration(OldFD);
+  adjustDeclContextForDeclaratorDecl(NewFD, OldFD);
   if (NewFD->isCXXClassMember()) {
 NewFD->setAccess(OldTemplateDecl->getAccess());
 NewTemplateDecl->setAccess(OldTemplateDecl->getAccess());

Added: cfe/trunk/test/SemaCXX/friend-template-redecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/friend-template-redecl.cpp?rev=344157=auto
==
--- 

[PATCH] D52784: [ARM][AArch64] Pass through endianness flags to the GNU assembler

2018-10-10 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

Ping. Does anyone have any changes they'd like me to make?


https://reviews.llvm.org/D52784



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


[PATCH] D52418: [driver][mips] Enable integrated assembler for MIPS64 except N32 ABI selected

2018-10-10 Thread Brad Smith via Phabricator via cfe-commits
brad added a comment.

IMHO it would be best to try and deal with as many known / exposed issues with 
the N32 support and then just enable IAS across the board. Then tackle any 
remaining issues as they come up.


Repository:
  rC Clang

https://reviews.llvm.org/D52418



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


[PATCH] D42242: Make libc++abi work with gcc's ARM unwind library

2018-10-10 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists closed this revision.
mclow.lists added a comment.

Committed as revision 344152


https://reviews.llvm.org/D42242



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


[PATCH] D46441: [clang][CodeGenCXX] Noalias attr for 'this' parameter

2018-10-10 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev added a comment.

@rsmith, thanks. Le'ts see if there is a need for the command-line option down 
the road.


Repository:
  rL LLVM

https://reviews.llvm.org/D46441



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


[PATCH] D52891: [AMDGPU] Add -fvisibility-amdgpu-non-kernel-functions

2018-10-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In https://reviews.llvm.org/D52891#1258070, @scott.linder wrote:

> I will update the patch to modify the HIP toolchain and to add tests for 
> global variables.
>
> As far as the semantics are concerned, are we OK with this being AMDGPU only? 
> I do not see a means of determining what is a "kernel" in a language-agnostic 
> way other than checking for our AMDGPU-specific calling convention. If there 
> is a more general mechanism, this could be implemented in 
> `LinkageComputer::getLVForNamespaceScopeDecl` instead. As it stands, it 
> sounds like being AMDGPU specific, but omitting `amdgpu` from the option name 
> is preferred?


The checking of kernel functions can be made target independent. For now we 
only need to consider OpenCL and CUDA/HIP.  We can check function attribute 
AT_CUDAGlobal and AT_OpenCLKernel. Then this option can be made target 
independent. HCC can add its own check out of tree.

> What about:
> 
>   -fvisibility-non-offload-functions=

This name looks good to me.


https://reviews.llvm.org/D52891



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


[PATCH] D52598: [OpenCL] Fixed address space cast in C style cast of C++ parsing

2018-10-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia closed this revision.
Anastasia added a comment.

Committed in r344148. The review link was forgotten and therefore didn't get 
closed automatically.


https://reviews.llvm.org/D52598



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


r344148 - [OpenCL] Fixed address space cast in C style cast of C++ parsing

2018-10-10 Thread Anastasia Stulova via cfe-commits
Author: stulova
Date: Wed Oct 10 09:05:22 2018
New Revision: 344148

URL: http://llvm.org/viewvc/llvm-project?rev=344148=rev
Log:
[OpenCL] Fixed address space cast in C style cast of C++ parsing

C style cast in OpenCL C++ was ignoring the address space
conversions from OpenCL C and as a result accepting incorrect
code to compile. This commit adds special function for checking 
correctness of address spaces that is shared between C and C++
casts.
 

Modified:
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
cfe/trunk/test/SemaOpenCL/address-spaces.cl

Modified: cfe/trunk/lib/Sema/SemaCast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=344148=344147=344148=diff
==
--- cfe/trunk/lib/Sema/SemaCast.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCast.cpp Wed Oct 10 09:05:22 2018
@@ -131,6 +131,9 @@ namespace {
   return PlaceholderKind == K;
 }
 
+// Language specific cast restrictions for address spaces.
+void checkAddressSpaceCast(QualType SrcType, QualType DestType);
+
 void checkCastAlign() {
   Self.CheckCastAlign(SrcExpr.get(), DestType, OpRange);
 }
@@ -2276,6 +2279,27 @@ static TryCastResult TryReinterpretCast(
   return SuccessResult;
 }
 
+void CastOperation::checkAddressSpaceCast(QualType SrcType, QualType DestType) 
{
+  // In OpenCL only conversions between pointers to objects in overlapping
+  // addr spaces are allowed. v2.0 s6.5.5 - Generic addr space overlaps
+  // with any named one, except for constant.
+  if (Self.getLangOpts().OpenCL) {
+auto SrcPtrType = SrcType->getAs();
+if (!SrcPtrType)
+  return;
+auto DestPtrType = DestType->getAs();
+if (!DestPtrType)
+  return;
+if (!DestPtrType->isAddressSpaceOverlapping(*SrcPtrType)) {
+  Self.Diag(OpRange.getBegin(),
+diag::err_typecheck_incompatible_address_space)
+  << SrcType << DestType << Sema::AA_Casting
+  << SrcExpr.get()->getSourceRange();
+  SrcExpr = ExprError();
+}
+  }
+}
+
 void CastOperation::CheckCXXCStyleCast(bool FunctionalStyle,
bool ListInitialization) {
   assert(Self.getLangOpts().CPlusPlus);
@@ -2403,6 +2427,8 @@ void CastOperation::CheckCXXCStyleCast(b
 }
   }
 
+  checkAddressSpaceCast(SrcExpr.get()->getType(), DestType);
+
   if (isValidCast(tcr)) {
 if (Kind == CK_BitCast)
   checkCastAlign();
@@ -2489,20 +2515,9 @@ void CastOperation::CheckCStyleCast() {
 
   assert(!SrcType->isPlaceholderType());
 
-  // OpenCL v1 s6.5: Casting a pointer to address space A to a pointer to
-  // address space B is illegal.
-  if (Self.getLangOpts().OpenCL && DestType->isPointerType() &&
-  SrcType->isPointerType()) {
-const PointerType *DestPtr = DestType->getAs();
-if (!DestPtr->isAddressSpaceOverlapping(*SrcType->getAs())) {
-  Self.Diag(OpRange.getBegin(),
-diag::err_typecheck_incompatible_address_space)
-  << SrcType << DestType << Sema::AA_Casting
-  << SrcExpr.get()->getSourceRange();
-  SrcExpr = ExprError();
-  return;
-}
-  }
+  checkAddressSpaceCast(SrcType, DestType);
+  if (SrcExpr.isInvalid())
+return;
 
   if (Self.RequireCompleteType(OpRange.getBegin(), DestType,
diag::err_typecheck_cast_to_incomplete)) {

Modified: cfe/trunk/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl?rev=344148=344147=344148=diff
==
--- cfe/trunk/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl (original)
+++ cfe/trunk/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl Wed Oct 10 
09:05:22 2018
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=CL2.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=CL2.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=CL2.0
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=c++
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=c++
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=c++
 
 /* OpenCLC v2.0 adds a set of restrictions for conversions between pointers to
 *  different address spaces, mainly described in Sections 6.5.5 and 6.5.6.
@@ -17,71 +20,111 @@
 */
 
 #ifdef GENERIC
-#define AS generic
-#define AS_COMP local
-#define AS_INCOMP constant
+#define AS __generic
+#define AS_COMP __local
+#define AS_INCOMP __constant
 #endif
 
 #ifdef GLOBAL
-#define AS global
-#define AS_COMP global
-#define AS_INCOMP local

[PATCH] D51464: clang: fix MIPS/N32 triple and paths

2018-10-10 Thread Simon Atanasyan via Phabricator via cfe-commits
atanasyan added a comment.

I'm going to test current MIPS N32 ABI implementation. Maybe we are ready to 
enable integrated assembler for it. In that case both 
`Generic_GCC::IsIntegratedAssemblerDefault()` and `MipsMCAsmInfo` ctor can be 
simplified.


https://reviews.llvm.org/D51464



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


[PATCH] D52418: [driver][mips] Enable integrated assembler for MIPS64 except N32 ABI selected

2018-10-10 Thread Simon Atanasyan via Phabricator via cfe-commits
atanasyan added a comment.

In https://reviews.llvm.org/D52418#1256189, @brad wrote:

> Simon, and what about lib/Target/Mips/MCTargetDesc/MipsMCAsmInfo.cpp?


Good point. In fact, integrated assembler for GNUABIN32 was enabled in the 
`MipsMCAsmInfo` ctor by me and by mistake. I have another patch which fix it. 
But anyway there is a problem - we cannot check command line options in the 
`MipsMCAsmInfo`. So I'm going to test current MIPS N32 ABI implementation. 
Maybe we are ready to enable integrated assembler for it. In that case both 
`Generic_GCC::IsIntegratedAssemblerDefault()` and `MipsMCAsmInfo` ctor can be 
simplified.


Repository:
  rC Clang

https://reviews.llvm.org/D52418



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


[PATCH] D52857: Deprecate 'set output foo' API of clang-query

2018-10-10 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added a comment.

> I don't see this functionality being so critical that we need to deprecate 
> the existing spelling when there are backwards compatible options available, 
> which is why I'm opposed to this patch going in with the proposed syntax.

I don't think we're going to go anywhere except around in circles :). I don't 
see your comma separated syntax as viable. Maybe there is a third way that both 
of us don't see.

I tried to catch you on IRC without success. Thanks for the reviews! I 
appreciate your time. I'll see if I can find a different reviewer for this in a 
while.

Thanks,


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52857



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


r344147 - [Hexagon] Use GetLinkerPath instead of hard-coded string.

2018-10-10 Thread Sid Manning via cfe-commits
Author: sidneym
Date: Wed Oct 10 08:37:03 2018
New Revision: 344147

URL: http://llvm.org/viewvc/llvm-project?rev=344147=rev
Log:
[Hexagon] Use GetLinkerPath instead of hard-coded string.

Add GetLinkerPath and set the default to "hexagon-link".
Use GetLinkerPath instead of the hard-coded string.

This change will allow -fuse-ld to function correctly.

Differential revision: https://reviews.llvm.org/D53038

Modified:
cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
cfe/trunk/lib/Driver/ToolChains/Hexagon.h

Modified: cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp?rev=344147=344146=344147=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp Wed Oct 10 08:37:03 2018
@@ -369,9 +369,8 @@ void hexagon::Linker::ConstructJob(Compi
   constructHexagonLinkArgs(C, JA, HTC, Output, Inputs, Args, CmdArgs,
LinkingOutput);
 
-  std::string Linker = HTC.GetProgramPath("hexagon-link");
-  C.addCommand(llvm::make_unique(JA, *this, 
Args.MakeArgString(Linker),
-  CmdArgs, Inputs));
+  const char *Exec = Args.MakeArgString(HTC.GetLinkerPath());
+  C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
 // Hexagon tools end.
 

Modified: cfe/trunk/lib/Driver/ToolChains/Hexagon.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Hexagon.h?rev=344147=344146=344147=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.h Wed Oct 10 08:37:03 2018
@@ -81,6 +81,9 @@ public:
   void addLibStdCxxIncludePaths(
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
+
+  const char *getDefaultLinker() const override { return "hexagon-link"; }
+
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList ) const 
override;
 
   StringRef GetGCCLibAndIncVersion() const { return GCCLibAndIncVersion.Text; }


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


[PATCH] D53038: [Hexagon] Use GetLinkerPath method instead of hard-coded linker name.

2018-10-10 Thread Sid Manning via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC344147: [Hexagon] Use GetLinkerPath instead of hard-coded 
string. (authored by sidneym, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D53038

Files:
  lib/Driver/ToolChains/Hexagon.cpp
  lib/Driver/ToolChains/Hexagon.h


Index: lib/Driver/ToolChains/Hexagon.cpp
===
--- lib/Driver/ToolChains/Hexagon.cpp
+++ lib/Driver/ToolChains/Hexagon.cpp
@@ -369,9 +369,8 @@
   constructHexagonLinkArgs(C, JA, HTC, Output, Inputs, Args, CmdArgs,
LinkingOutput);
 
-  std::string Linker = HTC.GetProgramPath("hexagon-link");
-  C.addCommand(llvm::make_unique(JA, *this, 
Args.MakeArgString(Linker),
-  CmdArgs, Inputs));
+  const char *Exec = Args.MakeArgString(HTC.GetLinkerPath());
+  C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
 // Hexagon tools end.
 
Index: lib/Driver/ToolChains/Hexagon.h
===
--- lib/Driver/ToolChains/Hexagon.h
+++ lib/Driver/ToolChains/Hexagon.h
@@ -81,6 +81,9 @@
   void addLibStdCxxIncludePaths(
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
+
+  const char *getDefaultLinker() const override { return "hexagon-link"; }
+
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList ) const 
override;
 
   StringRef GetGCCLibAndIncVersion() const { return GCCLibAndIncVersion.Text; }


Index: lib/Driver/ToolChains/Hexagon.cpp
===
--- lib/Driver/ToolChains/Hexagon.cpp
+++ lib/Driver/ToolChains/Hexagon.cpp
@@ -369,9 +369,8 @@
   constructHexagonLinkArgs(C, JA, HTC, Output, Inputs, Args, CmdArgs,
LinkingOutput);
 
-  std::string Linker = HTC.GetProgramPath("hexagon-link");
-  C.addCommand(llvm::make_unique(JA, *this, Args.MakeArgString(Linker),
-  CmdArgs, Inputs));
+  const char *Exec = Args.MakeArgString(HTC.GetLinkerPath());
+  C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
 // Hexagon tools end.
 
Index: lib/Driver/ToolChains/Hexagon.h
===
--- lib/Driver/ToolChains/Hexagon.h
+++ lib/Driver/ToolChains/Hexagon.h
@@ -81,6 +81,9 @@
   void addLibStdCxxIncludePaths(
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
+
+  const char *getDefaultLinker() const override { return "hexagon-link"; }
+
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList ) const override;
 
   StringRef GetGCCLibAndIncVersion() const { return GCCLibAndIncVersion.Text; }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52675: [clang] Properly apply attributes on explicit instantiations of static data members

2018-10-10 Thread Louis Dionne via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL344146: [clang] Properly apply attributes on explicit 
instantiations of static data… (authored by ldionne, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D52675?vs=167564=169020#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D52675

Files:
  cfe/trunk/lib/Sema/SemaTemplate.cpp
  cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp


Index: cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
===
--- cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
+++ cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+
+// PR39118
+// Make sure that attributes are properly applied to explicit template
+// instantiations.
+
+#define HIDDEN __attribute__((__visibility__("hidden")))
+#define VISIBLE __attribute__((__visibility__("default")))
+
+namespace ns HIDDEN {
+struct A { };
+template  struct B { static A a; };
+template  A B::a;
+
+// CHECK: @_ZN2ns1BIiE1aE = weak_odr global
+// CHECK-NOT: hidden
+template VISIBLE A B::a;
+}
+
+struct C { };
+template  struct D { static C c; };
+template  C D::c;
+
+// CHECK-DAG: @_ZN1DIiE1cB3TAGE
+template __attribute__((abi_tag("TAG"))) C D::c;
Index: cfe/trunk/lib/Sema/SemaTemplate.cpp
===
--- cfe/trunk/lib/Sema/SemaTemplate.cpp
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp
@@ -9173,10 +9173,8 @@
 if (!HasNoEffect) {
   // Instantiate static data member or variable template.
   Prev->setTemplateSpecializationKind(TSK, D.getIdentifierLoc());
-  if (PrevTemplate) {
-// Merge attributes.
-ProcessDeclAttributeList(S, Prev, D.getDeclSpec().getAttributes());
-  }
+  // Merge attributes.
+  ProcessDeclAttributeList(S, Prev, D.getDeclSpec().getAttributes());
   if (TSK == TSK_ExplicitInstantiationDefinition)
 InstantiateVariableDefinition(D.getIdentifierLoc(), Prev);
 }


Index: cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
===
--- cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
+++ cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+
+// PR39118
+// Make sure that attributes are properly applied to explicit template
+// instantiations.
+
+#define HIDDEN __attribute__((__visibility__("hidden")))
+#define VISIBLE __attribute__((__visibility__("default")))
+
+namespace ns HIDDEN {
+struct A { };
+template  struct B { static A a; };
+template  A B::a;
+
+// CHECK: @_ZN2ns1BIiE1aE = weak_odr global
+// CHECK-NOT: hidden
+template VISIBLE A B::a;
+}
+
+struct C { };
+template  struct D { static C c; };
+template  C D::c;
+
+// CHECK-DAG: @_ZN1DIiE1cB3TAGE
+template __attribute__((abi_tag("TAG"))) C D::c;
Index: cfe/trunk/lib/Sema/SemaTemplate.cpp
===
--- cfe/trunk/lib/Sema/SemaTemplate.cpp
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp
@@ -9173,10 +9173,8 @@
 if (!HasNoEffect) {
   // Instantiate static data member or variable template.
   Prev->setTemplateSpecializationKind(TSK, D.getIdentifierLoc());
-  if (PrevTemplate) {
-// Merge attributes.
-ProcessDeclAttributeList(S, Prev, D.getDeclSpec().getAttributes());
-  }
+  // Merge attributes.
+  ProcessDeclAttributeList(S, Prev, D.getDeclSpec().getAttributes());
   if (TSK == TSK_ExplicitInstantiationDefinition)
 InstantiateVariableDefinition(D.getIdentifierLoc(), Prev);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r344146 - [clang] Properly apply attributes on explicit instantiations of static data members

2018-10-10 Thread Louis Dionne via cfe-commits
Author: ldionne
Date: Wed Oct 10 08:32:29 2018
New Revision: 344146

URL: http://llvm.org/viewvc/llvm-project?rev=344146=rev
Log:
[clang] Properly apply attributes on explicit instantiations of static data 
members

Summary: https://llvm.org/PR39118

Reviewers: aaron.ballman, rnk

Subscribers: dexonsmith, cfe-commits

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

Added:
cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
Modified:
cfe/trunk/lib/Sema/SemaTemplate.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=344146=344145=344146=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Wed Oct 10 08:32:29 2018
@@ -9173,10 +9173,8 @@ DeclResult Sema::ActOnExplicitInstantiat
 if (!HasNoEffect) {
   // Instantiate static data member or variable template.
   Prev->setTemplateSpecializationKind(TSK, D.getIdentifierLoc());
-  if (PrevTemplate) {
-// Merge attributes.
-ProcessDeclAttributeList(S, Prev, D.getDeclSpec().getAttributes());
-  }
+  // Merge attributes.
+  ProcessDeclAttributeList(S, Prev, D.getDeclSpec().getAttributes());
   if (TSK == TSK_ExplicitInstantiationDefinition)
 InstantiateVariableDefinition(D.getIdentifierLoc(), Prev);
 }

Added: cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp?rev=344146=auto
==
--- cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp (added)
+++ cfe/trunk/test/SemaCXX/attr-on-explicit-template-instantiation.cpp Wed Oct 
10 08:32:29 2018
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+
+// PR39118
+// Make sure that attributes are properly applied to explicit template
+// instantiations.
+
+#define HIDDEN __attribute__((__visibility__("hidden")))
+#define VISIBLE __attribute__((__visibility__("default")))
+
+namespace ns HIDDEN {
+struct A { };
+template  struct B { static A a; };
+template  A B::a;
+
+// CHECK: @_ZN2ns1BIiE1aE = weak_odr global
+// CHECK-NOT: hidden
+template VISIBLE A B::a;
+}
+
+struct C { };
+template  struct D { static C c; };
+template  C D::c;
+
+// CHECK-DAG: @_ZN1DIiE1cB3TAGE
+template __attribute__((abi_tag("TAG"))) C D::c;


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


[PATCH] D53046: [Sema] Fix an error-on-valid with friends and templates

2018-10-10 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.


https://reviews.llvm.org/D53046



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


[PATCH] D53076: [analyzer] WIP: Enhance ConditionBRVisitor to write out more information

2018-10-10 Thread Umann Kristóf via Phabricator via cfe-commits
Szelethus added a comment.

I'm sadly not that knowledgeable on visitors to help you, but the idea is 
awesome, thank you for working on this!


https://reviews.llvm.org/D53076



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


[PATCH] D53085: [clang-doc] Add unit tests for Markdown

2018-10-10 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett created this revision.
juliehockett added reviewers: leonardchan, jakehehrlich, lebedev.ri.
juliehockett added a project: clang-tools-extra.
Herald added a subscriber: mgorny.

This is part of a move to convert clang-doc's tests to a more maintainable unit 
test framework, with a smaller number of integration tests to maintain and more 
granular failure feedback.


https://reviews.llvm.org/D53085

Files:
  clang-tools-extra/unittests/clang-doc/CMakeLists.txt
  clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp
===
--- /dev/null
+++ clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp
@@ -0,0 +1,356 @@
+//===-- clang-doc/MDGeneratorTest.cpp -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ClangDocTest.h"
+#include "Generators.h"
+#include "Representation.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace doc {
+
+std::unique_ptr getMDGenerator() {
+  auto G = doc::findGeneratorByName("md");
+  if (!G)
+return nullptr;
+  return std::move(G.get());
+}
+
+TEST(MDGeneratorTest, emitNamespaceMD) {
+  NamespaceInfo I;
+  I.Name = "Namespace";
+  I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
+
+  I.ChildNamespaces.emplace_back(EmptySID, "ChildNamespace",
+ InfoType::IT_namespace);
+  I.ChildRecords.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record);
+  I.ChildFunctions.emplace_back();
+  I.ChildFunctions.back().Name = "OneFunction";
+  I.ChildEnums.emplace_back();
+  I.ChildEnums.back().Name = "OneEnum";
+
+  auto G = getMDGenerator();
+  assert(G);
+  std::string Buffer;
+  llvm::raw_string_ostream Actual(Buffer);
+  auto Err = G->generateDocForInfo(, Actual);
+  assert(!Err);
+  std::string Expected = "# namespace Namespace\n"
+ "\n"
+ "\n"
+ "\n"
+ "## Namespaces\n"
+ "\n"
+ "ChildNamespace\n"
+ "\n"
+ "\n"
+ "\n"
+ "## Records\n"
+ "\n"
+ "ChildStruct\n"
+ "\n"
+ "\n"
+ "\n"
+ "## Functions\n"
+ "\n"
+ "### OneFunction\n"
+ "\n"
+ "* OneFunction()*\n"
+ "\n"
+ "\n"
+ "\n"
+ "## Enums\n"
+ "\n"
+ "| enum OneEnum |\n"
+ "\n"
+ "--\n"
+ "\n"
+ "\n"
+ "\n"
+ "\n"
+ "\n";
+  EXPECT_EQ(Expected, Actual.str());
+}
+
+TEST(MDGeneratorTest, emitRecordMD) {
+  RecordInfo I;
+  I.Name = "r";
+  I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
+
+  I.DefLoc = Location(10, llvm::SmallString<16>("test.cpp"));
+  I.Loc.emplace_back(12, llvm::SmallString<16>("test.cpp"));
+
+  I.Members.emplace_back("int", "X", AccessSpecifier::AS_private);
+  I.TagType = TagTypeKind::TTK_Class;
+  I.Parents.emplace_back(EmptySID, "F", InfoType::IT_record);
+  I.VirtualParents.emplace_back(EmptySID, "G", InfoType::IT_record);
+
+  I.ChildRecords.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record);
+  I.ChildFunctions.emplace_back();
+  I.ChildFunctions.back().Name = "OneFunction";
+  I.ChildEnums.emplace_back();
+  I.ChildEnums.back().Name = "OneEnum";
+
+  auto G = getMDGenerator();
+  assert(G);
+  std::string Buffer;
+  llvm::raw_string_ostream Actual(Buffer);
+  auto Err = G->generateDocForInfo(, Actual);
+  assert(!Err);
+  std::string Expected = "# class r\n"
+ "\n"
+ "*Defined at line 10 of test.cpp*\n"
+ "\n"
+ "Inherits from F, G\n"
+ "\n"
+ "\n"
+ "\n"
+ "## Members\n"
+ "\n"
+ "private int X\n"
+ "\n"
+ "\n"
+ "\n"
+ "## Records\n"
+ "\n"
+ "ChildStruct\n"
+ "\n"
+ "\n"
+ "\n"
+  

[PATCH] D53084: [clang-doc] Add unit tests for YAML

2018-10-10 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett created this revision.
juliehockett added reviewers: leonardchan, jakehehrlich, lebedev.ri.
juliehockett added a project: clang-tools-extra.
Herald added a subscriber: mgorny.

This is part of a move to convert clang-doc's tests to a more maintainable unit 
test framework, with a smaller number of integration tests to maintain and more 
granular failure feedback.


https://reviews.llvm.org/D53084

Files:
  clang-tools-extra/unittests/clang-doc/CMakeLists.txt
  clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
===
--- /dev/null
+++ clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
@@ -0,0 +1,422 @@
+//===-- clang-doc/YAMLGeneratorTest.cpp
+//===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ClangDocTest.h"
+#include "Generators.h"
+#include "Representation.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace doc {
+
+std::unique_ptr getYAMLGenerator() {
+  auto G = doc::findGeneratorByName("yaml");
+  if (!G)
+return nullptr;
+  return std::move(G.get());
+}
+
+TEST(YAMLGeneratorTest, emitNamespaceYAML) {
+  NamespaceInfo I;
+  I.Name = "Namespace";
+  I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
+
+  I.ChildNamespaces.emplace_back(EmptySID, "ChildNamespace",
+ InfoType::IT_namespace);
+  I.ChildRecords.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record);
+  I.ChildFunctions.emplace_back();
+  I.ChildFunctions.back().Name = "OneFunction";
+  I.ChildEnums.emplace_back();
+  I.ChildEnums.back().Name = "OneEnum";
+
+  auto G = getYAMLGenerator();
+  assert(G);
+  std::string Buffer;
+  llvm::raw_string_ostream Actual(Buffer);
+  auto Err = G->generateDocForInfo(, Actual);
+  assert(!Err);
+  std::string Expected =
+  "---\n"
+  "USR: ''\n"
+  "Name:'Namespace'\n"
+  "Namespace:   \n"
+  "  - Type:Namespace\n"
+  "Name:'A'\n"
+  "ChildNamespaces: \n"
+  "  - Type:Namespace\n"
+  "Name:'ChildNamespace'\n"
+  "ChildRecords:\n"
+  "  - Type:Record\n"
+  "Name:'ChildStruct'\n"
+  "ChildFunctions:  \n"
+  "  - USR: ''\n"
+  "Name:'OneFunction'\n"
+  "ReturnType:  \n"
+  "ChildEnums:  \n"
+  "  - USR: ''\n"
+  "Name:'OneEnum'\n"
+  "...\n";
+  EXPECT_EQ(Expected, Actual.str());
+}
+
+TEST(YAMLGeneratorTest, emitRecordYAML) {
+  RecordInfo I;
+  I.Name = "r";
+  I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
+
+  I.DefLoc = Location(10, llvm::SmallString<16>("test.cpp"));
+  I.Loc.emplace_back(12, llvm::SmallString<16>("test.cpp"));
+
+  I.Members.emplace_back("int", "X", AccessSpecifier::AS_private);
+  I.TagType = TagTypeKind::TTK_Class;
+  I.Parents.emplace_back(EmptySID, "F", InfoType::IT_record);
+  I.VirtualParents.emplace_back(EmptySID, "G", InfoType::IT_record);
+
+  I.ChildRecords.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record);
+  I.ChildFunctions.emplace_back();
+  I.ChildFunctions.back().Name = "OneFunction";
+  I.ChildEnums.emplace_back();
+  I.ChildEnums.back().Name = "OneEnum";
+
+  auto G = getYAMLGenerator();
+  assert(G);
+  std::string Buffer;
+  llvm::raw_string_ostream Actual(Buffer);
+  auto Err = G->generateDocForInfo(, Actual);
+  assert(!Err);
+  std::string Expected =
+  "---\n"
+  "USR: ''\n"
+  "Name:'r'\n"
+  "Namespace:   \n"
+  "  - Type:Namespace\n"
+  "Name:'A'\n"
+  "DefLocation: \n"
+  "  LineNumber:  10\n"
+  "  Filename:'test.cpp'\n"
+  "Location:\n"
+  "  - LineNumber:  12\n"
+  "Filename:'test.cpp'\n"
+  "TagType: Class\n"
+  "Members: \n"
+  "  - Type:\n"
+  "  Name:'int'\n"
+  "Name:'X'\n"
+  "Access:  Private\n"
+  "Parents: \n"
+  "  - Type:Record\n"
+  "Name:'F'\n"
+  "VirtualParents:  \n"
+  "  - Type:Record\n"
+  "Name:'G'\n"
+  "ChildRecords:\n"
+  "  - Type:Record\n"
+  "Name:'ChildStruct'\n"
+  "ChildFunctions:  \n"
+  "  - USR: 

[PATCH] D53081: [clang-doc] Add unit tests for serialization

2018-10-10 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett created this revision.
juliehockett added reviewers: leonardchan, jakehehrlich, lebedev.ri.
juliehockett added a project: clang-tools-extra.
Herald added subscribers: kadircet, arphaman, mgorny.

This is part of a move to convert clang-doc's tests to a more maintainable unit 
test framework, with a smaller number of integration tests to maintain and more 
granular failure feedback.


https://reviews.llvm.org/D53081

Files:
  clang-tools-extra/unittests/CMakeLists.txt
  clang-tools-extra/unittests/clang-doc/CMakeLists.txt
  clang-tools-extra/unittests/clang-doc/ClangDocTest.cpp
  clang-tools-extra/unittests/clang-doc/ClangDocTest.h
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp

Index: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
===
--- /dev/null
+++ clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
@@ -0,0 +1,346 @@
+//===-- clang-doc/SerializeTest.cpp ---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "Serialize.h"
+#include "ClangDocTest.h"
+#include "Representation.h"
+#include "clang/AST/Comment.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace doc {
+
+class ClangDocSerializeTestVisitor
+: public RecursiveASTVisitor {
+
+  EmittedInfoList 
+  bool Public;
+
+comments::FullComment *
+getComment(const NamedDecl *D) const {
+  if (RawComment *Comment = D->getASTContext().getRawCommentForDeclNoCache(D)) {
+Comment->setAttached();
+return Comment->parse(D->getASTContext(), nullptr, D);
+  }
+  return nullptr;
+}
+
+public:
+  ClangDocSerializeTestVisitor(EmittedInfoList , bool Public)
+  : EmittedInfos(EmittedInfos), Public(Public) {}
+
+  bool VisitNamespaceDecl(const NamespaceDecl *D) {
+auto I = serialize::emitInfo(D, getComment(D), /*Line*/ 0,
+ /*File=*/"test.cpp", Public);
+if (I)
+  EmittedInfos.emplace_back(std::move(I));
+return true;
+  }
+
+  bool VisitFunctionDecl(const FunctionDecl *D) {
+// Don't visit CXXMethodDecls twice
+if (dyn_cast(D))
+  return true;
+auto I = serialize::emitInfo(D, getComment(D), /*Line*/ 0,
+ /*File=*/"test.cpp", Public);
+if (I)
+  EmittedInfos.emplace_back(std::move(I));
+return true;
+  }
+
+  bool VisitCXXMethodDecl(const CXXMethodDecl *D) {
+auto I = serialize::emitInfo(D, getComment(D), /*Line*/ 0,
+ /*File=*/"test.cpp", Public);
+if (I)
+  EmittedInfos.emplace_back(std::move(I));
+return true;
+  }
+
+  bool VisitRecordDecl(const RecordDecl *D) {
+auto I = serialize::emitInfo(D, getComment(D), /*Line*/ 0,
+ /*File=*/"test.cpp", Public);
+if (I)
+  EmittedInfos.emplace_back(std::move(I));
+return true;
+  }
+
+  bool VisitEnumDecl(const EnumDecl *D) {
+auto I = serialize::emitInfo(D, getComment(D), /*Line*/ 0,
+ /*File=*/"test.cpp", Public);
+if (I)
+  EmittedInfos.emplace_back(std::move(I));
+return true;
+  }
+};
+
+void ExtractInfosFromCode(StringRef Code, size_t NumExpectedInfos, bool Public,
+  EmittedInfoList ) {
+  auto ASTUnit = clang::tooling::buildASTFromCode(Code);
+  auto TU = ASTUnit->getASTContext().getTranslationUnitDecl();
+  ClangDocSerializeTestVisitor Visitor(EmittedInfos, Public);
+  Visitor.TraverseTranslationUnitDecl(TU);
+  ASSERT_EQ(NumExpectedInfos, EmittedInfos.size());
+}
+
+void ExtractInfosFromCodeWithArgs(StringRef Code, size_t NumExpectedInfos, bool Public,
+  EmittedInfoList , std::vector& Args) {
+  auto ASTUnit = clang::tooling::buildASTFromCodeWithArgs(Code, Args);
+  auto TU = ASTUnit->getASTContext().getTranslationUnitDecl();
+  ClangDocSerializeTestVisitor Visitor(EmittedInfos, Public);
+  Visitor.TraverseTranslationUnitDecl(TU);
+  ASSERT_EQ(NumExpectedInfos, EmittedInfos.size());
+}
+
+// Test serialization of namespace declarations.
+TEST(SerializeTest, emitNamespaceInfo) {
+  EmittedInfoList Infos;
+  ExtractInfosFromCode("namespace A { namespace B { void f() {} } }", 3,
+   /*Public=*/false, Infos);
+
+  NamespaceInfo *A = InfoAsNamespace(Infos[0].get());
+  NamespaceInfo ExpectedA(EmptySID, "A");
+  CheckNamespaceInfo(, A);
+
+  NamespaceInfo *B = InfoAsNamespace(Infos[1].get());
+  NamespaceInfo ExpectedB(EmptySID, "B");
+  ExpectedB.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
+  CheckNamespaceInfo(, B);
+
+  NamespaceInfo *BWithFunction = InfoAsNamespace(Infos[2].get());
+  NamespaceInfo ExpectedBWithFunction(EmptySID);
+  FunctionInfo F;
+  

[PATCH] D52857: Deprecate 'set output foo' API of clang-query

2018-10-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D52857#1260455, @steveire wrote:

> >   you have to find the right place to stick the `set dump-output true` in 
> > order to enable it.
>
> What do you mean "the right place"?


The point from which they want to enable dump outputting.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52857



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


[PATCH] D52857: Deprecate 'set output foo' API of clang-query

2018-10-10 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added a comment.

>   you have to find the right place to stick the `set dump-output true` in 
> order to enable it.

What do you mean "the right place"?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52857



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


[PATCH] D52857: Deprecate 'set output foo' API of clang-query

2018-10-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D52857#1259522, @steveire wrote:

> > What's more, given that clang-output has no real documentation to speak of, 
> > how will users even *know* to update their scripts?
>
> The release notes will tell them.


That's not user friendly.

> But your comment also raises a different point: If there is so little 
> clang-query documentation, what justification is there for relying on current 
> behavior?

That's pretty much the only reason I think it's reasonable to consider 
deprecating the command in the first place. The justification for relying on it 
is: this has been the behavior since Day 1 of clang-query and we do not often 
remove user-facing options without there being a Very Good Reason to do so. 
This is not a situation where it's an undocumented feature that's in-flux or 
there's no indication it's being used.

> Also, what scripts are you referring to that rely on clang-query? Do we know 
> of any that are expected to work long-term without maintenance (unlikely, as 
> the AST itself is not stable), or is this concern imagined?

I'm referring to third-party scripts kept by people out of tree. I have 
several, I know a few other folks internally at my company who do as well.

I think it's reasonable to expect differences in AST output when updating 
clang-query, but this is not that. It's reasonable to expect command stability.

>> can you expound on your concerns?
> 
> After this patch, the user writes
> 
>   set dump-output true
> 
> 
> or `false`.
> 
> and after the follow-up (https://reviews.llvm.org/D52859) they write
> 
>   set matcher-output true
> 
> 
> After more features I have in the pipeline they will write other similar 
> commands.
> 
> With my command-design, if a user wants to enable dump output in addition to 
> what they have, they just
> 
>   set dump-output true
> 
> 
> In your design, they have to recall/find out what options are currently 
> enabled, and add them in a comma separated list. That is not user-friendly.

Yes -- you are required to make a decision that you want to opt in to new 
functionality. The exact same thing is true with your proposal -- you have to 
find the right place to stick the `set dump-output true` in order to enable it.

>> wonder whether set blah-output options are mutually exclusive or not.
> 
> These options are obviously and clearly toggles.

Your notions of obvious and clear do not match mine.

> There is definitely no reason to think that they are mutually exclusive any 
> more than there is reason to think `set output dump` is mutually exclusive 
> with `set bind-root false`.

Well, except for the fact that each of these commands says "output" in the name 
and they are replacing a command argument named "output" that was mutually 
exclusive and there's zero documentation explaining the commands.

> And even if someone did wonder that, they would just try it and learn that 
> they are toggles.

I don't see this functionality being so critical that we need to deprecate the 
existing spelling when there are backwards compatible options available, which 
is why I'm opposed to this patch going in with the proposed syntax.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52857



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


[PATCH] D53079: [OPENMP] Add 'dynamic_allocators' clause to OMP5.0 'requires' directive

2018-10-10 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rC Clang

https://reviews.llvm.org/D53079



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


[PATCH] D53079: [OPENMP] Add 'dynamic_allocators' clause to OMP5.0 'requires' directive

2018-10-10 Thread Patrick Lyster via Phabricator via cfe-commits
patricklyster created this revision.
patricklyster added reviewers: ABataev, Hahnfeld, RaviNarayanaswamy, mikerice, 
kkwli0, hfinkel, gtbercea.
patricklyster added a project: clang.
Herald added subscribers: cfe-commits, arphaman, guansong.

Added new `dynamic_allocators` clause to existing OMP5.0 `requires` directive.


Repository:
  rC Clang

https://reviews.llvm.org/D53079

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/requires_unified_address_ast_print.cpp
  clang/test/OpenMP/requires_unified_address_messages.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2216,6 +2216,9 @@
 void OMPClauseEnqueue::VisitOMPReverseOffloadClause(
 const OMPReverseOffloadClause *) {}
 
+void OMPClauseEnqueue::VisitOMPDynamicAllocatorsClause(
+const OMPDynamicAllocatorsClause *) {}
+
 void OMPClauseEnqueue::VisitOMPDeviceClause(const OMPDeviceClause *C) {
   Visitor->AddStmt(C->getDevice());
 }
Index: clang/test/OpenMP/requires_unified_address_messages.cpp
===
--- clang/test/OpenMP/requires_unified_address_messages.cpp
+++ clang/test/OpenMP/requires_unified_address_messages.cpp
@@ -14,6 +14,11 @@
 
 #pragma omp requires reverse_offload, reverse_offload // expected-error {{Only one reverse_offload clause can appear on a requires directive in a single translation unit}} expected-error {{directive '#pragma omp requires' cannot contain more than one 'reverse_offload' clause}}
 
+#pragma omp requires dynamic_allocators // expected-note {{dynamic_allocators clause previously used here}} expected-note {{dynamic_allocators clause previously used here}}
+
+#pragma omp requires dynamic_allocators, dynamic_allocators // expected-error {{Only one dynamic_allocators clause can appear on a requires directive in a single translation unit}} expected-error {{directive '#pragma omp requires' cannot contain more than one 'dynamic_allocators' clause}}
+
+
 #pragma omp requires // expected-error {{expected at least one clause on '#pragma omp requires' directive}}
 
 #pragma omp requires invalid_clause // expected-warning {{extra tokens at the end of '#pragma omp requires' are ignored}} expected-error {{expected at least one clause on '#pragma omp requires' directive}}
@@ -24,7 +29,7 @@
 
 #pragma omp requires invalid_clause unified_address // expected-warning {{extra tokens at the end of '#pragma omp requires' are ignored}} expected-error {{expected at least one clause on '#pragma omp requires' directive}}
 
-#pragma omp requires unified_shared_memory, unified_address, reverse_offload // expected-error {{Only one unified_shared_memory clause can appear on a requires directive in a single translation unit}} expected-error{{Only one unified_address clause can appear on a requires directive in a single translation unit}} expected-error{{Only one reverse_offload clause can appear on a requires directive in a single translation unit}}
+#pragma omp requires unified_shared_memory, unified_address, reverse_offload, dynamic_allocators // expected-error {{Only one unified_shared_memory clause can appear on a requires directive in a single translation unit}} expected-error{{Only one unified_address clause can appear on a requires directive in a single translation unit}} expected-error{{Only one reverse_offload clause can appear on a requires directive in a single translation unit}} expected-error{{Only one dynamic_allocators clause can appear on a requires directive in a single translation unit}}
 
 namespace A {
   #pragma omp requires unified_address // expected-error {{Only one unified_address clause can appear on a requires directive in a single translation unit}}
Index: clang/test/OpenMP/requires_unified_address_ast_print.cpp
===
--- clang/test/OpenMP/requires_unified_address_ast_print.cpp
+++ clang/test/OpenMP/requires_unified_address_ast_print.cpp
@@ -19,4 +19,7 @@
 #pragma omp requires reverse_offload
 // CHECK:#pragma omp requires reverse_offload
 
+#pragma omp requires dynamic_allocators
+// CHECK:#pragma omp requires dynamic_allocators
+
 #endif
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -6937,3 

[PATCH] D52727: [clang-tidy] White List Option for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-10-10 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a reviewer: JonasToth.
lebedev.ri accepted this revision.
lebedev.ri added a comment.
This revision is now accepted and ready to land.

LG unless @JonasToth or @aaron.ballman has any further comments.


https://reviews.llvm.org/D52727



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


[PATCH] D51340: Add /Zc:DllexportInlines option to clang-cl

2018-10-10 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

Thanks! I think this is getting close now.




Comment at: clang/lib/Sema/SemaDecl.cpp:11976
+
+while (FD && !getDLLAttr(FD) &&
+   !FD->hasAttr() &&

Why does this need to be a loop? I don't think FunctionDecl's can be nested?



Comment at: clang/lib/Sema/SemaDecl.cpp:11995
+
+// Function having static local variables should be exported.
+auto *ExportAttr = 
cast(NewAttr->clone(getASTContext()));

Isn't it enough that the static local is exported, does the function itself 
need to be exported too?



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5703
+if (Context.getTargetInfo().getCXXABI().isMicrosoft() &&
+!getLangOpts().DllExportInlines &&
+TSK != TSK_ExplicitInstantiationDeclaration &&

I don't think checking for Microsoft ABI is necessary, just checking the 
DllExportInlines flag should be enough.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5705
+TSK != TSK_ExplicitInstantiationDeclaration &&
+TSK != TSK_ExplicitInstantiationDefinition) {
+  if (ClassExported) {

But I don't understand why the template stuff is checked here...

The way I imagined this, we'd only need to change the code when creating 
NewAttr below..
Something like

```
NewAttr = ClassAtr->clone()...
if (!getLandOpts().DllExportInlines() && Member is an inline method)
  NewAttr = our new dllimport/export static locals attribute
```

What do you think?


https://reviews.llvm.org/D51340



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


[PATCH] D52773: clang-cl: Add /showFilenames option (PR31957)

2018-10-10 Thread Hans Wennborg via Phabricator via cfe-commits
hans updated this revision to Diff 168999.
hans added a comment.

Here's a version now using cc1 flags, but printing directly from the driver. 
Please take a look.


https://reviews.llvm.org/D52773

Files:
  include/clang/Driver/CLCompatOptions.td
  include/clang/Driver/Job.h
  lib/Driver/Job.cpp
  lib/Driver/ToolChains/Clang.cpp
  test/Driver/cl-showfilenames.c


Index: test/Driver/cl-showfilenames.c
===
--- /dev/null
+++ test/Driver/cl-showfilenames.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cl /c /showFilenames -- %s 2>&1 | FileCheck -check-prefix=show 
%s
+// RUN: %clang_cl /c /showFilenames -- %s %S/Inputs/wildcard*.c 2>&1 | 
FileCheck -check-prefix=multiple %s
+
+// show: cl-showfilenames.c
+
+// multiple: cl-showfilenames.c
+// multiple-NEXT: wildcard1.c
+// multiple-NEXT: wildcard2.c
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -5066,6 +5066,13 @@
 C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
   }
 
+  // Make the compile command echo its inputs for /showFilenames.
+  if (Output.getType() == types::TY_Object &&
+  Args.hasFlag(options::OPT__SLASH_showFilenames,
+   options::OPT__SLASH_showFilenames_, false)) {
+C.getJobs().getJobs().back()->setPrintInputFilenames(true);
+  }
+
   if (Arg *A = Args.getLastArg(options::OPT_pg))
 if (!shouldUseFramePointer(Args, Triple))
   D.Diag(diag::err_drv_argument_not_allowed_with) << "-fomit-frame-pointer"
Index: lib/Driver/Job.cpp
===
--- lib/Driver/Job.cpp
+++ lib/Driver/Job.cpp
@@ -315,6 +315,11 @@
 
 int Command::Execute(ArrayRef> Redirects,
  std::string *ErrMsg, bool *ExecutionFailed) const {
+  if (PrintInputFilenames) {
+for (const char *Arg : InputFilenames)
+  llvm::outs() << llvm::sys::path::filename(Arg) << "\n";
+  }
+
   SmallVector Argv;
 
   Optional> Env;
Index: include/clang/Driver/Job.h
===
--- include/clang/Driver/Job.h
+++ include/clang/Driver/Job.h
@@ -59,6 +59,9 @@
   /// The list of program arguments which are inputs.
   llvm::opt::ArgStringList InputFilenames;
 
+  /// Whether to print the input filenames when executing.
+  bool PrintInputFilenames = false;
+
   /// Response file name, if this command is set to use one, or nullptr
   /// otherwise
   const char *ResponseFile = nullptr;
@@ -128,6 +131,9 @@
 
   /// Print a command argument, and optionally quote it.
   static void printArg(llvm::raw_ostream , StringRef Arg, bool Quote);
+
+  /// Set whether to print the input filenames when executing.
+  void setPrintInputFilenames(bool P) { PrintInputFilenames = P; }
 };
 
 /// Like Command, but with a fallback which is executed in case
Index: include/clang/Driver/CLCompatOptions.td
===
--- include/clang/Driver/CLCompatOptions.td
+++ include/clang/Driver/CLCompatOptions.td
@@ -158,6 +158,10 @@
 def _SLASH_showIncludes : CLFlag<"showIncludes">,
   HelpText<"Print info about included files to stderr">,
   Alias;
+def _SLASH_showFilenames : CLFlag<"showFilenames">,
+  HelpText<"Print the name of each compiled file">;
+def _SLASH_showFilenames_ : CLFlag<"showFilenames-">,
+  HelpText<"Don't print the name of each compiled file (default)">;
 def _SLASH_source_charset : CLCompileJoined<"source-charset:">,
   HelpText<"Source encoding, supports only UTF-8">, Alias;
 def _SLASH_execution_charset : CLCompileJoined<"execution-charset:">,


Index: test/Driver/cl-showfilenames.c
===
--- /dev/null
+++ test/Driver/cl-showfilenames.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cl /c /showFilenames -- %s 2>&1 | FileCheck -check-prefix=show %s
+// RUN: %clang_cl /c /showFilenames -- %s %S/Inputs/wildcard*.c 2>&1 | FileCheck -check-prefix=multiple %s
+
+// show: cl-showfilenames.c
+
+// multiple: cl-showfilenames.c
+// multiple-NEXT: wildcard1.c
+// multiple-NEXT: wildcard2.c
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -5066,6 +5066,13 @@
 C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
   }
 
+  // Make the compile command echo its inputs for /showFilenames.
+  if (Output.getType() == types::TY_Object &&
+  Args.hasFlag(options::OPT__SLASH_showFilenames,
+   options::OPT__SLASH_showFilenames_, false)) {
+C.getJobs().getJobs().back()->setPrintInputFilenames(true);
+  }
+
   if (Arg *A = Args.getLastArg(options::OPT_pg))
 if (!shouldUseFramePointer(Args, Triple))
   D.Diag(diag::err_drv_argument_not_allowed_with) << "-fomit-frame-pointer"
Index: 

[PATCH] D52949: [Diagnostics] Implement -Wsizeof-pointer-div

2018-10-10 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

In https://reviews.llvm.org/D52949#1259947, @jfb wrote:

> Can you add tests with arrays?


Yes :)

> The error message doesn't really say what to do instead. What's wrong? What's 
> correct instead?

What do you suggest? "division produces the incorrect number of array elements; 
pass the length of array as a function argument"?

> In C++17 and later we should suggest using `std::size` for some cases instead.

Ok, good idea.


https://reviews.llvm.org/D52949



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


[clang-tools-extra] r344140 - Lift VFS from clang to llvm (NFC)

2018-10-10 Thread Jonas Devlieghere via cfe-commits
Author: jdevlieghere
Date: Wed Oct 10 06:27:25 2018
New Revision: 344140

URL: http://llvm.org/viewvc/llvm-project?rev=344140=rev
Log:
Lift VFS from clang to llvm (NFC)

This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
 - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
 - Moves the corresponding unit test from clang to llvm.
 - Moves the vfs namespace from clang::vfs to llvm::vfs.
 - Formats the lines affected by this change, mostly this is the result of
   the added llvm namespace.

RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html

Differential revision: https://reviews.llvm.org/D52783

Modified:
clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp
clang-tools-extra/trunk/clang-tidy/ClangTidy.h
clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp
clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h
clang-tools-extra/trunk/clangd/ClangdUnit.cpp
clang-tools-extra/trunk/clangd/ClangdUnit.h
clang-tools-extra/trunk/clangd/CodeComplete.cpp
clang-tools-extra/trunk/clangd/CodeComplete.h
clang-tools-extra/trunk/clangd/Compiler.cpp
clang-tools-extra/trunk/clangd/Compiler.h
clang-tools-extra/trunk/clangd/FS.cpp
clang-tools-extra/trunk/clangd/FS.h
clang-tools-extra/trunk/clangd/FSProvider.h
clang-tools-extra/trunk/clangd/Headers.h
clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
clang-tools-extra/trunk/unittests/clang-tidy/ClangTidyTest.h
clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
clang-tools-extra/trunk/unittests/clangd/FSTests.cpp
clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
clang-tools-extra/trunk/unittests/clangd/TestFS.h
clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp

clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp?rev=344140=344139=344140=diff
==
--- clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp Wed Oct 10 06:27:25 2018
@@ -96,7 +96,7 @@ private:
 class ErrorReporter {
 public:
   ErrorReporter(ClangTidyContext , bool ApplyFixes,
-llvm::IntrusiveRefCntPtr BaseFS)
+llvm::IntrusiveRefCntPtr BaseFS)
   : Files(FileSystemOptions(), BaseFS), DiagOpts(new DiagnosticOptions()),
 DiagPrinter(new TextDiagnosticPrinter(llvm::outs(), &*DiagOpts)),
 Diags(IntrusiveRefCntPtr(new DiagnosticIDs), &*DiagOpts,
@@ -503,7 +503,7 @@ getCheckOptions(const ClangTidyOptions &
 void runClangTidy(clang::tidy::ClangTidyContext ,
   const CompilationDatabase ,
   ArrayRef InputFiles,
-  llvm::IntrusiveRefCntPtr BaseFS,
+  llvm::IntrusiveRefCntPtr BaseFS,
   bool EnableCheckProfile, llvm::StringRef StoreCheckProfile) {
   ClangTool Tool(Compilations, InputFiles,
  std::make_shared(), BaseFS);
@@ -590,9 +590,9 @@ void runClangTidy(clang::tidy::ClangTidy
 
 void handleErrors(ClangTidyContext , bool Fix,
   unsigned ,
-  llvm::IntrusiveRefCntPtr BaseFS) {
+  llvm::IntrusiveRefCntPtr BaseFS) {
   ErrorReporter Reporter(Context, Fix, BaseFS);
-  vfs::FileSystem  =
+  llvm::vfs::FileSystem  =
   *Reporter.getSourceManager().getFileManager().getVirtualFileSystem();
   auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
   if (!InitialWorkingDir)

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidy.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidy.h?rev=344140=344139=344140=diff
==
--- clang-tools-extra/trunk/clang-tidy/ClangTidy.h (original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidy.h Wed Oct 10 06:27:25 2018
@@ -233,7 +233,7 @@ getCheckOptions(const ClangTidyOptions &
 void runClangTidy(clang::tidy::ClangTidyContext ,
   const tooling::CompilationDatabase ,
   ArrayRef InputFiles,
-  llvm::IntrusiveRefCntPtr BaseFS,
+  llvm::IntrusiveRefCntPtr BaseFS,
   bool EnableCheckProfile = false,
   llvm::StringRef StoreCheckProfile = StringRef());
 
@@ -245,7 +245,7 @@ void runClangTidy(clang::tidy::ClangTidy
 /// clang-format configuration file is found, the given \P FormatStyle is used.
 void handleErrors(ClangTidyContext , bool Fix,
   unsigned ,
-  llvm::IntrusiveRefCntPtr BaseFS);
+  llvm::IntrusiveRefCntPtr BaseFS);
 
 /// \brief Serializes 

[PATCH] D52727: [clang-tidy] White List Option for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

2018-10-10 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 168993.
baloghadamsoftware added a comment.

Matching of allowed types happens now on the top-level type, not the canonical 
one.


https://reviews.llvm.org/D52727

Files:
  clang-tidy/performance/ForRangeCopyCheck.cpp
  clang-tidy/performance/ForRangeCopyCheck.h
  clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tidy/performance/UnnecessaryCopyInitialization.h
  clang-tidy/performance/UnnecessaryValueParamCheck.cpp
  clang-tidy/performance/UnnecessaryValueParamCheck.h
  clang-tidy/utils/Matchers.h
  docs/clang-tidy/checks/performance-for-range-copy.rst
  docs/clang-tidy/checks/performance-unnecessary-copy-initialization.rst
  docs/clang-tidy/checks/performance-unnecessary-value-param.rst
  test/clang-tidy/performance-for-range-copy-allowed-types.cpp
  test/clang-tidy/performance-unnecessary-copy-initialization-allowed-types.cpp
  test/clang-tidy/performance-unnecessary-value-param-allowed-types.cpp

Index: test/clang-tidy/performance-unnecessary-value-param-allowed-types.cpp
===
--- /dev/null
+++ test/clang-tidy/performance-unnecessary-value-param-allowed-types.cpp
@@ -0,0 +1,75 @@
+// RUN: %check_clang_tidy %s performance-unnecessary-value-param %t -- -config="{CheckOptions: [{key: performance-unnecessary-value-param.AllowedTypes, value: '[Pp]ointer$;[Pp]tr$;[Rr]ef(erence)?$'}]}" --
+
+struct SmartPointer {
+  ~SmartPointer();
+};
+
+struct smart_pointer {
+  ~smart_pointer();
+};
+
+struct SmartPtr {
+  ~SmartPtr();
+};
+
+struct smart_ptr {
+  ~smart_ptr();
+};
+
+struct SmartReference {
+  ~SmartReference();
+};
+
+struct smart_reference {
+  ~smart_reference();
+};
+
+struct SmartRef {
+  ~SmartRef();
+};
+
+struct smart_ref {
+  ~smart_ref();
+};
+
+struct OtherType {
+  ~OtherType();
+};
+
+template  struct SomeComplexTemplate {
+  ~SomeComplexTemplate();
+};
+
+typedef SomeComplexTemplate NotTooComplexRef;
+
+void negativeSmartPointer(SmartPointer P) {
+}
+
+void negative_smart_pointer(smart_pointer p) {
+}
+
+void negativeSmartPtr(SmartPtr P) {
+}
+
+void negative_smart_ptr(smart_ptr p) {
+}
+
+void negativeSmartReference(SmartReference R) {
+}
+
+void negative_smart_reference(smart_reference r) {
+}
+
+void negativeSmartRef(SmartRef R) {
+}
+
+void negative_smart_ref(smart_ref r) {
+}
+
+void positiveOtherType(OtherType O) {
+  // CHECK-MESSAGES: [[@LINE-1]]:34: warning: the parameter 'O' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]
+  // CHECK-FIXES: void positiveOtherType(const OtherType& O) {
+}
+
+void negativeNotTooComplexRef(NotTooComplexRef R) {
+}
Index: test/clang-tidy/performance-unnecessary-copy-initialization-allowed-types.cpp
===
--- /dev/null
+++ test/clang-tidy/performance-unnecessary-copy-initialization-allowed-types.cpp
@@ -0,0 +1,98 @@
+// RUN: %check_clang_tidy %s performance-unnecessary-copy-initialization %t -- -config="{CheckOptions: [{key: performance-unnecessary-copy-initialization.AllowedTypes, value: '[Pp]ointer$;[Pp]tr$;[Rr]ef(erence)?$'}]}" --
+
+struct SmartPointer {
+  ~SmartPointer();
+};
+
+struct smart_pointer {
+  ~smart_pointer();
+};
+
+struct SmartPtr {
+  ~SmartPtr();
+};
+
+struct smart_ptr {
+  ~smart_ptr();
+};
+
+struct SmartReference {
+  ~SmartReference();
+};
+
+struct smart_reference {
+  ~smart_reference();
+};
+
+struct SmartRef {
+  ~SmartRef();
+};
+
+struct smart_ref {
+  ~smart_ref();
+};
+
+struct OtherType {
+  ~OtherType();
+};
+
+template  struct SomeComplexTemplate {
+  ~SomeComplexTemplate();
+};
+
+typedef SomeComplexTemplate NotTooComplexRef;
+
+const SmartPointer ();
+const smart_pointer _smart_pointer();
+const SmartPtr ();
+const smart_ptr _smart_ptr();
+const SmartReference ();
+const smart_reference _smart_reference();
+const SmartRef ();
+const smart_ref _smart_ref();
+const OtherType ();
+const NotTooComplexRef ();
+
+void negativeSmartPointer() {
+  const auto P = getSmartPointer();
+}
+
+void negative_smart_pointer() {
+  const auto p = get_smart_pointer();
+}
+
+void negativeSmartPtr() {
+  const auto P = getSmartPtr();
+}
+
+void negative_smart_ptr() {
+  const auto p = get_smart_ptr();
+}
+
+void negativeSmartReference() {
+  const auto R = getSmartReference();
+}
+
+void negative_smart_reference() {
+  const auto r = get_smart_reference();
+}
+
+void negativeSmartRef() {
+  const auto R = getSmartRef();
+}
+
+void negative_smart_ref() {
+  const auto r = get_smart_ref();
+}
+
+void positiveOtherType() {
+  const auto O = getOtherType();
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: the const qualified variable 'O' is copy-constructed from a const reference; consider making it a const reference [performance-unnecessary-copy-initialization]
+  // CHECK-FIXES: const auto& O = getOtherType();
+}
+
+void negativeNotTooComplexRef() {
+  const 

[PATCH] D53069: [analyzer][www] Update avaible_checks.html

2018-10-10 Thread Reka Kovacs via Phabricator via cfe-commits
rnkovacs added inline comments.



Comment at: www/analyzer/available_checks.html:376-393
+
+cplusplus.InnerPointer
+(C++)
+Check for inner pointers of C++ containers used after re/deallocation.
+
+
+

Szelethus wrote:
> @rnkovacs Is this a good description of your checker?
Hmm, how about:

```
void log(const char *str);

void test(int value) {
  const char *msg = std::to_string(value).c_str();
  // msg points to the buffer of a temporary that is now destroyed
  log(msg);  // warn: inner pointer of container used after re/deallocation
}
```

Most of the issues it found in real code looked like this.
Thanks a lot!


https://reviews.llvm.org/D53069



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


[PATCH] D53072: [clang-format] Introduce the flag which allows not to shrink lines

2018-10-10 Thread Ivan Donchevskii via Phabricator via cfe-commits
yvvan created this revision.
yvvan added reviewers: klimek, djasper, krasimir.

Currently there's no way to prevent to lines optimization even if you have 
intentionally put  to split the line.

In general case it's fine. So I would prefer to have such option which you can 
enable in special cases (for me it's an IDE related use case).


https://reviews.llvm.org/D53072

Files:
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Format/UnwrappedLineFormatter.cpp
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -349,6 +349,14 @@
"  void funk() {}\n"
"};",
Style));
+
+  Style.KeepLineBreaksForNonEmptyLines = true;
+  Style.ColumnLimit = 0;
+  EXPECT_EQ("int foo(int a,\n"
+"int b) {}",
+format("int foo(int a,\n"
+   "int b) {}",
+   Style));
 }
 
 TEST_F(FormatTest, RecognizesBinaryOperatorKeywords) {
Index: lib/Format/UnwrappedLineFormatter.cpp
===
--- lib/Format/UnwrappedLineFormatter.cpp
+++ lib/Format/UnwrappedLineFormatter.cpp
@@ -672,7 +672,7 @@
   LineFormatter(ContinuationIndenter *Indenter, WhitespaceManager *Whitespaces,
 const FormatStyle ,
 UnwrappedLineFormatter *BlockFormatter)
-  : Indenter(Indenter), Whitespaces(Whitespaces), Style(Style),
+  : Indenter(Indenter), Style(Style), Whitespaces(Whitespaces),
 BlockFormatter(BlockFormatter) {}
   virtual ~LineFormatter() {}
 
@@ -760,10 +760,10 @@
   }
 
   ContinuationIndenter *Indenter;
+  const FormatStyle 
 
 private:
   WhitespaceManager *Whitespaces;
-  const FormatStyle 
   UnwrappedLineFormatter *BlockFormatter;
 };
 
@@ -786,7 +786,8 @@
 while (State.NextToken) {
   bool Newline =
   Indenter->mustBreak(State) ||
-  (Indenter->canBreak(State) && State.NextToken->NewlinesBefore > 0);
+  (State.NextToken->NewlinesBefore > 0 &&
+   (Style.KeepLineBreaksForNonEmptyLines || Indenter->canBreak(State)));
   unsigned Penalty = 0;
   formatChildren(State, Newline, /*DryRun=*/false, Penalty);
   Indenter->addTokenToState(State, Newline, /*DryRun=*/false);
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -416,6 +416,8 @@
Style.IndentWrappedFunctionNames);
 IO.mapOptional("JavaScriptQuotes", Style.JavaScriptQuotes);
 IO.mapOptional("JavaScriptWrapImports", Style.JavaScriptWrapImports);
+IO.mapOptional("KeepLineBreaksForNonEmptyLines",
+   Style.KeepLineBreaksForNonEmptyLines);
 IO.mapOptional("KeepEmptyLinesAtTheStartOfBlocks",
Style.KeepEmptyLinesAtTheStartOfBlocks);
 IO.mapOptional("MacroBlockBegin", Style.MacroBlockBegin);
@@ -676,6 +678,7 @@
   LLVMStyle.JavaScriptWrapImports = true;
   LLVMStyle.TabWidth = 8;
   LLVMStyle.MaxEmptyLinesToKeep = 1;
+  LLVMStyle.KeepLineBreaksForNonEmptyLines = false;
   LLVMStyle.KeepEmptyLinesAtTheStartOfBlocks = true;
   LLVMStyle.NamespaceIndentation = FormatStyle::NI_None;
   LLVMStyle.ObjCBinPackProtocolList = FormatStyle::BPS_Auto;
@@ -741,6 +744,7 @@
   {"^", 2}, {"^<.*\\.h>", 1}, {"^<.*", 2}, {".*", 3}};
   GoogleStyle.IncludeStyle.IncludeIsMainRegex = "([-_](test|unittest))?$";
   GoogleStyle.IndentCaseLabels = true;
+  GoogleStyle.KeepLineBreaksForNonEmptyLines = false;
   GoogleStyle.KeepEmptyLinesAtTheStartOfBlocks = false;
   GoogleStyle.ObjCBinPackProtocolList = FormatStyle::BPS_Never;
   GoogleStyle.ObjCSpaceAfterProperty = false;
Index: include/clang/Format/Format.h
===
--- include/clang/Format/Format.h
+++ include/clang/Format/Format.h
@@ -1160,6 +1160,16 @@
   /// \endcode
   bool JavaScriptWrapImports;
 
+  /// If true, no line breaks are optimized out (works only with ColumnLimit = 0)
+  /// \code
+  ///true:  false:
+  ///int foo(int a, vs. int foo(int a, int b) {
+  ///int b) {
+  ///  bar(); bar();
+  ///}  }
+  /// \endcode
+  bool KeepLineBreaksForNonEmptyLines;
+
   /// If true, the empty line at the start of blocks is kept.
   /// \code
   ///true:  false:
@@ -1726,6 +1736,7 @@
IndentWrappedFunctionNames == R.IndentWrappedFunctionNames &&
JavaScriptQuotes == R.JavaScriptQuotes &&
JavaScriptWrapImports == R.JavaScriptWrapImports &&
+   KeepLineBreaksForNonEmptyLines == R.KeepLineBreaksForNonEmptyLines &&
KeepEmptyLinesAtTheStartOfBlocks ==
 

[PATCH] D51340: Add /Zc:DllexportInlines option to clang-cl

2018-10-10 Thread Takuto Ikuta via Phabricator via cfe-commits
takuto.ikuta added a comment.

Thank you for review!




Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5599
 
+bool Sema::isInlineFunctionDLLExportable(const CXXMethodDecl *MD) {
+  assert(MD->isInlined());

hans wrote:
> Okay, breaking out this logic is a little better, but I still don't like that 
> we now have split the "inherit dllexport attribute" in two places: one for 
> non-inline functions and one for inline (even if they both call this 
> function). It feels like it will be hard to maintain.
> 
> Here is another idea:
> 
> When we inherit the dllexport attribute to class members, if 
> getLangOpts().DllExportInlines is false, we don't put dllexport on inline 
> functions, but instead we put a new attribute "dllexportstaticlocals".
> 
> That attribute only has the effect that it makes static locals exported. We 
> would check for it when computing the linkage of the static local, similar to 
> how it works in hidden functions.
> 
> This has two benefits: it doesn't complicate the "inherit dllexport" code 
> very much, and it avoids the need for a separate AST walk of the function.
> 
> What do you think?
I implemented your idea the way I understood.
Use new attribute to check static local var later.

Due to difference of treating between linkage and dll attribute, I inherit dll 
attribute in Sema/SemaDecl.cpp instead of  AST/Decl.cpp


https://reviews.llvm.org/D51340



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


[PATCH] D51340: Add /Zc:DllexportInlines option to clang-cl

2018-10-10 Thread Takuto Ikuta via Phabricator via cfe-commits
takuto.ikuta updated this revision to Diff 168979.
takuto.ikuta added a comment.

address comment


https://reviews.llvm.org/D51340

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/CLCompatOptions.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp

Index: clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
@@ -0,0 +1,160 @@
+// RUN: %clang_cc1 %s -fms-extensions -triple x86_64-windows-msvc   \
+// RUN: -fno-dllexport-inlines -emit-llvm -O0 -o - |\
+// RUN: FileCheck --check-prefix=DEFAULT --check-prefix=NOINLINE %s
+
+// RUN: %clang_cc1 %s -fms-extensions -triple x86_64-windows-msvc   \
+// RUN: -emit-llvm -O0 -o - |   \
+// RUN: FileCheck --check-prefix=DEFAULT --check-prefix=INLINE %s
+
+
+// Function
+
+// DEFAULT-DAG: define dso_local dllexport void @"?NormalFunction@@YAXXZ"()
+void __declspec(dllexport) NormalFunction() {}
+
+
+// DEFAULT-DAG: define weak_odr dso_local dllexport void @"?AlwaysInlineFunction@@YAXXZ"
+__forceinline void __declspec(dllexport) AlwaysInlineFunction() {}
+
+// DEFAULT-DAG: @"?static_variable@?1??AlwaysInlineWithStaticVariableExported@@YAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+__forceinline int __declspec(dllexport) AlwaysInlineWithStaticVariableExported() {
+  static int static_variable = 0;
+  ++static_variable;
+  return static_variable;
+}
+
+// DEFAULT-DAG: @"?static_variable@?1??AlwaysInlineWithStaticVariableImported@@YAHXZ@4HA" = available_externally dllimport global i32 0, align 4
+__forceinline int __declspec(dllimport) AlwaysInlineWithStaticVariableImported() {
+  static int static_variable = 0;
+  ++static_variable;
+  return static_variable;
+}
+
+int ImportedFunctionUser() {
+  return AlwaysInlineWithStaticVariableImported();
+}
+
+// Class member function
+
+// check for local static variables
+// NOINLINE-DAG: @"?static_variable@?1??InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+
+// INLINE-DAG: @"?static_variable@?1??InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ@4HA" = weak_odr dso_local dllexport global i32 0, comdat, align 4
+class __declspec(dllexport) NoTemplateExportedClass {
+ public:
+  // DEFAULT-NOT: NoTemplateExportedClass@NoTemplateExportedClass@@
+  NoTemplateExportedClass() = default;
+
+  // NOINLINE-NOT: InclassDefFunc@NoTemplateExportedClass
+  // INLINE-DAG: define weak_odr dso_local dllexport void @"?InclassDefFunc@NoTemplateExportedClass@@
+  void InclassDefFunc() {}
+
+  int f();
+
+  // DEFAULT-DAG: define weak_odr dso_local dllexport i32 @"?InclassDefFuncWithStaticVariable@NoTemplateExportedClass@@QEAAHXZ"
+  int InclassDefFuncWithStaticVariable() {
+static int static_variable = 0;
+++static_variable;
+return static_variable;
+  }
+
+  // DEFAULT-DAG: define weak_odr dso_local dllexport i32 @"?InclassDefFunctWithLambdaStaticVariable@NoTemplateExportedClass@@QEAAHXZ"
+  int InclassDefFunctWithLambdaStaticVariable() {
+return ([]() { static int static_x; return ++static_x; })();
+  }
+
+  // DEFAULT-NOT: InlineOutclassDefFuncWihtoutDefinition
+  __forceinline void InlineOutclassDefFuncWihtoutDefinition();
+
+  // DEFAULT-NOT: InlineOutclassDefFunc@NoTemplateExportedClass@@
+  __forceinline void InlineOutclassDefFunc();
+
+  // DEFAULT-NOT: InlineOutclassDefFuncWithStaticVariable@NoTemplateExportedClass@@
+  __forceinline int InlineOutclassDefFuncWithStaticVariable();
+
+  // DEFAULT-DAG: define dso_local dllexport void @"?OutclassDefFunc@NoTemplateExportedClass@@QEAAXXZ"
+  void OutclassDefFunc();
+};
+
+void NoTemplateExportedClass::OutclassDefFunc() {}
+
+__forceinline void NoTemplateExportedClass::InlineOutclassDefFunc() {}
+
+__forceinline int NoTemplateExportedClass::InlineOutclassDefFuncWithStaticVariable() {
+  static int static_variable = 0;
+  return ++static_variable;
+}
+
+void __declspec(dllexport) NoTemplateExportedClassUser() {
+  NoTemplateExportedClass a;
+  a.InlineOutclassDefFunc();
+}
+
+template
+class __declspec(dllexport) TemplateExportedClass {
+  void InclassDefFunc() {}
+  void OutclassDefFunc();
+
+  T templateValue;
+};
+
+// DEFAULT-NOT: define dso_local dllexport void @"?OutclassDefFunc@NoTemplateExportedClass@@
+template void TemplateExportedClass::OutclassDefFunc() {}
+
+class A11{};
+class B22{};
+
+// DEFAULT-DAG: define weak_odr dso_local dllexport void @"?InclassDefFunc@?$TemplateExportedClass@VA11@@
+// DEFAULT-DAG: define weak_odr dso_local dllexport void 

  1   2   >