[PATCH] D86823: [clang][Modules] Perform an Extra Consistency Check When Searching The ModuleManager's Cache For Implicit Modules

2020-08-28 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl accepted this revision.
aprantl added a comment.
This revision is now accepted and ready to land.

Assuming that it works, this seems fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86823

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


[PATCH] D85676: [NewPM] collapsing nested pass mangers of the same type

2020-08-28 Thread Alina Sbirlea via Phabricator via cfe-commits
asbirlea accepted this revision.
asbirlea added a comment.
This revision is now accepted and ready to land.

Seems like a good idea. I'm curious if you saw any impact from this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85676

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


[PATCH] D86822: [clang] Enable -fsanitize=thread on Fuchsia.

2020-08-28 Thread Marco Vanotti via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2e800495a78a: [clang] Enable -fsanitize=thread on Fuchsia. 
(authored by charco).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86822

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp


Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -703,6 +703,8 @@
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -747,7 +749,8 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");


Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -703,6 +703,8 @@
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -747,7 +749,8 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 2e80049 - [clang] Enable -fsanitize=thread on Fuchsia.

2020-08-28 Thread Marco Vanotti via cfe-commits

Author: Marco Vanotti
Date: 2020-08-28T17:26:27-07:00
New Revision: 2e800495a78a6d722eed5766bba1e2fe76f295bc

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

LOG: [clang] Enable -fsanitize=thread on Fuchsia.

This CL modifies clang enabling using -fsanitize=thread on fuchsia. The
change doesn't build the runtime for fuchsia, it just enables the
instrumentation to be used.

pair-programmed-with: mdemp...@google.com
Change-Id: I816c4d240d1f15e9eae2803fb8ba3a7bf667ed51

Reviewed By: mcgrathr, phosek

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 39308f8ea5b7..8bbb642c2917 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -703,6 +703,8 @@ collectSanitizerRuntimes(const ToolChain &TC, const ArgList 
&Args,
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -747,7 +749,8 @@ collectSanitizerRuntimes(const ToolChain &TC, const ArgList 
&Args,
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");

diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 94e025e3055a..781179be39a3 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@ SanitizerMask Fuchsia::getSupportedSanitizers() const {
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 



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


[PATCH] D86822: [clang] Enable -fsanitize=thread on Fuchsia.

2020-08-28 Thread Marco Vanotti via Phabricator via cfe-commits
charco updated this revision to Diff 288735.
charco added a comment.

remove change-id lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86822

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp


Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -698,6 +698,8 @@
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -735,7 +737,8 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");


Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -698,6 +698,8 @@
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -735,7 +737,8 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86823: [clang][Modules] Perform an Extra Consistency Check When Searching The ModuleManager's Cache For Implicit Modules

2020-08-28 Thread Robert Widmann via Phabricator via cfe-commits
CodaFi updated this revision to Diff 288734.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86823

Files:
  clang/lib/Serialization/ModuleManager.cpp


Index: clang/lib/Serialization/ModuleManager.cpp
===
--- clang/lib/Serialization/ModuleManager.cpp
+++ clang/lib/Serialization/ModuleManager.cpp
@@ -132,15 +132,38 @@
 return Missing;
   }
 
+  // The ModuleManager's use of FileEntry nodes as the keys for its map of
+  // loaded modules is less than ideal. Uniqueness for FileEntry nodes is
+  // maintained by FileManager, which in turn uses inode numbers on hosts
+  // that support that. When coupled with the module cache's proclivity for
+  // turning over and deleting stale PCMs, this means entries for different
+  // module files can wind up reusing the same underlying inode. When this
+  // happens, subsequent accesses to the Modules map will disagree on the
+  // ModuleFile associated with a given file. In general, it is not sufficient
+  // to resolve this conundrum with a type like FileEntryRef that stores the
+  // name of the FileEntry node on first access because of path 
canonicalization
+  // issues. However, the paths constructed for implicit module builds are
+  // fully under Clang's control. We *can*, therefore, rely on their structure
+  // being consistent across operating systems and across subsequent accesses
+  // to the Modules map.
+  auto implicitModuleNamesMatch = [](ModuleKind Kind, const ModuleFile *MF,
+ const FileEntry *Entry) -> bool {
+if (Kind != MK_ImplicitModule)
+  return true;
+return Entry->getName() == MF->FileName;
+  };
+
   // Check whether we already loaded this module, before
   if (ModuleFile *ModuleEntry = Modules.lookup(Entry)) {
-// Check the stored signature.
-if (checkSignature(ModuleEntry->Signature, ExpectedSignature, ErrorStr))
-  return OutOfDate;
-
-Module = ModuleEntry;
-updateModuleImports(*ModuleEntry, ImportedBy, ImportLoc);
-return AlreadyLoaded;
+if (implicitModuleNamesMatch(Type, ModuleEntry, Entry)) {
+  // Check the stored signature.
+  if (checkSignature(ModuleEntry->Signature, ExpectedSignature, ErrorStr))
+return OutOfDate;
+
+  Module = ModuleEntry;
+  updateModuleImports(*ModuleEntry, ImportedBy, ImportLoc);
+  return AlreadyLoaded;
+}
   }
 
   // Allocate a new module.


Index: clang/lib/Serialization/ModuleManager.cpp
===
--- clang/lib/Serialization/ModuleManager.cpp
+++ clang/lib/Serialization/ModuleManager.cpp
@@ -132,15 +132,38 @@
 return Missing;
   }
 
+  // The ModuleManager's use of FileEntry nodes as the keys for its map of
+  // loaded modules is less than ideal. Uniqueness for FileEntry nodes is
+  // maintained by FileManager, which in turn uses inode numbers on hosts
+  // that support that. When coupled with the module cache's proclivity for
+  // turning over and deleting stale PCMs, this means entries for different
+  // module files can wind up reusing the same underlying inode. When this
+  // happens, subsequent accesses to the Modules map will disagree on the
+  // ModuleFile associated with a given file. In general, it is not sufficient
+  // to resolve this conundrum with a type like FileEntryRef that stores the
+  // name of the FileEntry node on first access because of path canonicalization
+  // issues. However, the paths constructed for implicit module builds are
+  // fully under Clang's control. We *can*, therefore, rely on their structure
+  // being consistent across operating systems and across subsequent accesses
+  // to the Modules map.
+  auto implicitModuleNamesMatch = [](ModuleKind Kind, const ModuleFile *MF,
+ const FileEntry *Entry) -> bool {
+if (Kind != MK_ImplicitModule)
+  return true;
+return Entry->getName() == MF->FileName;
+  };
+
   // Check whether we already loaded this module, before
   if (ModuleFile *ModuleEntry = Modules.lookup(Entry)) {
-// Check the stored signature.
-if (checkSignature(ModuleEntry->Signature, ExpectedSignature, ErrorStr))
-  return OutOfDate;
-
-Module = ModuleEntry;
-updateModuleImports(*ModuleEntry, ImportedBy, ImportLoc);
-return AlreadyLoaded;
+if (implicitModuleNamesMatch(Type, ModuleEntry, Entry)) {
+  // Check the stored signature.
+  if (checkSignature(ModuleEntry->Signature, ExpectedSignature, ErrorStr))
+return OutOfDate;
+
+  Module = ModuleEntry;
+  updateModuleImports(*ModuleEntry, ImportedBy, ImportLoc);
+  return AlreadyLoaded;
+}
   }
 
   // Allocate a new module.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86823: [clang][Modules] Perform an Extra Consistency Check When Searching The ModuleManager's Cache For Implicit Modules

2020-08-28 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl added inline comments.



Comment at: clang/lib/Serialization/ModuleManager.cpp:152
+ const FileEntry *Entry) -> bool {
+if (Kind != MK_ImplicitModule) {
+  return true;

nit: LLVM style omits curly braces on single statements.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86823

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


[PATCH] D86502: [CSSPGO] A Clang switch -fpseudo-probe-for-profiling for pseudo-probe instrumentation.

2020-08-28 Thread Wei Mi via Phabricator via cfe-commits
wmi added a comment.

In D86502#2245578 , @hoy wrote:

> In D86502#2245460 , @wmi wrote:
>
>>> The early instrumentation also allows the inliner to duplicate probes for 
>>> inlined instances. When a probe along with the other instructions of a 
>>> callee function are inlined into its caller function, the GUID of the 
>>> callee function goes with the probe. This allows samples collected on 
>>> inlined probes to be reported for the original callee function.
>>
>> Just get a question from reading the above. Suppose `A` only has one BB and 
>> the BB has one PseudoProbe in it. If function `A` is inlined into `B1` and 
>> `B2` and both `B1` and `B2` inlined into `C`, the PseudoProbe from `A` will 
>> have two copies in `C` both carrying GUID of `A`. How the samples collected 
>> from `A` inlined into `B1` inlined into `C` are categorized differently from 
>> `A` inlined into `B2` inlined into `C`, especially when debug information is 
>> not enabled (so no inline stack information in the binary)?
>
> This is a very good question. Inlined functions are differentiated by their 
> original callsites. A pseudo probe is allocated for each callsite in the 
> `SampleProfileProbe` pass. Nested inlining will produce a stack of pseudo 
> probes, similar with the Dwarf inline stack. The work is not included in the 
> first set of patches.

Thanks, then how does the pseudo probe for a callsite after inline to represent 
the inline scope it covers?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86502

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


[clang] b5ef137 - [gcov] Increment counters with atomicrmw if -fsanitize=thread

2020-08-28 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-08-28T16:32:35-07:00
New Revision: b5ef137c11b1cc6ae839ee75b49233825772bdd0

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

LOG: [gcov] Increment counters with atomicrmw if -fsanitize=thread

Without this patch, `clang --coverage -fsanitize=thread` may fail spuriously
because non-atomic counter increments can be detected as data races.

Added: 
clang/test/CodeGen/code-coverage-tsan.c
llvm/test/Transforms/GCOVProfiling/atomic-counter.ll

Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/Transforms/Instrumentation.h
llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 1d4763fff80e..258f5fe69ff8 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -553,7 +553,9 @@ static void initTargetOptions(DiagnosticsEngine &Diags,
   Options.MCOptions.Argv0 = CodeGenOpts.Argv0;
   Options.MCOptions.CommandLineArgs = CodeGenOpts.CommandLineArgs;
 }
-static Optional getGCOVOptions(const CodeGenOptions &CodeGenOpts) 
{
+
+static Optional getGCOVOptions(const CodeGenOptions &CodeGenOpts,
+const LangOptions &LangOpts) {
   if (CodeGenOpts.DisableGCov)
 return None;
   if (!CodeGenOpts.EmitGcovArcs && !CodeGenOpts.EmitGcovNotes)
@@ -567,6 +569,7 @@ static Optional getGCOVOptions(const 
CodeGenOptions &CodeGenOpts) {
   Options.NoRedZone = CodeGenOpts.DisableRedZone;
   Options.Filter = CodeGenOpts.ProfileFilterFiles;
   Options.Exclude = CodeGenOpts.ProfileExcludeFiles;
+  Options.Atomic = LangOpts.Sanitize.has(SanitizerKind::Thread);
   return Options;
 }
 
@@ -763,7 +766,7 @@ void EmitAssemblyHelper::CreatePasses(legacy::PassManager 
&MPM,
 MPM.add(createUniqueInternalLinkageNamesPass());
   }
 
-  if (Optional Options = getGCOVOptions(CodeGenOpts)) {
+  if (Optional Options = getGCOVOptions(CodeGenOpts, LangOpts)) {
 MPM.add(createGCOVProfilerPass(*Options));
 if (CodeGenOpts.getDebugInfo() == codegenoptions::NoDebugInfo)
   MPM.add(createStripSymbolsPass(true));
@@ -1229,7 +1232,7 @@ void EmitAssemblyHelper::EmitAssemblyWithNewPassManager(
 MPM.addPass(LowerTypeTestsPass(/*ExportSummary=*/nullptr,
/*ImportSummary=*/nullptr,
/*DropTypeTests=*/true));
-  if (Optional Options = getGCOVOptions(CodeGenOpts))
+  if (Optional Options = getGCOVOptions(CodeGenOpts, 
LangOpts))
 MPM.addPass(GCOVProfilerPass(*Options));
   if (Optional Options =
   getInstrProfOptions(CodeGenOpts, LangOpts))
@@ -1349,7 +1352,7 @@ void EmitAssemblyHelper::EmitAssemblyWithNewPassManager(
   /*CompileKernel=*/false, Recover, UseAfterScope)));
 });
   }
-  if (Optional Options = getGCOVOptions(CodeGenOpts))
+  if (Optional Options = getGCOVOptions(CodeGenOpts, 
LangOpts))
 PB.registerPipelineStartEPCallback([Options](ModulePassManager &MPM) {
   MPM.addPass(GCOVProfilerPass(*Options));
 });

diff  --git a/clang/test/CodeGen/code-coverage-tsan.c 
b/clang/test/CodeGen/code-coverage-tsan.c
new file mode 100644
index ..023a99598075
--- /dev/null
+++ b/clang/test/CodeGen/code-coverage-tsan.c
@@ -0,0 +1,12 @@
+/// -fsanitize=thread requires the (potentially concurrent) counter updates to 
be atomic.
+// RUN: %clang_cc1 %s -triple x86_64 -emit-llvm -fsanitize=thread 
-femit-coverage-notes -femit-coverage-data \
+// RUN:   -coverage-notes-file /dev/null -coverage-data-file /dev/null -o - | 
FileCheck %s
+
+// CHECK-LABEL: void @foo()
+/// Two counters are incremented by __tsan_atomic64_fetch_add.
+// CHECK: call i64 @__tsan_atomic64_fetch_add
+// CHECK-NEXT:call i64 @__tsan_atomic64_fetch_add
+// CHECK-NEXT:call i32 @__tsan_atomic32_fetch_sub
+
+_Atomic(int) cnt;
+void foo() { cnt--; }

diff  --git a/llvm/include/llvm/Transforms/Instrumentation.h 
b/llvm/include/llvm/Transforms/Instrumentation.h
index 0453cb428bc0..c960d5b0ab50 100644
--- a/llvm/include/llvm/Transforms/Instrumentation.h
+++ b/llvm/include/llvm/Transforms/Instrumentation.h
@@ -66,6 +66,9 @@ struct GCOVOptions {
   // Add the 'noredzone' attribute to added runtime library calls.
   bool NoRedZone;
 
+  // Use atomic profile counter increments.
+  bool Atomic = false;
+
   // Regexes separated by a semi-colon to filter the files to instrument.
   std::string Filter;
 

diff  --git a/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp 
b/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
index 53a89f7348de..3773c3e19ef6 100644
--- a/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
+++ b/

[PATCH] D86823: [clang][Modules] Perform an Extra Consistency Check When Searching The ModuleManager's Cache For Implicit Modules

2020-08-28 Thread Robert Widmann via Phabricator via cfe-commits
CodaFi created this revision.
CodaFi added reviewers: vsapsai, aprantl, doug.gregor.
Herald added subscribers: cfe-commits, danielkiss.
Herald added a project: clang.
CodaFi requested review of this revision.

The ModuleManager's use of FileEntry nodes as the keys for its map of
loaded modules is less than ideal. Uniqueness for FileEntry nodes is
maintained by FileManager, which in turn uses inode numbers on hosts
that support that. When coupled with the module cache's proclivity for
turning over and deleting stale PCMs, this means entries for different
module files can wind up reusing the same underlying inode. When this
happens, subsequent accesses to the Modules map will disagree on the
ModuleFile associated with a given file.

In general, it is not sufficient to resolve this conundrum with a type like 
FileEntryRef that stores the
name of the FileEntry node on first access because of path canonicalization
issues. However, the paths constructed for implicit module builds are
fully under Clang's control. We *can*, therefore, rely on their structure
being consistent across operating systems and across subsequent accesses
to the Modules map.

To mitigate the effects of inode reuse, perform an extra name check when
implicit modules are returned from the cache. This has the effect of
forcing reused FileEntry nodes to stomp over existing-but-stale entries
in the cache, which simulates a miss - exactly the desired behavior.

rdar://48443680


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86823

Files:
  clang/lib/Serialization/ModuleManager.cpp


Index: clang/lib/Serialization/ModuleManager.cpp
===
--- clang/lib/Serialization/ModuleManager.cpp
+++ clang/lib/Serialization/ModuleManager.cpp
@@ -132,15 +132,40 @@
 return Missing;
   }
 
+  // The ModuleManager's use of FileEntry nodes as the keys for its map of
+  // loaded modules is less than ideal. Uniqueness for FileEntry nodes is
+  // maintained by FileManager, which in turn uses inode numbers on hosts
+  // that support that. When coupled with the module cache's proclivity for
+  // turning over and deleting stale PCMs, this means entries for different
+  // module files can wind up reusing the same underlying inode. When this
+  // happens, subsequent accesses to the Modules map will disagree on the
+  // ModuleFile associated with a given file. In general, it is not sufficient
+  // to resolve this conundrum with a type like FileEntryRef that stores the
+  // name of the FileEntry node on first access because of path 
canonicalization
+  // issues. However, the paths constructed for implicit module builds are
+  // fully under Clang's control. We *can*, therefore, rely on their structure
+  // being consistent across operating systems and across subsequent accesses
+  // to the Modules map.
+  auto implicitModuleNamesMatch = [](ModuleKind Kind,
+ const ModuleFile *MF,
+ const FileEntry *Entry) -> bool {
+if (Kind != MK_ImplicitModule) {
+  return true;
+}
+return Entry->getName() == MF->FileName;
+  };
+
   // Check whether we already loaded this module, before
   if (ModuleFile *ModuleEntry = Modules.lookup(Entry)) {
-// Check the stored signature.
-if (checkSignature(ModuleEntry->Signature, ExpectedSignature, ErrorStr))
-  return OutOfDate;
-
-Module = ModuleEntry;
-updateModuleImports(*ModuleEntry, ImportedBy, ImportLoc);
-return AlreadyLoaded;
+if (implicitModuleNamesMatch(Type, ModuleEntry, Entry)) {
+  // Check the stored signature.
+  if (checkSignature(ModuleEntry->Signature, ExpectedSignature, ErrorStr))
+return OutOfDate;
+
+  Module = ModuleEntry;
+  updateModuleImports(*ModuleEntry, ImportedBy, ImportLoc);
+  return AlreadyLoaded;
+}
   }
 
   // Allocate a new module.


Index: clang/lib/Serialization/ModuleManager.cpp
===
--- clang/lib/Serialization/ModuleManager.cpp
+++ clang/lib/Serialization/ModuleManager.cpp
@@ -132,15 +132,40 @@
 return Missing;
   }
 
+  // The ModuleManager's use of FileEntry nodes as the keys for its map of
+  // loaded modules is less than ideal. Uniqueness for FileEntry nodes is
+  // maintained by FileManager, which in turn uses inode numbers on hosts
+  // that support that. When coupled with the module cache's proclivity for
+  // turning over and deleting stale PCMs, this means entries for different
+  // module files can wind up reusing the same underlying inode. When this
+  // happens, subsequent accesses to the Modules map will disagree on the
+  // ModuleFile associated with a given file. In general, it is not sufficient
+  // to resolve this conundrum with a type like FileEntryRef that stores the
+  // name of the FileEntry node on first access because of path canonicalization
+  // issues. However, the path

[PATCH] D85981: [clang][Modules] Increase the Entropy of ModuleManager Map Keys

2020-08-28 Thread Robert Widmann via Phabricator via cfe-commits
CodaFi abandoned this revision.
CodaFi added a comment.
Herald added a subscriber: danielkiss.

We have tested this proposed change out on our CI systems and have seen no 
relief from the symptoms of inode reuse with this approach. Abandoning this 
revision in favor of a more narrow fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85981

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


[PATCH] D86822: [clang] Enable -fsanitize=thread on Fuchsia.

2020-08-28 Thread Roland McGrath via Phabricator via cfe-commits
mcgrathr accepted this revision.
mcgrathr added a comment.

I'm not 100% sure we don't need more fiddles in the driver, but we can iterate 
from here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86822

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


[PATCH] D86822: [clang] Enable -fsanitize=thread on Fuchsia.

2020-08-28 Thread Petr Hosek via Phabricator via cfe-commits
phosek accepted this revision.
phosek added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86822

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


[PATCH] D85408: Let -basic-block-sections=labels emit basicblock metadata in a new .bb_addr_map section, instead of emitting special unary-encoded symbols.

2020-08-28 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish accepted this revision.
snehasish added a comment.
This revision is now accepted and ready to land.

LGTM. Please wait a bit for additional comments from others.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85408

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


[PATCH] D86822: [clang] Enable -fsanitize=thread on Fuchsia.

2020-08-28 Thread Marco Vanotti via Phabricator via cfe-commits
charco created this revision.
charco added reviewers: mcgrathr, phosek.
Herald added subscribers: cfe-commits, danielkiss.
Herald added a project: clang.
charco requested review of this revision.

This CL modifies clang enabling using -fsanitize=thread on fuchsia. The
change doesn't build the runtime for fuchsia, it just enables the
instrumentation to be used.

pair-programmed-with: mdemp...@google.com
Change-Id: I816c4d240d1f15e9eae2803fb8ba3a7bf667ed51


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86822

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp


Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -698,6 +698,8 @@
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -735,7 +737,8 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");


Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -95,6 +95,8 @@
 std::string Dyld = D.DyldPrefix;
 if (SanArgs.needsAsanRt() && SanArgs.needsSharedRt())
   Dyld += "asan/";
+if (SanArgs.needsTsanRt() && SanArgs.needsSharedRt())
+  Dyld += "tsan/";
 Dyld += "ld.so.1";
 CmdArgs.push_back("-dynamic-linker");
 CmdArgs.push_back(Args.MakeArgString(Dyld));
@@ -349,6 +351,7 @@
   Res |= SanitizerKind::Leak;
   Res |= SanitizerKind::SafeStack;
   Res |= SanitizerKind::Scudo;
+  Res |= SanitizerKind::Thread;
   return Res;
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -698,6 +698,8 @@
   else
 SharedRuntimes.push_back("scudo");
 }
+if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes())
+  SharedRuntimes.push_back("tsan");
 if (SanArgs.needsHwasanRt() && SanArgs.linkRuntimes())
   SharedRuntimes.push_back("hwasan");
   }
@@ -735,7 +737,8 @@
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("msan_cxx");
   }
-  if (SanArgs.needsTsanRt() && SanArgs.linkRuntimes()) {
+  if (!SanArgs.needsSharedRt() && SanArgs.needsTsanRt() &&
+  SanArgs.linkRuntimes()) {
 StaticRuntimes.push_back("tsan");
 if (SanArgs.linkCXXRuntimes())
   StaticRuntimes.push_back("tsan_cxx");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86156: [BFI] Preserve BFI information through loop passes via VH callbacks inside LoopStandardAnalysisResults

2020-08-28 Thread Di Mo via Phabricator via cfe-commits
modimo added a comment.

In D86156#2245103 , @nikic wrote:

> I have no familiarity with BFI, so possibly stupid question: There is already 
> some similar handling as part of BFIImpl here: 
> https://github.com/llvm/llvm-project/blob/0f14b2e6cbb54c84ed3b00b0db521f5ce2d1e3f2/llvm/include/llvm/Analysis/BlockFrequencyInfoImpl.h#L1043-L1058
>  What is the difference to that / why are both needed?

Well this is a funny situation: looks like someone else saw the same problem we 
observed and pushed the fix also using VH callbacks (D75341 
). Both of us coming to the same solution here 
is a good sign that its a good fit.

I'm glad you pointed this out! Looking at my diff with both callbacks 
incorporated the node gets erase() called twice but since the second call isn't 
in the DenseMap erase becomes a no-op. This explains why both changes didn't 
catastrophically collide against each other.

Given all that, the changes here to pass along the BFI information in the loop 
passes and allow usage in LICM still seems meaningful enough to commit. I've 
removed the redundant call-back added. Also updating the description to reflect 
the latest updates.




Comment at: llvm/lib/Transforms/Scalar/LoopDistribute.cpp:1062
+LoopStandardAnalysisResults AR = {AA,  AC,  DT,  LI, SE,
+  TLI, TTI, nullptr, nullptr};
 return LAM.getResult(L, AR);

nikic wrote:
> Huh, surprised that clang-format allows this.
I also thought that was a mis-format at first but the combination of rules 
turns out to prefer this.


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

https://reviews.llvm.org/D86156

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


[PATCH] D86156: [BFI] Preserve BFI information through loop passes via VH callbacks inside LoopStandardAnalysisResults

2020-08-28 Thread Di Mo via Phabricator via cfe-commits
modimo updated this revision to Diff 288719.
modimo added a comment.

Remove redundant VH callback as @nikic helpfully pointed out!


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

https://reviews.llvm.org/D86156

Files:
  llvm/include/llvm/Analysis/LoopAnalysisManager.h
  llvm/include/llvm/Transforms/Scalar/LoopPassManager.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Transforms/Scalar/LICM.cpp
  llvm/lib/Transforms/Scalar/LoopDistribute.cpp
  llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
  llvm/lib/Transforms/Scalar/LoopUnswitch.cpp
  llvm/lib/Transforms/Utils/LoopVersioning.cpp
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline-enable-matrix.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/unittests/Transforms/Scalar/LoopPassManagerTest.cpp

Index: llvm/unittests/Transforms/Scalar/LoopPassManagerTest.cpp
===
--- llvm/unittests/Transforms/Scalar/LoopPassManagerTest.cpp
+++ llvm/unittests/Transforms/Scalar/LoopPassManagerTest.cpp
@@ -9,7 +9,10 @@
 #include "llvm/Transforms/Scalar/LoopPassManager.h"
 #include "llvm/Analysis/AliasAnalysis.h"
 #include "llvm/Analysis/AssumptionCache.h"
+#include "llvm/Analysis/BlockFrequencyInfo.h"
+#include "llvm/Analysis/BranchProbabilityInfo.h"
 #include "llvm/Analysis/MemorySSA.h"
+#include "llvm/Analysis/PostDominators.h"
 #include "llvm/Analysis/ScalarEvolution.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/TargetTransformInfo.h"
@@ -294,6 +297,9 @@
 // those.
 FAM.registerPass([&] { return AAManager(); });
 FAM.registerPass([&] { return AssumptionAnalysis(); });
+FAM.registerPass([&] { return BlockFrequencyAnalysis(); });
+FAM.registerPass([&] { return BranchProbabilityAnalysis(); });
+FAM.registerPass([&] { return PostDominatorTreeAnalysis(); });
 FAM.registerPass([&] { return MemorySSAAnalysis(); });
 FAM.registerPass([&] { return ScalarEvolutionAnalysis(); });
 FAM.registerPass([&] { return TargetLibraryAnalysis(); });
Index: llvm/test/Other/opt-Os-pipeline.ll
===
--- llvm/test/Other/opt-Os-pipeline.ll
+++ llvm/test/Other/opt-Os-pipeline.ll
@@ -97,6 +97,8 @@
 ; CHECK-NEXT: Loop Pass Manager
 ; CHECK-NEXT:   Rotate Loops
 ; CHECK-NEXT: Memory SSA
+; CHECK-NEXT: Lazy Branch Probability Analysis
+; CHECK-NEXT: Lazy Block Frequency Analysis
 ; CHECK-NEXT: Loop Pass Manager
 ; CHECK-NEXT:   Loop Invariant Code Motion
 ; CHECK-NEXT:   Unswitch loops
@@ -154,6 +156,8 @@
 ; CHECK-NEXT: LCSSA Verifier
 ; CHECK-NEXT: Loop-Closed SSA Form Pass
 ; CHECK-NEXT: Scalar Evolution Analysis
+; CHECK-NEXT: Lazy Branch Probability Analysis
+; CHECK-NEXT: Lazy Block Frequency Analysis
 ; CHECK-NEXT: Loop Pass Manager
 ; CHECK-NEXT:   Loop Invariant Code Motion
 ; CHECK-NEXT: Post-Dominator Tree Construction
@@ -256,10 +260,10 @@
 ; CHECK-NEXT:   LCSSA Verifier
 ; CHECK-NEXT:   Loop-Closed SSA Form Pass
 ; CHECK-NEXT:   Scalar Evolution Analysis
-; CHECK-NEXT:   Loop Pass Manager
-; CHECK-NEXT: Loop Invariant Code Motion
 ; CHECK-NEXT:   Lazy Branch Probability Analysis
 ; CHECK-NEXT:   Lazy Block Frequency Analysis
+; CHECK-NEXT:   Loop Pass Manager
+; CHECK-NEXT: Loop Invariant Code Motion
 ; CHECK-NEXT:   Optimization Remark Emitter
 ; CHECK-NEXT:   Warn about non-applied transformations
 ; CHECK-NEXT:   Alignment from assumptions
Index: llvm/test/Other/opt-O3-pipeline.ll
===
--- llvm/test/Other/opt-O3-pipeline.ll
+++ llvm/test/Other/opt-O3-pipeline.ll
@@ -116,6 +116,8 @@
 ; CHECK-NEXT: Loop Pass Manager
 ; CHECK-NEXT:   Rotate Loops
 ; CHECK-NEXT: Memory SSA
+; CHECK-NEXT: Lazy Branch Probability Analysis
+; CHECK-NEXT: Lazy Block Frequency Analysis
 ; CHECK-NEXT: Loop Pass Manager
 ; CHECK-NEXT:   Loop Invariant Code Motion
 ; CHECK-NEXT:   Unswitch loops
@@ -173,6 +175,8 @@
 ; CHECK-NEXT: LCSSA Verifier
 ; CHECK-NEXT: Loop-Closed SSA Form Pass
 ; CHECK-NEXT: Scalar Evolution Analysis
+; CHECK-NEXT: Lazy Branch Probability Analysis
+; CHECK-NEXT: Lazy Block Frequency Analysis
 ; CHECK-NEXT: Loop Pass Manager
 ; CHECK-NEXT:   Loop Invariant Code Motion
 ; CHECK-NEXT: Post-Dominator Tree Construction
@@ -275,10 +279,10 @@
 ; CHECK-NEXT:   LCSSA Verifier
 ; CHECK-NEXT:   Loop-Closed SSA Form Pass
 ; CHECK-NEXT:   Scalar Evolution Analysis
-; CHECK-NEXT:   Loop Pass Manager
-; CHECK-NEXT: Loop Invariant Code Motion
 ; CHECK-NEXT:   Lazy Branch Probability Analysis
 ; CHECK-N

[PATCH] D67113: ICK_Function_Conversion is a third kind conversion

2020-08-28 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added a comment.
Herald added a subscriber: danielkiss.

In D67113#2244463 , @aaron.ballman 
wrote:

> There may be a deeper issue here in that there are four standard conversion 
> sequences, not three: http://eel.is/c++draft/conv#1, but otherwise this 
> change seems correct to me (function conversion is certainly not in the first 
> group).

It seems we've collapsed the third and fourth kind into one, I wonder if that 
makes a difference. This can even be observed in the AST:

  void f() noexcept;
  void (*const fp)() = f;
  // VarDecl fp 'void (*const)()' cinit
  // (2) `-ImplicitCastExpr 'void (*const)()' 
  // (1)   `-ImplicitCastExpr 'void (*)() noexcept' 
  // `-DeclRefExpr 'void () noexcept' lvalue Function 'f' 'void () 
noexcept'

where (1) is a first kind conversion, and (2) a combined third and fourth kind 
conversion. Since both are essentially no-ops (see also D67112 
), it probably doesn't make sense to go into 
more detail.

> Do you have a test case which can exercise this change?

Nope, just discovered this while reading the code. This should be unreachable, 
so it would be bad if I could observe a change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67113

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


[PATCH] D86502: [CSSPGO] A Clang switch -fpseudo-probe-for-profiling for pseudo-probe instrumentation.

2020-08-28 Thread Hongtao Yu via Phabricator via cfe-commits
hoy updated this revision to Diff 288716.
hoy marked an inline comment as done.
hoy added a comment.

Updating D86502 : [CSSPGO] A Clang switch 
-fpseudo-probe-for-profiling for pseudo-probe instrumentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86502

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/emit-pseudo-probe.c
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/Passes/PassBuilder.cpp

Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -901,6 +901,12 @@
 OptimizationLevel Level, ThinLTOPhase Phase, bool DebugLogging) {
   ModulePassManager MPM(DebugLogging);
 
+  // Place pseudo probe instrumentation as the first pass of the pipeline to
+  // minimize the impact of optimization changes.
+  if (PGOOpt && PGOOpt->PseudoProbeForProfiling &&
+  Phase != ThinLTOPhase::PostLink)
+MPM.addPass(SampleProfileProbePass(TM));
+
   bool HasSampleProfile = PGOOpt && (PGOOpt->Action == PGOOptions::SampleUse);
 
   // In ThinLTO mode, when flattened profile is used, all the available
@@ -1254,7 +1260,7 @@
   for (auto &C : PipelineStartEPCallbacks)
 C(MPM);
 
-  if (PGOOpt && PGOOpt->SamplePGOSupport)
+  if (PGOOpt && PGOOpt->DebugInfoForProfiling)
 MPM.addPass(createModuleToFunctionPassAdaptor(AddDiscriminatorsPass()));
 
   // Add the core simplification pipeline.
@@ -1278,7 +1284,7 @@
   // Force any function attributes we want the rest of the pipeline to observe.
   MPM.addPass(ForceFunctionAttrsPass());
 
-  if (PGOOpt && PGOOpt->SamplePGOSupport)
+  if (PGOOpt && PGOOpt->DebugInfoForProfiling)
 MPM.addPass(createModuleToFunctionPassAdaptor(AddDiscriminatorsPass()));
 
   // Apply module pipeline start EP callback.
Index: llvm/include/llvm/Passes/PassBuilder.h
===
--- llvm/include/llvm/Passes/PassBuilder.h
+++ llvm/include/llvm/Passes/PassBuilder.h
@@ -36,11 +36,15 @@
   enum CSPGOAction { NoCSAction, CSIRInstr, CSIRUse };
   PGOOptions(std::string ProfileFile = "", std::string CSProfileGenFile = "",
  std::string ProfileRemappingFile = "", PGOAction Action = NoAction,
- CSPGOAction CSAction = NoCSAction, bool SamplePGOSupport = false)
+ CSPGOAction CSAction = NoCSAction,
+ bool DebugInfoForProfiling = false,
+ bool PseudoProbeForProfiling = false)
   : ProfileFile(ProfileFile), CSProfileGenFile(CSProfileGenFile),
 ProfileRemappingFile(ProfileRemappingFile), Action(Action),
-CSAction(CSAction),
-SamplePGOSupport(SamplePGOSupport || Action == SampleUse) {
+CSAction(CSAction), DebugInfoForProfiling(DebugInfoForProfiling ||
+  (Action == SampleUse &&
+   !PseudoProbeForProfiling)),
+PseudoProbeForProfiling(PseudoProbeForProfiling) {
 // Note, we do allow ProfileFile.empty() for Action=IRUse LTO can
 // callback with IRUse action without ProfileFile.
 
@@ -55,16 +59,18 @@
 // a profile.
 assert(this->CSAction != CSIRUse || this->Action == IRUse);
 
-// If neither Action nor CSAction, SamplePGOSupport needs to be true.
+// If neither Action nor CSAction, DebugInfoForProfiling or
+// PseudoProbeForProfiling needs to be true.
 assert(this->Action != NoAction || this->CSAction != NoCSAction ||
-   this->SamplePGOSupport);
+   this->DebugInfoForProfiling || this->PseudoProbeForProfiling);
   }
   std::string ProfileFile;
   std::string CSProfileGenFile;
   std::string ProfileRemappingFile;
   PGOAction Action;
   CSPGOAction CSAction;
-  bool SamplePGOSupport;
+  bool DebugInfoForProfiling;
+  bool PseudoProbeForProfiling;
 };
 
 /// Tunable parameters for passes in the default pipelines.
Index: clang/test/CodeGen/emit-pseudo-probe.c
===
--- /dev/null
+++ clang/test/CodeGen/emit-pseudo-probe.c
@@ -0,0 +1,17 @@
+// RUN: %clang -O2  -fexperimental-new-pass-manager -fpseudo-probe-for-profiling -g -emit-llvm -S -o - %s | FileCheck %s
+
+// Check the generation of pseudoprobe intrinsic call
+
+void bar();
+void go();
+
+void foo(int x) {
+  // CHECK: call void @llvm.pseudoprobe(i64 [[#GUID:]], i64 1)
+  if (x == 0)
+// CHECK: call void @llvm.pseudoprobe(i64 [[#GUID]], i64 2)
+bar();
+  else
+// CHECK: call void @llvm.pseudoprobe(i64 [[#GUID]], i64 3)
+go();
+  // CHECK: call void @llvm.pseudoprobe(i64 [[#GUID]], i64 4)
+}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===

[PATCH] D86502: [CSSPGO] A Clang switch -fpseudo-probe-for-profiling for pseudo-probe instrumentation.

2020-08-28 Thread Hongtao Yu via Phabricator via cfe-commits
hoy marked an inline comment as done.
hoy added a comment.

In D86502#2245460 , @wmi wrote:

>> The early instrumentation also allows the inliner to duplicate probes for 
>> inlined instances. When a probe along with the other instructions of a 
>> callee function are inlined into its caller function, the GUID of the callee 
>> function goes with the probe. This allows samples collected on inlined 
>> probes to be reported for the original callee function.
>
> Just get a question from reading the above. Suppose `A` only has one BB and 
> the BB has one PseudoProbe in it. If function `A` is inlined into `B1` and 
> `B2` and both `B1` and `B2` inlined into `C`, the PseudoProbe from `A` will 
> have two copies in `C` both carrying GUID of `A`. How the samples collected 
> from `A` inlined into `B1` inlined into `C` are categorized differently from 
> `A` inlined into `B2` inlined into `C`, especially when debug information is 
> not enabled (so no inline stack information in the binary)?

This is a very good question. Inlined functions are differentiated by their 
original callsites. A pseudo probe is allocated for each callsite in the 
`SampleProfileProbe` pass. Nested inlining will produce a stack of pseudo 
probes, similar with the Dwarf inline stack. The work is not included in the 
first set of patches.




Comment at: llvm/include/llvm/Passes/PassBuilder.h:67-69
+// Pseudo probe instrumentation should only work with autoFDO or no FDO.
+assert(!this->PseudoProbeForProfiling || this->Action == NoAction ||
+   this->Action == SampleUse);

wmi wrote:
> Need it to work with more types of action for example instrumentation FDO or 
> cs instrumentation FDO. For instrumentation FDO optimized binary, we may want 
> to collect AutoFDO profile for it for performance comparison, enhance the 
> intrumentation profile with AutoFDO profile to make the profile more 
> production representative, ...
> 
> Currently debug information based AutoFDO supports it.
I see. I just removed this assert and the let assert above handle both 
`DebugInfoForProfiling` and `PseudoProbeForProfiling`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86502

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


[PATCH] D86820: [X86] Add a /tune: option for clang-cl

2020-08-28 Thread Craig Topper via Phabricator via cfe-commits
craig.topper created this revision.
craig.topper added reviewers: rnk, thakis, hans, echristo, erichkeane.
Herald added subscribers: dang, danielkiss.
craig.topper requested review of this revision.

We recently added support for -mtune. This patch adds /tune: so we can specify 
the tune CPU from clang-cl. MSVC doesn't support this but icc does.


https://reviews.llvm.org/D86820

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-x86-flags.c


Index: clang/test/Driver/cl-x86-flags.c
===
--- clang/test/Driver/cl-x86-flags.c
+++ clang/test/Driver/cl-x86-flags.c
@@ -128,5 +128,9 @@
 // RUN: %clang_cl -m64 -arch:avx512 --target=i386-pc-windows -### -- 2>&1 %s | 
FileCheck -check-prefix=avx51264 %s
 // avx51264: argument unused during compilation
 
+// RUN: %clang_cl -m64 -arch:AVX -tune:haswell --target=x86_64-pc-windows -### 
-- 2>&1 %s | FileCheck -check-prefix=tune %s
+// tune: "-target-cpu" "sandybridge"
+// tune-SAME: "-tune-cpu" "haswell"
+
 void f() {
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2080,8 +2080,9 @@
   if (!Args.hasArg(clang::driver::options::OPT_march_EQ))
 TuneCPU = "generic";
 
-  // Override based on -mtune.
-  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ)) {
+  // Override based on -mtune or /tune:
+  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ,
+ clang::driver::options::OPT__SLASH_tune)) 
{
 StringRef Name = A->getValue();
 
 if (Name == "native") {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4690,6 +4690,8 @@
 
 def _SLASH_arch : CLCompileJoined<"arch:">,
   HelpText<"Set architecture for code generation">;
+def _SLASH_tune : CLCompileJoined<"tune:">,
+  HelpText<"Set CPU for optimization without affecting instruction set">;
 
 def _SLASH_M_Group : OptionGroup<"">, Group;
 def _SLASH_volatile_Group : OptionGroup<"">,


Index: clang/test/Driver/cl-x86-flags.c
===
--- clang/test/Driver/cl-x86-flags.c
+++ clang/test/Driver/cl-x86-flags.c
@@ -128,5 +128,9 @@
 // RUN: %clang_cl -m64 -arch:avx512 --target=i386-pc-windows -### -- 2>&1 %s | FileCheck -check-prefix=avx51264 %s
 // avx51264: argument unused during compilation
 
+// RUN: %clang_cl -m64 -arch:AVX -tune:haswell --target=x86_64-pc-windows -### -- 2>&1 %s | FileCheck -check-prefix=tune %s
+// tune: "-target-cpu" "sandybridge"
+// tune-SAME: "-tune-cpu" "haswell"
+
 void f() {
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2080,8 +2080,9 @@
   if (!Args.hasArg(clang::driver::options::OPT_march_EQ))
 TuneCPU = "generic";
 
-  // Override based on -mtune.
-  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ)) {
+  // Override based on -mtune or /tune:
+  if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ,
+ clang::driver::options::OPT__SLASH_tune)) {
 StringRef Name = A->getValue();
 
 if (Name == "native") {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4690,6 +4690,8 @@
 
 def _SLASH_arch : CLCompileJoined<"arch:">,
   HelpText<"Set architecture for code generation">;
+def _SLASH_tune : CLCompileJoined<"tune:">,
+  HelpText<"Set CPU for optimization without affecting instruction set">;
 
 def _SLASH_M_Group : OptionGroup<"">, Group;
 def _SLASH_volatile_Group : OptionGroup<"">,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86819: [PowerPC][Power10] Implementation of 128-bit Binary Vector Rotate builtins

2020-08-28 Thread Albion Fung via Phabricator via cfe-commits
Conanap created this revision.
Conanap added reviewers: PowerPC, saghir, nemanjai, hfinkel.
Conanap added projects: LLVM, clang, PowerPC.
Herald added subscribers: danielkiss, steven.zhang, kbarton.
Conanap requested review of this revision.

This patch implements 128-bit Binary Vector Rotate builtins for PowerPC10.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86819

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-vector-rotate.ll

Index: llvm/test/CodeGen/PowerPC/p10-vector-rotate.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/p10-vector-rotate.ll
@@ -0,0 +1,51 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
+
+; This test case aims to test the builtins for vector rotate instructions
+; on Power10.
+
+
+define <1 x i128> @test_vrlq(<1 x i128> %x, <1 x i128> %y) nounwind readnone {
+; CHECK-LABEL: test_vrlq:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vrlq v2, v3, v2
+; CHECK-NEXT:blr
+  %shl.i = shl <1 x i128> %y, %x
+  %sub.i = sub <1 x i128> , %x
+  %lshr.i = lshr <1 x i128> %y, %sub.i
+  %tmp = or <1 x i128> %shl.i, %lshr.i
+  ret <1 x i128> %tmp
+}
+
+; Function Attrs: nounwind readnone
+define <1 x i128> @test_vrlqmi(<1 x i128> %a, <1 x i128> %b, <1 x i128> %c) {
+; CHECK-LABEL: test_vrlqmi:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vrlqmi v3, v2, v4
+; CHECK-NEXT:vmr v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <1 x i128> @llvm.ppc.altivec.vrlqmi(<1 x i128> %a, <1 x i128> %c, <1 x i128> %b)
+  ret <1 x i128> %tmp
+}
+
+; Function Attrs: nounwind readnone
+define <1 x i128> @test_vrlqnm(<1 x i128> %a, <1 x i128> %b, <1 x i128> %c) {
+; CHECK-LABEL: test_vrlqnm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vrlqnm v2, v2, v3
+; CHECK-NEXT:xxland v2, v2, v4
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call <1 x i128> @llvm.ppc.altivec.vrlqnm(<1 x i128> %a, <1 x i128> %b)
+  %tmp = and <1 x i128> %0, %c
+  ret <1 x i128> %tmp
+}
+
+; Function Attrs: nounwind readnone
+declare <1 x i128> @llvm.ppc.altivec.vrlqmi(<1 x i128>, <1 x i128>, <1 x i128>)
+
+; Function Attrs: nounwind readnone
+declare <1 x i128> @llvm.ppc.altivec.vrlqnm(<1 x i128>, <1 x i128>)
Index: llvm/lib/Target/PowerPC/PPCInstrPrefix.td
===
--- llvm/lib/Target/PowerPC/PPCInstrPrefix.td
+++ llvm/lib/Target/PowerPC/PPCInstrPrefix.td
@@ -1285,19 +1285,25 @@
"vcmpuq $BF, $vA, $vB", IIC_VecGeneral, []>;
   def VCMPSQ : VXForm_BF3_VAB5<321, (outs crrc:$BF), (ins vrrc:$vA, vrrc:$vB),
"vcmpsq $BF, $vA, $vB", IIC_VecGeneral, []>;
-  def VRLQNM : VX1_VT5_VA5_VB5<325, "vrlqnm", []>;
-  def VRLQMI : VXForm_1<69, (outs vrrc:$vD),
-(ins vrrc:$vA, vrrc:$vB, vrrc:$vDi),
-"vrlqmi $vD, $vA, $vB", IIC_VecFP, []>,
-RegConstraint<"$vDi = $vD">, NoEncode<"$vDi">;
   def VSLQ : VX1_VT5_VA5_VB5<261, "vslq", []>;
   def VSRAQ : VX1_VT5_VA5_VB5<773, "vsraq", []>;
   def VSRQ : VX1_VT5_VA5_VB5<517, "vsrq", []>;
-  def VRLQ : VX1_VT5_VA5_VB5<5, "vrlq", []>;
   def XSCVQPUQZ : X_VT5_XO5_VB5<63, 0, 836, "xscvqpuqz", []>;
   def XSCVQPSQZ : X_VT5_XO5_VB5<63, 8, 836, "xscvqpsqz", []>;
   def XSCVUQQP : X_VT5_XO5_VB5<63, 3, 836, "xscvuqqp", []>;
   def XSCVSQQP : X_VT5_XO5_VB5<63, 11, 836, "xscvsqqp", []>;
+  def VRLQ : VX1_VT5_VA5_VB5<5, "vrlq", []>;
+  def VRLQNM : VX1_VT5_VA5_VB5<325, "vrlqnm",
+   [(set v1i128:$vD,
+   (int_ppc_altivec_vrlqnm v1i128:$vA,
+   v1i128:$vB))]>;
+  def VRLQMI : VXForm_1<69, (outs vrrc:$vD),
+(ins vrrc:$vA, vrrc:$vB, vrrc:$vDi),
+"vrlqmi $vD, $vA, $vB", IIC_VecFP,
+[(set v1i128:$vD,
+   (int_ppc_altivec_vrlqmi v1i128:$vA, v1i128:$vB,
+   v1i128:$vDi))]>,
+RegConstraint<"$vDi = $vD">, NoEncode<"$vDi">;
 }
 
 // Anonymous Patterns //
@@ -1344,6 +1350,9 @@
  (v1i128 (COPY_TO_REGCLASS (LXVRWX xoaddr:$src), VRRC))>;
   def : Pat <(v1i128 (PPClxvrzx xoaddr:$src, 64)),
  (v1i128 (COPY_TO_REGCLASS (LXVRDX xoaddr:$src), VRRC))>;
+
+  def : Pat<(v1i128 (rotl v1i128:$vA, v1i128:$vB)),
+(v1i128 (VRLQ v1i128:$vA, v1i128:

[PATCH] D86558: [OPENMP]Add support for allocate vars in untied tasks.

2020-08-28 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev updated this revision to Diff 288711.
ABataev added a comment.
Herald added a subscriber: danielkiss.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86558

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/allocate_codegen.cpp
  clang/test/OpenMP/for_lastprivate_codegen.cpp
  clang/test/OpenMP/for_linear_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/parallel_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_private_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp

Index: clang/test/OpenMP/task_codegen.cpp
===
--- clang/test/OpenMP/task_codegen.cpp
+++ clang/test/OpenMP/task_codegen.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -x c++ -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix UNTIEDRT
-// RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -x c++ -emit-llvm %s -o - -DUNTIEDRT | FileCheck %s --check-prefix CHECK --check-prefix UNTIEDRT
+// RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s -DUNTIEDRT
+// RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix UNTIEDRT
 //
 // RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -fopenmp-enable-irbuilder -x c++ -emit-llvm %s -o - | FileCheck %s
 // RUN: %clang_cc1 -fopenmp -fopenmp-enable-irbuilder -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
@@ -14,6 +14,19 @@
 #ifndef HEADER
 #define HEADER
 
+enum omp_allocator_handle_t {
+  omp_null_allocator = 0,
+  omp_default_mem_alloc = 1,
+  omp_large_cap_mem_alloc = 2,
+  omp_const_mem_alloc = 3,
+  omp_high_bw_mem_alloc = 4,
+  omp_low_lat_mem_alloc = 5,
+  omp_cgroup_mem_alloc = 6,
+  omp_pteam_mem_alloc = 7,
+  omp_thread_mem_alloc = 8,
+  KMP_ALLOCATOR_MAX_HANDLE = __UINTPTR_MAX__
+};
+
 // CHECK-DAG: [[IDENT_T:%.+]] = type { i32, i32, i32, i32, i8* }
 // CHECK-DAG: [[STRUCT_SHAREDS:%.+]] = type { i8*, [2 x [[STRUCT_S:%.+]]]* }
 // CHECK-DAG: [[STRUCT_SHAREDS1:%.+]] = type { [2 x [[STRUCT_S:%.+]]]* }
@@ -258,21 +271,26 @@
 a = 4;
 c = 5;
   }
-// CHECK: [[ORIG_TASK_PTR:%.+]] = call i8* @__kmpc_omp_task_alloc([[IDENT_T]]* @{{.+}}, i32 {{%.*}}, i32 0, i64 48, i64 1, i32 (i32, i8*)* bitcast (i32 (i32, [[KMP_TASK_T]]{{.*}}*)* [[TASK_ENTRY6:@.+]] to i32 (i32, i8*)*))
+// CHECK: [[ORIG_TASK_PTR:%.+]] = call i8* @__kmpc_omp_task_alloc([[IDENT_T]]* @{{.+}}, i32 {{%.*}}, i32 0, i64 256, i64 1, i32 (i32, i8*)* bitcast (i32 (i32, [[KMP_TASK_T]]{{.*}}*)* [[TASK_ENTRY6:@.+]] to i32 (i32, i8*)*))
 // CHECK: call i32 @__kmpc_omp_task([[IDENT_T]]* @{{.+}}, i32 {{%.*}}, i8* [[ORIG_TASK_PTR]])
-#pragma omp task untied
+#pragma omp task untied firstprivate(c) allocate(omp_pteam_mem_alloc:c)
   {
-S s1;
+S s1, s2;
+#ifdef UNTIEDRT
+#pragma omp allocate(s2) allocator(omp_pteam_mem_alloc)
+#endif
+s2.a = 0;
 #pragma omp task
-a = 4;
+a = c = 4;
 #pragma omp taskyield
 s1 = S();
+s2.a = 10;
 #pragma omp taskwait
   }
   return a;
 }
 // CHECK: define internal i32 [[TASK_ENTRY1]](i32 %0, [[KMP_TASK_T]]{{.*}}* noalias %1)
-// CHECK: store i32 15, i32* [[A_PTR:@.+]]
+// CHECK: store i32 15, i32* [[A_PTR:@.+]],
 // CHECK: [[A_VAL:%.+]] = load i32, i32* [[A_PTR]]
 // CHECK: [[A_VAL_I8:%.+]] = trunc i32 [[A_VAL]] to i8
 // CHECK: store i8 [[A_VAL_I8]], i8* %{{.+}}
@@ -294,10 +312,13 @@
 // CHECK: define internal i32
 // CHECK: store i32 4, i32* [[A_PTR]]
 
-// CHECK: define internal i32 [[TASK_ENTRY6]](i32 %0, [[KMP_TASK_T]]{{.*}}* noalias %1)
+// CHECK: define internal i32 [[TASK_ENTRY6]](i32 %0, [[KMP_TASK_T]]{{.*}}* noalias %{{.+}})
 // UNTIEDRT: [[S1_ADDR_PTR:%.+]] = alloca %struct.S*,
-// UNTIEDRT: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, %struct.S** [[S1_ADDR_PTR]])
-// UNTIEDRT: [[S1_ADDR:%.+]] = load %struct.S*, %struct.S** [[S1_ADDR_PTR]],
+// UNTIEDRT: [[S2_ADDR_PTR_REF:%.+]] = alloca %struct.S**,
+// UNTIEDRT: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, %struct.S** [[S1_ADDR_PTR]], %struct.S*** [[S2_ADDR_PTR_REF]])
+// UNTIEDRT-DAG: [[S1_ADDR:%.+]] = load %struct.S*, %struct.S** [[S1_ADDR_PTR]],
+// UNTIEDRT-DAG: [[S2_ADDR_PTR:%.+]] = load %struct.S**, %struct.S*** [[S2_ADDR_PTR_REF]],
+// UNTIEDRT-DAG: [[S2_ADDR:%.+]] = load %struct.S*, %struct.S** [[S2_ADDR_PTR]],
 // CHECK: switch i32 %{{.+}}, label %[[DONE:.+]] [
 
 // CHECK: [[DONE]]:
@@ -309,16 +330,25 @@
 // UNTIEDRT: br label %[[EXIT:[^,]+]]
 
 // UNTIEDRT: call void [[CONSTR:@.+]](%struct.S* [[S1_ADDR]])
+// UNTI

[clang] 7128e64 - [UpdateTestChecks] include { in function signature check line

2020-08-28 Thread via cfe-commits

Author: sstefan1
Date: 2020-08-28T23:44:03+02:00
New Revision: 7128e647063dd858901aa7a5d90be8744c673866

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

LOG: [UpdateTestChecks] include { in function signature check line

After D85099, if we have attribute group in the function signature that hasn't
been seen before, and later a callsite with the same attribute group, filecheck 
will evaluate
the first attribute group to for example '#0 {'. We now include { in the 
args_and_sig group to avoid this.

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

Added: 


Modified: 

clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/argument_name_reuse.ll.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/check_attrs.ll.funcattrs.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/check_attrs.ll.plain.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.initially_disabled.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/various_ir_values.ll.funcsig.expected
llvm/utils/UpdateTestChecks/common.py

Removed: 




diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
 
b/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
index 313bd5bcef7c..2069f7e185bb 100644
--- 
a/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
@@ -3,7 +3,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
 
 // CHECK-LABEL: define {{[^@]+}}@test
-// CHECK-SAME: (i64 [[A:%.*]], i32 [[B:%.*]]) [[ATTR0:#.*]]
+// CHECK-SAME: (i64 [[A:%.*]], i32 [[B:%.*]]) [[ATTR0:#.*]] {
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
 // CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4
@@ -21,7 +21,7 @@ long test(long a, int b) {
 
 // A function with a mangled name
 // CHECK-LABEL: define {{[^@]+}}@_Z4testlii
-// CHECK-SAME: (i64 [[A:%.*]], i32 [[B:%.*]], i32 [[C:%.*]]) [[ATTR0]]
+// CHECK-SAME: (i64 [[A:%.*]], i32 [[B:%.*]], i32 [[C:%.*]]) [[ATTR0]] {
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
 // CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4

diff  --git 
a/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/argument_name_reuse.ll.expected
 
b/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/argument_name_reuse.ll.expected
index 461a8b6a5bf6..0e6f08020703 100644
--- 
a/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/argument_name_reuse.ll.expected
+++ 
b/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/argument_name_reuse.ll.expected
@@ -3,7 +3,7 @@
 
 define i32 @reuse_arg_names(i32 %X, i32 %Y) {
 ; CHECK-LABEL: define {{[^@]+}}@reuse_arg_names
-; CHECK-SAME: (i32 [[X:%.*]], i32 [[Y:%.*]])
+; CHECK-SAME: (i32 [[X:%.*]], i32 [[Y:%.*]]) {
 ; CHECK-NEXT:[[Z:%.*]] = sub i32 [[X]], [[Y]]
 ; CHECK-NEXT:[[Q:%.*]] = add i32 [[Z]], [[Y]]
 ; CHECK-NEXT:ret i32 [[Q]]

diff  --git 
a/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
 
b/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
index c30d105b60ae..03405ca57c2b 100644
--- 
a/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
+++ 
b/llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
@@ -4,7 +4,7 @@
 
 define i32 @common_sub_operand(i32 %X, i32 %Y) {
 ; CHECK-LABEL: define {{[^@]+}}@common_sub_operand
-; CHECK-SAME: (i32 [[X:%.*]], i32 [[Y:%.*]])
+; CHECK-SAME: (i32 [[X:%.*]], i32 [[Y:%.*]]) {
 ; CHECK-NEXT:ret i32 [[X]]
 ;
   %Z = sub i32 %X, %Y
@@ -14,7 +14,7 @@ define i32 @common_sub_operand(i32 %X, i32 %Y) {
 
 define i32 @negated_operand(i32 %x) {
 ; CHECK-LABEL: define {{[^@]+}}@negated_operand
-; CHECK-SAME: (i32 [[X:%.*]])
+; CHECK-SAME: (i32 [[X:%.*]]) {
 ; CHECK-NEXT:ret i32 0
 ;
   %negx = sub i32 0, %x
@@ -24,7 +24,7 @@ define i32 @negated_operand(i32 %x) {
 
 define <2 x i32> @negated_operand_commute_vec(<2 x i32> %x) {
 ; CHECK-LABEL: define {{[^@]+}}@negated_operand_commute_vec
-; CHECK-SAME: (<2 x i32> [[X:%.*]])
+; CHECK-SAME: (<2 x i32> [[X:%.*]]) {
 ; CHECK-NEXT:ret <2 x i32> zeroinitializer
 ;
   %negx = sub <2 x i32> zeroinitializer, %x
@@ -34,7 +34,7 @@ define <2 x i32> @negated_operand_

[PATCH] D86769: [UpdateTestChecks] include { in function signature check line

2020-08-28 Thread Stefan Stipanovic via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7128e647063d: [UpdateTestChecks] include { in function 
signature check line (authored by sstefan1).
Herald added subscribers: cfe-commits, danielkiss.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D86769?vs=288547&id=288709#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86769

Files:
  clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/argument_name_reuse.ll.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/check_attrs.ll.funcattrs.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/check_attrs.ll.plain.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.initially_disabled.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/various_ir_values.ll.funcsig.expected
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -146,7 +146,7 @@
 
 OPT_FUNCTION_RE = re.compile(
 r'^(\s*;\s*Function\sAttrs:\s(?P[\w\s]+?))?\s*define\s+(?:internal\s+)?[^@]*@(?P[\w.-]+?)\s*'
-r'(?P\((\)|(.*?[\w.-]+?)\))[^{]*)\{\n(?P.*?)^\}$',
+r'(?P\((\)|(.*?[\w.-]+?)\))[^{]*\{)\n(?P.*?)^\}$',
 flags=(re.M | re.S))
 
 ANALYZE_FUNCTION_RE = re.compile(
Index: llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/various_ir_values.ll.funcsig.expected
===
--- llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/various_ir_values.ll.funcsig.expected
+++ llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/various_ir_values.ll.funcsig.expected
@@ -10,7 +10,7 @@
 ; Function Attrs: nounwind uwtable
 define dso_local void @foo(i32* %A) #0 !dbg !7 {
 ; CHECK-LABEL: define {{[^@]+}}@foo
-; CHECK-SAME: (i32* [[A:%.*]]) [[ATTR0:#.*]] [[DBG7:!dbg !.*]]
+; CHECK-SAME: (i32* [[A:%.*]]) [[ATTR0:#.*]] [[DBG7:!dbg !.*]] {
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32*, align 8
 ; CHECK-NEXT:[[I:%.*]] = alloca i32, align 4
@@ -99,7 +99,7 @@
 ; Function Attrs: nounwind uwtable
 define dso_local void @bar(i32* %A) #0 !dbg !39 {
 ; CHECK-LABEL: define {{[^@]+}}@bar
-; CHECK-SAME: (i32* [[A:%.*]]) [[ATTR0]] [[DBG39:!dbg !.*]]
+; CHECK-SAME: (i32* [[A:%.*]]) [[ATTR0]] [[DBG39:!dbg !.*]] {
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32*, align 8
 ; CHECK-NEXT:[[I:%.*]] = alloca i32, align 4
Index: llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.initially_disabled.expected
===
--- llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.initially_disabled.expected
+++ llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.initially_disabled.expected
@@ -18,14 +18,14 @@
 ; UTC_ARGS: --enable
 
 define void @check_lines_2() {
-; CHECK-LABEL: define {{[^@]+}}@check_lines_2()
+; CHECK-LABEL: define {{[^@]+}}@check_lines_2() {
 ; CHECK-NEXT:ret void
 ;
   ret void
 }
 
 define void @scrub() {
-; CHECK-LABEL: define {{[^@]+}}@scrub()
+; CHECK-LABEL: define {{[^@]+}}@scrub() {
 ; CHECK-NEXT:call void @foo()
 ; CHECK-NEXT:ret void
 ;
@@ -35,7 +35,7 @@
 
 define i32 @signature(i32 %arg) {
 ; CHECK-LABEL: define {{[^@]+}}@signature
-; CHECK-SAME: (i32 [[ARG:%.*]])
+; CHECK-SAME: (i32 [[ARG:%.*]]) {
 ; CHECK-NEXT:ret i32 [[ARG]]
 ;
   ret i32 %arg
Index: llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.expected
===
--- llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.expected
+++ llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/on_the_fly_arg_change.ll.expected
@@ -4,7 +4,7 @@
 declare void @foo()
 
 define void @check_lines_1() {
-; CHECK-LABEL: define {{[^@]+}}@check_lines_1()
+; CHECK-LABEL: define {{[^@]+}}@check_lines_1() {
 ; CHECK-NEXT:ret void
 ;
   ret void
@@ -21,14 +21,14 @@
 ; UTC_ARGS: --enable
 
 define void @check_lines_2() {
-; CHECK-LABEL: define {{[^@]+}}@check_lines_2()
+; CHECK-LABEL: define {{[^@]+}}@check_lines_2() {
 ; CHECK-NEXT:ret void
 ;
   ret void
 }
 
 define void @scrub() {
-; CHECK-LABEL: define {{[^@]+}}@scrub()
+; CHECK-LABEL: define {{[^@]+}}@scrub() {
 

[PATCH] D86502: [CSSPGO] A Clang switch -fpseudo-probe-for-profiling for pseudo-probe instrumentation.

2020-08-28 Thread Wei Mi via Phabricator via cfe-commits
wmi added a comment.
Herald added a subscriber: danielkiss.

> The early instrumentation also allows the inliner to duplicate probes for 
> inlined instances. When a probe along with the other instructions of a callee 
> function are inlined into its caller function, the GUID of the callee 
> function goes with the probe. This allows samples collected on inlined probes 
> to be reported for the original callee function.

Just get a question from reading the above. Suppose `A` only has one BB and the 
BB has one PseudoProbe in it. If function `A` is inlined into `B1` and `B2` and 
both `B1` and `B2` inlined into `C`, the PseudoProbe from `A` will have two 
copies in `C` both carrying GUID of `A`. How the samples collected from `A` 
inlined into `B1` inlined into `C` are categorized differently from `A` inlined 
into `B2` inlined into `C`, especially when debug information is not enabled 
(so no inline stack information in the binary)?




Comment at: llvm/include/llvm/Passes/PassBuilder.h:67-69
+// Pseudo probe instrumentation should only work with autoFDO or no FDO.
+assert(!this->PseudoProbeForProfiling || this->Action == NoAction ||
+   this->Action == SampleUse);

Need it to work with more types of action for example instrumentation FDO or cs 
instrumentation FDO. For instrumentation FDO optimized binary, we may want to 
collect AutoFDO profile for it for performance comparison, enhance the 
intrumentation profile with AutoFDO profile to make the profile more production 
representative, ...

Currently debug information based AutoFDO supports it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86502

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


[PATCH] D85762: [OPENMP]Do not allow threadprivates as base for array-like reduction.

2020-08-28 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev updated this revision to Diff 288701.
ABataev added a comment.
Herald added a subscriber: danielkiss.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85762

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/parallel_reduction_messages.cpp


Index: clang/test/OpenMP/parallel_reduction_messages.cpp
===
--- clang/test/OpenMP/parallel_reduction_messages.cpp
+++ clang/test/OpenMP/parallel_reduction_messages.cpp
@@ -92,6 +92,8 @@
 
 S3 h, k;
 #pragma omp threadprivate(h) // expected-note 2 {{defined as threadprivate or 
thread local}}
+int *gptr;
+#pragma omp threadprivate(gptr) // expected-note {{defined as threadprivate or 
thread local}}
 
 template// expected-note {{declared here}}
 T tmain(T argc) {
@@ -277,6 +279,8 @@
   m++;
 #pragma omp parallel reduction(task, + : m) // omp45-error 2 {{expected 
expression}} omp45-warning {{missing ':' after reduction identifier - ignoring}}
   m++;
+#pragma omp parallel reduction(+:gptr[:argc]) // expected-error 
{{threadprivate or thread local variable cannot be reduction}}
+  ;
 
   return tmain(argc) + tmain(fl); // expected-note {{in instantiation of 
function template specialization 'tmain' requested here}} expected-note 
{{in instantiation of function template specialization 'tmain' requested 
here}}
 }
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -15119,6 +15119,17 @@
   continue;
 }
   }
+} else {
+  // Threadprivates cannot be shared between threads, so dignose if the 
base
+  // is a threadprivate variable.
+  DSAStackTy::DSAVarData DVar = Stack->getTopDSA(D, /*FromParent=*/false);
+  if (DVar.CKind == OMPC_threadprivate) {
+S.Diag(ELoc, diag::err_omp_wrong_dsa)
+<< getOpenMPClauseName(DVar.CKind)
+<< getOpenMPClauseName(OMPC_reduction);
+reportOriginalDsa(S, Stack, D, DVar);
+continue;
+  }
 }
 
 // Try to find 'declare reduction' corresponding construct before using


Index: clang/test/OpenMP/parallel_reduction_messages.cpp
===
--- clang/test/OpenMP/parallel_reduction_messages.cpp
+++ clang/test/OpenMP/parallel_reduction_messages.cpp
@@ -92,6 +92,8 @@
 
 S3 h, k;
 #pragma omp threadprivate(h) // expected-note 2 {{defined as threadprivate or thread local}}
+int *gptr;
+#pragma omp threadprivate(gptr) // expected-note {{defined as threadprivate or thread local}}
 
 template// expected-note {{declared here}}
 T tmain(T argc) {
@@ -277,6 +279,8 @@
   m++;
 #pragma omp parallel reduction(task, + : m) // omp45-error 2 {{expected expression}} omp45-warning {{missing ':' after reduction identifier - ignoring}}
   m++;
+#pragma omp parallel reduction(+:gptr[:argc]) // expected-error {{threadprivate or thread local variable cannot be reduction}}
+  ;
 
   return tmain(argc) + tmain(fl); // expected-note {{in instantiation of function template specialization 'tmain' requested here}} expected-note {{in instantiation of function template specialization 'tmain' requested here}}
 }
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -15119,6 +15119,17 @@
   continue;
 }
   }
+} else {
+  // Threadprivates cannot be shared between threads, so dignose if the base
+  // is a threadprivate variable.
+  DSAStackTy::DSAVarData DVar = Stack->getTopDSA(D, /*FromParent=*/false);
+  if (DVar.CKind == OMPC_threadprivate) {
+S.Diag(ELoc, diag::err_omp_wrong_dsa)
+<< getOpenMPClauseName(DVar.CKind)
+<< getOpenMPClauseName(OMPC_reduction);
+reportOriginalDsa(S, Stack, D, DVar);
+continue;
+  }
 }
 
 // Try to find 'declare reduction' corresponding construct before using
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D84887: [OPENMP]Fix codegen for is_device_ptr component, captured by reference.

2020-08-28 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev updated this revision to Diff 288700.
ABataev added a comment.
Herald added a subscriber: danielkiss.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84887

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_is_device_ptr_codegen.cpp


Index: clang/test/OpenMP/target_is_device_ptr_codegen.cpp
===
--- clang/test/OpenMP/target_is_device_ptr_codegen.cpp
+++ clang/test/OpenMP/target_is_device_ptr_codegen.cpp
@@ -285,4 +285,41 @@
   ++arg;
 }
 #endif
+///==///
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix 
CK3 --check-prefix CK3-64
+// RUN: %clang_cc1 -DCK3 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ 
-triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck %s  --check-prefix CK3 --check-prefix CK3-64
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu 
-x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s  
--check-prefix CK3 --check-prefix CK3-32
+// RUN: %clang_cc1 -DCK3 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple 
i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck %s  --check-prefix CK3 --check-prefix CK3-32
+
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple 
powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x 
c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp-simd 
-fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown 
-emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x 
c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm 
-o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// SIMD-ONLY1-NOT: {{__kmpc|__tgt}}
+#ifdef CK3
+
+// CK3-DAG: [[SIZES:@.+]] = {{.+}}constant [1 x i[[SZ:64|32]]] [i{{64|32}} 
{{8|4}}]
+// OMP_MAP_TARGET_PARAM = 0x20 | OMP_MAP_TO = 0x1 = 0x21
+// CK3-DAG: [[TYPES:@.+]] = {{.+}}constant [1 x i64] [i64 [[#0x21]]]
+void bar() {
+  __attribute__((aligned(64))) double *ptr;
+  // CK3-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, 
i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES]]{{.+}}, 
{{.+}}[[TYPES]]{{.+}}, i8** null)
+  // CK3-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, 
i32 0
+  // CK3-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, 
i32 0
+  // CK3-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
+  // CK3-DAG: [[P1:%.+]] = getelementptr inbounds {{.+}}[[PS]], i32 0, i32 0
+  // CK3-DAG: [[CBP1:%.+]] = bitcast i8** [[BP1]] to double***
+  // CK3-DAG: [[CP1:%.+]] = bitcast i8** [[P1]] to double***
+  // CK3-DAG: store double** [[PTR:%.+]], double*** [[CBP1]]
+  // CK3-DAG: store double** [[PTR]], double*** [[CP1]]
+
+  // CK3: call void [[KERNEL:@.+]](double** [[PTR]])
+#pragma omp target is_device_ptr(ptr)
+  *ptr = 0;
+}
+#endif
 #endif
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -8436,10 +8436,12 @@
 if (DevPointersMap.count(VD)) {
   CombinedInfo.BasePointers.emplace_back(Arg, VD);
   CombinedInfo.Pointers.push_back(Arg);
-  CombinedInfo.Sizes.push_back(
-  
CGF.Builder.CreateIntCast(CGF.getTypeSize(CGF.getContext().VoidPtrTy),
-CGF.Int64Ty, /*isSigned=*/true));
-  CombinedInfo.Types.push_back(OMP_MAP_LITERAL | OMP_MAP_TARGET_PARAM);
+  CombinedInfo.Sizes.push_back(CGF.Builder.CreateIntCast(
+  CGF.getTypeSize(CGF.getContext().VoidPtrTy), CGF.Int64Ty,
+  /*isSigned=*/true));
+  CombinedInfo.Types.push_back(
+  (Cap->

[clang] 0e00a95 - Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace.

2020-08-28 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-08-28T13:35:50-07:00
New Revision: 0e00a95b4fad5e72851de012d3a0b2c2d01f8685

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

LOG: Add new warning for compound punctuation tokens that are split across 
macro expansions or split by whitespace.

For example:

#define FOO(x) (x)
FOO({});

... forms a statement-expression after macro expansion. This warning
applies to '({' and '})' delimiting statement-expressions, '[[' and ']]'
delimiting attributes, and '::*' introducing a pointer-to-member.

The warning for forming these compound tokens across macro expansions
(or across files!) is enabled by default; the warning for whitespace
within the tokens is not, but is included in -Wall.

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

Added: 
clang/test/Parser/compound-token-split.cpp

Modified: 
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Parse/Parser.h
clang/lib/Headers/altivec.h
clang/lib/Parse/ParseDecl.cpp
clang/lib/Parse/ParseDeclCXX.cpp
clang/lib/Parse/ParseExpr.cpp
clang/lib/Parse/ParseStmt.cpp
clang/lib/Parse/Parser.cpp
clang/test/Misc/warning-wall.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 10a5c90c960e..a79e057a5b33 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -45,6 +45,11 @@ def GNUCompoundLiteralInitializer : 
DiagGroup<"gnu-compound-literal-initializer"
 def BitFieldConstantConversion : DiagGroup<"bitfield-constant-conversion">;
 def BitFieldEnumConversion : DiagGroup<"bitfield-enum-conversion">;
 def BitFieldWidth : DiagGroup<"bitfield-width">;
+def CompoundTokenSplitByMacro : DiagGroup<"compound-token-split-by-macro">;
+def CompoundTokenSplitBySpace : DiagGroup<"compound-token-split-by-space">;
+def CompoundTokenSplit : DiagGroup<"compound-token-split",
+   [CompoundTokenSplitByMacro,
+CompoundTokenSplitBySpace]>;
 def CoroutineMissingUnhandledException :
   DiagGroup<"coroutine-missing-unhandled-exception">;
 def Coroutine : DiagGroup<"coroutine", [CoroutineMissingUnhandledException]>;
@@ -943,7 +948,8 @@ def Consumed   : DiagGroup<"consumed">;
 // Note that putting warnings in -Wall will not disable them by default. If a
 // warning should be active _only_ when -Wall is passed in, mark it as
 // DefaultIgnore in addition to putting it here.
-def All : DiagGroup<"all", [Most, Parentheses, Switch, SwitchBool, 
MisleadingIndentation]>;
+def All : DiagGroup<"all", [Most, Parentheses, Switch, SwitchBool,
+MisleadingIndentation, CompoundTokenSplit]>;
 
 // Warnings that should be in clang-cl /w4.
 def : DiagGroup<"CL4", [All, Extra]>;

diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 08b91de31993..42da8bbad74f 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -62,6 +62,23 @@ def warn_misleading_indentation : Warning<
 def note_previous_statement : Note<
   "previous statement is here">;
 
+def subst_compound_token_kind : TextSubstitution<
+  "%select{%1 and |}0%2 tokens "
+  "%select{introducing statement expression|terminating statement expression|"
+  "introducing attribute|terminating attribute|"
+  "forming pointer to member type}3">;
+def warn_compound_token_split_by_macro : Warning<
+  "%sub{subst_compound_token_kind}0,1,2,3 appear in 
diff erent "
+  "macro expansion contexts">, InGroup;
+def warn_compound_token_split_by_file : Warning<
+  "%sub{subst_compound_token_kind}0,1,2,3 appear in 
diff erent source files">,
+  InGroup;
+def note_compound_token_split_second_token_here : Note<
+  "%select{|second }0%1 token is here">;
+def warn_compound_token_split_by_whitespace : Warning<
+  "%sub{subst_compound_token_kind}0,1,2,3 are separated by whitespace">,
+  InGroup, DefaultIgnore;
+
 def ext_thread_before : Extension<"'__thread' before '%0'">;
 def ext_keyword_as_ident : ExtWarn<
   "keyword '%0' will be made available as an identifier "

diff  --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 4068e6a444c9..37ca9e893329 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1045,6 +1045,25 @@ class Parser : public CodeCompletionHandler {
   /// was successful.
   bool expectIdentifier();
 
+  /// Kinds of compound pseudo-tokens formed by a sequence of two real tokens.
+  enum class CompoundToken {
+/// A '(' '{' beginning a statement-expressio

[PATCH] D86751: Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace.

2020-08-28 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
rsmith marked an inline comment as done.
Closed by commit rG0e00a95b4fad: Add new warning for compound punctuation 
tokens that are split across macro… (authored by rsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86751

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Parse/Parser.h
  clang/lib/Headers/altivec.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Parser/compound-token-split.cpp

Index: clang/test/Parser/compound-token-split.cpp
===
--- /dev/null
+++ clang/test/Parser/compound-token-split.cpp
@@ -0,0 +1,40 @@
+// RUN: %clang_cc1 %s -verify
+// RUN: %clang_cc1 %s -verify=expected,space -Wcompound-token-split
+// RUN: %clang_cc1 %s -verify=expected,space -Wall
+
+#ifdef LSQUARE
+[ // expected-note {{second '[' token is here}}
+#else
+
+#define VAR(type, name, init) type name = (init)
+
+void f() {
+  VAR(int, x, {}); // #1
+  // expected-warning@#1 {{'(' and '{' tokens introducing statement expression appear in different macro expansion contexts}}
+  // expected-note-re@#1 ^}}'{' token is here}}
+  //
+  // FIXME: It would be nice to suppress this when we already warned about the opening '({'.
+  // expected-warning@#1 {{'}' and ')' tokens terminating statement expression appear in different macro expansion contexts}}
+  // expected-note-re@#1 ^}}')' token is here}}
+  //
+  // expected-error@#1 {{cannot initialize a variable of type 'int' with an rvalue of type 'void'}}
+}
+
+#define RPAREN )
+
+int f2() {
+  int n = ({ 1; }RPAREN; // expected-warning {{'}' and ')' tokens terminating statement expression appear in different macro expansion contexts}} expected-note {{')' token is here}}
+  return n;
+}
+
+[ // expected-warning-re ^}}'[' tokens introducing attribute appear in different source files}}
+#define LSQUARE
+#include __FILE__
+  noreturn ]]  void g();
+
+[[noreturn] ] void h(); // space-warning-re ^}}']' tokens terminating attribute are separated by whitespace}}
+
+struct X {};
+int X:: *p; // space-warning {{'::' and '*' tokens forming pointer to member type are separated by whitespace}}
+
+#endif
Index: clang/test/Misc/warning-wall.c
===
--- clang/test/Misc/warning-wall.c
+++ clang/test/Misc/warning-wall.c
@@ -94,6 +94,9 @@
 CHECK-NEXT:  -Wswitch
 CHECK-NEXT:  -Wswitch-bool
 CHECK-NEXT:  -Wmisleading-indentation
+CHECK-NEXT:  -Wcompound-token-split
+CHECK-NEXT:-Wcompound-token-split-by-macro
+CHECK-NEXT:-Wcompound-token-split-by-space
 
 
 CHECK-NOT:-W
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -227,6 +227,39 @@
   return true;
 }
 
+void Parser::checkCompoundToken(SourceLocation FirstTokLoc,
+tok::TokenKind FirstTokKind, CompoundToken Op) {
+  if (FirstTokLoc.isInvalid())
+return;
+  SourceLocation SecondTokLoc = Tok.getLocation();
+
+  // We expect both tokens to come from the same FileID.
+  FileID FirstID = PP.getSourceManager().getFileID(FirstTokLoc);
+  FileID SecondID = PP.getSourceManager().getFileID(SecondTokLoc);
+  if (FirstID != SecondID) {
+Diag(FirstTokLoc, (FirstTokLoc.isMacroID() || SecondTokLoc.isMacroID())
+  ? diag::warn_compound_token_split_by_macro
+  : diag::warn_compound_token_split_by_file)
+<< (FirstTokKind == Tok.getKind()) << FirstTokKind << Tok.getKind()
+<< static_cast(Op) << SourceRange(FirstTokLoc);
+Diag(SecondTokLoc, diag::note_compound_token_split_second_token_here)
+<< (FirstTokKind == Tok.getKind()) << Tok.getKind()
+<< SourceRange(SecondTokLoc);
+return;
+  }
+
+  // We expect the tokens to abut.
+  if (Tok.hasLeadingSpace()) {
+SourceLocation SpaceLoc = PP.getLocForEndOfToken(FirstTokLoc);
+if (SpaceLoc.isInvalid())
+  SpaceLoc = FirstTokLoc;
+Diag(SpaceLoc, diag::warn_compound_token_split_by_whitespace)
+<< (FirstTokKind == Tok.getKind()) << FirstTokKind << Tok.getKind()
+<< static_cast(Op) << SourceRange(FirstTokLoc, SecondTokLoc);
+return;
+  }
+}
+
 //===--===//
 // Error recovery.
 //===--===//
Index: clang/lib/Parse/ParseStmt.cpp
===
--- clang/lib/Parse/ParseStmt

[PATCH] D86751: Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace.

2020-08-28 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith marked an inline comment as done.
rsmith added inline comments.
Herald added a subscriber: danielkiss.



Comment at: clang/test/Parser/compound-token-split.cpp:30
+
+[ // expected-warning-re ^}}'[' tokens introducing attribute appear in 
different source files}}
+#define LSQUARE

sbenza wrote:
> Does this count as a "different" source file?
> Or is it just an implementation detail of how clang uses FileIDs ?
:) Yes, this is a consequence of how Clang uses `FileID`s.

I guess it's debatable whether the includer and included file are "different", 
but I'm hoping no-one will be confused by the diagnostic. (I think it's one of 
those "if you ever see this diagnostic in practice you win a small prize" 
cases...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86751

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


[PATCH] D85408: Let -basic-block-sections=labels emit basicblock metadata in a new .bb_addr_map section, instead of emitting special unary-encoded symbols.

2020-08-28 Thread Rahman Lavaee via Phabricator via cfe-commits
rahmanl marked an inline comment as done.
rahmanl added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1030
+/// recursive return edges vs. indirect branches. The format of the metadata is
+/// described as follows: 1st bit (LSB): set if this is a return block (return
+/// or tail call). 2nd bit: set if this is a block ending with a tail call. 3rd

snehasish wrote:
> Did you intend to change the formatting of the comment? I think the list 
> items were on separate lines.
My bad. Didn't fully check the lint result.



Comment at: llvm/lib/CodeGen/MachineBasicBlock.cpp:58
 
+unsigned MachineBasicBlock::getBBAddrMapMetadata() const {
+  const TargetInstrInfo *TII = getParent()->getSubtarget().getInstrInfo();

snehasish wrote:
> rahmanl wrote:
> > snehasish wrote:
> > > I think this method only relies on already public methods of 
> > > MachineBasicBlock. It would be cleaner to move this from here to a static 
> > > helper function in AsmPrinter.cpp. This way we don't add yet another 
> > > method to the MachineBasicBlock class and keeps the relevant metadata 
> > > generation logic close to where it is used.
> > > 
> > > Feel free to ignore if you plan on calling this method elsewhere apart 
> > > from AsmPrinter.cpp but I can't think of a reason to do so.
> > Thanks for the suggestion. It makes the code much more readable since I 
> > just place that function above emitBBAddrMapSection.
> > I can even make it a lambda function within emitBBAddrMapSection. WDYT?
> I have a slight preference for the static method vs inline lambda since the 
> comment describing the metadata can be placed above the static method.
Makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85408

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


[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Andrew Gallagher via Phabricator via cfe-commits
andrewjcg updated this revision to Diff 288695.
andrewjcg added a comment.

add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86802

Files:
  clang/lib/Frontend/FrontendAction.cpp
  clang/test/Modules/Inputs/explicit-module-maps/invalid.modulemap
  clang/test/Modules/explicit-module-maps.cpp


Index: clang/test/Modules/explicit-module-maps.cpp
===
--- /dev/null
+++ clang/test/Modules/explicit-module-maps.cpp
@@ -0,0 +1,5 @@
+// Test that an explicit module map (which fails to parse/load in this case)
+// isn't used if modules aren't enabled.
+
+// RUN: %clang_cc1 
-fmodule-map-file=%S/Inputs/explicit-module-maps/invalid.modulemap -verify %s
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/explicit-module-maps/invalid.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/explicit-module-maps/invalid.modulemap
@@ -0,0 +1 @@
+DOES NOT PARSE!
Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -807,12 +807,14 @@
 goto failure;
 
   // If we were asked to load any module map files, do so now.
-  for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
-if (auto File = CI.getFileManager().getFile(Filename))
-  CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
-  *File, /*IsSystem*/false);
-else
-  CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+  if (CI.getLangOpts().Modules) {
+for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
+  if (auto File = CI.getFileManager().getFile(Filename))
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else
+CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+}
   }
 
   // Add a module declaration scope so that modules from -fmodule-map-file


Index: clang/test/Modules/explicit-module-maps.cpp
===
--- /dev/null
+++ clang/test/Modules/explicit-module-maps.cpp
@@ -0,0 +1,5 @@
+// Test that an explicit module map (which fails to parse/load in this case)
+// isn't used if modules aren't enabled.
+
+// RUN: %clang_cc1 -fmodule-map-file=%S/Inputs/explicit-module-maps/invalid.modulemap -verify %s
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/explicit-module-maps/invalid.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/explicit-module-maps/invalid.modulemap
@@ -0,0 +1 @@
+DOES NOT PARSE!
Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -807,12 +807,14 @@
 goto failure;
 
   // If we were asked to load any module map files, do so now.
-  for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
-if (auto File = CI.getFileManager().getFile(Filename))
-  CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
-  *File, /*IsSystem*/false);
-else
-  CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+  if (CI.getLangOpts().Modules) {
+for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
+  if (auto File = CI.getFileManager().getFile(Filename))
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else
+CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+}
   }
 
   // Add a module declaration scope so that modules from -fmodule-map-file
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D85408: Let -basic-block-sections=labels emit basicblock metadata in a new .bb_addr_map section, instead of emitting special unary-encoded symbols.

2020-08-28 Thread Rahman Lavaee via Phabricator via cfe-commits
rahmanl updated this revision to Diff 288694.
rahmanl added a comment.

- Move getBBAddrMetadata to AsmPrinter as a static function + nits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85408

Files:
  clang/docs/UsersManual.rst
  clang/test/CodeGen/basic-block-sections.c
  llvm/include/llvm/CodeGen/AsmPrinter.h
  llvm/include/llvm/CodeGen/MachineFunction.h
  llvm/include/llvm/MC/MCObjectFileInfo.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/BasicBlockSections.cpp
  llvm/lib/CodeGen/MIRParser/MIRParser.cpp
  llvm/lib/CodeGen/MachineBasicBlock.cpp
  llvm/lib/CodeGen/MachineFunction.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
  llvm/test/CodeGen/X86/basic-block-sections-labels.ll

Index: llvm/test/CodeGen/X86/basic-block-sections-labels.ll
===
--- llvm/test/CodeGen/X86/basic-block-sections-labels.ll
+++ llvm/test/CodeGen/X86/basic-block-sections-labels.ll
@@ -1,23 +1,24 @@
 ; Check the basic block sections labels option
-; RUN: llc < %s -mtriple=x86_64-pc-linux -function-sections -basic-block-sections=labels | FileCheck %s -check-prefix=LINUX-LABELS
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -function-sections -basic-block-sections=labels | FileCheck %s -check-prefix=LINUX-LABELS
 
-define void @_Z3bazb(i1 zeroext) {
-  %2 = alloca i8, align 1
-  %3 = zext i1 %0 to i8
-  store i8 %3, i8* %2, align 1
-  %4 = load i8, i8* %2, align 1
-  %5 = trunc i8 %4 to i1
-  br i1 %5, label %6, label %8
+define void @_Z3bazb(i1 zeroext) personality i32 (...)* @__gxx_personality_v0 {
+  br i1 %0, label %2, label %7
 
-6:; preds = %1
-  %7 = call i32 @_Z3barv()
-  br label %10
+2:
+  %3 = invoke i32 @_Z3barv()
+  to label %7 unwind label %5
+  br label %9
 
-8:; preds = %1
-  %9 = call i32 @_Z3foov()
-  br label %10
+5:
+  landingpad { i8*, i32 }
+  catch i8* null
+  br label %9
 
-10:   ; preds = %8, %6
+7:
+  %8 = call i32 @_Z3foov()
+  br label %9
+
+9:
   ret void
 }
 
@@ -25,9 +26,31 @@
 
 declare i32 @_Z3foov() #1
 
-; LINUX-LABELS: .section
-; LINUX-LABELS: _Z3bazb:
-; LINUX-LABELS-NOT: .section
-; LINUX-LABELS: r.BB._Z3bazb:
-; LINUX-LABELS-NOT: .section
-; LINUX-LABELS: rr.BB._Z3bazb:
+declare i32 @__gxx_personality_v0(...)
+
+; LINUX-LABELS-LABEL:	_Z3bazb:
+; LINUX-LABELS:		.Lfunc_begin0:
+; LINUX-LABELS:		.LBB_END0_[[L1:[0-9]+]]:
+; LINUX-LABELS:		.LBB0_[[L2:[0-9]+]]:
+; LINUX-LABELS:		.LBB_END0_[[L2]]:
+; LINUX-LABELS:		.LBB0_[[L3:[0-9]+]]:
+; LINUX-LABELS:		.LBB_END0_[[L3]]:
+; LINUX-LABELS:		.LBB0_[[L4:[0-9]+]]:
+; LINUX-LABELS:		.LBB_END0_[[L4]]:
+; LINUX-LABELS:		.Lfunc_end0:
+
+; LINUX-LABELS:		.section	.bb_addr_map,"o",@progbits,.text
+; LINUX-LABELS-NEXT:	.quad	.Lfunc_begin0
+; LINUX-LABELS-NEXT:	.byte	4
+; LINUX-LABELS-NEXT:	.uleb128 .Lfunc_begin0-.Lfunc_begin0
+; LINUX-LABELS-NEXT:	.uleb128 .LBB_END0_[[L1]]-.Lfunc_begin0
+; LINUX-LABELS-NEXT:	.byte	0
+; LINUX-LABELS-NEXT:	.uleb128 .LBB0_[[L2]]-.Lfunc_begin0
+; LINUX-LABELS-NEXT:	.uleb128 .LBB_END0_[[L2]]-.LBB0_[[L2]]
+; LINUX-LABELS-NEXT:	.byte	0
+; LINUX-LABELS-NEXT:	.uleb128 .LBB0_[[L3]]-.Lfunc_begin0
+; LINUX-LABELS-NEXT:	.uleb128 .LBB_END0_[[L3]]-.LBB0_[[L3]]
+; LINUX-LABELS-NEXT:	.byte	1
+; LINUX-LABELS-NEXT:	.uleb128 .LBB0_[[L4]]-.Lfunc_begin0
+; LINUX-LABELS-NEXT:	.uleb128 .LBB_END0_[[L4]]-.LBB0_[[L4]]
+; LINUX-LABELS-NEXT:	.byte	5
Index: llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
@@ -0,0 +1,35 @@
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -function-sections -basic-block-sections=labels | FileCheck %s
+
+$_Z4fooTIiET_v = comdat any
+
+define dso_local i32 @_Z3barv() {
+  ret i32 0
+}
+;; Check we add SHF_LINK_ORDER for .bb_addr_map and link it with the corresponding .text sections.
+; CHECK:	.section .text._Z3barv,"ax",@progbits
+; CHECK-LABEL:	_Z3barv:
+; CHECK-NEXT:	[[BAR_BEGIN:.+]]:
+; CHECK:	.section .bb_addr_map,"o",@progbits,.text._Z3barv{{$}}
+; CHECK-NEXT:	.quad [[BAR_BEGIN]]
+
+
+define dso_local i32 @_Z3foov() {
+  %1 = call i32 @_Z4fooTIiET_v()
+  ret i32 %1
+}
+; CHECK:	.section .text._Z3foov,"ax",@progbits
+; CHECK-LABEL:	_Z3foov:
+; CHECK-NEXT:	[[FOO_BEGIN:.+]]:
+; CHECK:	.section  .bb_addr_map,"o",@progbits,.text._Z3foov{{$}}
+; CHECK-NEXT:	.quad [[FOO_BEGIN]]
+
+
+define linkonce_odr dso_local i32 @_Z4fooTIiET_v() comdat {
+  ret i32 0
+}
+;; Check we add .bb_addr_map section to a COMDAT group with the corresponding .text section if such a COMDAT exists.
+; CHECK:	.section .text._Z4fooTIiET_v,"axG",@progbits,_Z4fooTIiET_v,comdat
+; CHECK-LABEL:

[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added inline comments.



Comment at: clang/lib/Frontend/FrontendAction.cpp:814
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else

andrewjcg wrote:
> bruno wrote:
> > Is this clang-formatted? 
> Ahh, yeah.  Should I avoid this sort of thing (and e.g. instead do this in 
> explicit codemod/refactoring diffs)?
It's fine in this case cause it's relevant as part of your changes (indentation 
for the block will change anyways), just double checking on the final 
formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86802

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


[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

2020-08-28 Thread David Blaikie via Phabricator via cfe-commits
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: danielkiss.

Sounds good to me - thanks!


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

https://reviews.llvm.org/D81865

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


[PATCH] D85676: [NewPM] collapsing nested pass mangers of the same type

2020-08-28 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added a comment.
Herald added subscribers: wenlei, danielkiss.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85676

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


[PATCH] D86156: [BFI] Preserve BFI information through loop passes via VH callbacks inside LoopStandardAnalysisResults

2020-08-28 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.
Herald added a subscriber: danielkiss.

New compile-time numbers: 
https://llvm-compile-time-tracker.com/compare.php?from=d7c119d89c5f6d0789cfd0a139c80e23912c0bb0&to=e0a1a6cac1b982023f8ceba8285d1ee7bc96bd32&stat=instructions
 The regression is now reduced to 0.2%. I assume that's the overhead of those 
CallbackVHs.

I have no familiarity with BFI, so possibly stupid question: There is already 
some similar handling as part of BFIImpl here: 
https://github.com/llvm/llvm-project/blob/0f14b2e6cbb54c84ed3b00b0db521f5ce2d1e3f2/llvm/include/llvm/Analysis/BlockFrequencyInfoImpl.h#L1043-L1058
 What is the difference to that / why are both needed?




Comment at: llvm/include/llvm/Analysis/BlockFrequencyInfo.h:43
+  class BFICallbackVH final : public CallbackVH {
+std::weak_ptr BFI;
+const BasicBlock *BB;

Is the shared_ptr/weak_ptr usage here necessary? This type of map deletion 
CallbackVH is a common pattern, but this is the first time I see it with 
weak_ptr.



Comment at: llvm/include/llvm/Analysis/BlockFrequencyInfo.h:44
+std::weak_ptr BFI;
+const BasicBlock *BB;
+

It should not be necessary to explicitly store `BB` here, it is already part of 
the value handle (you can access it via `*this` for example).



Comment at: llvm/include/llvm/Analysis/BlockFrequencyInfo.h:48
+BFICallbackVH(std::shared_ptr BFI, const BasicBlock *BB);
+virtual ~BFICallbackVH() = default;
+

I don't believe this virtual dtor is needed (class is final). For that matter, 
the method below also don't need to marked virtual.



Comment at: llvm/lib/Analysis/BlockFrequencyInfo.cpp:212
+  for (const auto *BB : RegisteredBlocks)
+BlockWatchers.emplace_back(BFICallbackVH(BFI, BB));
+

May want to clear BlockWatchers in `BlockFrequencyInfo::releaseMemory()`?



Comment at: llvm/lib/Transforms/Scalar/LoopDistribute.cpp:1062
+LoopStandardAnalysisResults AR = {AA,  AC,  DT,  LI, SE,
+  TLI, TTI, nullptr, nullptr};
 return LAM.getResult(L, AR);

Huh, surprised that clang-format allows this.


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

https://reviews.llvm.org/D86156

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


[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Andrew Gallagher via Phabricator via cfe-commits
andrewjcg added a comment.

> How about a malformed module map is not loaded and gives no errors?

Heh yeah, was thinking the same :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86802

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


[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Thorsten via Phabricator via cfe-commits
tschuett added a comment.
Herald added a subscriber: danielkiss.

How about a malformed module map is not loaded and gives no errors?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86802

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


[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Andrew Gallagher via Phabricator via cfe-commits
andrewjcg added a comment.

> Can you add a simple testcase to prove the point of the change?

Yup, will do!




Comment at: clang/lib/Frontend/FrontendAction.cpp:814
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else

bruno wrote:
> Is this clang-formatted? 
Ahh, yeah.  Should I avoid this sort of thing (and e.g. instead do this in 
explicit codemod/refactoring diffs)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86802

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


[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added a comment.

Hi Andrew, thanks for improving this. I think this makes sense: dependents can 
choose to not use modules without having to trigger the build system to rebuild 
all dependencies. Can you add a simple testcase to prove the point of the 
change?




Comment at: clang/lib/Frontend/FrontendAction.cpp:814
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else

Is this clang-formatted? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86802

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


[clang] 8782c72 - Strength-reduce SmallVectors to arrays. NFCI.

2020-08-28 Thread Benjamin Kramer via cfe-commits

Author: Benjamin Kramer
Date: 2020-08-28T21:14:20+02:00
New Revision: 8782c727655942c9aa4c80d698c9ba575510799c

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

LOG: Strength-reduce SmallVectors to arrays. NFCI.

Added: 


Modified: 
clang/lib/Driver/ToolChains/AMDGPU.cpp
llvm/lib/IR/DebugInfoMetadata.cpp
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
llvm/lib/Transforms/Utils/SimplifyCFG.cpp
mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index b11ce41de479..71acf3ed3281 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -245,9 +245,9 @@ void RocmInstallationDetector::detectDeviceLibrary() {
 // - ${ROCM_ROOT}/lib/*
 // - ${ROCM_ROOT}/lib/bitcode/*
 // so try to detect these layouts.
-static llvm::SmallVector SubDirsList[] = {
+static constexpr std::array SubDirsList[] = {
 {"amdgcn", "bitcode"},
-{"lib"},
+{"lib", ""},
 {"lib", "bitcode"},
 };
 

diff  --git a/llvm/lib/IR/DebugInfoMetadata.cpp 
b/llvm/lib/IR/DebugInfoMetadata.cpp
index f20270810ed6..129a52b710c6 100644
--- a/llvm/lib/IR/DebugInfoMetadata.cpp
+++ b/llvm/lib/IR/DebugInfoMetadata.cpp
@@ -133,7 +133,7 @@ const DILocation *DILocation::getMergedLocation(const 
DILocation *LocA,
 }
 
 Optional DILocation::encodeDiscriminator(unsigned BD, unsigned DF, 
unsigned CI) {
-  SmallVector Components = {BD, DF, CI};
+  std::array Components = {BD, DF, CI};
   uint64_t RemainingWork = 0U;
   // We use RemainingWork to figure out if we have no remaining components to
   // encode. For example: if BD != 0 but DF == 0 && CI == 0, we don't need to

diff  --git a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp 
b/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
index e68183dc46a2..e1b79393f25f 100644
--- a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+++ b/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -15710,8 +15710,8 @@ SDValue 
AArch64TargetLowering::LowerFixedLengthVectorSetccToSVE(
   auto Pg = getPredicateForFixedLengthVector(DAG, DL, InVT);
 
   EVT CmpVT = Pg.getValueType();
-  SmallVector CmpOps = {Pg, Op1, Op2, Op.getOperand(2)};
-  auto Cmp = DAG.getNode(AArch64ISD::SETCC_MERGE_ZERO, DL, CmpVT, CmpOps);
+  auto Cmp = DAG.getNode(AArch64ISD::SETCC_MERGE_ZERO, DL, CmpVT,
+ {Pg, Op1, Op2, Op.getOperand(2)});
 
   EVT PromoteVT = ContainerVT.changeTypeToInteger();
   auto Promote = DAG.getBoolExtOrTrunc(Cmp, DL, PromoteVT, InVT);

diff  --git a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp 
b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
index 75cb87345949..ae2471969160 100644
--- a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -3156,7 +3156,7 @@ static bool mergeConditionalStoreToAddress(BasicBlock 
*PTB, BasicBlock *PFB,
 return true;
   };
 
-  const SmallVector FreeStores = {PStore, QStore};
+  const std::array FreeStores = {PStore, QStore};
   if (!MergeCondStoresAggressively &&
   (!IsWorthwhile(PTB, FreeStores) || !IsWorthwhile(PFB, FreeStores) ||
!IsWorthwhile(QTB, FreeStores) || !IsWorthwhile(QFB, FreeStores)))

diff  --git a/mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp 
b/mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
index 126228bce25a..6c0c841451da 100644
--- a/mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
+++ b/mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
@@ -377,11 +377,10 @@ fuseProducerOfDep(OpBuilder &b, LinalgOp consumer, 
unsigned consumerIdx,
 Optional mlir::linalg::fuseProducerOf(
 OpBuilder &b, LinalgOp consumer, unsigned consumerIdx,
 const LinalgDependenceGraph &graph, OperationFolder *folder) {
-  SmallVector deps = {
-  LinalgDependenceGraph::DependenceType::RAW,
-  LinalgDependenceGraph::DependenceType::WAW,
-  };
-  for (auto dep : deps) {
+  for (auto dep : {
+   LinalgDependenceGraph::DependenceType::RAW,
+   LinalgDependenceGraph::DependenceType::WAW,
+   }) {
 if (auto res =
 fuseProducerOfDep(b, consumer, consumerIdx, graph, folder, dep))
   return res;

diff  --git a/mlir/lib/Dialect/SPIRV/SPIRVOps.cpp 
b/mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
index 7aeecdbbac35..83de4cc2e8fe 100644
--- a/mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
+++ b/mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
@@ -2849,9 +2849,9 @@ static ParseResult 
parseCooperativeMatrixLoadNVOp(OpAsmParser &parser,
   parser.parseType(ptrType) || parser.parseKeywordType("as", elementType)) 
{
 return failure();
   }
-  SmallVector OperandType = {ptrType, strideType, columnMajorType};
-  if (parser.resolveOperands(operandInfo, OperandType,

[PATCH] D86802: [Modules] Don't parse/load explicit module maps if modules are disabled

2020-08-28 Thread Andrew Gallagher via Phabricator via cfe-commits
andrewjcg created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
andrewjcg requested review of this revision.

In some build environments/systems, flags for explicit module map files
may be propagated up to dependents which may not choose to enable use of
modules (e.g. if a particular compilation doesn't currently work in
modular builds).

In this case, the explicit module files are still passed, even though
they're not used (and can trigger additional I/O at header search path,
like realpath'ing include roots if an explicit  module map contains a
umbrella dir).

This diff avoids parsing/loading these module map files if modules
haven't been enabled.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86802

Files:
  clang/lib/Frontend/FrontendAction.cpp


Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -807,12 +807,14 @@
 goto failure;
 
   // If we were asked to load any module map files, do so now.
-  for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
-if (auto File = CI.getFileManager().getFile(Filename))
-  CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
-  *File, /*IsSystem*/false);
-else
-  CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+  if (CI.getLangOpts().Modules) {
+for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
+  if (auto File = CI.getFileManager().getFile(Filename))
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else
+CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+}
   }
 
   // Add a module declaration scope so that modules from -fmodule-map-file


Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -807,12 +807,14 @@
 goto failure;
 
   // If we were asked to load any module map files, do so now.
-  for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
-if (auto File = CI.getFileManager().getFile(Filename))
-  CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
-  *File, /*IsSystem*/false);
-else
-  CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+  if (CI.getLangOpts().Modules) {
+for (const auto &Filename : CI.getFrontendOpts().ModuleMapFiles) {
+  if (auto File = CI.getFileManager().getFile(Filename))
+CI.getPreprocessor().getHeaderSearchInfo().loadModuleMapFile(
+*File, /*IsSystem*/ false);
+  else
+CI.getDiagnostics().Report(diag::err_module_map_not_found) << Filename;
+}
   }
 
   // Add a module declaration scope so that modules from -fmodule-map-file
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-08-28 Thread Ed Maste via Phabricator via cfe-commits
emaste added inline comments.



Comment at: clang/lib/Basic/Targets.cpp:361-362
   return new LinuxTargetInfo(Triple, Opts);
+case llvm::Triple::FreeBSD:
+  return new FreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::NetBSD:

Bdragon28 wrote:
> Bdragon28 wrote:
> > emaste wrote:
> > > List was previously in alpha order
> > Yes. However, I am following the ordering of the ppc64 and powerpc triples.
> that is, the ordering is "Linux, the BSDs, Embedded targets, Commercial 
> targets" for ppc*.
Ok, as long as it's consistent I'm happy with it


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

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


[PATCH] D86369: [Sema][MSVC] warn at dynamic_cast when /GR- is given

2020-08-28 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added inline comments.



Comment at: clang/lib/Sema/SemaCast.cpp:895
+  if (!Self.getLangOpts().RTTIData) {
+bool isMSVC = Self.getDiagnostics().getDiagnosticOptions().getFormat() ==
+  DiagnosticOptions::MSVC;

hans wrote:
> zequanwu wrote:
> > hans wrote:
> > > I'm not sure isMSVC is the best name (it's not clear what aspect is MSVC 
> > > exactly -- in this case it's the diagnostics format).
> > > 
> > > It's possible to target MSVC both with clang-cl and with regular clang.
> > > 
> > > For example, one could use
> > > 
> > >   clang-cl /c /tmp/a.cpp
> > > 
> > > or
> > > 
> > >   clang -c /tmp/a.cpp -target i686-pc-windows-msvc19.11.0 -fms-extensions
> > > 
> > > 
> > > My understanding is that the purpose of "isMSVC" here is to try and 
> > > detect if we're using clang-cl or clang so that the diagnostic can say 
> > > "/GR-" or "-fno-rtti-data". So maybe it's better to call it "isClangCL" 
> > > or something like that.
> > > 
> > > Also, I don't think we should check "isMSVC" in the if-statement below. 
> > > We want the warning to fire both when using clang and clang-cl: as long 
> > > as -fno-rtti-data or /GR- is used, the warning makes sense.
> > > 
> > > So I think the code could be more like:
> > > 
> > > ```
> > > if (!Self.getLangOpts().RTTIData && !DestPointee->isVoidType()) {
> > >   bool isClangCL = ...;
> > >   Self.Diag(...) << isClangCL;
> > > }
> > > ```
> > MSVC will warn even if the DestPointee is void type. What I thought is if 
> > invoked by clang-cl warn regardless of DeskPointee type. If invoked by 
> > clang, warn if it's not void type. 
> > https://godbolt.org/z/475q5v. I noticed MSVC won't warn at typeid if /GR- 
> > is given. Probably I should remove the warning in typeid.
> If it's true the casting to void* doesn't need RTTI data (I think it is, but 
> would be good to verify), then it doesn't make sense to warn. We don't have 
> to follow MSVC's behavior when it doesn't make sense :)
> 
> Similar reasoning for typeid() - I assume it won't work with /GR- also with 
> MSVC, so warning about it probably makes sense.
In clang, I believe that dynamic_cast to void* doesn't use RTTI data: 
https://godbolt.org/z/Kbr7Mq
Looks like MSVC only warns if the operand of typeid is not pointer: 
https://godbolt.org/z/chcMcn



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86369

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


[PATCH] D85743: [CodeGen][AArch64] Support arm_sve_vector_bits attribute

2020-08-28 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added a comment.

> The IR differences were caused by the new pass manager which is on by default 
> for the Fuchsia builder. I've re-landed the patch with a fix for 
> `CodeGen/attr-arm-sve-vector-bits-call.c` to use the legacy pm with 
> `-fno-experimental-new-pass-manager`.

Thanks for the update! We do have the new PM on by default, but I'm surprised 
that this wouldn't appear on `clang-x86_64-debian-new-pass-manager-fast` which 
also tests the new PM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85743

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


[PATCH] D86796: [Sema] Address-space sensitive index check for unbounded arrays

2020-08-28 Thread Chris Hamilton via Phabricator via cfe-commits
chrish_ericsson_atx updated this revision to Diff 288649.
chrish_ericsson_atx added a comment.

Removed Change-Id from commit log message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86796

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/const-eval.c
  clang/test/Sema/unbounded-array-bounds.c
  clang/test/SemaCXX/constant-expression-cxx1y.cpp

Index: clang/test/SemaCXX/constant-expression-cxx1y.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx1y.cpp
+++ clang/test/SemaCXX/constant-expression-cxx1y.cpp
@@ -1018,8 +1018,9 @@
 }
 
 constexpr void PR28739(int n) { // expected-error {{never produces a constant}}
-  int *p = &n;
+  int *p = &n;  // expected-note {{declared here}}
   p += (__int128)(unsigned long)-1; // expected-note {{cannot refer to element 18446744073709551615 of non-array object in a constant expression}}
+  // expected-warning@-1 {{refers past the last possible element}}
 }
 
 constexpr void Void(int n) {
Index: clang/test/Sema/unbounded-array-bounds.c
===
--- /dev/null
+++ clang/test/Sema/unbounded-array-bounds.c
@@ -0,0 +1,58 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fsyntax-only %s 2>&1 | FileCheck --check-prefix=CHECK-X86-ADDR64 %s  \
+// RUN:  --implicit-check-not 'past the last possible element'
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu   -fsyntax-only %s 2>&1 | FileCheck --check-prefix=CHECK-I386-ADDR32 %s \
+// RUN:  --implicit-check-not 'past the last possible element'
+// RUN: %clang_cc1 -triple avr-pc-linux-gnu-fsyntax-only %s 2>&1 | FileCheck --check-prefix=CHECK-AVR-ADDR16 %s  \
+// RUN:  --implicit-check-not 'past the last possible element'
+
+struct S {
+  long long a;
+  char b;
+  long long c;
+  short d;
+};
+
+struct S s[];
+
+void f1() {
+  ++s[3].a;
+  ++s[7073650413200313099].b;
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 576460752303423488 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 178956970 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+  ++s[7073650].c;
+  // CHECK-AVR-ADDR16:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+}
+
+long long ll[];
+
+void f2() {
+  ++ll[3];
+  ++ll[2705843009213693952];
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 2305843009213693952 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 536870912 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 8192 elements)
+  ++ll[847073650];
+  // CHECK-I386-ADDR32: :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 536870912 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 8192 elements)
+}
+
+void f3(struct S p[]) {
+  ++p[3].a;
+  ++p[7073650413200313099].b;
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 576460752303423488 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 178956970 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+  ++p[7073650].c;
+  // CHECK-AVR-ADDR16:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+}
+
+void f4(struct S *p) {
+  p += 3;
+  p += 7073650413200313099;
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:3: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 576460752303423488 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:3: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 178956970 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:3: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+  p += 7073650;
+  // CHECK-AVR-ADDR16:  :[[@LINE-1]]:3: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+}
Index: clang/test/Sema/const-eval.c
===
--- clang/test/Sem

[PATCH] D86796: [Sema] Address-space sensitive index check for unbounded arrays

2020-08-28 Thread Chris Hamilton via Phabricator via cfe-commits
chrish_ericsson_atx created this revision.
Herald added subscribers: cfe-commits, arphaman.
Herald added a project: clang.
chrish_ericsson_atx requested review of this revision.

Check applied to unbounded (incomplete) arrays and pointers
to spot cases where the computed address is beyond the
largest possible addressable extent of the array, based
on the address space in which the array is delcared, or
which the pointer refers to.

Check helps to avoid cases of nonsense pointer math and
array indexing which could lead to linker failures or
runtime exceptions.  Of particular interest when building
for embedded systems with small address spaces.

Change-Id: I836042912f0f7ba4ee774ac03d2fb47d987709e2


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86796

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/const-eval.c
  clang/test/Sema/unbounded-array-bounds.c
  clang/test/SemaCXX/constant-expression-cxx1y.cpp

Index: clang/test/SemaCXX/constant-expression-cxx1y.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx1y.cpp
+++ clang/test/SemaCXX/constant-expression-cxx1y.cpp
@@ -1018,8 +1018,9 @@
 }
 
 constexpr void PR28739(int n) { // expected-error {{never produces a constant}}
-  int *p = &n;
+  int *p = &n;  // expected-note {{declared here}}
   p += (__int128)(unsigned long)-1; // expected-note {{cannot refer to element 18446744073709551615 of non-array object in a constant expression}}
+  // expected-warning@-1 {{refers past the last possible element}}
 }
 
 constexpr void Void(int n) {
Index: clang/test/Sema/unbounded-array-bounds.c
===
--- /dev/null
+++ clang/test/Sema/unbounded-array-bounds.c
@@ -0,0 +1,58 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fsyntax-only %s 2>&1 | FileCheck --check-prefix=CHECK-X86-ADDR64 %s  \
+// RUN:  --implicit-check-not 'past the last possible element'
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu   -fsyntax-only %s 2>&1 | FileCheck --check-prefix=CHECK-I386-ADDR32 %s \
+// RUN:  --implicit-check-not 'past the last possible element'
+// RUN: %clang_cc1 -triple avr-pc-linux-gnu-fsyntax-only %s 2>&1 | FileCheck --check-prefix=CHECK-AVR-ADDR16 %s  \
+// RUN:  --implicit-check-not 'past the last possible element'
+
+struct S {
+  long long a;
+  char b;
+  long long c;
+  short d;
+};
+
+struct S s[];
+
+void f1() {
+  ++s[3].a;
+  ++s[7073650413200313099].b;
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 576460752303423488 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 178956970 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+  ++s[7073650].c;
+  // CHECK-AVR-ADDR16:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+}
+
+long long ll[];
+
+void f2() {
+  ++ll[3];
+  ++ll[2705843009213693952];
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 2305843009213693952 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 536870912 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 8192 elements)
+  ++ll[847073650];
+  // CHECK-I386-ADDR32: :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 536870912 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 8192 elements)
+}
+
+void f3(struct S p[]) {
+  ++p[3].a;
+  ++p[7073650413200313099].b;
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 576460752303423488 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:5: warning: {{.*}} past the last possible element {{.*}} in 32-bit {{.*}} (max possible 178956970 elements)
+  // CHECK-AVR-ADDR16:  :[[@LINE-3]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+  ++p[7073650].c;
+  // CHECK-AVR-ADDR16:  :[[@LINE-1]]:5: warning: {{.*}} past the last possible element {{.*}} in 16-bit {{.*}} (max possible 3276 elements)
+}
+
+void f4(struct S *p) {
+  p += 3;
+  p += 7073650413200313099;
+  // CHECK-X86-ADDR64:  :[[@LINE-1]]:3: warning: {{.*}} past the last possible element {{.*}} in 64-bit {{.*}} (max possible 576460752303423488 elements)
+  // CHECK-I386-ADDR32: :[[@LINE-2]]:3: warning: {{.*}} past the la

[PATCH] D86795: [PowerPC] Implement builtins for xvcvspbf16 and xvcvbf16spn

2020-08-28 Thread Amy Kwan via Phabricator via cfe-commits
amyk created this revision.
amyk added reviewers: bsaleil, lei, nemanjai, power-llvm-team, PowerPC.
amyk added projects: LLVM, PowerPC.
Herald added subscribers: llvm-commits, cfe-commits, shchenz, hiraditya.
Herald added a project: clang.
amyk requested review of this revision.

This patch adds the builtin implementation for the xvcvspbf16 and xvcvbf16spn 
instructions.

Depends on D86794 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86795

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/bfloat16-outer-product.ll

Index: llvm/test/CodeGen/PowerPC/bfloat16-outer-product.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/bfloat16-outer-product.ll
@@ -0,0 +1,52 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names \
+; RUN:   -ppc-vsr-nums-as-vr < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names \
+; RUN:   -ppc-vsr-nums-as-vr < %s | FileCheck %s --check-prefix=CHECK-BE
+
+; Function Attrs: nofree nounwind writeonly
+define dso_local void @test60(i8* nocapture readnone %vqp, i8* nocapture readnone %vpp, <16 x i8> %vc, i8* nocapture %resp) {
+; CHECK-LABEL: test60:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xvcvspbf16 vs0, v2
+; CHECK-NEXT:stxv vs0, 0(r7)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test60:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xvcvspbf16 vs0, v2
+; CHECK-BE-NEXT:stxv vs0, 0(r7)
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = tail call <16 x i8> @llvm.ppc.vsx.xvcvspbf16(<16 x i8> %vc)
+  %1 = bitcast i8* %resp to <16 x i8>*
+  store <16 x i8> %0, <16 x i8>* %1, align 16
+  ret void
+}
+; Function Attrs: nounwind readnone
+declare <16 x i8> @llvm.ppc.vsx.xvcvspbf16(<16 x i8>)
+
+; Function Attrs: nofree nounwind writeonly
+define dso_local void @test61(i8* nocapture readnone %vqp, i8* nocapture readnone %vpp, <16 x i8> %vc, i8* nocapture %resp) {
+; CHECK-LABEL: test61:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xvcvbf16spn vs0, v2
+; CHECK-NEXT:stxv vs0, 0(r7)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test61:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xvcvbf16spn vs0, v2
+; CHECK-BE-NEXT:stxv vs0, 0(r7)
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = tail call <16 x i8> @llvm.ppc.vsx.xvcvbf16spn(<16 x i8> %vc)
+  %1 = bitcast i8* %resp to <16 x i8>*
+  store <16 x i8> %0, <16 x i8>* %1, align 16
+  ret void
+}
+
+; Function Attrs: nounwind readnone
+declare <16 x i8> @llvm.ppc.vsx.xvcvbf16spn(<16 x i8>)
Index: llvm/lib/Target/PowerPC/PPCInstrPrefix.td
===
--- llvm/lib/Target/PowerPC/PPCInstrPrefix.td
+++ llvm/lib/Target/PowerPC/PPCInstrPrefix.td
@@ -506,6 +506,11 @@
 def PairedVectorMemops : Predicate<"PPCSubTarget->pairedVectorMemops()">;
 def MMA : Predicate<"PPCSubTarget->hasMMA()">;
 
+def RCCp {
+  dag AToVSRC = (COPY_TO_REGCLASS $XA, VSRC);
+  dag BToVSRC = (COPY_TO_REGCLASS $XB, VSRC);
+}
+
 let Predicates = [PrefixInstrs] in {
   let Interpretation64Bit = 1, isCodeGenOnly = 1 in {
 defm PADDI8 :
@@ -1333,6 +1338,13 @@
 (v1i128 (VSRAQ v1i128:$VRA, v1i128:$VRB))>;
 }
 
+let Predicates = [IsISA3_1, HasVSX] in {
+  def : Pat<(v16i8 (int_ppc_vsx_xvcvspbf16 v16i8:$XA)),
+(COPY_TO_REGCLASS (XVCVSPBF16 RCCp.AToVSRC), VRRC)>;
+  def : Pat<(v16i8 (int_ppc_vsx_xvcvbf16spn v16i8:$XA)),
+(COPY_TO_REGCLASS (XVCVBF16SPN RCCp.AToVSRC), VRRC)>;
+}
+
 let AddedComplexity = 400, Predicates = [IsISA3_1] in {
   def : Pat<(truncstorei8 (i32 (vector_extract v16i8:$rS, 0)), xoaddr:$src),
 (STXVRBX (COPY_TO_REGCLASS $rS, VSRC), xoaddr:$src)>;
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1124,6 +1124,12 @@
 def int_ppc_vsx_xvcvhpsp :
   PowerPC_VSX_Intrinsic<"xvcvhpsp", [llvm_v4f32_ty],
 [llvm_v8i16_ty],[IntrNoMem]>;
+def int_ppc_vsx_xvcvspbf16 :
+  PowerPC_VSX_Intrinsic<"xvcvspbf16", [llvm_v16i8_ty],
+[llvm_v16i8_ty], [IntrNoMem]>;
+def int_ppc_vsx_xvcvbf16spn :
+  PowerPC_VSX_Intrinsic<"xvcvbf16spn", [llvm_v16i8_ty],
+[llvm_v16i8_ty], [IntrNoMem]>;
 def int_ppc_vsx_xxextractuw :
   PowerPC_VSX_Intrinsic<"xxextractuw",[llvm_v2i64_ty],
 [llvm_v2i64_ty,llvm_i32_ty], [IntrNoMem]>;
Index: clang/test/CodeGen/builtins-ppc-p10vector.c
=

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.h:44
   llvm::Optional
-  GetDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
+  getDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
  const SourceManager &SM) const override;

dougpuob wrote:
> dougpuob wrote:
> > aaron.ballman wrote:
> > > Given that the other functions in the class use the wrong style of 
> > > casing, we should probably leave this declaration alone so it doesn't 
> > > become locally inconsistent.
> > Do you mean create another function with three parameters for it?
> I think I got it. Keep consistent even it is wrong style of casting. 
Yes, exactly!



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:428
 
   case IdentifierNamingCheck::CT_HungarianNotation: {
 const NamedDecl *pNamedDecl = dyn_cast(pDecl);

dougpuob wrote:
> njames93 wrote:
> > aaron.ballman wrote:
> > > I feel like I must be missing something because I don't have this enum in 
> > > my copy of ToT despite pulling this morning. Is the patch missing some 
> > > content?
> > I feel like this is an incremental diff based on the first version of this 
> > patch rather than a diff from trunk. 
> @aaron.ballman and @njames93, the diff is based on first version not from 
> master(trunk).
> 
> Is it the best way that I should merge with the latest master(trunk) every 
> time before updating the diffs ?
Patches are typically a diff against trunk unless you have a series of related 
patches that build on top of one another (in which case, Phab has a way to mark 
related reviews so reviewers can still track the full context of the patch 
set). So when you create the diff, it should typically be against trunk.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[clang] 331dcc4 - [PowerPC] Implemented Vector Load with Zero and Signed Extend Builtins

2020-08-28 Thread Albion Fung via cfe-commits

Author: Albion Fung
Date: 2020-08-28T11:28:58-05:00
New Revision: 331dcc43eac28b8e659f928fd1f1ce7fd091e1e3

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

LOG: [PowerPC] Implemented Vector Load with Zero and Signed Extend Builtins

This patch implements the builtins for Vector Load with Zero and Signed Extend 
Builtins (lxvr_x for b, h, w, d), and adds the appropriate test cases for these 
builtins. The builtins utilize the vector load instructions itnroduced with ISA 
3.1.

Differential Revision:  https://reviews.llvm.org/D82502#inline-797941

Added: 


Modified: 
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-p10vector.c
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
llvm/lib/Target/PowerPC/PPCISelLowering.h
llvm/lib/Target/PowerPC/PPCInstrPrefix.td
llvm/test/CodeGen/PowerPC/builtins-ppc-p10vsx.ll

Removed: 




diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index 6583b0f22a16..5bc0e23792d4 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -16557,6 +16557,54 @@ vec_xl_be(signed long long  __offset, unsigned 
__int128 *__ptr) {
   #define vec_xl_be vec_xl
 #endif
 
+#if defined(__POWER10_VECTOR__) && defined(__VSX__)
+
+/* vect_xl_sext */
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_sext(signed long long __offset, signed char *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_sext(signed long long __offset, signed short *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_sext(signed long long __offset, signed int *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_sext(signed long long __offset, signed long long *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+/* vec_xl_zext */
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_zext(signed long long __offset, unsigned char *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_zext(signed long long __offset, unsigned short *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_zext(signed long long __offset, unsigned int *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_xl_zext(signed long long __offset, unsigned long long *__pointer) {
+  return (vector unsigned __int128)*(__pointer + __offset);
+}
+
+#endif
+
 /* vec_xst */
 
 static inline __ATTRS_o_ai void vec_xst(vector signed char __vec,

diff  --git a/clang/test/CodeGen/builtins-ppc-p10vector.c 
b/clang/test/CodeGen/builtins-ppc-p10vector.c
index 16e468b62318..09477891bb06 100644
--- a/clang/test/CodeGen/builtins-ppc-p10vector.c
+++ b/clang/test/CodeGen/builtins-ppc-p10vector.c
@@ -20,10 +20,14 @@ vector unsigned long long vulla, vullb, vullc;
 vector unsigned __int128 vui128a, vui128b, vui128c;
 vector float vfa, vfb;
 vector double vda, vdb;
-unsigned int uia, uib;
-unsigned char uca;
-unsigned short usa;
-unsigned long long ulla;
+signed int *iap;
+unsigned int uia, uib, *uiap;
+signed char *cap;
+unsigned char uca, *ucap;
+signed short *sap;
+unsigned short usa, *usap;
+signed long long *llap, llb;
+unsigned long long ulla, *ullap;
 
 vector signed long long test_vec_mul_sll(void) {
   // CHECK: mul <2 x i64>
@@ -911,3 +915,59 @@ int test_vec_test_lsbb_all_zeros(void) {
   // CHECK-NEXT: ret i32
   return vec_test_lsbb_all_zeros(vuca);
 }
+
+vector signed __int128 test_vec_xl_sext_i8(void) {
+  // CHECK: load i8
+  // CHECK: sext i8
+  // CHECK: ret <1 x i128>
+  return vec_xl_sext(llb, cap);
+}
+
+vector signed __int128 test_vec_xl_sext_i16(void) {
+  // CHECK: load i16
+  // CHECK: sext i16
+  // CHECK: ret <1 x i128>
+  return vec_xl_sext(llb, sap);
+}
+
+vector signed __int128 test_vec_xl_sext_i32(void) {
+  // CHECK: load i32
+  // CHECK: sext i32
+  // CHECK: ret <1 x i128>
+  return vec_xl_sext(llb, iap);
+}
+
+vector signed __int128 test_vec_xl_sext_i64(void) {
+  // CHECK: load i64
+  // CHECK: sext i64
+  // CHECK: ret <1 x i128>
+  return vec_xl_sext(llb, llap);
+}
+
+vector unsigned __int128 test_vec_xl_zext_i8(void) {
+  // CHECK: load i8
+  // CHECK: zext i8
+  // CHECK: ret <1 x i128>
+  return vec_xl_zext(llb, ucap);
+}
+
+vector unsigned __int128 test_vec_xl_zext_i16(void) {
+  // CHECK: load i16
+  // CHECK: zext i16
+  // CHECK: ret <1 x i128>
+  return 

[PATCH] D82502: [PowerPC] Implement Load VSX Vector and Sign Extend and Zero Extend

2020-08-28 Thread Albion Fung via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Conanap marked an inline comment as done.
Closed by commit rG331dcc43eac2: [PowerPC] Implemented Vector Load with Zero 
and Signed Extend Builtins (authored by Conanap).

Changed prior to commit:
  https://reviews.llvm.org/D82502?vs=283061&id=288637#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82502

Files:
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCISelLowering.h
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-p10vsx.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-p10vsx.ll
===
--- llvm/test/CodeGen/PowerPC/builtins-ppc-p10vsx.ll
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-p10vsx.ll
@@ -239,3 +239,181 @@
   store i64 %conv, i64* %add.ptr, align 8
   ret void
 }
+
+define dso_local <1 x i128> @vec_xl_zext(i64 %__offset, i8* nocapture readonly %__pointer) {
+; CHECK-LABEL: vec_xl_zext:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lxvrbx v2, r4, r3
+; CHECK-NEXT:blr
+;
+; CHECK-O0-LABEL: vec_xl_zext:
+; CHECK-O0:   # %bb.0: # %entry
+; CHECK-O0-NEXT:lxvrbx vs0, r4, r3
+; CHECK-O0-NEXT:xxlor v2, vs0, vs0
+; CHECK-O0-NEXT:blr
+entry:
+  %add.ptr = getelementptr inbounds i8, i8* %__pointer, i64 %__offset
+  %0 = load i8, i8* %add.ptr, align 1
+  %conv = zext i8 %0 to i128
+  %splat.splatinsert = insertelement <1 x i128> undef, i128 %conv, i32 0
+  ret <1 x i128> %splat.splatinsert
+}
+
+define dso_local <1 x i128> @vec_xl_zext_short(i64 %__offset, i16* nocapture readonly %__pointer) {
+; CHECK-LABEL: vec_xl_zext_short:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:sldi r3, r3, 1
+; CHECK-NEXT:lxvrhx v2, r4, r3
+; CHECK-NEXT:blr
+;
+; CHECK-O0-LABEL: vec_xl_zext_short:
+; CHECK-O0:   # %bb.0: # %entry
+; CHECK-O0-NEXT:sldi r3, r3, 1
+; CHECK-O0-NEXT:lxvrhx vs0, r4, r3
+; CHECK-O0-NEXT:xxlor v2, vs0, vs0
+; CHECK-O0-NEXT:blr
+entry:
+  %add.ptr = getelementptr inbounds i16, i16* %__pointer, i64 %__offset
+  %0 = load i16, i16* %add.ptr, align 2
+  %conv = zext i16 %0 to i128
+  %splat.splatinsert = insertelement <1 x i128> undef, i128 %conv, i32 0
+  ret <1 x i128> %splat.splatinsert
+}
+
+define dso_local <1 x i128> @vec_xl_zext_word(i64 %__offset, i32* nocapture readonly %__pointer) {
+; CHECK-LABEL: vec_xl_zext_word:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:sldi r3, r3, 2
+; CHECK-NEXT:lxvrwx v2, r4, r3
+; CHECK-NEXT:blr
+;
+; CHECK-O0-LABEL: vec_xl_zext_word:
+; CHECK-O0:   # %bb.0: # %entry
+; CHECK-O0-NEXT:sldi r3, r3, 2
+; CHECK-O0-NEXT:lxvrwx vs0, r4, r3
+; CHECK-O0-NEXT:xxlor v2, vs0, vs0
+; CHECK-O0-NEXT:blr
+entry:
+  %add.ptr = getelementptr inbounds i32, i32* %__pointer, i64 %__offset
+  %0 = load i32, i32* %add.ptr, align 4
+  %conv = zext i32 %0 to i128
+  %splat.splatinsert = insertelement <1 x i128> undef, i128 %conv, i32 0
+  ret <1 x i128> %splat.splatinsert
+}
+
+define dso_local <1 x i128> @vec_xl_zext_dw(i64 %__offset, i64* nocapture readonly %__pointer) {
+; CHECK-LABEL: vec_xl_zext_dw:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:sldi r3, r3, 3
+; CHECK-NEXT:lxvrdx v2, r4, r3
+; CHECK-NEXT:blr
+;
+; CHECK-O0-LABEL: vec_xl_zext_dw:
+; CHECK-O0:   # %bb.0: # %entry
+; CHECK-O0-NEXT:sldi r3, r3, 3
+; CHECK-O0-NEXT:lxvrdx vs0, r4, r3
+; CHECK-O0-NEXT:xxlor v2, vs0, vs0
+; CHECK-O0-NEXT:blr
+entry:
+  %add.ptr = getelementptr inbounds i64, i64* %__pointer, i64 %__offset
+  %0 = load i64, i64* %add.ptr, align 8
+  %conv = zext i64 %0 to i128
+  %splat.splatinsert = insertelement <1 x i128> undef, i128 %conv, i32 0
+  ret <1 x i128> %splat.splatinsert
+}
+
+define dso_local <1 x i128> @vec_xl_sext_b(i64 %offset, i8* %p) {
+; CHECK-LABEL: vec_xl_sext_b:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lbzx r3, r4, r3
+; CHECK-NEXT:extsb r3, r3
+; CHECK-NEXT:sradi r4, r3, 63
+; CHECK-NEXT:mtvsrdd v2, r4, r3
+; CHECK-NEXT:blr
+;
+; CHECK-O0-LABEL: vec_xl_sext_b:
+; CHECK-O0:   # %bb.0: # %entry
+; CHECK-O0-NEXT:lbzx r3, r4, r3
+; CHECK-O0-NEXT:extsb r3, r3
+; CHECK-O0-NEXT:sradi r4, r3, 63
+; CHECK-O0-NEXT:mtvsrdd v2, r4, r3
+; CHECK-O0-NEXT:blr
+entry:
+  %add.ptr = getelementptr inbounds i8, i8* %p, i64 %offset
+  %0 = load i8, i8* %add.ptr, align 1
+  %conv = sext i8 %0 to i128
+  %splat.splatinsert = insertelement <1 x i128> undef, i128 %conv, i32 0
+  ret <1 x i128> %splat.splatinsert
+}
+
+define dso_local <1 x i128> @vec_xl_sext_h(i64 %offset, i16* %p) {
+; CHECK-LABEL: vec_xl_sext_h:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:sldi r3, r3, 1
+; CHECK-NEXT:lhax r3, r4, r3
+; CHECK-NE

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.h:44
   llvm::Optional
-  GetDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
+  getDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
  const SourceManager &SM) const override;

dougpuob wrote:
> aaron.ballman wrote:
> > Given that the other functions in the class use the wrong style of casing, 
> > we should probably leave this declaration alone so it doesn't become 
> > locally inconsistent.
> Do you mean create another function with three parameters for it?
I think I got it. Keep consistent even it is wrong style of casting. 


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob marked 2 inline comments as not done.
dougpuob added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.h:44
   llvm::Optional
-  GetDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
+  getDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
  const SourceManager &SM) const override;

aaron.ballman wrote:
> Given that the other functions in the class use the wrong style of casing, we 
> should probably leave this declaration alone so it doesn't become locally 
> inconsistent.
Do you mean create another function with three parameters for it?



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:428
 
   case IdentifierNamingCheck::CT_HungarianNotation: {
 const NamedDecl *pNamedDecl = dyn_cast(pDecl);

njames93 wrote:
> aaron.ballman wrote:
> > I feel like I must be missing something because I don't have this enum in 
> > my copy of ToT despite pulling this morning. Is the patch missing some 
> > content?
> I feel like this is an incremental diff based on the first version of this 
> patch rather than a diff from trunk. 
@aaron.ballman and @njames93, the diff is based on first version not from 
master(trunk).

Is it the best way that I should merge with the latest master(trunk) every time 
before updating the diffs ?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

2020-08-28 Thread Nathan Froyd via Phabricator via cfe-commits
froydnj requested review of this revision.
froydnj added a comment.

Throwing this back into the review queue.


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

https://reviews.llvm.org/D81865

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


[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

2020-08-28 Thread Nathan Froyd via Phabricator via cfe-commits
froydnj updated this revision to Diff 288628.
froydnj added a comment.

Updated to use a struct instead of a union for the actual table in an effort to 
avoid UB.


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

https://reviews.llvm.org/D81865

Files:
  clang/lib/Basic/DiagnosticIDs.cpp

Index: clang/lib/Basic/DiagnosticIDs.cpp
===
--- clang/lib/Basic/DiagnosticIDs.cpp
+++ clang/lib/Basic/DiagnosticIDs.cpp
@@ -26,6 +26,78 @@
 
 namespace {
 
+struct StaticDiagInfoRec;
+
+// Store the descriptions in a separate table to avoid pointers that need to
+// be relocated, and also decrease the amount of data needed on 64-bit
+// platforms. See "How To Write Shared Libraries" by Ulrich Drepper.
+struct StaticDiagInfoDescriptionStringTable {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, CATEGORY)\
+  char ENUM##_desc[sizeof(DESC)];
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
+const StaticDiagInfoDescriptionStringTable StaticDiagInfoDescriptions = {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, CATEGORY)\
+  DESC,
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
+extern const StaticDiagInfoRec StaticDiagInfo[];
+
+// Stored separately from StaticDiagInfoRec to pack better.  Otherwise,
+// StaticDiagInfoRec would have extra padding on 64-bit platforms.
+const uint32_t StaticDiagInfoDescriptionOffsets[] = {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, CATEGORY)\
+  offsetof(StaticDiagInfoDescriptionStringTable, ENUM##_desc),
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
 // Diagnostic classes.
 enum {
   CLASS_NOTE   = 0x01,
@@ -47,14 +119,16 @@
   uint16_t OptionGroupIndex;
 
   uint16_t DescriptionLen;
-  const char *DescriptionStr;
 
   unsigned getOptionGroupIndex() const {
 return OptionGroupIndex;
   }
 
   StringRef getDescription() const {
-return StringRef(DescriptionStr, DescriptionLen);
+size_t MyIndex = this - &StaticDiagInfo[0];
+uint32_t StringOffset = StaticDiagInfoDescriptionOffsets[MyIndex];
+const char* Table = reinterpret_cast(&StaticDiagInfoDescriptions);
+return StringRef(&Table[StringOffset], DescriptionLen);
   }
 
   diag::Flavor getFlavor() const {
@@ -91,16 +165,20 @@
 #undef VALIDATE_DIAG_SIZE
 #undef STRINGIFY_NAME
 
-} // namespace anonymous
-
-static const StaticDiagInfoRec StaticDiagInfo[] = {
+const StaticDiagInfoRec StaticDiagInfo[] = {
 #define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
  SHOWINSYSHEADER, CATEGORY)\
   {\
-diag::ENUM, DEFAULT_SEVERITY, CLASS, DiagnosticIDs::SFINAE, NOWERROR,  \
-SHOWINSYSHEADER, CATEGORY, GROUP, STR_SIZE(DESC, uin

[PATCH] D85743: [CodeGen][AArch64] Support arm_sve_vector_bits attribute

2020-08-28 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes added a comment.

In D85743#2243188 , @c-rhodes wrote:

> In D85743#2242931 , @leonardchan 
> wrote:
>
>> Hi! The `attr-arm-sve-vector-bits-call.c` test seems to be failing on our 
>> clang builders:
>>
>> Could you take a look? Thanks.
>>
>> Builder: 
>> https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8870800848452818112?
>
> Sorry about that, I've reverted it (commit 2e7041f 
> ) whilst 
> I investigate. Thanks for raising.

The IR differences were caused by the new pass manager which is on by default 
for the Fuchsia builder. I've re-landed the patch with a fix for 
`CodeGen/attr-arm-sve-vector-bits-call.c` to use the legacy pm with 
`-fno-experimental-new-pass-manager`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85743

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


[PATCH] D85032: [builtins] Make divXf3 handle denormal results

2020-08-28 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko updated this revision to Diff 288625.
atrosinenko added a comment.

Re-upload after changing parent diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85032

Files:
  compiler-rt/lib/builtins/fp_div_impl.inc
  compiler-rt/test/builtins/Unit/divdf3_test.c
  compiler-rt/test/builtins/Unit/divsf3_test.c
  compiler-rt/test/builtins/Unit/divtf3_test.c

Index: compiler-rt/test/builtins/Unit/divtf3_test.c
===
--- compiler-rt/test/builtins/Unit/divtf3_test.c
+++ compiler-rt/test/builtins/Unit/divtf3_test.c
@@ -146,6 +146,13 @@
  UINT64_C(0xfffe)))
 return 1;
 
+// smallest normal value divided by 2.0
+if (test__divtf3(0x1.0p-16382L, 2.L, UINT64_C(0x8000), UINT64_C(0x0)))
+  return 1;
+// smallest subnormal result
+if (test__divtf3(0x1.0p-1022L, 0x1p+52L, UINT64_C(0x0), UINT64_C(0x1)))
+  return 1;
+
 // any / any
 if (test__divtf3(0x1.a23b45362464523375893ab4cdefp+5L,
  0x1.eedcbaba3a94546558237654321fp-1L,
Index: compiler-rt/test/builtins/Unit/divsf3_test.c
===
--- compiler-rt/test/builtins/Unit/divsf3_test.c
+++ compiler-rt/test/builtins/Unit/divsf3_test.c
@@ -92,5 +92,20 @@
 if (test__divsf3(0x1.0p+0F, 0x1.0001p+0F, UINT32_C(0x3f7fff00)))
   return 1;
 
+// smallest normal value divided by 2.0
+if (test__divsf3(0x1.0p-126F, 2.0F, UINT32_C(0x0040)))
+  return 1;
+// smallest subnormal result
+if (test__divsf3(0x1.0p-126F, 0x1p+23F, UINT32_C(0x0001)))
+  return 1;
+
+// some misc test cases obtained by fuzzing against h/w implementation
+if (test__divsf3(-0x1.3e75e6p-108F, -0x1.cf372p+38F, UINT32_C(0x0006)))
+  return 1;
+if (test__divsf3(0x1.e77c54p+81F, -0x1.e77c52p-47F, UINT32_C(0xff80)))
+  return 1;
+if (test__divsf3(0x1.fep-126F, 2.F, UINT32_C(0x0080)))
+  return 1;
+
 return 0;
 }
Index: compiler-rt/test/builtins/Unit/divdf3_test.c
===
--- compiler-rt/test/builtins/Unit/divdf3_test.c
+++ compiler-rt/test/builtins/Unit/divdf3_test.c
@@ -92,6 +92,13 @@
 if (test__divdf3(0x1.0p+0, 0x1.0001p+0, UINT64_C(0x3fefffe0)))
   return 1;
 
+// smallest normal value divided by 2.0
+if (test__divdf3(0x1.0p-1022, 2., UINT64_C(0x0008)))
+  return 1;
+// smallest subnormal result
+if (test__divdf3(0x1.0p-1022, 0x1.0p+52, UINT64_C(0x0001)))
+  return 1;
+
 // some misc test cases obtained by fuzzing against h/w implementation
 if (test__divdf3(0x1.fdc239dd64735p-658, -0x1.fff9364c0843fp-948, UINT64_C(0xd20fdc8fc0ceffb1)))
   return 1;
@@ -99,6 +106,12 @@
   return 1;
 if (test__divdf3(-0x1.da7dfe6048b8bp-875, 0x1.ffc7ea3ff60a4p-610, UINT64_C(0xaf5dab1fe0269e2a)))
   return 1;
+if (test__divdf3(0x1.0p-1022, 0x1.9p+5, UINT64_C(0x51eb851eb852)))
+  return 1;
+if (test__divdf3(0x1.0p-1022, 0x1.0028p+41, UINT64_C(0x07ff)))
+  return 1;
+if (test__divdf3(0x1.0p-1022, 0x1.0028p+52, UINT64_C(0x1)))
+  return 1;
 
 return 0;
 }
Index: compiler-rt/lib/builtins/fp_div_impl.inc
===
--- compiler-rt/lib/builtins/fp_div_impl.inc
+++ compiler-rt/lib/builtins/fp_div_impl.inc
@@ -328,6 +328,7 @@
   if (quotient_UQ1 < (implicitBit << 1)) {
 residualLo = (aSignificand << (significandBits + 1)) - quotient_UQ1 * bSignificand;
 writtenExponent -= 1;
+aSignificand <<= 1;
 
 // the error is doubled
   } else {
@@ -357,19 +358,25 @@
   // Now, quotient_UQ1_SB <= the correctly-rounded result
   // and may need taking NextAfter() up to 3 times (see error estimates above)
   // r = a - b * q
+  rep_t absResult;
+  if (writtenExponent > 0) {
+// Clear the implicit bit
+absResult = quotient_UQ1 & significandMask;
+// Insert the exponent
+absResult |= (rep_t)writtenExponent << significandBits;
+residualLo <<= 1;
+  } else {
+// Prevent shift amount from being negative
+if (significandBits + writtenExponent < 0)
+  return fromRep(quotientSign);
 
-  if (writtenExponent < 0) {
-// Result is definitely subnormal, flushing to zero
-return fromRep(quotientSign);
-  }
+absResult = quotient_UQ1 >> (-writtenExponent + 1);
 
-  // Clear the implicit bit
-  rep_t absResult = quotient_UQ1 & significandMask;
-  // Insert the exponent
-  absResult |= (rep_t)writtenExponent << significandBits;
+// multiplied by two to prevent shift amount to be negative
+residualLo = (aSignificand << (significandBits + writtenExponent)) - (absResult * bSignificand << 1);
+  }
 
   // Round
-  residualLo <<= 1;
   residualLo += absResult & 1; // tie

[PATCH] D85031: [builtins] Unify the softfloat division implementation

2020-08-28 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko updated this revision to Diff 288623.
atrosinenko added a comment.

Add some other explanations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85031

Files:
  compiler-rt/lib/builtins/divdf3.c
  compiler-rt/lib/builtins/divsf3.c
  compiler-rt/lib/builtins/divtf3.c
  compiler-rt/lib/builtins/fp_div_impl.inc
  compiler-rt/lib/builtins/fp_lib.h
  compiler-rt/lib/builtins/int_util.h
  compiler-rt/test/builtins/Unit/divdf3_test.c

Index: compiler-rt/test/builtins/Unit/divdf3_test.c
===
--- compiler-rt/test/builtins/Unit/divdf3_test.c
+++ compiler-rt/test/builtins/Unit/divdf3_test.c
@@ -92,5 +92,13 @@
 if (test__divdf3(0x1.0p+0, 0x1.0001p+0, UINT64_C(0x3fefffe0)))
   return 1;
 
+// some misc test cases obtained by fuzzing against h/w implementation
+if (test__divdf3(0x1.fdc239dd64735p-658, -0x1.fff9364c0843fp-948, UINT64_C(0xd20fdc8fc0ceffb1)))
+  return 1;
+if (test__divdf3(-0x1.78abb261d47c8p+794, 0x1.fb01d537cc5aep+266, UINT64_C(0xe0e7c6148ffc23e3)))
+  return 1;
+if (test__divdf3(-0x1.da7dfe6048b8bp-875, 0x1.ffc7ea3ff60a4p-610, UINT64_C(0xaf5dab1fe0269e2a)))
+  return 1;
+
 return 0;
 }
Index: compiler-rt/lib/builtins/int_util.h
===
--- compiler-rt/lib/builtins/int_util.h
+++ compiler-rt/lib/builtins/int_util.h
@@ -28,4 +28,20 @@
 #define COMPILE_TIME_ASSERT2(expr, cnt)\
   typedef char ct_assert_##cnt[(expr) ? 1 : -1] UNUSED
 
+// Force unrolling the code specified to be repeated N times.
+#define REPEAT_0_TIMES(code_to_repeat) /* do nothing */
+#define REPEAT_1_TIMES(code_to_repeat) code_to_repeat
+#define REPEAT_2_TIMES(code_to_repeat) \
+  REPEAT_1_TIMES(code_to_repeat)   \
+  code_to_repeat
+#define REPEAT_3_TIMES(code_to_repeat) \
+  REPEAT_2_TIMES(code_to_repeat)   \
+  code_to_repeat
+#define REPEAT_4_TIMES(code_to_repeat) \
+  REPEAT_3_TIMES(code_to_repeat)   \
+  code_to_repeat
+
+#define REPEAT_N_TIMES_(N, code_to_repeat) REPEAT_##N##_TIMES(code_to_repeat)
+#define REPEAT_N_TIMES(N, code_to_repeat) REPEAT_N_TIMES_(N, code_to_repeat)
+
 #endif // INT_UTIL_H
Index: compiler-rt/lib/builtins/fp_lib.h
===
--- compiler-rt/lib/builtins/fp_lib.h
+++ compiler-rt/lib/builtins/fp_lib.h
@@ -40,9 +40,12 @@
 
 #if defined SINGLE_PRECISION
 
+typedef uint16_t half_rep_t;
 typedef uint32_t rep_t;
+typedef uint64_t twice_rep_t;
 typedef int32_t srep_t;
 typedef float fp_t;
+#define HALF_REP_C UINT16_C
 #define REP_C UINT32_C
 #define significandBits 23
 
@@ -58,9 +61,11 @@
 
 #elif defined DOUBLE_PRECISION
 
+typedef uint32_t half_rep_t;
 typedef uint64_t rep_t;
 typedef int64_t srep_t;
 typedef double fp_t;
+#define HALF_REP_C UINT32_C
 #define REP_C UINT64_C
 #define significandBits 52
 
@@ -102,9 +107,11 @@
 #elif defined QUAD_PRECISION
 #if __LDBL_MANT_DIG__ == 113 && defined(__SIZEOF_INT128__)
 #define CRT_LDBL_128BIT
+typedef uint64_t half_rep_t;
 typedef __uint128_t rep_t;
 typedef __int128_t srep_t;
 typedef long double fp_t;
+#define HALF_REP_C UINT64_C
 #define REP_C (__uint128_t)
 // Note: Since there is no explicit way to tell compiler the constant is a
 // 128-bit integer, we let the constant be casted to 128-bit integer
Index: compiler-rt/lib/builtins/fp_div_impl.inc
===
--- /dev/null
+++ compiler-rt/lib/builtins/fp_div_impl.inc
@@ -0,0 +1,389 @@
+//===-- fp_div_impl.inc - Floating point division -*- C -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements soft-float division with the IEEE-754 default
+// rounding (to nearest, ties to even).
+//
+//===--===//
+
+#include "fp_lib.h"
+
+// The __divXf3__ function implements Newton-Raphson floating point division.
+// It uses 3 iterations for float32, 4 for float64 and 5 for float128,
+// respectively. Due to number of significant bits being roughly doubled
+// every iteration, the two modes are supported: N full-width iterations (as
+// it is done for float32 by default) and (N-1) half-width iteration plus one
+// final full-width iteration. It is expected that half-width integer
+// operations (w.r.t rep_t size

[PATCH] D86065: [SVE] Make ElementCount members private

2020-08-28 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm added a comment.

In D86065#2241146 , @david-arm wrote:

> Hi @ctetreau, ok for now I'm going to completely remove the operators and 
> revert the code using those operators to how it was before. I'm not sure what 
> you mean about the predicate functions so I've left those for now, since they 
> aren't needed for this patch. The purpose of this patch was originally 
> supposed to be mechanical anyway - just making members private. I only added 
> the operators as an after-thought really, just to be consistent with how 
> TypeSize dealt with the identical problem. For what it's worth, I believe 
> that GCC solved this exact same problem by adding two types of comparison 
> functions - one set that absolutely wanted an answer to ">,<,>=,<=" and 
> asserted if it wasn't known at compile time, and another set of comparison 
> functions that returned an additional boolean value indicating whether the 
> answer was known or not. Perhaps my knowledge is out of date, but I believe 
> this was the accepted solution and seemed to work well.

FWIW, the GCC scheme is to have one set of functions `maybe_` that are 
true if a condition *might* hold (i.e. would hold for one possible value of the 
runtime indeterminates), and another set of functions `known_` 
(originally `must_`) that are true if a condition *always* holds (i.e. 
would hold for all possible values of the runtime indeterminates).  `known_le` 
is a partial order but `maybe_le` is not (because it isn't antisymmetric).  
Having both is redundant with `!`, since e.g. `known_le` is the opposite of 
`maybe_gt`, but it seemed more readable to allow every condition to be 
expressed positively.

Like you say, there is also a test for whether two values are ordered by 
`known_le`, and there are also some operations like `ordered_min` and 
`ordered_max` that assert if the values aren't ordered by `known_le`.

[Sorry for the post-commit comment, but it's related to something that wasn't 
part of the commit.]


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86065

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Nathan James via Phabricator via cfe-commits
njames93 added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:428
 
   case IdentifierNamingCheck::CT_HungarianNotation: {
 const NamedDecl *pNamedDecl = dyn_cast(pDecl);

aaron.ballman wrote:
> I feel like I must be missing something because I don't have this enum in my 
> copy of ToT despite pulling this morning. Is the patch missing some content?
I feel like this is an incremental diff based on the first version of this 
patch rather than a diff from trunk. 


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-28 Thread JF Bastien via Phabricator via cfe-commits
jfb requested changes to this revision.
jfb added a comment.
This revision now requires changes to proceed.
Herald added a subscriber: dexonsmith.

Please consider these changes, and whether this is relevant as implemented: 
http://wg21.link/p0270




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:22
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use C++ constructs in 
signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: C++ construct used here
+  throw "error message";

"C++ construct" isn't particularly useful. Here it needs to call out throwing 
exceptions.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:57
+  // CHECK-MESSAGES: :[[@LINE-11]]:3: note: function called here
+  // CHECK-MESSAGES: :[[@LINE-23]]:3: note: C++ construct used here
+  recursive_function();

Here too, I have no idea what this means given just this message.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:73
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ 
constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: function called here
+  TestClass::static_function();

This is also very confusing.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

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


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-28 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib updated this revision to Diff 288617.
bruntib added a comment.

Update lincense.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.cpp
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
@@ -0,0 +1,133 @@
+// RUN: %check_clang_tidy %s cert-msc54-cpp %t -- -- -std=c++11
+
+namespace std {
+extern "C" using signalhandler = void(int);
+int signal(int sig, signalhandler *func);
+}
+
+#define SIG_ERR -1
+#define SIGTERM 15
+
+static void sig_handler(int sig) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: signal handlers must be 'extern "C"' [cert-msc54-cpp]
+// CHECK-MESSAGES: :[[@LINE+3]]:39: note: given as a signal parameter here
+
+void install_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, sig_handler))
+return;
+}
+
+extern "C" void cpp_signal_handler(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: C++ construct used here
+  throw "error message";
+}
+
+void install_cpp_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, cpp_signal_handler))
+return;
+}
+
+void indirect_recursion();
+
+void cpp_like(){
+  try {
+cpp_signal_handler(SIG_ERR);
+  } catch(...) {
+// handle error
+  }
+}
+
+void no_body();
+
+void recursive_function() {
+  indirect_recursion();
+  cpp_like();
+  no_body();
+  recursive_function();
+}
+
+void indirect_recursion() {
+  recursive_function();
+}
+
+extern "C" void signal_handler_with_cpp_function_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE-11]]:3: note: function called here
+  // CHECK-MESSAGES: :[[@LINE-23]]:3: note: C++ construct used here
+  recursive_function();
+}
+
+void install_signal_handler_with_cpp_function_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_function_call))
+return;
+}
+
+class TestClass {
+public:
+  static void static_function() {}
+};
+
+extern "C" void signal_handler_with_cpp_static_method_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: function called here
+  TestClass::static_function();
+}
+
+void install_signal_handler_with_cpp_static_method_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_static_method_call))
+return;
+}
+
+
+// Something that does not trigger the check:
+
+extern "C" void c_sig_handler(int sig) {
+#define cbrt(X) _Generic((X), long double \
+ : cbrtl, default \
+ : cbrt)(X)
+  auto char c = '1';
+  extern _Thread_local double _Complex d;
+  static const unsigned long int i = sizeof(float);
+  void f();
+  volatile struct c_struct {
+enum e {};
+union u;
+  };
+  typedef bool boolean;
+label:
+  switch (c) {
+  case ('1'):
+break;
+  default:
+d = 1.2;
+  }
+  goto label;
+  for (; i < 42;) {
+if (d == 1.2)
+  continue;
+else
+  return;
+  }
+  do {
+_Atomic int v = _Alignof(char);
+_Static_assert(42 == 42, "True");
+  } while (c == 42);
+}
+
+void install_c_sig_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, c_sig_handler)) {
+// Handle error
+  }
+}
+
+extern "C" void signal_handler_with_function_pointer(int sig) {
+  void (*funp) (void);
+  funp = &cpp_like;
+  funp();
+}
+
+void install_signal_handler_with_function_pointer() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_function_pointer))
+return;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -111,6 +111,7 @@
`cert-mem57-cpp `_,
`cert-msc50-cpp `_,
`cert-msc51-cpp `_,
+   `cert-msc54-cpp `_,
`cert-oop57-cpp `_,
`cert-oop58-cpp `_,
`clang-analyzer-core.DynamicTypePropagation `_,
Index: clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst
==

[PATCH] D86531: [analyzer][StdLibraryFunctionsChecker][NFC] Use Optionals throughout the summary API

2020-08-28 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:1006
+return IntRangeVector{std::pair{b, *e}};
+  return IntRangeVector{};
+}

This return of empty vector and possibility of adding empty vector to range 
constraint is a new thing, probably it is better to check at create of range 
constraint (or other place) for empty range (in this case the summary could be 
made invalid)? But this occurs probably never because the matching type (of the 
max value) should be used at the same function and if the type is there the max 
value should be too.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:1321
 
-Optional Mode_tTy = lookupType("mode_t", ACtx);
+Optional Mode_tTy = lookupTy("mode_t");
 

martong wrote:
> balazske wrote:
> > It is better to get every type at the start before adding functions, or 
> > group the functions and get some types at the start of these groups but 
> > mark the groups at least with comments.
> Well, with looked-up types I followed the usual convention to define a 
> variable right before using it. This means that we lookup a type just before 
> we try to add the function which first uses that type.
> 
> However, builtin types are defined at the beginning, because they are used 
> very often.
I still like it better if all the type variables are created at one place (can 
be more easy to maintain if order changes and we have one block of types and 
one of functions) but this is no reason to block this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86531

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


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-28 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib updated this revision to Diff 288606.
bruntib added a comment.
Herald added a subscriber: mgehre.

I rebased the patch so it compiles with master version of LLVM/Clang. I did no 
other change, so I would like if this patch would be committed on behalf of 
@NorenaLeonetti if the patch is acceptable.
I would kindly ask the reviewers to give some comments if any additional 
modification is needed. I run this checker on DuckDB project and this checker 
gave two reports on functions which shouldn't be used as signal handler:

duckdb-0.2.0/third_party/sqlsmith/sqlsmith.cc:38:17: do not use C++ constructs 
in signal handlers [cert-msc54-cpp]
https://github.com/cwida/duckdb/blob/master/third_party/sqlsmith/sqlsmith.cc#L38

duckdb-0.2.0/tools/shell/shell.c:8828:13: signal handlers must be 'extern "C"' 
[cert-msc54-cpp]
https://github.com/cwida/duckdb/blob/master/tools/shell/shell.c#L8828

I haven't found other C++ projects which use signals. However, this checker 
reports on the non-compliant code fragments of the corresponding SEI-CERT rule: 
https://wiki.sei.cmu.edu/confluence/display/cplusplus/MSC54-CPP.+A+signal+handler+must+be+a+plain+old+function.
 The two findings above also seem to be true positive.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.cpp
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
@@ -0,0 +1,133 @@
+// RUN: %check_clang_tidy %s cert-msc54-cpp %t -- -- -std=c++11
+
+namespace std {
+extern "C" using signalhandler = void(int);
+int signal(int sig, signalhandler *func);
+}
+
+#define SIG_ERR -1
+#define SIGTERM 15
+
+static void sig_handler(int sig) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: signal handlers must be 'extern "C"' [cert-msc54-cpp]
+// CHECK-MESSAGES: :[[@LINE+3]]:39: note: given as a signal parameter here
+
+void install_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, sig_handler))
+return;
+}
+
+extern "C" void cpp_signal_handler(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: C++ construct used here
+  throw "error message";
+}
+
+void install_cpp_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, cpp_signal_handler))
+return;
+}
+
+void indirect_recursion();
+
+void cpp_like(){
+  try {
+cpp_signal_handler(SIG_ERR);
+  } catch(...) {
+// handle error
+  }
+}
+
+void no_body();
+
+void recursive_function() {
+  indirect_recursion();
+  cpp_like();
+  no_body();
+  recursive_function();
+}
+
+void indirect_recursion() {
+  recursive_function();
+}
+
+extern "C" void signal_handler_with_cpp_function_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE-11]]:3: note: function called here
+  // CHECK-MESSAGES: :[[@LINE-23]]:3: note: C++ construct used here
+  recursive_function();
+}
+
+void install_signal_handler_with_cpp_function_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_function_call))
+return;
+}
+
+class TestClass {
+public:
+  static void static_function() {}
+};
+
+extern "C" void signal_handler_with_cpp_static_method_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: function called here
+  TestClass::static_function();
+}
+
+void install_signal_handler_with_cpp_static_method_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_static_method_call))
+return;
+}
+
+
+// Something that does not trigger the check:
+
+extern "C" void c_sig_handler(int sig) {
+#define cbrt(X) _Generic((X), long double \
+ : cbrtl, default \
+ : cbrt)(X)
+  auto char c = '1';
+  extern _Thread_local double _Complex d;
+  static const unsigned long int i = sizeof(float);
+  void f();
+  volatile struct c_struct {
+enum e {};
+union u;
+  };
+  typedef bool boolean;
+label:
+  switch (c) {
+  case ('1'):
+break;
+  default:
+d = 1.2;
+  }
+

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.h:44
   llvm::Optional
-  GetDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
+  getDeclFailureInfo(const StringRef &TypeName, const NamedDecl *Decl,
  const SourceManager &SM) const override;

Given that the other functions in the class use the wrong style of casing, we 
should probably leave this declaration alone so it doesn't become locally 
inconsistent.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:428
 
   case IdentifierNamingCheck::CT_HungarianNotation: {
 const NamedDecl *pNamedDecl = dyn_cast(pDecl);

I feel like I must be missing something because I don't have this enum in my 
copy of ToT despite pulling this morning. Is the patch missing some content?



Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h:69
   llvm::Optional
-  GetDeclFailureInfo(const StringRef &Type, const NamedDecl *Decl,
+  getDeclFailureInfo(const StringRef &Type, const NamedDecl *Decl,
  const SourceManager &SM) const override;

Same here.



Comment at: clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h:127
   virtual llvm::Optional
-  GetDeclFailureInfo(const StringRef &Type, const NamedDecl *Decl,
+  getDeclFailureInfo(const StringRef &Type, const NamedDecl *Decl,
  const SourceManager &SM) const = 0;

And same here.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-28 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib commandeered this revision.
bruntib added a reviewer: NorenaLeonetti.
bruntib added a comment.
Herald added subscribers: martong, steakhal, jfb.

I'll rebase this patch and continue its development.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D33825

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


[PATCH] D67113: ICK_Function_Conversion is a third kind conversion

2020-08-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D67113#2243451 , @aaronpuchert 
wrote:

> Maybe this is to trivial for a review. The comment on 
> `StandardConversionSequence::Third` in clang/Sema/Overload.h says
>
>> The third conversion can be a qualification conversion or a function 
>> conversion.

There may be a deeper issue here in that there are four standard conversion 
sequences, not three: http://eel.is/c++draft/conv#1, but otherwise this change 
seems correct to me (function conversion is certainly not in the first group).

Do you have a test case which can exercise this change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67113

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


[PATCH] D84603: Thread safety analysis: More consistent warning message

2020-08-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Analysis/ThreadSafety.cpp:1644
 if (!LDat) {
-  Analyzer->Handler.handleMutexNotHeld("", D, POK, Cp.toString(),
-   LK_Shared, Loc);
+  Analyzer->Handler.handleMutexNotHeld("negative capability", D, POK,
+   Cp.toString(), LK_Shared, Loc);

aaronpuchert wrote:
> aaron.ballman wrote:
> > aaronpuchert wrote:
> > > aaron.ballman wrote:
> > > > aaronpuchert wrote:
> > > > > aaron.ballman wrote:
> > > > > > It's a bit odd that we aren't using `DiagKind` as below, I assume 
> > > > > > that's because this is a negative test and the others are positive 
> > > > > > tests, but doesn't this introduce a terminology difference where a 
> > > > > > positive failure may call it a mutex and a negative failure may 
> > > > > > call it a negative capability? Should this be hooked in to 
> > > > > > `ClassifyDiagnostic()` (perhaps we need a 
> > > > > > `ClassifyNegativeDiagnostic()`?
> > > > > My thinking was that whatever the positive capability is called, we 
> > > > > should only talk about a "negative capability" instead of a "negative 
> > > > > mutex" or a "negative role". Also because not holding a capability is 
> > > > > in some way its own kind of capability.
> > > > I may still be confused or thinking of this differently, but I would 
> > > > assume that a negative mutex would be a mutex that's explicitly not 
> > > > held, which you may want to ensure on a function boundary to avoid 
> > > > deadlock. From that, I'd have guessed we would want the diagnostic to 
> > > > read `cannot call function 'bar' while mutex 'mu' is held` or `calling 
> > > > function 'bar' requires mutex 'mu' to not be held` because that's more 
> > > > clear than talking about negative capabilities (when the user is 
> > > > thinking in terms of mutexes which are or aren't held).
> > > Now I get it. I don't see an issue with that, but we need to distinguish 
> > > between `EXCLUDES(mu)` and `REQUIRES(!mu)`. The former will produce 
> > > "cannot call function 'bar' while mutex 'mu' is held" and we probably 
> > > want the latter to produce a different warning message.
> > > 
> > > Now one argument for the existing scheme remains that with 
> > > `-Wthread-safety-negative`, if you see a warning like "acquiring mutex 
> > > 'mu' requires negative capability '!mu'" on a lock operation, you know 
> > > you can fix that by adding `REQUIRES(!mu)` to your function.
> > > 
> > > If we say "warning: acquiring mutex 'mu' requires mutex 'mu' not to be 
> > > held" it might not be as clear what we want.
> > > Now I get it. I don't see an issue with that, but we need to distinguish 
> > > between EXCLUDES(mu) and REQUIRES(!mu). The former will produce "cannot 
> > > call function 'bar' while mutex 'mu' is held" and we probably want the 
> > > latter to produce a different warning message.
> > 
> > Ahhh, that's a good point.
> > 
> > > Now one argument for the existing scheme remains that with 
> > > -Wthread-safety-negative, if you see a warning like "acquiring mutex 'mu' 
> > > requires negative capability '!mu'" on a lock operation, you know you can 
> > > fix that by adding REQUIRES(!mu) to your function.
> > >
> > > If we say "warning: acquiring mutex 'mu' requires mutex 'mu' not to be 
> > > held" it might not be as clear what we want.
> > 
> > Hm, that's a good point as well.
> > 
> > Now that I understand the situation a bit better, I will be happy with 
> > either route, so I leave the decision in your capable hands. (If we get it 
> > wrong, we can always change the diagnostics later.) Do you have a preferred 
> > approach?
> There are basically two warnings related to negative capabilities: one is 
> about acquiring a capability without holding a negative capability, the other 
> about calling a function without holding a negative capability. Negative 
> capabilities can't be acquired or released, nor do they protect anything.
> 
> The other warning message also says "negative capability '!mu'", but mentions 
> the original capability kind earlier:
> 
> ```
> def warn_acquire_requires_negative_cap : Warning<
>   "acquiring %0 '%1' requires negative capability '%2'">,
> ```
> 
> I think that makes sense because there is a relation between the "positive" 
> capability of whatever kind that we want to acquire and the negative 
> capability that we need. The situation here is different: I just have some 
> `CallExpr` to a function with `REQUIRES(!...)`.
> 
> For that we have two different warnings, depending on whether we know the 
> capability to be held or not:
> 
> ```
> void foo() REQUIRES(!mu);
> void bar() REQUIRES(!mu) {
>   mu.Lock();
>   foo();// warning: cannot call function 'foo' while mutex 'mu' is 
> held
>   mu.Unlock();
> }
> void baz() {
>   foo();// warning: calling function 'foo' requires holding [negative 
> capability] '!mu'

[PATCH] D86531: [analyzer][StdLibraryFunctionsChecker][NFC] Use Optionals throughout the summary API

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 3 inline comments as done.
martong added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86531

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


[PATCH] D86721: [clang-format] Parse double-square attributes as pointer qualifiers

2020-08-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:8071
   verifyIndependentOfContext("MACRO(A *__attribute((foo)) a);");
+  verifyIndependentOfContext("MACRO(A *[[clang::attr]] a);");
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");

Can you also add a test case for an attribute with an argument list, e.g.,
```
MACRO(A *[[clang::attr("foobar")]] a);
```



Comment at: clang/unittests/Format/FormatTest.cpp:8141
   verifyFormat("x = (foo *_Nonnull)*v;");
+  verifyFormat("x = (foo *[[clang::attr]])*v;");
 

Same for the casting case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86721

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


[PATCH] D72932: [ARM] Follow AACPS standard for volatile bit-fields access width

2020-08-28 Thread Ties Stuij via Phabricator via cfe-commits
stuij added a comment.

@ostannard: pinging on behalf of @dnsampaio. The changes still apply cleanly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72932

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


[PATCH] D86743: [analyzer] Ignore VLASizeChecker case that could cause crash

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

I do not know how these changes can appear:
F12796482: Screenshot from 2020-08-28 16-06-02.png 

The checker makes only 2 assumptions, about the array dimension being positive 
and about the size of the array and the extent. (This state transition happens 
when https://reviews.llvm.org/D81061 is applied, without it the state may look 
even worse.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86743

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


[PATCH] D85031: [builtins] Unify the softfloat division implementation

2020-08-28 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko updated this revision to Diff 288599.
atrosinenko added a comment.

This update is expected to be completely NFC w.r.t. code behavior and 
significantly clarify the proof up to the end of half-width iterations.

Particularly, the reasoning about possible overflow of intermediate results 
turned out to be actually unclear/incorrect.

@sepavloff could you take a look on the new version in case it clarifies some 
of your questions? Another update for the second half of function may follow 
slightly later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85031

Files:
  compiler-rt/lib/builtins/divdf3.c
  compiler-rt/lib/builtins/divsf3.c
  compiler-rt/lib/builtins/divtf3.c
  compiler-rt/lib/builtins/fp_div_impl.inc
  compiler-rt/lib/builtins/fp_lib.h
  compiler-rt/lib/builtins/int_util.h
  compiler-rt/test/builtins/Unit/divdf3_test.c

Index: compiler-rt/test/builtins/Unit/divdf3_test.c
===
--- compiler-rt/test/builtins/Unit/divdf3_test.c
+++ compiler-rt/test/builtins/Unit/divdf3_test.c
@@ -92,5 +92,13 @@
 if (test__divdf3(0x1.0p+0, 0x1.0001p+0, UINT64_C(0x3fefffe0)))
   return 1;
 
+// some misc test cases obtained by fuzzing against h/w implementation
+if (test__divdf3(0x1.fdc239dd64735p-658, -0x1.fff9364c0843fp-948, UINT64_C(0xd20fdc8fc0ceffb1)))
+  return 1;
+if (test__divdf3(-0x1.78abb261d47c8p+794, 0x1.fb01d537cc5aep+266, UINT64_C(0xe0e7c6148ffc23e3)))
+  return 1;
+if (test__divdf3(-0x1.da7dfe6048b8bp-875, 0x1.ffc7ea3ff60a4p-610, UINT64_C(0xaf5dab1fe0269e2a)))
+  return 1;
+
 return 0;
 }
Index: compiler-rt/lib/builtins/int_util.h
===
--- compiler-rt/lib/builtins/int_util.h
+++ compiler-rt/lib/builtins/int_util.h
@@ -28,4 +28,20 @@
 #define COMPILE_TIME_ASSERT2(expr, cnt)\
   typedef char ct_assert_##cnt[(expr) ? 1 : -1] UNUSED
 
+// Force unrolling the code specified to be repeated N times.
+#define REPEAT_0_TIMES(code_to_repeat) /* do nothing */
+#define REPEAT_1_TIMES(code_to_repeat) code_to_repeat
+#define REPEAT_2_TIMES(code_to_repeat) \
+  REPEAT_1_TIMES(code_to_repeat)   \
+  code_to_repeat
+#define REPEAT_3_TIMES(code_to_repeat) \
+  REPEAT_2_TIMES(code_to_repeat)   \
+  code_to_repeat
+#define REPEAT_4_TIMES(code_to_repeat) \
+  REPEAT_3_TIMES(code_to_repeat)   \
+  code_to_repeat
+
+#define REPEAT_N_TIMES_(N, code_to_repeat) REPEAT_##N##_TIMES(code_to_repeat)
+#define REPEAT_N_TIMES(N, code_to_repeat) REPEAT_N_TIMES_(N, code_to_repeat)
+
 #endif // INT_UTIL_H
Index: compiler-rt/lib/builtins/fp_lib.h
===
--- compiler-rt/lib/builtins/fp_lib.h
+++ compiler-rt/lib/builtins/fp_lib.h
@@ -40,9 +40,12 @@
 
 #if defined SINGLE_PRECISION
 
+typedef uint16_t half_rep_t;
 typedef uint32_t rep_t;
+typedef uint64_t twice_rep_t;
 typedef int32_t srep_t;
 typedef float fp_t;
+#define HALF_REP_C UINT16_C
 #define REP_C UINT32_C
 #define significandBits 23
 
@@ -58,9 +61,11 @@
 
 #elif defined DOUBLE_PRECISION
 
+typedef uint32_t half_rep_t;
 typedef uint64_t rep_t;
 typedef int64_t srep_t;
 typedef double fp_t;
+#define HALF_REP_C UINT32_C
 #define REP_C UINT64_C
 #define significandBits 52
 
@@ -102,9 +107,11 @@
 #elif defined QUAD_PRECISION
 #if __LDBL_MANT_DIG__ == 113 && defined(__SIZEOF_INT128__)
 #define CRT_LDBL_128BIT
+typedef uint64_t half_rep_t;
 typedef __uint128_t rep_t;
 typedef __int128_t srep_t;
 typedef long double fp_t;
+#define HALF_REP_C UINT64_C
 #define REP_C (__uint128_t)
 // Note: Since there is no explicit way to tell compiler the constant is a
 // 128-bit integer, we let the constant be casted to 128-bit integer
Index: compiler-rt/lib/builtins/fp_div_impl.inc
===
--- /dev/null
+++ compiler-rt/lib/builtins/fp_div_impl.inc
@@ -0,0 +1,378 @@
+//===-- fp_div_impl.inc - Floating point division -*- C -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements soft-float division with the IEEE-754 default
+// rounding (to nearest, ties to even).
+//
+//===--===//
+
+#include "fp_lib.h"
+
+// The __divXf3__ function implements Newton-Raphson floating point divis

[PATCH] D72705: [analyzer] Added new checker 'alpha.unix.ErrorReturn'.

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D72705#2238487 , @Szelethus wrote:

> I debated this 
> 
>  report with @bruntib, depending from where you look at it, its either a 
> false positive or not -- in short, this is what happens:
>
>   char *p = /* some assumed to be valid c string */
>   end = strchr(p, '\n');
>   if (end - p > 4) { // <-- warning here on end's invalid use
>   }
>
> the guarded code wouldn't be executed, should `end` be zero. Now, if we 
> interpret the rule in a very literal sense, that
>
>> The successful completion or failure of each of the standard library 
>> functions listed in the following table shall be determined either by 
>> comparing the function’s return value with the value listed in the column 
>> labeled “Error Return” or by calling one of the library functions mentioned 
>> in the footnotes.
>
> then indeed, it doesn't compare the return value with the item in the table, 
> but it does compare it with superset of it. Now, we can either say that
>
> 1. A superset isn't good enough, because its a sign of code smell, or
> 2. Judge that the user probably did handle the error case, albeit in an 
> unconventional way, and report like these don't provide any value.
>
> I don't think we can realistically pursue point (2.). We would need to widen 
> the context (by going further up the AST with `Stmt::getParent()`) we're 
> considering for a potential check. However, forming a non-checking expression 
> that we don't immediately report can quickly get out of control:
>
>   char *p = /* some assumed to be valid c string */;
>   end = strchr(p, '\n');
>   int result = end - p;
>   if (result > 4) {
>   }
>
> You would be right to believe, without context from the code that is yet to 
> be executed, that the computation of `result` is invalid, because `end` is 
> unchecked. However, the code complies with the rule interpreted by (2.). This 
> seems to be a problem that can have infinite complexity without very severe 
> restriction on the analysis. Indeed, if we wander too far from the original 
> function call (by creating values that descend from the return value to be 
> checked), being sure that no checks happened (by point 2.) quickly becomes 
> unmanageable.
>
> So, for all practical purposes, we're locked to option (1.). However, the 
> warning message this way is imprecise -- we're **not** enforcing whether the 
> error value was checked for error, we're enforcing whether the return value 
> was checked against its respective failure value, and the message should 
> reflect that. In fact, the checker description, and some comments should be 
> clarified in this regard as well.
>
> I would imagine the pool of functions that deserve such incredibly strict 
> enforcement is rather small. Time management, maybe, but certainly not string 
> modeling functions, because problems related to them are solved by a 
> completely different checker infrastructure (`CStringChecker`), just as 
> stream modeling functions and memory management. Maybe we should only look 
> for statement-local bugs (basically a discarded return value) for functions 
> that don't demand this rigidness, but I suspect there is a clang-tidy check 
> already out there doing it. Seems like I got what @NoQ meant here.
>
> In D72705#2088319 , @NoQ wrote:
>
>> I still don't understand how do we enable this checker, i.e. for whom and 
>> how often. Is there anything we'll be able to turn on by default, like maybe 
>> warn on all functions that wear `__attribute__((warn_unused_result))`?
>
>
>
> ---
>
> I'm very happy we got another round of evaluations, we've gotten some 
> invaluable information out of it. For future patches, it would be great to 
> have your input on at least some of the reports as you're publishing them. 
> For the latest project, I think there is clear intent from the developer to 
> avoid null pointer misuses -- you should justify why a report is still 
> appropriate there.
>
> You mentioned in D72705#2187556  
> that on `duckdb` you stumbled across 1-2 false positives, but also that you 
> found 23 reports, and that you ran the checker on `vim`. This may be okay for 
> an alpha checker, or maybe not, if it points to a fundamental problem in your 
> approach. Please publish them before updating the patch. If all goes well and 
> those cases could be patched up later, here are the next important steps:
>
> - Have a warning message that precisely states what, and how the rule was 
> violated, even if its done with placeholders, even if you only 

[PATCH] D86065: [SVE] Make ElementCount members private

2020-08-28 Thread David Sherwood via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf4257c5832aa: [SVE] Make ElementCount members private 
(authored by david-arm).

Changed prior to commit:
  https://reviews.llvm.org/D86065?vs=288370&id=288594#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86065

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  llvm/include/llvm/Analysis/TargetTransformInfo.h
  llvm/include/llvm/Analysis/VectorUtils.h
  llvm/include/llvm/CodeGen/ValueTypes.h
  llvm/include/llvm/IR/DataLayout.h
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/include/llvm/IR/Instructions.h
  llvm/include/llvm/Support/MachineValueType.h
  llvm/include/llvm/Support/TypeSize.h
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/Analysis/VFABIDemangling.cpp
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/lib/CodeGen/ValueTypes.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ConstantFold.cpp
  llvm/lib/IR/Constants.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/IRBuilder.cpp
  llvm/lib/IR/Instructions.cpp
  llvm/lib/IR/IntrinsicInst.cpp
  llvm/lib/IR/Type.cpp
  llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
  llvm/lib/Transforms/Utils/FunctionComparator.cpp
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/lib/Transforms/Vectorize/VPlan.cpp
  llvm/lib/Transforms/Vectorize/VPlan.h
  llvm/unittests/CodeGen/ScalableVectorMVTsTest.cpp
  llvm/unittests/IR/VectorTypesTest.cpp

Index: llvm/unittests/IR/VectorTypesTest.cpp
===
--- llvm/unittests/IR/VectorTypesTest.cpp
+++ llvm/unittests/IR/VectorTypesTest.cpp
@@ -119,8 +119,8 @@
   EXPECT_EQ(ConvTy->getElementType()->getScalarSizeInBits(), 64U);
 
   EltCnt = V8Int64Ty->getElementCount();
-  EXPECT_EQ(EltCnt.Min, 8U);
-  ASSERT_FALSE(EltCnt.Scalable);
+  EXPECT_EQ(EltCnt.getKnownMinValue(), 8U);
+  ASSERT_FALSE(EltCnt.isScalable());
 }
 
 TEST(VectorTypesTest, Scalable) {
@@ -215,8 +215,8 @@
   EXPECT_EQ(ConvTy->getElementType()->getScalarSizeInBits(), 64U);
 
   EltCnt = ScV8Int64Ty->getElementCount();
-  EXPECT_EQ(EltCnt.Min, 8U);
-  ASSERT_TRUE(EltCnt.Scalable);
+  EXPECT_EQ(EltCnt.getKnownMinValue(), 8U);
+  ASSERT_TRUE(EltCnt.isScalable());
 }
 
 TEST(VectorTypesTest, BaseVectorType) {
@@ -250,7 +250,7 @@
 // test I == J
 VectorType *VI = VTys[I];
 ElementCount ECI = VI->getElementCount();
-EXPECT_EQ(isa(VI), ECI.Scalable);
+EXPECT_EQ(isa(VI), ECI.isScalable());
 
 for (size_t J = I + 1, JEnd = VTys.size(); J < JEnd; ++J) {
   // test I < J
Index: llvm/unittests/CodeGen/ScalableVectorMVTsTest.cpp
===
--- llvm/unittests/CodeGen/ScalableVectorMVTsTest.cpp
+++ llvm/unittests/CodeGen/ScalableVectorMVTsTest.cpp
@@ -71,8 +71,8 @@
 
   // Check fields inside llvm::ElementCount
   EltCnt = Vnx4i32.getVectorElementCount();
-  EXPECT_EQ(EltCnt.Min, 4U);
-  ASSERT_TRUE(EltCnt.Scalable);
+  EXPECT_EQ(EltCnt.getKnownMinValue(), 4U);
+  ASSERT_TRUE(EltCnt.isScalable());
 
   // Check that fixed-length vector types aren't scalable.
   EVT V8i32 = EVT::getVectorVT(Ctx, MVT::i32, 8);
@@ -82,8 +82,8 @@
 
   // Check that llvm::ElementCount works for fixed-length types.
   EltCnt = V8i32.getVectorElementCount();
-  EXPECT_EQ(EltCnt.Min, 8U);
-  ASSERT_FALSE(EltCnt.Scalable);
+  EXPECT_EQ(EltCnt.getKnownMinValue(), 8U);
+  ASSERT_FALSE(EltCnt.isScalable());
 }
 
 TEST(ScalableVectorMVTsTest, IRToVTTranslation) {
Index: llvm/lib/Transforms/Vectorize/VPlan.h
===
--- llvm/lib/Transforms/Vectorize/VPlan.h
+++ llvm/lib/Transforms/Vectorize/VPlan.h
@@ -151,14 +151,15 @@
   /// \return True if the map has a scalar entry for \p Key and \p Instance.
   bool hasScalarValue(Value *Key, const VPIteration &Instance) const {
 assert(Instance.Part < UF && "Queried Scalar Part is too large.");
-assert(Instance.Lane < VF.Min && "Queried Scalar Lane is too large.");
-assert(!VF.Scalable && "VF is assumed to be non scalable.");
+assert(Instance.Lane < VF.getKnownMinValue() &&
+   "Queried Scalar Lane is too large.");
+assert(!VF.isScalable() && "VF is assumed to be non scalable.");
 
 if (!hasAnyScalarValue(Key))
   return false;
 const ScalarParts &Entry = ScalarMapStorage.find(Key)->second;
 assert(Entry.size() == UF && "ScalarParts has wrong dimensions.");
-assert(Entry[Instance.Part].size() ==

[clang] f4257c5 - [SVE] Make ElementCount members private

2020-08-28 Thread David Sherwood via cfe-commits

Author: David Sherwood
Date: 2020-08-28T14:43:53+01:00
New Revision: f4257c5832aa51e960e7351929ca3d37031985b7

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

LOG: [SVE] Make ElementCount members private

This patch changes ElementCount so that the Min and Scalable
members are now private and can only be accessed via the get
functions getKnownMinValue() and isScalable(). In addition I've
added some other member functions for more commonly used operations.
Hopefully this makes the class more useful and will reduce the
need for calling getKnownMinValue().

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

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CGDebugInfo.cpp
clang/lib/CodeGen/CodeGenTypes.cpp
llvm/include/llvm/Analysis/TargetTransformInfo.h
llvm/include/llvm/Analysis/VectorUtils.h
llvm/include/llvm/CodeGen/ValueTypes.h
llvm/include/llvm/IR/DataLayout.h
llvm/include/llvm/IR/DerivedTypes.h
llvm/include/llvm/IR/Instructions.h
llvm/include/llvm/Support/MachineValueType.h
llvm/include/llvm/Support/TypeSize.h
llvm/lib/Analysis/InstructionSimplify.cpp
llvm/lib/Analysis/VFABIDemangling.cpp
llvm/lib/Analysis/ValueTracking.cpp
llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
llvm/lib/CodeGen/CodeGenPrepare.cpp
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/lib/CodeGen/TargetLoweringBase.cpp
llvm/lib/CodeGen/ValueTypes.cpp
llvm/lib/IR/AsmWriter.cpp
llvm/lib/IR/ConstantFold.cpp
llvm/lib/IR/Constants.cpp
llvm/lib/IR/Core.cpp
llvm/lib/IR/DataLayout.cpp
llvm/lib/IR/Function.cpp
llvm/lib/IR/IRBuilder.cpp
llvm/lib/IR/Instructions.cpp
llvm/lib/IR/IntrinsicInst.cpp
llvm/lib/IR/Type.cpp
llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
llvm/lib/Transforms/Utils/FunctionComparator.cpp
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
llvm/lib/Transforms/Vectorize/VPlan.cpp
llvm/lib/Transforms/Vectorize/VPlan.h
llvm/unittests/CodeGen/ScalableVectorMVTsTest.cpp
llvm/unittests/IR/VectorTypesTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 69899fd8e668..1192fbdc1c9d 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -8457,7 +8457,8 @@ Value 
*CodeGenFunction::EmitAArch64SVEBuiltinExpr(unsigned BuiltinID,
   case SVE::BI__builtin_sve_svlen_u64: {
 SVETypeFlags TF(Builtin->TypeModifier);
 auto VTy = cast(getSVEType(TF));
-auto NumEls = llvm::ConstantInt::get(Ty, VTy->getElementCount().Min);
+auto *NumEls =
+llvm::ConstantInt::get(Ty, VTy->getElementCount().getKnownMinValue());
 
 Function *F = CGM.getIntrinsic(Intrinsic::vscale, Ty);
 return Builder.CreateMul(NumEls, Builder.CreateCall(F));

diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index d90cffb4bb95..8a85a24910e4 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -726,7 +726,7 @@ llvm::DIType *CGDebugInfo::CreateType(const BuiltinType 
*BT) {
 {
   ASTContext::BuiltinVectorTypeInfo Info =
   CGM.getContext().getBuiltinVectorTypeInfo(BT);
-  unsigned NumElemsPerVG = (Info.EC.Min * Info.NumVectors) / 2;
+  unsigned NumElemsPerVG = (Info.EC.getKnownMinValue() * Info.NumVectors) 
/ 2;
 
   // Debuggers can't extract 1bit from a vector, so will display a
   // bitpattern for svbool_t instead.

diff  --git a/clang/lib/CodeGen/CodeGenTypes.cpp 
b/clang/lib/CodeGen/CodeGenTypes.cpp
index 9c072d416075..aede8a53ba90 100644
--- a/clang/lib/CodeGen/CodeGenTypes.cpp
+++ b/clang/lib/CodeGen/CodeGenTypes.cpp
@@ -586,7 +586,8 @@ llvm::Type *CodeGenTypes::ConvertType(QualType T) {
   ASTContext::BuiltinVectorTypeInfo Info =
   Context.getBuiltinVectorTypeInfo(cast(Ty));
   return llvm::ScalableVectorType::get(ConvertType(Info.ElementType),
-   Info.EC.Min * Info.NumVectors);
+   Info.EC.getKnownMinValue() *
+   Info.NumVectors);
 }
 case BuiltinType::Dependent:
 #define BUILTIN_TYPE(Id, SingletonId)

diff  --git a/llvm/include/llvm/Analysis/TargetTransformInfo.h 
b/llvm/include/llvm/Analysis/TargetTransformInfo.h
index a3e624842700..ffbec74c61d0 100644
--- a/llvm/include/llvm/Analysis/TargetTransformInfo.h
+++ b/llvm/include/llvm/Analysis/TargetTransformInfo.h
@@ -130,8 +130,8 @@ class IntrinsicCostAttributes {
   unsigned Fact

[PATCH] D72705: [analyzer] Added new checker 'alpha.unix.ErrorReturn'.

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> Another solution for the problem is if the system calls are modeled in a way 
> that there is always a state split between error end non-error (we will have 
> a path where it is known that the specific variable can be only (for example) 
> NULL and this can be detected by other checkers).

I think this approach could be easily modeled in `StdLibraryFunctionCheckers` 
with the form of `Cases` (branches). E.g. 
https://github.com/llvm/llvm-project/blob/f20e6c7253859454c2f39adae19d80a31a0456a9/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp#L1139

Also, Comments about the branches: 
https://github.com/llvm/llvm-project/blob/f20e6c7253859454c2f39adae19d80a31a0456a9/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp#L13


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72705

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


[PATCH] D86751: Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace.

2020-08-28 Thread Samuel Benzaquen via Phabricator via cfe-commits
sbenza accepted this revision.
sbenza added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/Parser/compound-token-split.cpp:30
+
+[ // expected-warning-re ^}}'[' tokens introducing attribute appear in 
different source files}}
+#define LSQUARE

Does this count as a "different" source file?
Or is it just an implementation detail of how clang uses FileIDs ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86751

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


[PATCH] D86743: [analyzer] Ignore VLASizeChecker case that could cause crash

2020-08-28 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers added a comment.

Thanks Balazs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86743

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

In D86671#2244236 , @dougpuob wrote:

> In D86671#2243788 , @Eugene.Zelenko 
> wrote:
>
>> It'll be good idea to add test case.
>
> Hi @Eugene.Zelenko,
> I have created a `readability-identifier-naming-hungarain-notion.cpp`  file 
> and several test cases for regression testing. Is it regression testing?
>
> Find it here (https://reviews.llvm.org/differential/changeset/?ref=2137882)

Yes, this is regression test. Please add newline at the end.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86736: [analyzer][NFC] Don't bind values to ObjCForCollectionStmt, replace it with a GDM trait

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> For any other loops, in order to know whether we should analyze another 
> iteration, among other things, we evaluate it's condition. Which is a problem 
> for ObjCForCollectionStmt, because it simply doesn't have one

Shouldn't we try to fix the ObjCForCollectionStmt in the AST rather? By adding 
the condition to that as a (sub)expression? There are already many 
discrepancies and inconsistencies between supposedly similar AST nodes, and 
people do fix them occasionally (e.g. D81787 ).
To be honest, it seems a bit off to store some parts of the liveness info in 
the GDM while other parts not in the GDM ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86736

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


[PATCH] D86782: [clang-format] Allow configuring list of macros that map to attributes

2020-08-28 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added reviewers: MyDeveloperDay, JakeMerdichAMD, sammccall, 
curdeius, jrtc27.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
arichardson requested review of this revision.

This adds a `AttributeMacros` configuration option that causes certain
identifiers to be parsed like a __attribute__((foo)) annotation.
This is motivated by our CHERI C/C++ fork which adds a __capability
qualifier for pointer/reference. Without this change clang-format parses
many type declarations as multiplications/bitwise-and instead.
I initially considered adding "__capability" as a new clang-format keyword,
but having a list of macros that should be treated as attributes is more
flexible since it can be used e.g. for static analyzer annotations or other 
language
extensions.

Example: std::vector -> std::vector

Depends on D86775  (to apply cleanly)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86782

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8030,7 +8030,20 @@
   verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  FormatStyle CustomQualifier = getLLVMStyle();
+  // Add indentifers that should not be parsed as a qualifier by default.
+  CustomQualifier.AttributeMacros.push_back("__my_qualifier");
+  CustomQualifier.AttributeMacros.push_back("_My_qualifier");
+  CustomQualifier.AttributeMacros.push_back("my_other_qualifier");
+  verifyFormat("vector parse_as_multiply;");
+  verifyFormat("vector v;", CustomQualifier);
+  verifyFormat("vector parse_as_multiply;");
+  verifyFormat("vector v;", CustomQualifier);
+  verifyFormat("vector parse_as_multiply;");
+  verifyFormat("vector v;", CustomQualifier);
   verifyFormat("vector v;");
+  verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("foo();");
   verifyFormat("foo();");
@@ -8073,10 +8086,23 @@
   verifyIndependentOfContext("MACRO(A *[[clang::attr]] a);");
   verifyIndependentOfContext("MACRO(A *__ptr32 a);");
   verifyIndependentOfContext("MACRO(A *__ptr64 a);");
+  verifyIndependentOfContext("MACRO(A *__capability);");
+  verifyIndependentOfContext("MACRO(A &__capability);");
+  verifyFormat("MACRO(A *__my_qualifier);"); // type declaration
+  verifyFormat("void f() { MACRO(A * __my_qualifier); }"); // multiplication
+  // If we add __my_qualifier to AttributeMacros it should always be parsed as
+  // a type declaration:
+  verifyFormat("MACRO(A *__my_qualifier);", CustomQualifier);
+  verifyFormat("void f() { MACRO(A *__my_qualifier); }", CustomQualifier);
+
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");
   verifyFormat("void f() { f(float{1}, a * a); }");
   // FIXME: Is there a way to make this work?
   // verifyIndependentOfContext("MACRO(A *a);");
+  verifyFormat("MACRO(A &B);");
+  verifyFormat("MACRO(A *B);");
+  verifyFormat("void f() { MACRO(A * B); }");
+  verifyFormat("void f() { MACRO(A & B); }");
 
   verifyFormat("DatumHandle const *operator->() const { return input_; }");
   verifyFormat("return options != nullptr && operator==(*options);");
@@ -8126,10 +8152,47 @@
   verifyFormat("a __attribute__((unused))\n"
"aaa(int i);");
   FormatStyle AfterType = getLLVMStyle();
-  AfterType.AlwaysBreakAfterReturnType = FormatStyle::RTBS_AllDefinitions;
+  AfterType.AlwaysBreakAfterReturnType = FormatStyle::RTBS_All;
   verifyFormat("__attribute__((nodebug)) void\n"
"foo() {}\n",
AfterType);
+  verifyFormat("__unused void\n"
+   "foo() {}",
+   AfterType);
+
+  FormatStyle CustomAttrs = getLLVMStyle();
+  CustomAttrs.AttributeMacros.push_back("__unused");
+  CustomAttrs.AttributeMacros.push_back("__attr1");
+  CustomAttrs.AttributeMacros.push_back("__attr2");
+  CustomAttrs.AttributeMacros.push_back("no_underscore_attr");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  // Check that it is parsed as a multiplication without AttributeMacros and
+  // as a pointer qualifier when we add __user to AttributeMacros.
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;", CustomAttrs);
+  verifyFormat("vector v;", CustomAttrs);
+  verifyFormat("vector v;", CustomAttrs);
+  verifyFormat("vector v;", CustomAttrs);
+  verifyFormat("vector v;", CustomAttrs);
+  verifyFormat("vector v;", 

[PATCH] D86660: Modifying ImportDeclContext(...) to ensure that we also handle the case when the FieldDecl is an ArrayType whose ElementType is a RecordDecl

2020-08-28 Thread Pavel Labath via Phabricator via cfe-commits
labath added a comment.

I'm going to respond to the rest of your (very insightful) comment later. So 
far, I'm just responding to this:

>>   This isn't exactly layout related, but there is the question of covariant 
>> methods. If a method is covariant, then its return type must be complete.
>
> We already import all the base classes of a derived class (at least in full 
> import). But, we do not import all the derived classes during the import of 
> the base. Is this what you do in LLDB to support covariant return types?

This situation is a bit tricky to explain as there are two independent class 
hierarchies that need to be considered. Let me start with an example:

  struct B1;
  struct B2;
  struct A1 { B1 *f(); };
  struct A2 { B2 *f(); };

This is a perfectly valid C++ snippet. In fact it could be extended to also 
implement `A1::f` and `A2::f` and call them and it would still not require the 
definitions for structs `B1` and `B2`. And I believe the ast importer will 
would not import their definitions even if they were available. It certainly 
wouldn't force them to be defined (`getExternalSource()->CompleteType(B1)`).

This changes if the methods become virtual. In this case, this code becomes 
valid only if `B2*` is convertible to `B1*` (i.e., `B2` is derived from `B1`). 
To know that, both `B1` and `B2` have to be complete. Regular clang parser will 
enforce that, and codegen will depend on it. However, the AST importer will not 
automatically import these classes. Lldb's code to do that is here 
https://github.com/llvm/llvm-project/blob/fdc6aea3fd822b639baaa5b666fdf7598d08c8de/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp#L994.

I don't know whether something like this would be in scope for the default ast 
importer, but it seemed useful to mention in the context of the present 
discussion.


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

https://reviews.llvm.org/D86660

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


[PATCH] D86135: [analyzer][MacroExpansion] Fix a crash where multiple parameters resolved to __VA_ARGS__

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D86135#2235473 , @Szelethus wrote:

> In D86135#2233611 , @martong wrote:
>
>>> The fundamental problem is, we simply can't ask Preprocessor what a macro 
>>> expands into without hacking really hard.
>>
>> Can you summarize what is the exact problem (or give a link to a discussion, 
>> etc)? Is it an architectural problem in Clang itself?
>
> I phrased myself poorly. The Preprocessor can tell what a macro usage 
> immediately expands into (otherwise this project would have been practically 
> impossible to implement), what it struggles to get done is show what a macro 
> usage in the source code turns into in the preprocessed translation unit. As 
> is often the case, macros may be nested into one another:
>
>   #define MACRO2(ptr) ptr = 0
>   #define MACRO1(x) MACRO2(x)
>   
>   int *a = get();
>   MACRO1(a); // Step 1. Expand MACRO1.
>  //a.) Retrieve the tokens defined for MACRO1.
>  //b.) Resolve parameter x to argument a.
>  // Step 2. Expand MACRO2...
>   *a = 5;
>
> From this code snippet, should we be interested in what `MACRO1(a)` expands 
> into, `Preprocessor` can pretty much only deliver on point 1a.) with any 
> convenience. The problem here is that it was simply never engineered to be 
> used outside of the preprocessing stage, so much so, that by the time I 
> worked on this project about a decade after `Preprocessor`'s inception, I 
> still had to turn super trivial methods const. Other than that, the 
> discussions I linked in the summary is pretty much all I can offer.
>
>> Could we somehow refactor Clang and the Preprocessor to be usable for us? I 
>> mean LLVM and Clang has the mindset to build reusable components, the 
>> Preprocessor (and the Sema) should be one of them too, not just the AST.
>
> Working with the `Preprocessor` seems incredibly tedious and error prone -- 
> mind that this is almost literally the first thing we implemented in Clang, 
> and you can tell. Also, its performance critical, and any meaningful 
> performance impact may need strong justification. While it would be 
> beneficial to have the knowledge I'm crafting being integrated into the 
> actual class, its hard to justify all the effort it would take to do so, 
> especially now this project is so far along anyways. If I has to start from 
> scratch, I would try to explore other approaches, but might still end up just 
> doing what I did here.
>
> In D86135#2233695 , @xazax.hun wrote:
>
>> Is this related to https://bugs.llvm.org/show_bug.cgi?id=44493?
>
> To some extent, but this patch unfortunately doesn't solve that bug. The 
> problem I think is that named variadic macros aren't supported at all.

Thanks, for the detailed explanation, makes it easier to understand the reasons!




Comment at: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1227
+  if (TheTok.getIdentifierInfo() == __VA_ARGS__II) {
+TStream.injectRange(PrevParamMap.at(__VA_ARGS__II));
+TStream.next(TheTok);

Why do we have to push back the tokens in case of __VA_ARGS? And what is in 
PrevParamMap here. Is it possible that `at` can fail here? Perhaps an example 
could make this hunk way easier to understand. To be honest, this hunk is a 
mystique for me in this form. 


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

https://reviews.llvm.org/D86135

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


[PATCH] D86743: [analyzer] Ignore VLASizeChecker case that could cause crash

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

The fix is probably OK but I could not find out what causes the problem in this 
case and not in other (similar) ones.
Why is not possible to assume `SVB.evalEQ(State, DynSize, *ArraySizeNL)` to 
true:
DynSize: `extent_$1{e}`
*ArraySizeNL: `8 U64b`
The problem occurs likely not at the first iteration of the loop. Probably 
something is "messed up" in the state.




Comment at: clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp:304
+// See https://bugs.llvm.org/show_bug.cgi?id=47272.
+if (!State)
+  return;

If the previous assumption fails the assumptions made before it (about size of 
array dimensions) can be applied. Like at line 284 a transition should be 
added. At least if the current state indicates not a problem that makes this 
unnecessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86743

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


[PATCH] D86135: [analyzer][MacroExpansion] Fix a crash where multiple parameters resolved to __VA_ARGS__

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:896-898
+RawLexer.reset(new Lexer(SM.getLocForStartOfFile(LocInfo.first), LangOpts,
+ MB->getBufferStart(), MacroNameTokenPos,
+ MB->getBufferEnd()));

Szelethus wrote:
> steakhal wrote:
> > I'm always puzzled if I see a naked `new`.
> > Couldn't we use the assignment operator and `std::make_unique` here?
> Wait, isn't it naked if its //not// surrounded by smart pointer stuff? In any 
> case, explicit calls to operator `new` and `delete` are indeed discouraged by 
> the 
> [[http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r11-avoid-calling-new-and-delete-explicitly
>  | core guidelines]].
It is not enough to call a smart pointer's constructor with a result of a naked 
new. Because after the allocation of the object, the object's constructor 
itself could throw (well, not in LLVM :D) and this could happen before 
acquiring the ownership by the smart pointer, bumm, we have a leak.


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

https://reviews.llvm.org/D86135

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


[PATCH] D86780: Copy blocks in variadic methods

2020-08-28 Thread 酷酷的哀殿 via Phabricator via cfe-commits
sunbohong created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
sunbohong requested review of this revision.

This commit will fix https://bugs.llvm.org/show_bug.cgi?id=46399.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86780

Files:
  clang/lib/Sema/SemaExprObjC.cpp


Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -1777,6 +1777,17 @@
 }
   }
 
+  for (unsigned i = NumNamedArgs, e = Args.size(); i < e; ++i) {
+if (Args[i]->isTypeDependent())
+  continue;
+// copy blocks [NSArray arrayWithObjects:^(){NSLog(@"blk0:%d", 
val);},^(){NSLog(@"blk1:%d", val);}, nil];
+if (Args[i]->getType()->isBlockPointerType()) {
+  ExprResult arg = Args[i];
+  maybeExtendBlockObject(arg);
+  Args[i] = arg.get();
+}
+  }
+
   DiagnoseSentinelCalls(Method, SelLoc, Args);
 
   // Do additional checkings on method.


Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -1777,6 +1777,17 @@
 }
   }
 
+  for (unsigned i = NumNamedArgs, e = Args.size(); i < e; ++i) {
+if (Args[i]->isTypeDependent())
+  continue;
+// copy blocks [NSArray arrayWithObjects:^(){NSLog(@"blk0:%d", val);},^(){NSLog(@"blk1:%d", val);}, nil];
+if (Args[i]->getType()->isBlockPointerType()) {
+  ExprResult arg = Args[i];
+  maybeExtendBlockObject(arg);
+  Args[i] = arg.get();
+}
+  }
+
   DiagnoseSentinelCalls(Method, SelLoc, Args);
 
   // Do additional checkings on method.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86660: Modifying ImportDeclContext(...) to ensure that we also handle the case when the FieldDecl is an ArrayType whose ElementType is a RecordDecl

2020-08-28 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:1755-1759
+  QualType FromTy = ArrayFrom->getElementType();
+  QualType ToTy = ArrayTo->getElementType();
+
+  FromRecordDecl = FromTy->getAsRecordDecl();
+  ToRecordDecl = ToTy->getAsRecordDecl();

labath wrote:
> shafik wrote:
> > martong wrote:
> > > labath wrote:
> > > > What about 2- or n-dimensional arrays?
> > > @labath, this is a very good question! And made me realize that D71378 is 
> > > fundamentally flawed (@shafik, please take no offense). Let me explain.
> > > 
> > > So, with D71378, we added the `if (ImportedOrErr) { ... }` block to 
> > > import definitions specifically of fields' Record types. But we forget to 
> > > handle arrays. Now we may forget to handle multidimensional arrays ... 
> > > and we may forget to handle other language constructs. So, we would 
> > > finally end up in re-implementing the logic of 
> > > `ASTNodeImporter::VisitFieldDecl`.
> > > 
> > > So all this should have been handled properly by the preceding import 
> > > call of the FieldDecl! Here
> > > ```
> > > 1735: ExpectedDecl ImportedOrErr = import(From);
> > > ```
> > > I have a suspicion that real reason why this import call fails in case of 
> > > the public ASTImporter::ImportDefinition() is that we fail to drive 
> > > through the import kind (`IDK_Everything`) during the import process.
> > > Below we set IDK_Everything and start a complete import process.
> > > ```
> > >   8784   if (auto *ToRecord = dyn_cast(To)) {
> > >   8785 if (!ToRecord->getDefinition()) {
> > >   8786   return Importer.ImportDefinition(   // 
> > > ASTNodeImporter::ImportDefinition !
> > >   8787   cast(FromDC), ToRecord,
> > >   8788   ASTNodeImporter::IDK_Everything);
> > >   8789 }
> > >   8790   }
> > > ```
> > > However, there may be many places where we fail to channel through that 
> > > we want to do a complete import. E.g here
> > > ```
> > > 1957   
> > > ImportDefinitionIfNeeded(Base1.getType()->getAsCXXRecordDecl()))
> > > ```
> > > we do another definition import and IDK_Everything is not set. So we may 
> > > have a wrong kind of import since the "minimal" flag is set.
> > > 
> > > The thing is, it is really confusing and error-prone to have both the 
> > > `ASTImporter::Minimal` flag and the `ImportDefinitionKind`. They seem to 
> > > be in contradiction to each other some times.
> > > I think we should get rid of the Minimal flag. And Kind should be either 
> > > a full completion (IDK_Everythink) or just a minimal (IDK_Basic). So, I'd 
> > > scrap the IDK_Default too. Alternatively we could have a Kind member in 
> > > AST**//Node//**Importer.
> > > I think we should go into this direction to avoid similar problems during 
> > > CodeGen in the future. WDYT?
> > No offense, you definitely understand the Importer better than I, so I 
> > value your input here. I don't believe that should have other fields where 
> > we could have a record that effects the layout but the concern is still 
> > valid and yes I did miss multi-dimensional arrays.
> > 
> > Your theory on `IDK_Everything` not be pushed through everywhere, I did a 
> > quick look and it seems pretty reasonable. 
> > 
> > I agree that the `ASTImporter::Minimal` flag and the `ImportDefinitionKind` 
> > seem to inconsistent or perhaps a work-around. That seems like a bigger 
> > change with a lot more impact beyond this fix but worth looking into longer 
> > term. 
> > 
> > If pushing through `IDK_Everything` everywhere fixes the underlying issue I 
> > am very happy to take that approach. If not we can discuss alternatives. 
> I've been looking at this code, but I'm still not very familiar with it, so 
> what I am asking may be obvious, but... What is the expected behavior for 
> non-minimal imports for code like this?
> ```
> struct A { ...};
> struct B { A* a; }; // Note the pointer
> ```
> Should importing B also import the definition of the A struct ? As I think 
> that should not happen in the minimal import... If we get rid of the minimal 
> flag, and rely solely on argument passing, we will need to be careful, as it 
> shouldn't be passed _everywhere_ (it should stop at pointers for instance). 
> But then it may not be possible to reproduce the current non-minimal import, 
> as it (I think) expects that A will be fully imported too...
> 
> > I don't believe that should have other fields where we could have a record 
> > that effects the layout
> This isn't exactly layout related, but there is the question of covariant 
> methods. If a method is covariant, then its return type must be complete. 
> Currently we handle the completion of these in LLDB, but that solution is a 
> bit hacky. It might be interesting if that could be handled by the ast 
> importer as well.
> What is the expected behavior for non-minimal imports for code like this?
In this case we import the definition of

[clang] a146195 - [SyntaxTree] Add coverage for declarators and init-declarators

2020-08-28 Thread Eduardo Caldas via cfe-commits

Author: Eduardo Caldas
Date: 2020-08-28T12:19:38Z
New Revision: a1461953f4efe574e3fdecfbae68bd18707748fb

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

LOG: [SyntaxTree] Add coverage for declarators and init-declarators

Added: 


Modified: 
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/unittests/Tooling/Syntax/BuildTreeTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index 2e9e74401e71..a9f326439a2a 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -200,6 +200,7 @@ static syntax::NodeKind getOperatorNodeKind(const 
CXXOperatorCallExpr &E) {
 /// Get the start of the qualified name. In the examples below it gives the
 /// location of the `^`:
 /// `int ^a;`
+/// `int *^a;`
 /// `int ^a::S::f(){}`
 static SourceLocation getQualifiedNameStart(NamedDecl *D) {
   assert((isa(D)) &&
@@ -242,7 +243,7 @@ static SourceRange getInitializerRange(Decl *D) {
 /// `int a[1][2][3];` -> range of `a[1][2][3]`,
 /// `int *a = nullptr` -> range of `*a = nullptr`.
 /// `int S::f(){}` -> range of `S::f()`.
-/// FIXME: \p Name must be a source range, e.g. for `operator+`.
+/// FIXME: \p Name must be a source range.
 static SourceRange getDeclaratorRange(const SourceManager &SM, TypeLoc T,
   SourceLocation Name,
   SourceRange Initializer) {

diff  --git a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp 
b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
index a07187e22e93..aab20008a497 100644
--- a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -3123,6 +3123,35 @@ SimpleDeclaration
 )txt"}));
 }
 
+TEST_P(SyntaxTreeTest, OutOfLineMemberFunctionDefinition) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+struct S {
+  void f();
+};
+[[void S::f(){}]]
+)cpp",
+  {R"txt(
+SimpleDeclaration
+|-'void'
+|-SimpleDeclarator Declarator
+| |-NestedNameSpecifier
+| | |-IdentifierNameSpecifier ListElement
+| | | `-'S'
+| | `-'::' ListDelimiter
+| |-'f'
+| `-ParametersAndQualifiers
+|   |-'(' OpenParen
+|   `-')' CloseParen
+`-CompoundStatement
+  |-'{' OpenParen
+  `-'}' CloseParen
+)txt"}));
+}
+
 TEST_P(SyntaxTreeTest, ConversionMemberFunction) {
   if (!GetParam().isCXX()) {
 return;
@@ -3792,6 +3821,53 @@ TranslationUnit Detached
 )txt"));
 }
 
+TEST_P(SyntaxTreeTest, InitDeclarator_Brace) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+int a {};
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-SimpleDeclaration
+  |-'int'
+  |-SimpleDeclarator Declarator
+  | |-'a'
+  | `-UnknownExpression
+  |   `-UnknownExpression
+  | |-'{'
+  | `-'}'
+  `-';'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, InitDeclarator_Paren) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+struct S {
+  S(int);
+};
+[[S s(1);]]
+)cpp",
+  {R"txt(
+SimpleDeclaration
+|-'S'
+|-SimpleDeclarator Declarator
+| `-UnknownExpression
+|   |-'s'
+|   |-'('
+|   |-IntegerLiteralExpression
+|   | `-'1' LiteralToken
+|   `-')'
+`-';'
+)txt"}));
+}
+
 TEST_P(SyntaxTreeTest, ArrayDeclarator_Simple) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(



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


[clang] 38bc006 - [SyntaxTree][NFC] Refactor function templates into functions taking base class

2020-08-28 Thread Eduardo Caldas via cfe-commits

Author: Eduardo Caldas
Date: 2020-08-28T12:19:38Z
New Revision: 38bc0060e60fef5395c23b8b75163e5bdee23af6

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

LOG: [SyntaxTree][NFC] Refactor function templates into functions taking base 
class

The refactored functions were
* `isReponsibleForCreatingDeclaration`
* `getQualifiedNameStart`

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

Added: 


Modified: 
clang/lib/Tooling/Syntax/BuildTree.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index b07e9c3faf9d..2e9e74401e71 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -197,18 +197,57 @@ static syntax::NodeKind getOperatorNodeKind(const 
CXXOperatorCallExpr &E) {
   llvm_unreachable("Unknown OverloadedOperatorKind enum");
 }
 
+/// Get the start of the qualified name. In the examples below it gives the
+/// location of the `^`:
+/// `int ^a;`
+/// `int ^a::S::f(){}`
+static SourceLocation getQualifiedNameStart(NamedDecl *D) {
+  assert((isa(D)) &&
+ "only DeclaratorDecl and TypedefNameDecl are supported.");
+
+  auto DN = D->getDeclName();
+  bool IsAnonymous = DN.isIdentifier() && !DN.getAsIdentifierInfo();
+  if (IsAnonymous)
+return SourceLocation();
+
+  if (const auto *DD = dyn_cast(D)) {
+if (DD->getQualifierLoc()) {
+  return DD->getQualifierLoc().getBeginLoc();
+}
+  }
+
+  return D->getLocation();
+}
+
+/// Gets the range of the initializer inside an init-declarator C++ [dcl.decl].
+/// `int a;` -> range of ``,
+/// `int *a = nullptr` -> range of `= nullptr`.
+/// `int a{}` -> range of `{}`.
+/// `int a()` -> range of `()`.
+static SourceRange getInitializerRange(Decl *D) {
+  if (auto *V = dyn_cast(D)) {
+auto *I = V->getInit();
+// Initializers in range-based-for are not part of the declarator
+if (I && !V->isCXXForRangeDecl())
+  return I->getSourceRange();
+  }
+
+  return SourceRange();
+}
+
 /// Gets the range of declarator as defined by the C++ grammar. E.g.
 /// `int a;` -> range of `a`,
 /// `int *a;` -> range of `*a`,
 /// `int a[10];` -> range of `a[10]`,
 /// `int a[1][2][3];` -> range of `a[1][2][3]`,
 /// `int *a = nullptr` -> range of `*a = nullptr`.
-/// FIMXE: \p Name must be a source range, e.g. for `operator+`.
+/// `int S::f(){}` -> range of `S::f()`.
+/// FIXME: \p Name must be a source range, e.g. for `operator+`.
 static SourceRange getDeclaratorRange(const SourceManager &SM, TypeLoc T,
   SourceLocation Name,
   SourceRange Initializer) {
   SourceLocation Start = GetStartLoc().Visit(T);
-  SourceLocation End = T.getSourceRange().getEnd();
+  SourceLocation End = T.getEndLoc();
   assert(End.isValid());
   if (Name.isValid()) {
 if (Start.isInvalid())
@@ -378,11 +417,9 @@ class syntax::TreeBuilder {
 
   /// Returns true if \p D is the last declarator in a chain and is thus
   /// reponsible for creating SimpleDeclaration for the whole chain.
-  template 
-  bool isResponsibleForCreatingDeclaration(const T *D) const {
-static_assert((std::is_base_of::value ||
-   std::is_base_of::value),
-  "only DeclaratorDecl and TypedefNameDecl are supported.");
+  bool isResponsibleForCreatingDeclaration(const Decl *D) const {
+assert((isa(D)) &&
+   "only DeclaratorDecl and TypedefNameDecl are supported.");
 
 const Decl *Next = D->getNextDeclInContext();
 
@@ -390,15 +427,14 @@ class syntax::TreeBuilder {
 if (Next == nullptr) {
   return true;
 }
-const auto *NextT = dyn_cast(Next);
 
 // Next sibling is not the same type, this one is responsible.
-if (NextT == nullptr) {
+if (D->getKind() != Next->getKind()) {
   return true;
 }
 // Next sibling doesn't begin at the same loc, it must be a 
diff erent
 // declaration, so this declarator is responsible.
-if (NextT->getBeginLoc() != D->getBeginLoc()) {
+if (Next->getBeginLoc() != D->getBeginLoc()) {
   return true;
 }
 
@@ -1405,43 +1441,12 @@ class BuildTreeVisitor : public 
RecursiveASTVisitor {
   }
 
 private:
-  template  SourceLocation getQualifiedNameStart(T *D) {
-static_assert((std::is_base_of::value ||
-   std::is_base_of::value),
-  "only DeclaratorDecl and TypedefNameDecl are supported.");
-
-auto DN = D->getDeclName();
-bool IsAnonymous = DN.isIdentifier() && !DN.getAsIdentifierInfo();
-if (IsAnonymous)
-  return SourceLocation();
-
-if (const auto *DD = dyn_cast(D)) {
-  if (DD->getQualifierLoc()) {
-return DD->getQualifierLoc().getBeginL

[PATCH] D86719: [SyntaxTree][NFC] Refactor function templates into functions taking base class

2020-08-28 Thread Eduardo Caldas via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
eduucaldas marked an inline comment as done.
Closed by commit rG38bc0060e60f: [SyntaxTree][NFC] Refactor function templates 
into functions taking base class (authored by eduucaldas).

Changed prior to commit:
  https://reviews.llvm.org/D86719?vs=288584&id=288586#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86719

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp

Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -197,18 +197,57 @@
   llvm_unreachable("Unknown OverloadedOperatorKind enum");
 }
 
+/// Get the start of the qualified name. In the examples below it gives the
+/// location of the `^`:
+/// `int ^a;`
+/// `int ^a::S::f(){}`
+static SourceLocation getQualifiedNameStart(NamedDecl *D) {
+  assert((isa(D)) &&
+ "only DeclaratorDecl and TypedefNameDecl are supported.");
+
+  auto DN = D->getDeclName();
+  bool IsAnonymous = DN.isIdentifier() && !DN.getAsIdentifierInfo();
+  if (IsAnonymous)
+return SourceLocation();
+
+  if (const auto *DD = dyn_cast(D)) {
+if (DD->getQualifierLoc()) {
+  return DD->getQualifierLoc().getBeginLoc();
+}
+  }
+
+  return D->getLocation();
+}
+
+/// Gets the range of the initializer inside an init-declarator C++ [dcl.decl].
+/// `int a;` -> range of ``,
+/// `int *a = nullptr` -> range of `= nullptr`.
+/// `int a{}` -> range of `{}`.
+/// `int a()` -> range of `()`.
+static SourceRange getInitializerRange(Decl *D) {
+  if (auto *V = dyn_cast(D)) {
+auto *I = V->getInit();
+// Initializers in range-based-for are not part of the declarator
+if (I && !V->isCXXForRangeDecl())
+  return I->getSourceRange();
+  }
+
+  return SourceRange();
+}
+
 /// Gets the range of declarator as defined by the C++ grammar. E.g.
 /// `int a;` -> range of `a`,
 /// `int *a;` -> range of `*a`,
 /// `int a[10];` -> range of `a[10]`,
 /// `int a[1][2][3];` -> range of `a[1][2][3]`,
 /// `int *a = nullptr` -> range of `*a = nullptr`.
-/// FIMXE: \p Name must be a source range, e.g. for `operator+`.
+/// `int S::f(){}` -> range of `S::f()`.
+/// FIXME: \p Name must be a source range, e.g. for `operator+`.
 static SourceRange getDeclaratorRange(const SourceManager &SM, TypeLoc T,
   SourceLocation Name,
   SourceRange Initializer) {
   SourceLocation Start = GetStartLoc().Visit(T);
-  SourceLocation End = T.getSourceRange().getEnd();
+  SourceLocation End = T.getEndLoc();
   assert(End.isValid());
   if (Name.isValid()) {
 if (Start.isInvalid())
@@ -378,11 +417,9 @@
 
   /// Returns true if \p D is the last declarator in a chain and is thus
   /// reponsible for creating SimpleDeclaration for the whole chain.
-  template 
-  bool isResponsibleForCreatingDeclaration(const T *D) const {
-static_assert((std::is_base_of::value ||
-   std::is_base_of::value),
-  "only DeclaratorDecl and TypedefNameDecl are supported.");
+  bool isResponsibleForCreatingDeclaration(const Decl *D) const {
+assert((isa(D)) &&
+   "only DeclaratorDecl and TypedefNameDecl are supported.");
 
 const Decl *Next = D->getNextDeclInContext();
 
@@ -390,15 +427,14 @@
 if (Next == nullptr) {
   return true;
 }
-const auto *NextT = dyn_cast(Next);
 
 // Next sibling is not the same type, this one is responsible.
-if (NextT == nullptr) {
+if (D->getKind() != Next->getKind()) {
   return true;
 }
 // Next sibling doesn't begin at the same loc, it must be a different
 // declaration, so this declarator is responsible.
-if (NextT->getBeginLoc() != D->getBeginLoc()) {
+if (Next->getBeginLoc() != D->getBeginLoc()) {
   return true;
 }
 
@@ -1405,43 +1441,12 @@
   }
 
 private:
-  template  SourceLocation getQualifiedNameStart(T *D) {
-static_assert((std::is_base_of::value ||
-   std::is_base_of::value),
-  "only DeclaratorDecl and TypedefNameDecl are supported.");
-
-auto DN = D->getDeclName();
-bool IsAnonymous = DN.isIdentifier() && !DN.getAsIdentifierInfo();
-if (IsAnonymous)
-  return SourceLocation();
-
-if (const auto *DD = dyn_cast(D)) {
-  if (DD->getQualifierLoc()) {
-return DD->getQualifierLoc().getBeginLoc();
-  }
-}
-
-return D->getLocation();
-  }
-
-  SourceRange getInitializerRange(Decl *D) {
-if (auto *V = dyn_cast(D)) {
-  auto *I = V->getInit();
-  // Initializers in range-based-for are not part of the declarator
-  if (I && !V->isCXXForRangeDecl())
-return I->getSourceRange();
-}

[PATCH] D86065: [SVE] Make ElementCount members private

2020-08-28 Thread Paul Walker via Phabricator via cfe-commits
paulwalker-arm added a comment.

To be more clear, I'm happy to defer the divide conversation for if/when we run 
into issues so my previous acceptance still stands.  It'll be good to get the 
intent of the patch in (i.e. stoping access to internal class members) asap, 
plus any follow up work will be a smaller more manageable patch.  It's worth 
talking this through during the next sync call to see it we can get some 
consensus regarding what maths is and isn't allowed.


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

https://reviews.llvm.org/D86065

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


[PATCH] D86719: [SyntaxTree][NFC] Refactor function templates into functions taking base class

2020-08-28 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas marked an inline comment as done.
eduucaldas added inline comments.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:245
+/// `int S::f(){}` -> range of `S::f()`.
+/// FIXME: \p Name must be a source range, e.g. for `operator+`.
 static SourceRange getDeclaratorRange(const SourceManager &SM, TypeLoc T,

gribozavr2 wrote:
> eduucaldas wrote:
> > There was no problem with the declarator of `operator+` should I remove 
> > this?
> > Also I really tried to break it ^^.
> > 
> > I think though perhaps this is going to bite us in an obscure way, so I 
> > would just remove the `e.g. ...`.
> Feel free to remove the fixme.
> 
> What do you mean by "remove the e.g. ..."? Removing the examples from the 
> comment? Why?
I meant 
```
/// FIXME: \p Name must be a source range, e.g. for `operator+`.
```
->
```
/// FIXME: \p Name must be a source range.
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86719

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


[PATCH] D86719: [SyntaxTree][NFC] Refactor function templates into functions taking base class

2020-08-28 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas updated this revision to Diff 288584.
eduucaldas marked an inline comment as done.
eduucaldas added a comment.

Rebase and answer comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86719

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp

Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -3123,6 +3123,35 @@
 )txt"}));
 }
 
+TEST_P(SyntaxTreeTest, OutOfLineMemberFunctionDefinition) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+struct S {
+  void f();
+};
+[[void S::f(){}]]
+)cpp",
+  {R"txt(
+SimpleDeclaration
+|-'void'
+|-SimpleDeclarator Declarator
+| |-NestedNameSpecifier
+| | |-IdentifierNameSpecifier ListElement
+| | | `-'S'
+| | `-'::' ListDelimiter
+| |-'f'
+| `-ParametersAndQualifiers
+|   |-'(' OpenParen
+|   `-')' CloseParen
+`-CompoundStatement
+  |-'{' OpenParen
+  `-'}' CloseParen
+)txt"}));
+}
+
 TEST_P(SyntaxTreeTest, ConversionMemberFunction) {
   if (!GetParam().isCXX()) {
 return;
@@ -3792,6 +3821,53 @@
 )txt"));
 }
 
+TEST_P(SyntaxTreeTest, InitDeclarator_Brace) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+int a {};
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-SimpleDeclaration
+  |-'int'
+  |-SimpleDeclarator Declarator
+  | |-'a'
+  | `-UnknownExpression
+  |   `-UnknownExpression
+  | |-'{'
+  | `-'}'
+  `-';'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, InitDeclarator_Paren) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+struct S {
+  S(int);
+};
+[[S s(1);]]
+)cpp",
+  {R"txt(
+SimpleDeclaration
+|-'S'
+|-SimpleDeclarator Declarator
+| `-UnknownExpression
+|   |-'s'
+|   |-'('
+|   |-IntegerLiteralExpression
+|   | `-'1' LiteralToken
+|   `-')'
+`-';'
+)txt"}));
+}
+
 TEST_P(SyntaxTreeTest, ArrayDeclarator_Simple) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -197,18 +197,58 @@
   llvm_unreachable("Unknown OverloadedOperatorKind enum");
 }
 
+/// Get the start of the qualified name. In the examples below it gives the
+/// location of the `^`:
+/// `int ^a;`
+/// `int *^a;`
+/// `int ^a::S::f(){}`
+static SourceLocation getQualifiedNameStart(NamedDecl *D) {
+  assert((isa(D)) &&
+ "only DeclaratorDecl and TypedefNameDecl are supported.");
+
+  auto DN = D->getDeclName();
+  bool IsAnonymous = DN.isIdentifier() && !DN.getAsIdentifierInfo();
+  if (IsAnonymous)
+return SourceLocation();
+
+  if (const auto *DD = dyn_cast(D)) {
+if (DD->getQualifierLoc()) {
+  return DD->getQualifierLoc().getBeginLoc();
+}
+  }
+
+  return D->getLocation();
+}
+
+/// Gets the range of the initializer inside an init-declarator C++ [dcl.decl].
+/// `int a;` -> range of ``,
+/// `int *a = nullptr` -> range of `= nullptr`.
+/// `int a{}` -> range of `{}`.
+/// `int a()` -> range of `()`.
+static SourceRange getInitializerRange(Decl *D) {
+  if (auto *V = dyn_cast(D)) {
+auto *I = V->getInit();
+// Initializers in range-based-for are not part of the declarator
+if (I && !V->isCXXForRangeDecl())
+  return I->getSourceRange();
+  }
+
+  return SourceRange();
+}
+
 /// Gets the range of declarator as defined by the C++ grammar. E.g.
 /// `int a;` -> range of `a`,
 /// `int *a;` -> range of `*a`,
 /// `int a[10];` -> range of `a[10]`,
 /// `int a[1][2][3];` -> range of `a[1][2][3]`,
 /// `int *a = nullptr` -> range of `*a = nullptr`.
-/// FIMXE: \p Name must be a source range, e.g. for `operator+`.
+/// `int S::f(){}` -> range of `S::f()`.
+/// FIXME: \p Name must be a source range.
 static SourceRange getDeclaratorRange(const SourceManager &SM, TypeLoc T,
   SourceLocation Name,
   SourceRange Initializer) {
   SourceLocation Start = GetStartLoc().Visit(T);
-  SourceLocation End = T.getSourceRange().getEnd();
+  SourceLocation End = T.getEndLoc();
   assert(End.isValid());
   if (Name.isValid()) {
 if (Start.isInvalid())
@@ -378,11 +418,9 @@
 
   /// Returns true if \p D is the last declarator in a chain and is thus
   /// reponsible for creating SimpleDeclaration for the whole chain.
-  template 
-  bool isResponsibleForCreatingDeclaration(const T *D) const {
-static_assert((std::is_base_of::value ||
-   std::is_base_of::value),
-  "only DeclaratorDecl and TypedefNameDecl are s

[PATCH] D86778: Extract infrastructure to ignore intermediate expressions into `clang/AST/IgnoreExpr.h`

2020-08-28 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added a comment.

> This allows users to use IgnoreExprNodes outside of clang/AST/Expr.h

Did you mean "outside of Expr.cpp"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86778

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


[PATCH] D86778: Extract infrastructure to ignore intermediate expressions into `clang/AST/IgnoreExpr.h`

2020-08-28 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
eduucaldas requested review of this revision.

This allows users to use `IgnoreExprNodes` outside of `clang/AST/Expr.h`


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86778

Files:
  clang/include/clang/AST/IgnoreExpr.h
  clang/lib/AST/Expr.cpp


Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -21,6 +21,7 @@
 #include "clang/AST/DependenceFlags.h"
 #include "clang/AST/EvaluatedExprVisitor.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/IgnoreExpr.h"
 #include "clang/AST/Mangle.h"
 #include "clang/AST/RecordLayout.h"
 #include "clang/AST/StmtVisitor.h"
@@ -2914,25 +2915,6 @@
   return E;
 }
 
-static Expr *IgnoreExprNodesImpl(Expr *E) { return E; }
-template 
-static Expr *IgnoreExprNodesImpl(Expr *E, FnTy &&Fn, FnTys &&... Fns) {
-  return IgnoreExprNodesImpl(Fn(E), std::forward(Fns)...);
-}
-
-/// Given an expression E and functions Fn_1,...,Fn_n : Expr * -> Expr *,
-/// Recursively apply each of the functions to E until reaching a fixed point.
-/// Note that a null E is valid; in this case nothing is done.
-template 
-static Expr *IgnoreExprNodes(Expr *E, FnTys &&... Fns) {
-  Expr *LastE = nullptr;
-  while (E != LastE) {
-LastE = E;
-E = IgnoreExprNodesImpl(E, std::forward(Fns)...);
-  }
-  return E;
-}
-
 Expr *Expr::IgnoreImpCasts() {
   return IgnoreExprNodes(this, IgnoreImpCastsSingleStep);
 }
Index: clang/include/clang/AST/IgnoreExpr.h
===
--- /dev/null
+++ clang/include/clang/AST/IgnoreExpr.h
@@ -0,0 +1,36 @@
+//===--- IgnoreExpr.h - Ignore intermediate Expressions -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines common functions to ignore intermediate expression nodes
+//
+//===--===//
+#include "clang/AST/Expr.h"
+
+namespace clang {
+namespace {
+/// Given an expression E and functions Fn_1,...,Fn_n : Expr * -> Expr *,
+/// Return Fn_n(...(Fn_1(E)))
+Expr *IgnoreExprNodesImpl(Expr *E) { return E; }
+template 
+Expr *IgnoreExprNodesImpl(Expr *E, FnTy &&Fn, FnTys &&...Fns) {
+  return IgnoreExprNodesImpl(Fn(E), std::forward(Fns)...);
+}
+} // namespace
+
+/// Given an expression E and functions Fn_1,...,Fn_n : Expr * -> Expr *,
+/// Recursively apply each of the functions to E until reaching a fixed point.
+/// Note that a null E is valid; in this case nothing is done.
+template  Expr *IgnoreExprNodes(Expr *E, FnTys &&...Fns) {
+  Expr *LastE = nullptr;
+  while (E != LastE) {
+LastE = E;
+E = IgnoreExprNodesImpl(E, std::forward(Fns)...);
+  }
+  return E;
+}
+} // namespace clang


Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -21,6 +21,7 @@
 #include "clang/AST/DependenceFlags.h"
 #include "clang/AST/EvaluatedExprVisitor.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/IgnoreExpr.h"
 #include "clang/AST/Mangle.h"
 #include "clang/AST/RecordLayout.h"
 #include "clang/AST/StmtVisitor.h"
@@ -2914,25 +2915,6 @@
   return E;
 }
 
-static Expr *IgnoreExprNodesImpl(Expr *E) { return E; }
-template 
-static Expr *IgnoreExprNodesImpl(Expr *E, FnTy &&Fn, FnTys &&... Fns) {
-  return IgnoreExprNodesImpl(Fn(E), std::forward(Fns)...);
-}
-
-/// Given an expression E and functions Fn_1,...,Fn_n : Expr * -> Expr *,
-/// Recursively apply each of the functions to E until reaching a fixed point.
-/// Note that a null E is valid; in this case nothing is done.
-template 
-static Expr *IgnoreExprNodes(Expr *E, FnTys &&... Fns) {
-  Expr *LastE = nullptr;
-  while (E != LastE) {
-LastE = E;
-E = IgnoreExprNodesImpl(E, std::forward(Fns)...);
-  }
-  return E;
-}
-
 Expr *Expr::IgnoreImpCasts() {
   return IgnoreExprNodes(this, IgnoreImpCastsSingleStep);
 }
Index: clang/include/clang/AST/IgnoreExpr.h
===
--- /dev/null
+++ clang/include/clang/AST/IgnoreExpr.h
@@ -0,0 +1,36 @@
+//===--- IgnoreExpr.h - Ignore intermediate Expressions -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines common functions to ignore intermediate expression nodes
+//
+//===-

[PATCH] D86775: [clang-format] Parse __ptr32/__ptr64 as a pointer qualifier

2020-08-28 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added reviewers: MyDeveloperDay, JakeMerdichAMD, sammccall, 
curdeius.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
arichardson requested review of this revision.

Before:
x = (foo *__ptr32) * v;
MACRO(A * __ptr32 a);
x = (foo *__ptr64) * v;
MACRO(A * __ptr64 a);

After:
x = (foo *__ptr32)*v;
MACRO(A *__ptr32 a);
x = (foo *__ptr64)*v;
MACRO(A *__ptr64 a);

Depends on D86721  (to apply cleanly)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86775

Files:
  clang/lib/Format/FormatToken.h
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8028,6 +8028,8 @@
   verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("foo();");
@@ -8069,6 +8071,8 @@
   verifyIndependentOfContext("MACRO(A *__attribute__((foo)) a);");
   verifyIndependentOfContext("MACRO(A *__attribute((foo)) a);");
   verifyIndependentOfContext("MACRO(A *[[clang::attr]] a);");
+  verifyIndependentOfContext("MACRO(A *__ptr32 a);");
+  verifyIndependentOfContext("MACRO(A *__ptr64 a);");
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");
   verifyFormat("void f() { f(float{1}, a * a); }");
   // FIXME: Is there a way to make this work?
@@ -8139,6 +8143,8 @@
   verifyFormat("x = (foo *_Null_unspecified)*v;");
   verifyFormat("x = (foo *_Nonnull)*v;");
   verifyFormat("x = (foo *[[clang::attr]])*v;");
+  verifyFormat("x = (foo *__ptr32)*v;");
+  verifyFormat("x = (foo *__ptr64)*v;");
 
   // Check that we handle multiple trailing qualifiers and skip them all to
   // determine that the expression is a cast to a pointer type.
Index: clang/lib/Format/FormatToken.h
===
--- clang/lib/Format/FormatToken.h
+++ clang/lib/Format/FormatToken.h
@@ -442,7 +442,7 @@
   bool canBePointerOrReferenceQualifier() const {
 return isOneOf(tok::kw_const, tok::kw_restrict, tok::kw_volatile,
tok::kw___attribute, tok::kw__Nonnull, tok::kw__Nullable,
-   tok::kw__Null_unspecified);
+   tok::kw__Null_unspecified, tok::kw___ptr32, 
tok::kw___ptr64);
   }
 
   /// Determine whether the token is a simple-type-specifier.


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8028,6 +8028,8 @@
   verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("vector v;");
+  verifyFormat("vector v;");
+  verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("vector v;");
   verifyFormat("foo();");
@@ -8069,6 +8071,8 @@
   verifyIndependentOfContext("MACRO(A *__attribute__((foo)) a);");
   verifyIndependentOfContext("MACRO(A *__attribute((foo)) a);");
   verifyIndependentOfContext("MACRO(A *[[clang::attr]] a);");
+  verifyIndependentOfContext("MACRO(A *__ptr32 a);");
+  verifyIndependentOfContext("MACRO(A *__ptr64 a);");
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");
   verifyFormat("void f() { f(float{1}, a * a); }");
   // FIXME: Is there a way to make this work?
@@ -8139,6 +8143,8 @@
   verifyFormat("x = (foo *_Null_unspecified)*v;");
   verifyFormat("x = (foo *_Nonnull)*v;");
   verifyFormat("x = (foo *[[clang::attr]])*v;");
+  verifyFormat("x = (foo *__ptr32)*v;");
+  verifyFormat("x = (foo *__ptr64)*v;");
 
   // Check that we handle multiple trailing qualifiers and skip them all to
   // determine that the expression is a cast to a pointer type.
Index: clang/lib/Format/FormatToken.h
===
--- clang/lib/Format/FormatToken.h
+++ clang/lib/Format/FormatToken.h
@@ -442,7 +442,7 @@
   bool canBePointerOrReferenceQualifier() const {
 return isOneOf(tok::kw_const, tok::kw_restrict, tok::kw_volatile,
tok::kw___attribute, tok::kw__Nonnull, tok::kw__Nullable,
-   tok::kw__Null_unspecified);
+   tok::kw__Null_unspecified, tok::kw___ptr32, tok::kw___ptr64);
   }
 
   /// Determine whether the token is a simple-type-specifier.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-28 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob added a comment.

In D86671#2243788 , @Eugene.Zelenko 
wrote:

> It'll be good idea to add test case.

Hi @Eugene.Zelenko,
I have created a `readability-identifier-naming-hungarain-notion.cpp`  file and 
several test cases for regression testing. Is it regression testing?

Find it here (https://reviews.llvm.org/differential/changeset/?ref=2137882)


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


  1   2   >