[PATCH] D74591: [Driver] Rename AddGoldPlugin to addLTOOptions. NFC

2020-02-13 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added reviewers: evgeny777, tejohnson.
Herald added subscribers: cfe-commits, dexonsmith, inglorion, emaste.
Herald added a project: clang.

AddGoldPlugin does more than adding `-plugin path/to/LLVMgold.so`.
It works with lld and GNU ld, and adds other LTO options.
So AddGoldPlugin is no longer a suitable name.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D74591

Files:
  clang/lib/Driver/ToolChains/Ananas.cpp
  clang/lib/Driver/ToolChains/CloudABI.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -512,7 +512,7 @@
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");
-AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+addLTOOptions(ToolChain, Args, CmdArgs, Output, Inputs[0],
   D.getLTOMode() == LTOK_Thin);
   }
 
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -111,7 +111,7 @@
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");
-AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+addLTOOptions(ToolChain, Args, CmdArgs, Output, Inputs[0],
   D.getLTOMode() == LTOK_Thin);
   }
 
Index: clang/lib/Driver/ToolChains/FreeBSD.cpp
===
--- clang/lib/Driver/ToolChains/FreeBSD.cpp
+++ clang/lib/Driver/ToolChains/FreeBSD.cpp
@@ -275,7 +275,7 @@
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");
-AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+addLTOOptions(ToolChain, Args, CmdArgs, Output, Inputs[0],
   D.getLTOMode() == LTOK_Thin);
   }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -58,7 +58,7 @@
 const JobAction &JA, const llvm::opt::ArgList &Args,
 const InputInfo &Output, const char *OutFile);
 
-void AddGoldPlugin(const ToolChain &ToolChain, const llvm::opt::ArgList &Args,
+void addLTOOptions(const ToolChain &ToolChain, const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs, const InputInfo &Output,
const InputInfo &Input, bool IsThinLTO);
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -353,7 +353,7 @@
   return Triple.getOS() == llvm::Triple::CloudABI;
 }
 
-void tools::AddGoldPlugin(const ToolChain &ToolChain, const ArgList &Args,
+void tools::addLTOOptions(const ToolChain &ToolChain, const ArgList &Args,
   ArgStringList &CmdArgs, const InputInfo &Output,
   const InputInfo &Input, bool IsThinLTO) {
   const char *Linker = Args.MakeArgString(ToolChain.GetLinkerPath());
Index: clang/lib/Driver/ToolChains/CloudABI.cpp
===
--- clang/lib/Driver/ToolChains/CloudABI.cpp
+++ clang/lib/Driver/ToolChains/CloudABI.cpp
@@ -75,7 +75,7 @@
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");
-AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+addLTOOptions(ToolChain, Args, CmdArgs, Output, Inputs[0],
   D.getLTOMode() == LTOK_Thin);
   }
 
Index: clang/lib/Driver/ToolChains/Ananas.cpp
===
--- clang/lib/Driver/ToolChains/Ananas.cpp
+++ clang/lib/Driver/ToolChains/Ananas.cpp
@@ -103,7 +103,7 @@
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");
-AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+addLTOOptions(ToolChain, Args, CmdArgs, Output, Inputs[0],
   D.getLTOMode() == LTOK_Thin);
   }
 


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -512,7 +512,7 @@
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");
-AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+addLTOOptions(ToolChain, Args, CmdArgs, Output, Inputs[0],
   D.getLTOM

[PATCH] D73462: [dwarf-5] Support DebugInfo for Defaulted parameters for C++ templates

2020-02-13 Thread Awanish Pandey via Phabricator via cfe-commits
awpandey updated this revision to Diff 244571.
awpandey marked 2 inline comments as done.
awpandey added a comment.

Hi @aprantl, I have added a test that two DITemplateTypeParameter only differ 
in the isDefault parameter are not equal.


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

https://reviews.llvm.org/D73462

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-template-parameter.cpp
  llvm/include/llvm/IR/DIBuilder.h
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/MetadataLoader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/DIBuilder.cpp
  llvm/lib/IR/DebugInfoMetadata.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/test/Assembler/DITemplateParameter.ll
  llvm/test/Bitcode/DITemplateParameter-5.0.ll
  llvm/test/Bitcode/DITemplateParameter-5.0.ll.bc
  llvm/test/DebugInfo/X86/debug-info-template-parameter.ll
  llvm/unittests/IR/MetadataTest.cpp

Index: llvm/unittests/IR/MetadataTest.cpp
===
--- llvm/unittests/IR/MetadataTest.cpp
+++ llvm/unittests/IR/MetadataTest.cpp
@@ -2077,16 +2077,17 @@
   StringRef Name = "template";
   DIType *Type = getBasicType("basic");
 
-  auto *N = DITemplateTypeParameter::get(Context, Name, Type);
+  auto *N = DITemplateTypeParameter::get(Context, Name, Type, false);
 
   EXPECT_EQ(dwarf::DW_TAG_template_type_parameter, N->getTag());
   EXPECT_EQ(Name, N->getName());
   EXPECT_EQ(Type, N->getType());
-  EXPECT_EQ(N, DITemplateTypeParameter::get(Context, Name, Type));
+  EXPECT_EQ(N, DITemplateTypeParameter::get(Context, Name, Type, false));
 
-  EXPECT_NE(N, DITemplateTypeParameter::get(Context, "other", Type));
-  EXPECT_NE(N,
-DITemplateTypeParameter::get(Context, Name, getBasicType("other")));
+  EXPECT_NE(N, DITemplateTypeParameter::get(Context, "other", Type, false));
+  EXPECT_NE(N, DITemplateTypeParameter::get(Context, Name,
+getBasicType("other"), false));
+  EXPECT_NE(N, DITemplateTypeParameter::get(Context, Name, Type, true));
 
   TempDITemplateTypeParameter Temp = N->clone();
   EXPECT_EQ(N, MDNode::replaceWithUniqued(std::move(Temp)));
@@ -2100,22 +2101,26 @@
   DIType *Type = getBasicType("basic");
   Metadata *Value = getConstantAsMetadata();
 
-  auto *N = DITemplateValueParameter::get(Context, Tag, Name, Type, Value);
+  auto *N =
+  DITemplateValueParameter::get(Context, Tag, Name, Type, false, Value);
   EXPECT_EQ(Tag, N->getTag());
   EXPECT_EQ(Name, N->getName());
   EXPECT_EQ(Type, N->getType());
   EXPECT_EQ(Value, N->getValue());
-  EXPECT_EQ(N, DITemplateValueParameter::get(Context, Tag, Name, Type, Value));
+  EXPECT_EQ(
+  N, DITemplateValueParameter::get(Context, Tag, Name, Type, false, Value));
 
   EXPECT_NE(N, DITemplateValueParameter::get(
Context, dwarf::DW_TAG_GNU_template_template_param, Name,
-   Type, Value));
-  EXPECT_NE(N,
-DITemplateValueParameter::get(Context, Tag, "other", Type, Value));
-  EXPECT_NE(N, DITemplateValueParameter::get(Context, Tag, Name,
- getBasicType("other"), Value));
-  EXPECT_NE(N, DITemplateValueParameter::get(Context, Tag, Name, Type,
+   Type, false, Value));
+  EXPECT_NE(N, DITemplateValueParameter::get(Context, Tag, "other", Type, false,
+ Value));
+  EXPECT_NE(N, DITemplateValueParameter::get(
+   Context, Tag, Name, getBasicType("other"), false, Value));
+  EXPECT_NE(N, DITemplateValueParameter::get(Context, Tag, Name, Type, false,
  getConstantAsMetadata()));
+  EXPECT_NE(
+  N, DITemplateValueParameter::get(Context, Tag, Name, Type, true, Value));
 
   TempDITemplateValueParameter Temp = N->clone();
   EXPECT_EQ(N, MDNode::replaceWithUniqued(std::move(Temp)));
Index: llvm/test/DebugInfo/X86/debug-info-template-parameter.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/X86/debug-info-template-parameter.ll
@@ -0,0 +1,90 @@
+; RUN: %llc_dwarf  %s -filetype=obj -o - | llvm-dwarfdump -v - | FileCheck %s
+
+; C++ source to regenerate:
+
+;template 
+;class foo {
+;};
+;
+;int main() {
+; foo f1;
+; foo<> f2;
+; return 0;
+;}
+
+; $ clang++ -O0 -gdwarf-5 -S -gdwarf-5 test.cpp 
+
+; CHECK: .debug_abbrev contents:
+; CHECK: DW_AT_default_value DW_FORM_flag_present
+
+; CHECK: debug_info contents:
+
+; CHECK: DW_AT_name {{.*}} "foo"
+; CHECK: DW_AT_type {{.*}} "int"
+; CHECK-NEXT: DW_AT_name {{.*}} "T"
+; CHECK-NOT: DW_AT_default_value
+; CHECK: DW_AT_type {{.*}} "int"
+; CHECK-NEXT: DW_AT_name {{.*}} "i"
+; CHECK-NOT: DW_AT_default_value
+
+; CHECK: DW_AT_name {{.*}} "foo"
+; CHECK: DW_AT_type {{.*}} "char"
+; CHECK-NEXT: DW_AT_

[PATCH] D71903: [Coroutines][6/6] Clang schedules new passes

2020-02-13 Thread Brian Gesiak via Phabricator via cfe-commits
modocache updated this revision to Diff 244566.
modocache added a comment.

Clean up coroutine intrinsics as part of the ThinLTO pre-link pipeline.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71903

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGenCoroutines/coro-newpm-pipeline.cpp
  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
@@ -242,6 +242,7 @@
   SLPVectorization = RunSLPVectorization;
   LoopUnrolling = true;
   ForgetAllSCEVInLoopUnroll = ForgetSCEVInLoopUnroll;
+  Coroutines = false;
   LicmMssaOptCap = SetLicmMssaOptCap;
   LicmMssaNoAccForPromotionCap = SetLicmMssaNoAccForPromotionCap;
 }
@@ -721,6 +722,8 @@
   EarlyFPM.addPass(SROA());
   EarlyFPM.addPass(EarlyCSEPass());
   EarlyFPM.addPass(LowerExpectIntrinsicPass());
+  if (PTO.Coroutines)
+EarlyFPM.addPass(CoroEarlyPass());
   if (Level == OptimizationLevel::O3)
 EarlyFPM.addPass(CallSiteSplittingPass());
 
@@ -844,6 +847,11 @@
 
   MainCGPipeline.addPass(AttributorCGSCCPass());
 
+  if (PTO.Coroutines) {
+MainCGPipeline.addPass(CoroSplitPass());
+MainCGPipeline.addPass(createCGSCCToFunctionPassAdaptor(CoroElidePass()));
+  }
+
   // Now deduce any function attributes based in the current code.
   MainCGPipeline.addPass(PostOrderFunctionAttrsPass());
 
@@ -1046,6 +1054,9 @@
   // inserting redundancies into the program. This even includes SimplifyCFG.
   OptimizePM.addPass(SpeculateAroundPHIsPass());
 
+  if (PTO.Coroutines)
+OptimizePM.addPass(CoroCleanupPass());
+
   for (auto &C : OptimizerLastEPCallbacks)
 C(OptimizePM, Level);
 
@@ -1129,6 +1140,12 @@
   // Reduce the size of the IR as much as possible.
   MPM.addPass(GlobalOptPass());
 
+  // Module simplification splits coroutines, but does not fully clean up
+  // coroutine intrinsics. To ensure ThinLTO optimization passes don't trip up
+  // on these, we schedule the cleanup here.
+  if (PTO.Coroutines)
+MPM.addPass(createModuleToFunctionPassAdaptor(CoroCleanupPass()));
+
   return MPM;
 }
 
Index: llvm/include/llvm/Passes/PassBuilder.h
===
--- llvm/include/llvm/Passes/PassBuilder.h
+++ llvm/include/llvm/Passes/PassBuilder.h
@@ -92,6 +92,12 @@
   /// is that of the flag: `-forget-scev-loop-unroll`.
   bool ForgetAllSCEVInLoopUnroll;
 
+  /// Tuning option to enable/disable coroutine intrinsic lowering. Its default
+  /// value is false. Frontends such as Clang may enable this conditionally. For
+  /// example, Clang enables this option if the flags `-std=c++2a` or above, or
+  /// `-fcoroutines-ts`, have been specified.
+  bool Coroutines;
+
   /// Tuning option to cap the number of calls to retrive clobbering accesses in
   /// MemorySSA, in LICM.
   unsigned LicmMssaOptCap;
Index: clang/test/CodeGenCoroutines/coro-newpm-pipeline.cpp
===
--- /dev/null
+++ clang/test/CodeGenCoroutines/coro-newpm-pipeline.cpp
@@ -0,0 +1,57 @@
+// Tests that coroutine passes are added to and run by the new pass manager
+// pipeline, at -O0 and above.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -o /dev/null \
+// RUN:   -fexperimental-new-pass-manager -fdebug-pass-manager -fcoroutines-ts \
+// RUN:   -O0 %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -o /dev/null \
+// RUN:   -fexperimental-new-pass-manager -fdebug-pass-manager -fcoroutines-ts \
+// RUN:   -O1 %s 2>&1 | FileCheck %s
+//
+// CHECK: Starting llvm::Module pass manager run.
+// CHECK: Running pass:{{.*}}CoroEarlyPass
+//
+// The first coro-split pass enqueues a second run of the entire CGSCC pipeline.
+// CHECK: Starting CGSCC pass manager run.
+// CHECK: Running pass: CoroSplitPass on (_Z3foov)
+// CHECK: Running pass:{{.*}}CoroElidePass{{.*}} on (_Z3foov)
+// CHECK: Finished CGSCC pass manager run.
+//
+// The second coro-split pass splits coroutine 'foo' into funclets
+// 'foo.resume', 'foo.destroy', and 'foo.cleanup'.
+// CHECK: Starting CGSCC pass manager run.
+// CHECK: Running pass: CoroSplitPass on (_Z3foov)
+// CHECK: Running pass:{{.*}}CoroElidePass{{.*}} on (_Z3foov)
+// CHECK: Finished CGSCC pass manager run.
+//
+// CHECK: Running pass:{{.*}}CoroCleanupPass
+// CHECK: Finished llvm::Module pass manager run.
+
+namespace std {
+namespace experimental {
+
+struct handle {};
+
+struct awaitable {
+  bool await_ready() { return true; }
+  void await_suspend(handle) {}
+  bool await_resume() { return true; }
+};
+
+template  struct coroutine_handle {
+  static handle from_address(void *address) { return {}; }
+};
+
+template  struct coroutine_traits {
+  struct promise_type {
+awaitable initial_suspend()

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2020-02-13 Thread Andy Kaylor via Phabricator via cfe-commits
andrew.w.kaylor added a subscriber: MaskRay.
andrew.w.kaylor added a comment.

In D74436#1875386 , @thakis wrote:

> The revert of this breaks tests everywhere, as far as I can tell.


It looks like something strange happened with the revert:

> clang-11: warning: overriding '-ffp-model=strict' option with 
> '-ffp-model=strict' [-Woverriding-t-option]

I believe the problem is that the original change that was being reverted 
contained this:

  clang/lib/Driver/ToolChains/Clang.cpp 
  @@ -2768,7 +2766,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
  !AssociativeMath && !ReciprocalMath &&
  SignedZeros && TrappingMath && RoundingFPMath &&
  DenormalFPMath != llvm::DenormalMode::getIEEE() &&
  +FPContract.empty())
  -(FPContract.equals("off") || FPContract.empty()))

But sometime in the land-revert-land-revert cycle the line above that changed, 
causing the merge to miss this change in the most recent revert. I see that 
@MaskRay has since re-landed this change set, but it's going to cause problems 
for PowerPC. If someone needs to revert this yet again, I think it can be 
safely done by recovering the change above.

Apologies for the mess!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436



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


[PATCH] D72553: [clang-tidy] Add performance-prefer-preincrement check

2020-02-13 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 244557.
njames93 added a comment.

- Fix order in release notes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553

Files:
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/performance/CMakeLists.txt
  clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/clang-tidy/performance/PreferPreIncrementCheck.cpp
  clang-tools-extra/clang-tidy/performance/PreferPreIncrementCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/llvm-prefer-pre-increment.rst
  clang-tools-extra/docs/clang-tidy/checks/performance-prefer-pre-increment.rst
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/performance-prefer-pre-increment/iterator.h
  
clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment-disable-cpp-opcalls.cpp
  clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
  
clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp
@@ -0,0 +1,63 @@
+// RUN: %check_clang_tidy %s performance-prefer-pre-increment %t -- -- \
+// RUN: -I%S/Inputs/performance-prefer-pre-increment
+
+#include "iterator.h"
+
+class IntIterator : public Iterator {
+  using Iterator::Iterator;
+};
+
+void foo() {
+  int Array[32];
+  Iterator It(&Array[0]);
+  It++; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++It; // fooNormal
+  It--; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --It; // fooNormal
+  (*It)++; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++(*It); // fooNormal
+  (*It)--; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --(*It); // fooNormal
+  *It++; // fooNormal
+  *It--; // fooNormal
+
+  PostfixIterator PfIt(&Array[0]);
+  PfIt++;// fooPostfix
+  PfIt--;// fooPostfix
+  (*PfIt)++; // fooPostfix
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++(*PfIt); // fooPostfix
+  (*PfIt)--; // fooPostfix
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --(*PfIt); // fooPostfix
+  *PfIt++; // fooPostfix
+  *PfIt--; // fooPostfix
+
+  IntIterator IntIt(&Array[0]);
+  IntIt++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++IntIt;
+  IntIt--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --IntIt;
+  (*IntIt)++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++(*IntIt);
+  (*IntIt)--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --(*IntIt);
+  *IntIt++;
+  *IntIt--;
+}
+
+template 
+void tempDependent(){
+  typename T::iterator it;
+  it++; //depType
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES-NOT: {{^}}  ++it; //depType
+}
Index: clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
@@ -0,0 +1,128 @@
+// RUN: %check_clang_tidy %s performance-prefer-pre-increment %t
+
+#define INC(X) X++
+#define DEC(X) X--
+
+void foo(int A) {
+  for (int I = 0; I < 10; I++) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use pre-increment instead of post-increment
+// CHECK-FIXES: {{^}}  for (int I = 0; I < 10; ++I) {
+  }
+  for (int I = 0; I < 10; ++I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use pre-increment instead of post-increment
+  }
+  for (int I = 0; I < 10; A = I++) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use pre-increment instead of post-increment
+  }
+
+  for (int I = 10; I < 0; I--) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use pre-decrement instead of post-decrement
+// CHECK-FIXES: {{^}}  for (int I = 10; I < 0; --I) {
+  }
+  for (int I = 10; I < 0; --I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use pre-decrement instead of post-decrement
+  }
+  for (int I = 10; I < 0; A = I--)

[PATCH] D72553: [clang-tidy] Add performance-prefer-preincrement check

2020-02-13 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 244555.
njames93 added a comment.

- Added option to enable transforming template dependent types


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553

Files:
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/performance/CMakeLists.txt
  clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/clang-tidy/performance/PreferPreIncrementCheck.cpp
  clang-tools-extra/clang-tidy/performance/PreferPreIncrementCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/llvm-prefer-pre-increment.rst
  clang-tools-extra/docs/clang-tidy/checks/performance-prefer-pre-increment.rst
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/performance-prefer-pre-increment/iterator.h
  
clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment-disable-cpp-opcalls.cpp
  clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
  
clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp
@@ -0,0 +1,63 @@
+// RUN: %check_clang_tidy %s performance-prefer-pre-increment %t -- -- \
+// RUN: -I%S/Inputs/performance-prefer-pre-increment
+
+#include "iterator.h"
+
+class IntIterator : public Iterator {
+  using Iterator::Iterator;
+};
+
+void foo() {
+  int Array[32];
+  Iterator It(&Array[0]);
+  It++; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++It; // fooNormal
+  It--; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --It; // fooNormal
+  (*It)++; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++(*It); // fooNormal
+  (*It)--; // fooNormal
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --(*It); // fooNormal
+  *It++; // fooNormal
+  *It--; // fooNormal
+
+  PostfixIterator PfIt(&Array[0]);
+  PfIt++;// fooPostfix
+  PfIt--;// fooPostfix
+  (*PfIt)++; // fooPostfix
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++(*PfIt); // fooPostfix
+  (*PfIt)--; // fooPostfix
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --(*PfIt); // fooPostfix
+  *PfIt++; // fooPostfix
+  *PfIt--; // fooPostfix
+
+  IntIterator IntIt(&Array[0]);
+  IntIt++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++IntIt;
+  IntIt--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --IntIt;
+  (*IntIt)++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES: {{^}}  ++(*IntIt);
+  (*IntIt)--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-decrement instead of post-decrement
+  // CHECK-FIXES: {{^}}  --(*IntIt);
+  *IntIt++;
+  *IntIt--;
+}
+
+template 
+void tempDependent(){
+  typename T::iterator it;
+  it++; //depType
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use pre-increment instead of post-increment
+  // CHECK-FIXES-NOT: {{^}}  ++it; //depType
+}
\ No newline at end of file
Index: clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
@@ -0,0 +1,128 @@
+// RUN: %check_clang_tidy %s performance-prefer-pre-increment %t
+
+#define INC(X) X++
+#define DEC(X) X--
+
+void foo(int A) {
+  for (int I = 0; I < 10; I++) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use pre-increment instead of post-increment
+// CHECK-FIXES: {{^}}  for (int I = 0; I < 10; ++I) {
+  }
+  for (int I = 0; I < 10; ++I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use pre-increment instead of post-increment
+  }
+  for (int I = 0; I < 10; A = I++) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use pre-increment instead of post-increment
+  }
+
+  for (int I = 10; I < 0; I--) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use pre-decrement instead of post-decrement
+// CHECK-FIXES: {{^}}  for (int I = 10; I < 0; --I) {
+  }
+  for (int I = 10; I < 0; --I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use pre-decrement inst

[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-13 Thread Sean Fertile via Phabricator via cfe-commits
sfertile added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:520
+
+class XLCXXABI final : public ItaniumCXXABI {
+public:

Xiangling_L wrote:
> sfertile wrote:
> > Here would be a good place to add a comment to indicate that XL has several 
> > C++ ABIs, but this represents the one used in 'xlClang++'.
> You mean we have legacy XLC and XLClang++ ABI? But for static init, they have 
> same implementation. So it's not a must to point it out. 
> 
> And also AFAIK, `static init` is the only thing we will differ from Generic 
> Itanium ABI in the frontend, so basically it's the only thing we will add in 
> this ABI.
> 
> I am okay with either way with a little concern that legacy XLC user may 
> wonder is there any difference of static init implementation between XLC and 
> XLClang++ ABI if we add the comment.
Sorry, I had a matching comment on the 'XL' enum, but I must have deleted it 
accidentally before submitting. I said I agreed with using just 'XL' since 
there is only one XL C++ ABI implemented in Clang we don't have to worry about 
differentiating between the 'legacy' XL and the C++11 XL ABIs. If you did want 
to clarify then adding a comment here would be the only thing I suggest.


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

https://reviews.llvm.org/D74015



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

@tra that's great context, thank you very much for writing it up.


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

https://reviews.llvm.org/D74571



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


[clang] 1d49eb0 - [AsmPrinter] De-capitalize all AsmPrinter::Emit* but EmitInstruction

2020-02-13 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-02-13T17:06:24-08:00
New Revision: 1d49eb00d97a8e920ae34ff433419d0cd61641fd

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

LOG: [AsmPrinter] De-capitalize all AsmPrinter::Emit* but EmitInstruction

Similar to rL328848.

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGExprScalar.cpp
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
clang/lib/CodeGen/CodeGenFunction.h
llvm/docs/GarbageCollection.rst
llvm/include/llvm/CodeGen/AsmPrinter.h
llvm/include/llvm/ExecutionEngine/ExecutionEngine.h
llvm/lib/CodeGen/AsmPrinter/ARMException.cpp
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
llvm/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp
llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
llvm/lib/CodeGen/AsmPrinter/EHStreamer.cpp
llvm/lib/CodeGen/AsmPrinter/ErlangGCPrinter.cpp
llvm/lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp
llvm/lib/CodeGen/AsmPrinter/WinException.cpp
llvm/lib/ExecutionEngine/ExecutionEngine.cpp
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.h
llvm/lib/Target/ARM/ARMAsmPrinter.cpp
llvm/lib/Target/ARM/ARMAsmPrinter.h
llvm/lib/Target/Mips/Mips16HardFloat.cpp
llvm/lib/Target/Mips/MipsAsmPrinter.cpp
llvm/lib/Target/Mips/MipsAsmPrinter.h
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
llvm/lib/Target/SystemZ/SystemZAsmPrinter.h
llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp
llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.h
llvm/lib/Target/X86/X86AsmPrinter.cpp
llvm/lib/Target/XCore/XCoreAsmPrinter.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 509400bfc574..77f48b92eb01 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -2164,7 +2164,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
   AlignmentCI = ConstantInt::get(AlignmentCI->getType(),
  llvm::Value::MaximumAlignment);
 
-EmitAlignmentAssumption(PtrValue, Ptr,
+emitAlignmentAssumption(PtrValue, Ptr,
 /*The expr loc is sufficient.*/ SourceLocation(),
 AlignmentCI, OffsetValue);
 return RValue::get(PtrValue);
@@ -14555,7 +14555,7 @@ RValue CodeGenFunction::EmitBuiltinAlignTo(const 
CallExpr *E, bool AlignUp) {
 Result = Builder.CreatePointerCast(Result, Args.SrcType);
 // Emit an alignment assumption to ensure that the new alignment is
 // propagated to loads/stores, etc.
-EmitAlignmentAssumption(Result, E, E->getExprLoc(), Args.Alignment);
+emitAlignmentAssumption(Result, E, E->getExprLoc(), Args.Alignment);
   }
   assert(Result->getType() == Args.SrcType);
   return RValue::get(Result);

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 432058bdc17a..6cc01540febe 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -3906,7 +3906,7 @@ template  class 
AbstractAssumeAlignedAttrEmitter {
   void EmitAsAnAssumption(SourceLocation Loc, QualType RetTy, RValue &Ret) {
 if (!AA)
   return;
-CGF.EmitAlignmentAssumption(Ret.getScalarVal(), RetTy, Loc,
+CGF.emitAlignmentAssumption(Ret.getScalarVal(), RetTy, Loc,
 AA->getLocation(), Alignment, OffsetCI);
 AA = nullptr; // We're done. Disallow doing anything else.
   }

diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index 1f3f4e7b894d..706aa43a5071 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -297,7 +297,7 @@ class ScalarExprEmitter
 
 Value *AlignmentValue = CGF.EmitScalarExpr(AVAttr->getAlignment());
 llvm::ConstantInt *AlignmentCI = cast(AlignmentValue);
-CGF.EmitAlignmentAssumption(V, E, AVAttr->getLocation(), AlignmentCI);
+CGF.emitAlignmentAssumption(V, E, AVAttr->getLocation(), AlignmentCI);
   }
 
   /// EmitLoadOfLValue - Given an expression with complex type that represents 
a

diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index bba7df70fb19..ea9617cc82ac 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -1770,7 +1770,7 @@ static void emitAlignedClause(CodeGenFunction &CGF,
  "alignment is not power of 2");
   if (Alignment != 0) {
 llvm::Value *PtrValue = CGF.EmitScalarExpr(E);
-CGF.EmitAlignmentAssumption(
+CGF.emitAlignmentAssumptio

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2020-02-13 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

The revert of this breaks tests everywhere, as far as I can tell.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436



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


[clang] 0a1123e - Reland D74436 "Change clang option -ffp-model=precise to select ffp-contract=on"

2020-02-13 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-02-13T16:22:03-08:00
New Revision: 0a1123eb43f945593b26dd037490e0c909fa3c4f

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

LOG: Reland D74436 "Change clang option -ffp-model=precise to select 
ffp-contract=on"

Buildbot are failing with the current revert status. So reland with a
fix to fp-model.c

Added: 


Modified: 
clang/docs/UsersManual.rst
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ppc-emmintrin.c
clang/test/CodeGen/ppc-xmmintrin.c
clang/test/Driver/fp-model.c

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 856d5e34bbcc..6c8c9f802082 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1190,8 +1190,50 @@ installed.
 Controlling Floating Point Behavior
 ---
 
-Clang provides a number of ways to control floating point behavior. The options
-are listed below.
+Clang provides a number of ways to control floating point behavior, including
+with command line options and source pragmas. This section
+describes the various floating point semantic modes and the corresponding 
options.
+
+.. csv-table:: Floating Point Semantic Modes
+  :header: "Mode", "Values"
+  :widths: 15, 30, 30
+
+  "except_behavior", "{ignore, strict, may_trap}", "ffp-exception-behavior"
+  "fenv_access", "{off, on}", "(none)"
+  "rounding_mode", "{dynamic, tonearest, downward, upward, towardzero}", 
"frounding-math"
+  "contract", "{on, off, fast}", "ffp-contract"
+  "denormal_fp_math", "{IEEE, PreserveSign, PositiveZero}", "fdenormal-fp-math"
+  "denormal_fp32_math", "{IEEE, PreserveSign, PositiveZero}", 
"fdenormal-fp-math-fp32"
+  "support_math_errno", "{on, off}", "fmath-errno"
+  "no_honor_nans", "{on, off}", "fhonor-nans"
+  "no_honor_infinities", "{on, off}", "fhonor-infinities"
+  "no_signed_zeros", "{on, off}", "fsigned-zeros"
+  "allow_reciprocal", "{on, off}", "freciprocal-math"
+  "allow_approximate_fns", "{on, off}", "(none)"
+  "allow_reassociation", "{on, off}", "fassociative-math"
+
+
+This table describes the option settings that correspond to the three
+floating point semantic models: precise (the default), strict, and fast.
+
+
+.. csv-table:: Floating Point Models
+  :header: "Mode", "Precise", "Strict", "Fast"
+  :widths: 25, 15, 15, 15
+
+  "except_behavior", "ignore", "strict", "ignore"
+  "fenv_access", "off", "on", "off"
+  "rounding_mode", "tonearest", "dynamic", "tonearest"
+  "contract", "on", "off", "fast"
+  "denormal_fp_math", "IEEE", "IEEE", "PreserveSign"
+  "denormal_fp32_math", "IEEE","IEEE", "PreserveSign"
+  "support_math_errno", "on", "on", "off"
+  "no_honor_nans", "off", "off", "on"
+  "no_honor_infinities", "off", "off", "on"
+  "no_signed_zeros", "off", "off", "on"
+  "allow_reciprocal", "off", "off", "on"
+  "allow_approximate_fns", "off", "off", "on"
+  "allow_reassociation", "off", "off", "on"
 
 .. option:: -ffast-math
 
@@ -1385,7 +1427,7 @@ Note that floating-point operations performed as part of 
constant initialization
and ``fast``.
Details:
 
-   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=fast``).  This is the default behavior.
+   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=on``).  This is the default behavior.
* ``strict`` Enables ``-frounding-math`` and 
``-ffp-exception-behavior=strict``, and disables contractions (FMA).  All of 
the ``-ffast-math`` enablements are disabled.
* ``fast`` Behaves identically to specifying both ``-ffast-math`` and 
``ffp-contract=fast``
 

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 5a207f3ca9f7..d1197556aeef 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2525,10 +2525,9 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
 
   llvm::DenormalMode DenormalFPMath = DefaultDenormalFPMath;
   llvm::DenormalMode DenormalFP32Math = DefaultDenormalFP32Math;
-  StringRef FPContract = "";
+  StringRef FPContract = "on";
   bool StrictFPModel = false;
 
-
   if (const Arg *A = Args.getLastArg(options::OPT_flimited_precision_EQ)) {
 CmdArgs.push_back("-mlimit-float-precision");
 CmdArgs.push_back(A->getValue());
@@ -2551,7 +2550,6 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
   SignedZeros = true;
   // -fno_fast_math restores default denormal and fpcontract handling
   DenormalFPMath = DefaultDenormalFPMath;
-  FPContract = "";
   StringRef Val = A->getValue();
 

[PATCH] D74386: [SVE] Update API ConstantVector::getSplat() to use ElementCount.

2020-02-13 Thread Huihui Zhang via Phabricator via cfe-commits
huihuiz updated this revision to Diff 244546.
huihuiz marked 2 inline comments as done.
huihuiz added a comment.

Thanks Eli for the review!

Add test cases to check for size query changes in 
ConstantExpr::getGetElementPtr().


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74386

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/Analysis/Utils/Local.h
  llvm/include/llvm/IR/Constants.h
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/IR/ConstantFold.cpp
  llvm/lib/IR/Constants.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
  llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/InstSimplify/gep.ll
  llvm/unittests/FuzzMutate/OperationsTest.cpp
  llvm/unittests/IR/VerifierTest.cpp

Index: llvm/unittests/IR/VerifierTest.cpp
===
--- llvm/unittests/IR/VerifierTest.cpp
+++ llvm/unittests/IR/VerifierTest.cpp
@@ -57,7 +57,7 @@
   ConstantInt *CI = ConstantInt::get(ITy, 0);
 
   // Valid type : freeze(<2 x i32>)
-  Constant *CV = ConstantVector::getSplat(2, CI);
+  Constant *CV = ConstantVector::getSplat({2, false}, CI);
   FreezeInst *FI_vec = new FreezeInst(CV);
   FI_vec->insertBefore(RI);
 
Index: llvm/unittests/FuzzMutate/OperationsTest.cpp
===
--- llvm/unittests/FuzzMutate/OperationsTest.cpp
+++ llvm/unittests/FuzzMutate/OperationsTest.cpp
@@ -92,8 +92,8 @@
   ConstantStruct::get(StructType::create(Ctx, "OpaqueStruct"));
   Constant *a =
   ConstantArray::get(ArrayType::get(i32->getType(), 2), {i32, i32});
-  Constant *v8i8 = ConstantVector::getSplat(8, i8);
-  Constant *v4f16 = ConstantVector::getSplat(4, f16);
+  Constant *v8i8 = ConstantVector::getSplat({8, false}, i8);
+  Constant *v4f16 = ConstantVector::getSplat({4, false}, f16);
   Constant *p0i32 =
   ConstantPointerNull::get(PointerType::get(i32->getType(), 0));
 
Index: llvm/test/Transforms/InstSimplify/gep.ll
===
--- llvm/test/Transforms/InstSimplify/gep.ll
+++ llvm/test/Transforms/InstSimplify/gep.ll
@@ -103,3 +103,69 @@
   ret <8 x i64*> %el
 }
 
+; Check ConstantExpr::getGetElementPtr() using ElementCount for size queries - begin.
+
+; Constant ptr
+
+define i32* @ptr_idx_scalar() {
+; CHECK-LABEL: @ptr_idx_scalar(
+; CHECK-NEXT:ret i32* inttoptr (i64 4 to i32*)
+;
+  %gep = getelementptr <4 x i32>, <4 x i32>* null, i64 0, i64 1
+  ret i32* %gep
+}
+
+define <2 x i32*> @ptr_idx_vector() {
+; CHECK-LABEL: @ptr_idx_vector(
+; CHECK-NEXT:ret <2 x i32*> getelementptr (i32, i32* null, <2 x i64> )
+;
+  %gep = getelementptr i32, i32* null, <2 x i64> 
+  ret <2 x i32*> %gep
+}
+
+define <4 x i32*> @ptr_idx_mix_scalar_vector(){
+; CHECK-LABEL: @ptr_idx_mix_scalar_vector(
+; CHECK-NEXT:ret <4 x i32*> getelementptr ([42 x [3 x i32]], [42 x [3 x i32]]* null, <4 x i64> zeroinitializer, <4 x i64> , <4 x i64> zeroinitializer)
+;
+  %gep = getelementptr [42 x [3 x i32]], [42 x [3 x i32]]* null, i64 0, <4 x i64> , i64 0
+  ret <4 x i32*> %gep
+}
+
+; Constant vector
+
+define <4 x i32*> @vector_idx_scalar() {
+; CHECK-LABEL: @vector_idx_scalar(
+; CHECK-NEXT:ret <4 x i32*> getelementptr (i32, <4 x i32*> zeroinitializer, <4 x i64> )
+;
+  %gep = getelementptr i32, <4 x i32*> zeroinitializer, i64 1
+  ret <4 x i32*> %gep
+}
+
+define <4 x i32*> @vector_idx_vector() {
+; CHECK-LABEL: @vector_idx_vector(
+; CHECK-NEXT:ret <4 x i32*> getelementptr (i32, <4 x i32*> zeroinitializer, <4 x i64> )
+;
+  %gep = getelementptr i32, <4 x i32*> zeroinitializer, <4 x i64> 
+  ret <4 x i32*> %gep
+}
+
+%struct = type { double, float }
+define <4 x float*> @vector_idx_mix_scalar_vector() {
+; CHECK-LABEL: @vector_idx_mix_scalar_vector(
+; CHECK-NEXT:ret <4 x float*> getelementptr (%struct, <4 x %struct*> zeroinitializer, <4 x i64> zeroinitializer, <4 x i32> )
+;
+  %gep = getelementptr %struct, <4 x %struct*> zeroinitializer, i32 0, <4 x i32> 
+  ret <4 x float*> %gep
+}
+
+; Constant scalable
+
+define  @scalable_idx_scalar() {
+; CHECK-LABEL: @scalable_idx_scalar(
+; CHECK-NEXT:ret  getelementptr (i32,  zeroinitializer,  shufflevector ( insertelement ( undef, i64 1, i32 0),  undef,  zeroinitializer))
+;
+  %gep = getelementptr i32,  zeroinitializer, i64 1
+  ret  %gep
+}
+
+; Check ConstantExpr::getGetElementPtr() using ElementCount for size queries - end.
Index: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
===
--- llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -1726,9 +1726,10 @@
   // FIXME: If the step is non-constant, we create the vector splat with
   //IRBuilder. IRBuilder can constant-fol

[PATCH] D71830: [OpenMP][Part 2] Use reusable OpenMP context/traits handling

2020-02-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert marked 11 inline comments as done.
jdoerfert added inline comments.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:367
   } else {
-llvm_unreachable("Unknown SimpleArgument type!");
+OS << "if (SA->get" << getUpperName() << "())\n  ";
+OS << "  OS << \" \" << *SA->get" << getUpperName() << "();\n";

aaron.ballman wrote:
> Can we leave the unreachable in there and add actual checking for this case? 
> The unreachable is intended to remind people "do this work when you're 
> mucking about in here" and silently doing something that may or may not be 
> wrong makes this harder to spot.
Overlooked this one, sorry. Will fix it and make it unreachable again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71830



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


[PATCH] D71830: [OpenMP][Part 2] Use reusable OpenMP context/traits handling

2020-02-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/AST/OpenMPClause.cpp:1723
+llvm::APInt CondVal =
+Selector.ScoreOrCondition->EvaluateKnownConstInt(ASTCtx);
+if (CondVal.isNullValue())

aaron.ballman wrote:
> jdoerfert wrote:
> > aaron.ballman wrote:
> > > I didn't see anything that validated that this is known to be a constant 
> > > expression. Did I miss something?
> > > 
> > > Also, is there anything checking that the expression is not value 
> > > dependent?
> > > I didn't see anything that validated that this is known to be a constant 
> > > expression. Did I miss something? 
> > 
> > I'll look into that and make sure we check in the parser.
> > 
> > > Also, is there anything checking that the expression is not value 
> > > dependent?
> > 
> > That should be fine. If it is attached to a template it is instantiated 
> > with the template. Or am I missing something?
> > That should be fine. If it is attached to a template it is instantiated 
> > with the template. Or am I missing something?
> 
> `EvaluateKnownConstInt()` asserts that the expression is not value dependent, 
> so I just wanted to be certain that assertion wouldn't trigger. Sounds like 
> it won't because this should only be called on an instantiation?
I added detection and tests for constant, value-dependent, and non-constant 
expressions in score and user condition. Assuming I didn't miss anything it 
should not assert here.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:1379
   // Parse inner context selectors.
-  SmallVector Data;
-  if (!parseOpenMPContextSelectors(Loc, Data)) {
-// Parse ')'.
-(void)T.consumeClose();
-// Need to check for extra tokens.
-if (Tok.isNot(tok::annot_pragma_openmp_end)) {
-  Diag(Tok, diag::warn_omp_extra_tokens_at_eol)
-  << getOpenMPDirectiveName(OMPD_declare_variant);
-}
-  }
+  OMPTraitInfo *TI = new OMPTraitInfo();
+  parseOMPContextSelectors(Loc, *TI);

jdoerfert wrote:
> aaron.ballman wrote:
> > What is responsible for freeing this memory?
> Will check and fix if needed.
I made sure all OMPTraitInfo are freed, I think. If an `OMPDeclareVariantAttr` 
is build its taking owenership and calls delete in the destructor.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:110
   .Case("ParamIdx", "ParamIdx::deserialize(Record.readInt())")
+  .EndsWith("*", "Record.readUserType<" +
+ std::string(type.data(), 0, type.size() - 1) + ">()")

aaron.ballman wrote:
> jdoerfert wrote:
> > aaron.ballman wrote:
> > > The idea here being that if someone adds a `GenericPointerArg`, they'll 
> > > have to add a specialization of `readUserType<>` for that named pointer 
> > > type or else get template instantiation errors because there's no 
> > > definition for the primary template?
> > Correct.
> I like it. :-)
It's gone now ;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71830



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D74571#1875296 , @JonChesterfield 
wrote:

> Interesting distinction.
>
> Should compiling without warning indicate comprehensive support, or merely 
> that we ran the tests and they passed?


The test in LLVM do have very limited testing to CUDA-versioned things and at 
the moment they have no tests for anything specific to 10.2.

> I assumed the latter on the basis that we probably don't have comprehensive 
> support for cuda 10.1 either. No preference either way though.

On LLVM side I believe we have almost everything that came with PTX6.4 which 
arrived in CUDA-10.1.
Clang also has the necessary builtins plumbed through. That's not the case for 
PTX6.5 & CUDA-10.2.
Most of the CUDA testing is done in the test-suite and updating it for 
CUDA-10.2 is another TODO item.
At the moment all we can infer from the passing tests is that we didn't break 
CUDA-10.1 functionality.
If we could force users to never use any new features from 10.2, then we could 
have declared mission accomplished.
As things stand right now, it would be a matter of time when the actual lack of 
support would start manifesting itself.

In the past I did now and then do something similar to this patch, allowing 
compilation 
with the new CUDA version without adding the features that come with that 
version. 
Arguably it was better than not being able to compile at all, but I did end up 
with a fair share 
of users trying to compile some code that relied on the latest and greatest 
CUDA features 
only to see things fail with odd error messages -- PTX reporting syntax errors, 
clang complaining about unknown functions.

The "warn and assume the last known version" was the best compromise I managed 
to come up with. 
You can *try* using it with a newer CUDA version before someone gets to 
implement the missing bits, 
but whether it will work is very much a YMMV situation. For those who find it 
acceptable, 
there's a big red "Trust me, I know what I'm doing" button in form of 
`-Wno-cuda-unknown-version`.
Everybody else gets a somewhat informative warning explaining what's going on.


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

https://reviews.llvm.org/D74571



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


[PATCH] D74554: [ASTImporter] Added visibility check for scoped enums.

2020-02-13 Thread Aleksei Sidorin via Phabricator via cfe-commits
a_sidorin accepted this revision.
a_sidorin added inline comments.



Comment at: clang/unittests/AST/ASTImporterTest.cpp:4870
+  Decl *ToTU = getToTuDecl(
+  R"(
+  enum class E;

Maybe it's better to use just non-raw string literals here?
```
Decl *ToTU = getToTuDecl("enum class E;");
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74554



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


[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2020-02-13 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

@jsji Will your backend tolerate -ffp-contract=on if optimizations are not 
disabled, e.g. -O2?  We are proposing that the default floating point model be 
-ffp-model=precise, and with precise model, the ffp-contract=on. However you 
are right we don't want the frontend to create FMA when optimizations are 
disabled -O0


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436



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


[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2020-02-13 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

> You're right, -O0 shouldn't generate FMA. I'm preparing to revert this now -- 
> just verifying the build.

Perhaps this should be
`off` with no optimization
`on` with `-O1/-O2/-O3/-Os/-Oz`
`fast` with fast math

Just a suggestion, I'm not sure whether that would be the best breakdown. 
Perhaps we can also see what the defaults are for GCC and unify with those?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436



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


[clang] 88ec01c - Revert "Revert "Revert "Change clang option -ffp-model=precise to select ffp-contract=on"""

2020-02-13 Thread Melanie Blower via cfe-commits

Author: Melanie Blower
Date: 2020-02-13T15:06:12-08:00
New Revision: 88ec01ca1bfa4c3a29225db93d36e6d32278190d

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

LOG: Revert "Revert "Revert "Change clang option -ffp-model=precise to select 
ffp-contract=on"""

This reverts commit abd09053bc7aa6144873c196a7d50aa6ce6ca430.
It's causing internal buildbot fails on ppc

Conflicts:
clang/lib/Driver/ToolChains/Clang.cpp

Added: 


Modified: 
clang/docs/UsersManual.rst
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ppc-emmintrin.c
clang/test/CodeGen/ppc-xmmintrin.c
clang/test/Driver/fp-model.c

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 6c8c9f802082..856d5e34bbcc 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1190,50 +1190,8 @@ installed.
 Controlling Floating Point Behavior
 ---
 
-Clang provides a number of ways to control floating point behavior, including
-with command line options and source pragmas. This section
-describes the various floating point semantic modes and the corresponding 
options.
-
-.. csv-table:: Floating Point Semantic Modes
-  :header: "Mode", "Values"
-  :widths: 15, 30, 30
-
-  "except_behavior", "{ignore, strict, may_trap}", "ffp-exception-behavior"
-  "fenv_access", "{off, on}", "(none)"
-  "rounding_mode", "{dynamic, tonearest, downward, upward, towardzero}", 
"frounding-math"
-  "contract", "{on, off, fast}", "ffp-contract"
-  "denormal_fp_math", "{IEEE, PreserveSign, PositiveZero}", "fdenormal-fp-math"
-  "denormal_fp32_math", "{IEEE, PreserveSign, PositiveZero}", 
"fdenormal-fp-math-fp32"
-  "support_math_errno", "{on, off}", "fmath-errno"
-  "no_honor_nans", "{on, off}", "fhonor-nans"
-  "no_honor_infinities", "{on, off}", "fhonor-infinities"
-  "no_signed_zeros", "{on, off}", "fsigned-zeros"
-  "allow_reciprocal", "{on, off}", "freciprocal-math"
-  "allow_approximate_fns", "{on, off}", "(none)"
-  "allow_reassociation", "{on, off}", "fassociative-math"
-
-
-This table describes the option settings that correspond to the three
-floating point semantic models: precise (the default), strict, and fast.
-
-
-.. csv-table:: Floating Point Models
-  :header: "Mode", "Precise", "Strict", "Fast"
-  :widths: 25, 15, 15, 15
-
-  "except_behavior", "ignore", "strict", "ignore"
-  "fenv_access", "off", "on", "off"
-  "rounding_mode", "tonearest", "dynamic", "tonearest"
-  "contract", "on", "off", "fast"
-  "denormal_fp_math", "IEEE", "IEEE", "PreserveSign"
-  "denormal_fp32_math", "IEEE","IEEE", "PreserveSign"
-  "support_math_errno", "on", "on", "off"
-  "no_honor_nans", "off", "off", "on"
-  "no_honor_infinities", "off", "off", "on"
-  "no_signed_zeros", "off", "off", "on"
-  "allow_reciprocal", "off", "off", "on"
-  "allow_approximate_fns", "off", "off", "on"
-  "allow_reassociation", "off", "off", "on"
+Clang provides a number of ways to control floating point behavior. The options
+are listed below.
 
 .. option:: -ffast-math
 
@@ -1427,7 +1385,7 @@ Note that floating-point operations performed as part of 
constant initialization
and ``fast``.
Details:
 
-   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=on``).  This is the default behavior.
+   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=fast``).  This is the default behavior.
* ``strict`` Enables ``-frounding-math`` and 
``-ffp-exception-behavior=strict``, and disables contractions (FMA).  All of 
the ``-ffast-math`` enablements are disabled.
* ``fast`` Behaves identically to specifying both ``-ffast-math`` and 
``ffp-contract=fast``
 

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index d1197556aeef..5a207f3ca9f7 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2525,9 +2525,10 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
 
   llvm::DenormalMode DenormalFPMath = DefaultDenormalFPMath;
   llvm::DenormalMode DenormalFP32Math = DefaultDenormalFP32Math;
-  StringRef FPContract = "on";
+  StringRef FPContract = "";
   bool StrictFPModel = false;
 
+
   if (const Arg *A = Args.getLastArg(options::OPT_flimited_precision_EQ)) {
 CmdArgs.push_back("-mlimit-float-precision");
 CmdArgs.push_back(A->getValue());
@@ -2550,6 +2551,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
   SignedZeros = true;
   // -fno_fast_math restores default denormal and fpcontract handling
   DenormalFPMath

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2020-02-13 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

In D74436#1875273 , @jsji wrote:

> This is also breaking test-suites in our internal buildbots ..
>
> This change is actually changing the default behavior: if user does NOT 
> supply `-ffp-contract`, it becomes `-ffp-contract=on`.
>
> So this means any code without explicitly add `-ffp-contract=off` will have 
> `-ffp-contract=on`.
>  eg: -O0 will also generate FMA.
>
> Is this intended behavior change?   @mibintc @andrew.w.kaylor


You're right, -O0 shouldn't generate FMA. I'm preparing to revert this now -- 
just verifying the build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Interesting distinction.

Should compiling without warning indicate comprehensive support, or merely that 
we ran the tests and they passed?

I assumed the latter on the basis that we probably don't have comprehensive 
support for cuda 10.1 either. No preference either way though.


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

https://reviews.llvm.org/D74571



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


[PATCH] D74554: [ASTImporter] Added visibility check for scoped enums.

2020-02-13 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik accepted this revision.
shafik 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/D74554/new/

https://reviews.llvm.org/D74554



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


[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2020-02-13 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added a comment.

This is also breaking test-suites in our internal buildbots ..

This change is actually changing the default behavior: if user does NOT supply 
`-ffp-contract`, it becomes `-ffp-contract=on`.

So this means any code without explicitly add `-ffp-contract=off` will have 
`-ffp-contract=on`.
eg: -O0 will also generate FMA.

Is this intended behavior change?   @mibintc @andrew.w.kaylor


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436



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


[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-13 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L marked 3 inline comments as done.
Xiangling_L added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:520
+
+class XLCXXABI final : public ItaniumCXXABI {
+public:

sfertile wrote:
> Here would be a good place to add a comment to indicate that XL has several 
> C++ ABIs, but this represents the one used in 'xlClang++'.
You mean we have legacy XLC and XLClang++ ABI? But for static init, they have 
same implementation. So it's not a must to point it out. 

And also AFAIK, `static init` is the only thing we will differ from Generic 
Itanium ABI in the frontend, so basically it's the only thing we will add in 
this ABI.

I am okay with either way with a little concern that legacy XLC user may wonder 
is there any difference of static init implementation between XLC and XLClang++ 
ABI if we add the comment.


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

https://reviews.llvm.org/D74015



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


[clang] f7e2227 - [clang] Fix bad line ending (DOS instead of Unix) inside the release notes.

2020-02-13 Thread via cfe-commits

Author: Wawha
Date: 2020-02-13T22:52:28+01:00
New Revision: f7e2227832a6691bf2d07cebf4bd772d5eafbe1a

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

LOG: [clang] Fix bad line ending (DOS instead of Unix) inside the release notes.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e0a15f8d38a1..b98abc82d247 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1,291 +1,291 @@
-
-Clang 11.0.0 (In-Progress) Release Notes
-
-
-.. contents::
-   :local:
-   :depth: 2
-
-Written by the `LLVM Team `_
-
-.. warning::
-
-   These are in-progress notes for the upcoming Clang 11 release.
-   Release notes for previous releases can be found on
-   `the Download Page `_.
-
-Introduction
-
-
-This document contains the release notes for the Clang C/C++/Objective-C
-frontend, part of the LLVM Compiler Infrastructure, release 11.0.0. Here we
-describe the status of Clang in some detail, including major
-improvements from the previous release and new feature work. For the
-general LLVM release notes, see `the LLVM
-documentation `_. All LLVM
-releases may be downloaded from the `LLVM releases web
-site `_.
-
-For more information about Clang or LLVM, including information about the
-latest release, please see the `Clang Web Site `_ or 
the
-`LLVM Web Site `_.
-
-Note that if you are reading this file from a Git checkout or the
-main Clang web page, this document applies to the *next* release, not
-the current one. To see the release notes for a specific release, please
-see the `releases page `_.
-
-What's New in Clang 11.0.0?
-===
-
-Some of the major new features and improvements to Clang are listed
-here. Generic improvements to Clang as a whole or to its underlying
-infrastructure are described first, followed by language-specific
-sections with improvements to Clang's support for those languages.
-
-Major New Features
---
-
-- ...
-
-Improvements to Clang's diagnostics
-^^^
-
-- ...
-
-Non-comprehensive list of changes in this release
--
-
-
-New Compiler Flags
---
-
-
-- -fstack-clash-protection will provide a protection against the stack clash
-  attack for x86 architecture through automatic probing of each page of
-  allocated stack.
-
-Deprecated Compiler Flags
--
-
-The following options are deprecated and ignored. They will be removed in
-future versions of Clang.
-
-- ...
-
-Modified Compiler Flags

-
-
-New Pragmas in Clang
-
-
-- ...
-
-Attribute Changes in Clang
---
-
-- ...
-
-Windows Support

-
-C Language Changes in Clang

-
-- ...
-
-C11 Feature Support
-^^^
-
-...
-
-C++ Language Changes in Clang
--
-
-- Clang now implements a restriction on giving non-C-compatible anonymous
-  structs a typedef name for linkage purposes, as described in C++ committee
-  paper `P1766R1 `. This paper was adopted by the
-  C++ committee as a Defect Report resolution, so it is applied retroactively
-  to all C++ standard versions. This affects code such as:
-
-  .. code-block:: c++
-
-typedef struct {
-  int f() { return 0; }
-} S;
-
-  Previous versions of Clang rejected some constructs of this form
-  (specifically, where the linkage of the type happened to be computed
-  before the parser reached the typedef name); those cases are still rejected
-  in Clang 11.  In addition, cases that previous versions of Clang did not
-  reject now produce an extension warning. This warning can be disabled with
-  the warning flag ``-Wno-non-c-typedef-for-linkage``.
-
-  Affected code should be updated to provide a tag name for the anonymous
-  struct:
-
-  .. code-block:: c++
-
-struct S {
-  int f() { return 0; }
-};
-
-  If the code is shared with a C compilation (for example, if the parts that
-  are not C-compatible are guarded with ``#ifdef __cplusplus``), the typedef
-  declaration should be retained, but a tag name should still be provided:
-
-  .. code-block:: c++
-
-typedef struct S {
-  int f() { return 0; }
-} S;
-
-C++1z Feature Support
-^
-
-...
-
-Objective-C Language Changes in Clang
--

[PATCH] D74542: [ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs.

2020-02-13 Thread Aleksei Sidorin via Phabricator via cfe-commits
a_sidorin accepted this revision.
a_sidorin added a comment.

Nice solution!


Repository:
  rC Clang

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

https://reviews.llvm.org/D74542



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


[PATCH] D74572: [WIP][BPF] implement intrinsic function __builtin__btf_type_id()

2020-02-13 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song updated this revision to Diff 244529.
yonghong-song edited the summary of this revision.
yonghong-song added a comment.
Herald added a subscriber: ormris.

add the type_id assignment to FieldInfo relocation .btf.ext ELF section.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74572

Files:
  clang/include/clang/Basic/BuiltinsBPF.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  llvm/include/llvm/IR/IntrinsicsBPF.td
  llvm/lib/Target/BPF/BPF.h
  llvm/lib/Target/BPF/BPFCORE.h
  llvm/lib/Target/BPF/BPFMIPreserveDIType.cpp
  llvm/lib/Target/BPF/BPFPreserveDIType.cpp
  llvm/lib/Target/BPF/BPFTargetMachine.cpp
  llvm/lib/Target/BPF/BTFDebug.cpp
  llvm/lib/Target/BPF/BTFDebug.h
  llvm/lib/Target/BPF/CMakeLists.txt
  llvm/test/CodeGen/BPF/BTF/builtin-btf-type-id.ll

Index: llvm/test/CodeGen/BPF/BTF/builtin-btf-type-id.ll
===
--- /dev/null
+++ llvm/test/CodeGen/BPF/BTF/builtin-btf-type-id.ll
@@ -0,0 +1,147 @@
+; RUN: llc -march=bpfel -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+; RUN: llc -march=bpfeb -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+; RUN: llc -march=bpfel -mattr=+alu32 -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+; RUN: llc -march=bpfeb -mattr=+alu32 -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+;
+; Source code:
+;   static int (*bpf_log)(unsigned tid, void *data, int data_size) = (void *)999;
+;   struct {
+; char f1[100];
+; typeof(3) f2;
+;   } tmp__abc = {1, 3};
+;   void prog1() {
+; bpf_log(__builtin_btf_type_id(tmp__abc), &tmp__abc, sizeof(tmp__abc));
+;   }
+;   void prog2() {
+; bpf_log(__builtin_btf_type_id(&tmp__abc), &tmp__abc, sizeof(tmp__abc));
+;   }
+;   void prog3() {
+; bpf_log(__builtin_btf_type_id(tmp__abc.f1[3]), &tmp__abc, sizeof(tmp__abc));
+;   }
+; Compilation flag:
+;   clang -target bpf -O2 -g -S -emit-llvm test.c
+
+%struct.anon = type { [100 x i8], i32 }
+
+@tmp__abc = dso_local global { <{ i8, i8, [98 x i8] }>, i32 } { <{ i8, i8, [98 x i8] }> <{ i8 1, i8 3, [98 x i8] zeroinitializer }>, i32 0 }, align 4, !dbg !0
+
+; Function Attrs: nounwind
+define dso_local void @prog1() local_unnamed_addr #0 !dbg !28 {
+entry:
+  %0 = tail call i32 @llvm.bpf.btf.type.id.p0s_struct.anons.i32(%struct.anon* bitcast ({ <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc to %struct.anon*), i32 1), !dbg !31, !llvm.preserve.access.index !7
+  %call = tail call i32 inttoptr (i64 999 to i32 (i32, i8*, i32)*)(i32 %0, i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 0), i32 104) #2, !dbg !32
+  ret void, !dbg !33
+}
+
+; Function Attrs: nounwind readnone
+declare i32 @llvm.bpf.btf.type.id.p0s_struct.anons.i32(%struct.anon*, i32) #1
+
+; Function Attrs: nounwind
+define dso_local void @prog2() local_unnamed_addr #0 !dbg !34 {
+entry:
+  %0 = tail call i32 @llvm.bpf.btf.type.id.p0s_struct.anons.i32(%struct.anon* bitcast ({ <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc to %struct.anon*), i32 0), !dbg !35, !llvm.preserve.access.index !6
+  %call = tail call i32 inttoptr (i64 999 to i32 (i32, i8*, i32)*)(i32 %0, i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 0), i32 104) #2, !dbg !36
+  ret void, !dbg !37
+}
+
+; Function Attrs: nounwind
+define dso_local void @prog3() local_unnamed_addr #0 !dbg !38 {
+entry:
+  %0 = tail call i32 @llvm.bpf.btf.type.id.p0i8.i32(i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 2, i64 1), i32 1), !dbg !39, !llvm.preserve.access.index !11
+  %call = tail call i32 inttoptr (i64 999 to i32 (i32, i8*, i32)*)(i32 %0, i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 0), i32 104) #2, !dbg !40
+  ret void, !dbg !41
+}
+
+; CHECK-LABEL:   prog1
+; CHECK: r1 = 3
+; CHECK-LABEL:   prog2
+; CHECK: r1 = 10
+; CHECK-LABEL:   prog3
+; CHECK: r1 = 4
+;
+; CHECK: .long   0   # BTF_KIND_STRUCT(id = 3)
+; CHECK-NEXT:.long   67108866# 0x402
+; CHECK-NEXT:.long   104
+; CHECK-NEXT:.long   13
+; CHECK-NEXT:.long   5
+; CHECK-NEXT:.long   0   # 0x0
+; CHECK-NEXT:.long   16
+; CHECK-NEXT:.long   7
+; CHECK-NEXT:.long   800 # 0x320
+; CHECK-NEXT:.long   19  # BTF_KIND_INT(id = 4)
+; CHECK-NEXT:.long   16777216# 0x100
+; CHECK-NEXT:.long   1
+; CHECK-NEXT:.long   16777224# 0x108
+; CHECK: .long   0   # BTF_KIND_PTR(id = 10)
+; CHECK-NEXT:.long   33554432# 0x200
+; CHECK-NEXT:.

[PATCH] D74513: [OpenMP][NFCI] Use the libFrontend DefaultKind in Clang

2020-02-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D74513#1874825 , @atmnpatel wrote:

> I am unable to commit this myself, can someone commit for me?


I'll do that later. Ping me if I forget please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74513



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


[PATCH] D44609: [clang-format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

2020-02-13 Thread Francois JEAN via Phabricator via cfe-commits
Wawha added a comment.

In D44609#1871612 , @MyDeveloperDay 
wrote:

> Correct follow that description on how to request commit access


It's done. I have the commit right, and push that change on github : 
https://github.com/llvm/llvm-project/commit/fa0118e6e588fe303b08e7e06ba28ac1f8d50c68

Thank you for the review and advices!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D44609



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


[PATCH] D44609: [clang-format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

2020-02-13 Thread Francois JEAN via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfa0118e6e588: [clang-format] Add new option BeforeLambdaBody 
in Allman style. (authored by Wawha).
Herald added a reviewer: jdoerfert.

Changed prior to commit:
  https://reviews.llvm.org/D44609?vs=241875&id=244523#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D44609

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12673,6 +12673,7 @@
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterExternBlock);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeCatch);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeElse);
+  CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeLambdaBody);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, IndentBraces);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, SplitEmptyFunction);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, SplitEmptyRecord);
@@ -13962,6 +13963,245 @@
"function([]() { return b; }, a)", MergeInline);
   verifyFormat("function(a, []() { return b; })",
"function(a, []() { return b; })", MergeInline);
+
+  // Check option "BraceWrapping.BeforeLambdaBody" and different state of
+  // AllowShortLambdasOnASingleLine
+  FormatStyle LLVMWithBeforeLambdaBody = getLLVMStyle();
+  LLVMWithBeforeLambdaBody.BreakBeforeBraces = FormatStyle::BS_Custom;
+  LLVMWithBeforeLambdaBody.BraceWrapping.BeforeLambdaBody = true;
+  LLVMWithBeforeLambdaBody.AllowShortLambdasOnASingleLine =
+  FormatStyle::ShortLambdaStyle::SLS_None;
+  verifyFormat("FctWithOneNestedLambdaInline_SLS_None(\n"
+   "[]()\n"
+   "{\n"
+   "  return 17;\n"
+   "});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("FctWithOneNestedLambdaEmpty_SLS_None(\n"
+   "[]()\n"
+   "{\n"
+   "});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto fct_SLS_None = []()\n"
+   "{\n"
+   "  return 17;\n"
+   "};",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("TwoNestedLambdas_SLS_None(\n"
+   "[]()\n"
+   "{\n"
+   "  return Call(\n"
+   "  []()\n"
+   "  {\n"
+   "return 17;\n"
+   "  });\n"
+   "});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("void Fct()\n"
+   "{\n"
+   "  return {[]()\n"
+   "  {\n"
+   "return 17;\n"
+   "  }};\n"
+   "}",
+   LLVMWithBeforeLambdaBody);
+
+  LLVMWithBeforeLambdaBody.AllowShortLambdasOnASingleLine =
+  FormatStyle::ShortLambdaStyle::SLS_Empty;
+  verifyFormat("FctWithOneNestedLambdaInline_SLS_Empty(\n"
+   "[]()\n"
+   "{\n"
+   "  return 17;\n"
+   "});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("FctWithOneNestedLambdaEmpty_SLS_Empty([]() {});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("FctWithOneNestedLambdaEmptyInsideAVeryVeryVeryVeryVeryVeryVeryL"
+   "ongFunctionName_SLS_Empty(\n"
+   "[]() {});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("FctWithMultipleParams_SLS_Empty(A, B,\n"
+   "[]()\n"
+   "{\n"
+   "  return 17;\n"
+   "});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto fct_SLS_Empty = []()\n"
+   "{\n"
+   "  return 17;\n"
+   "};",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("TwoNestedLambdas_SLS_Empty(\n"
+   "[]()\n"
+   "{\n"
+   "  return Call([]() {});\n"
+   "});",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("TwoNestedLambdas_SLS_Empty(A,\n"
+   "   []()\n"
+   "   {\n"
+   " return Call([]() {});\n"
+   "   });",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat(
+  "FctWithLongLineInLambda_SLS_Empty(\n"
+  "[]()\n"
+  "{\n"
+  "  return HereAVeryLongLine(ThatWillB

[clang] fa0118e - [clang-format] Add new option BeforeLambdaBody in Allman style.

2020-02-13 Thread via cfe-commits

Author: Wawha
Date: 2020-02-13T22:16:41+01:00
New Revision: fa0118e6e588fe303b08e7e06ba28ac1f8d50c68

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

LOG: [clang-format] Add new option BeforeLambdaBody in Allman style.

This option add a line break then a lambda is inside a function call.

Reviewers : djasper, klimek, krasimir, MyDeveloperDay

Reviewed By: MyDeveloperDay

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

Added: 


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

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 0c515922e650..50b4ff5d9010 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -968,6 +968,24 @@ the configuration (without a prefix: ``Auto``).
   } else {
   }
 
+  * ``bool BeforeLambdaBody`` Wrap lambda block.
+
+.. code-block:: c++
+
+  true:
+  connect(
+[]()
+{
+  foo();
+  bar();
+});
+
+  false:
+  connect([]() {
+foo();
+bar();
+  });
+
   * ``bool IndentBraces`` Indent the wrapped braces themselves.
 
   * ``bool SplitEmptyFunction`` If ``false``, empty function body can be put 
on a single line.

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index d24cd85673c6..e0a15f8d38a1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1,272 +1,291 @@
-
-Clang 11.0.0 (In-Progress) Release Notes
-
-
-.. contents::
-   :local:
-   :depth: 2
-
-Written by the `LLVM Team `_
-
-.. warning::
-
-   These are in-progress notes for the upcoming Clang 11 release.
-   Release notes for previous releases can be found on
-   `the Download Page `_.
-
-Introduction
-
-
-This document contains the release notes for the Clang C/C++/Objective-C
-frontend, part of the LLVM Compiler Infrastructure, release 11.0.0. Here we
-describe the status of Clang in some detail, including major
-improvements from the previous release and new feature work. For the
-general LLVM release notes, see `the LLVM
-documentation `_. All LLVM
-releases may be downloaded from the `LLVM releases web
-site `_.
-
-For more information about Clang or LLVM, including information about the
-latest release, please see the `Clang Web Site `_ or 
the
-`LLVM Web Site `_.
-
-Note that if you are reading this file from a Git checkout or the
-main Clang web page, this document applies to the *next* release, not
-the current one. To see the release notes for a specific release, please
-see the `releases page `_.
-
-What's New in Clang 11.0.0?
-===
-
-Some of the major new features and improvements to Clang are listed
-here. Generic improvements to Clang as a whole or to its underlying
-infrastructure are described first, followed by language-specific
-sections with improvements to Clang's support for those languages.
-
-Major New Features
---
-
-- ...
-
-Improvements to Clang's diagnostics
-^^^
-
-- ...
-
-Non-comprehensive list of changes in this release
--
-
-
-New Compiler Flags
---
-
-
-- -fstack-clash-protection will provide a protection against the stack clash
-  attack for x86 architecture through automatic probing of each page of
-  allocated stack.
-
-Deprecated Compiler Flags
--
-
-The following options are deprecated and ignored. They will be removed in
-future versions of Clang.
-
-- ...
-
-Modified Compiler Flags

-
-
-New Pragmas in Clang
-
-
-- ...
-
-Attribute Changes in Clang
---
-
-- ...
-
-Windows Support

-
-C Language Changes in Clang

-
-- ...
-
-C11 Feature Support
-^^^
-
-...
-
-C++ Language Changes in Clang
--
-
-- Clang now implements a restriction on giving non-C-compatible anonymous
-  structs a typedef name for linkage purposes, as described in C++ committee
-  paper `P1766R1 `. This paper was adopted by the
-  C++ committee as a Defect Report resolution, so it is applied re

[PATCH] D72736: [AIX] Add improved interface for retrieving load module paths

2020-02-13 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast requested changes to this revision.
hubert.reinterpretcast added inline comments.
This revision now requires changes to proceed.



Comment at: llvm/lib/Support/Unix/Path.inc:243
+#elif defined(_AIX)
+  return getLoadModuleFilenameForFunction(MainAddr)->c_str();
 #elif defined(__linux__) || defined(__CYGWIN__) || defined(__gnu_hurd__)

The "expected" here is not checked for doing the error handling (soft-fail in 
this case). It appears `LLVM_ENABLE_ABI_BREAKING_CHECKS` would help to catch 
these.


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

https://reviews.llvm.org/D72736



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


[PATCH] D72239: [clang-tidy] new opencl recursion not supported check

2020-02-13 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

D72362  has landed.
I'd advise to see if any of the testcases here aren't being reported by that 
check, and filing a bugs for them.
Other than that, abandon?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D72239



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


[PATCH] D72736: [AIX] Add improved interface for retrieving load module paths

2020-02-13 Thread Xing Xue via Phabricator via cfe-commits
xingxue accepted this revision.
xingxue added a comment.
This revision is now accepted and ready to land.

LGTM.


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

https://reviews.llvm.org/D72736



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


[PATCH] D73462: [dwarf-5] Support DebugInfo for Defaulted parameters for C++ templates

2020-02-13 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl added a comment.

The upgrade test look good, I found a missing test in the unit tests though.




Comment at: llvm/unittests/IR/MetadataTest.cpp:2089
+  EXPECT_NE(N, DITemplateTypeParameter::get(Context, Name,
+getBasicType("other"), false));
 

I think you also need to add a new line here that tests that two 
DITemplateTypeParameter that only differ in the isDefault parameter are not 
equal. This tests the hashing/comparison mechanism.



Comment at: llvm/unittests/IR/MetadataTest.cpp:2120
+  EXPECT_NE(N, DITemplateValueParameter::get(Context, Tag, Name, Type, false,
  getConstantAsMetadata()));
 

and here.


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

https://reviews.llvm.org/D73462



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


[clang] e3548e2 - Remove unnecessary typedef that GCC doesn't like

2020-02-13 Thread Reid Kleckner via cfe-commits

Author: Reid Kleckner
Date: 2020-02-13T12:51:06-08:00
New Revision: e3548e23657d6c4988f815e9c87350f53e48e783

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

LOG: Remove unnecessary typedef that GCC doesn't like

Added: 


Modified: 
clang/include/clang/AST/ParentMapContext.h

Removed: 




diff  --git a/clang/include/clang/AST/ParentMapContext.h 
b/clang/include/clang/AST/ParentMapContext.h
index 3ab55fb3d309..be4d75df7b99 100644
--- a/clang/include/clang/AST/ParentMapContext.h
+++ b/clang/include/clang/AST/ParentMapContext.h
@@ -89,8 +89,6 @@ class TraversalKindScope {
 /// Container for either a single DynTypedNode or for an ArrayRef to
 /// DynTypedNode. For use with ParentMap.
 class DynTypedNodeList {
-  using DynTypedNode = DynTypedNode;
-
   llvm::AlignedCharArrayUnion> Storage;
   bool IsSingleNode;
 



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


[clang] 7ecf066 - [OPENMP][DOCS]Fix misprint, NFC.

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T15:43:05-05:00
New Revision: 7ecf066e65d8d5970b2254c2674ad12ce3a76e31

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

LOG: [OPENMP][DOCS]Fix misprint, NFC.

Added: 


Modified: 
clang/docs/OpenMPSupport.rst

Removed: 




diff  --git a/clang/docs/OpenMPSupport.rst b/clang/docs/OpenMPSupport.rst
index 98a4a324d67c..91e1de61b456 100644
--- a/clang/docs/OpenMPSupport.rst
+++ b/clang/docs/OpenMPSupport.rst
@@ -199,7 +199,7 @@ implementation.
 
+--+--+--+---+
 | device extension | clause: reverse_offload   
   | :none:`unclaimed parts`  | D52780  
  |
 
+--+--+--+---+
-| device extension | clause: atomic_default_mem_orrder 
   | :good:`done` | D53513  
  |
+| device extension | clause: atomic_default_mem_order  
   | :good:`done` | D53513  
  |
 
+--+--+--+---+
 | device extension | clause: dynamic_allocators
   | :none:`unclaimed parts`  | D53079  
  |
 
+--+--+--+---+



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


[PATCH] D74081: [clang][Analysis] CallGraph: store the actual call `Expr*` in the CallGraphNode::CallRecord

2020-02-13 Thread Roman Lebedev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd68c7b8e3e4d: [clang][Analysis] CallGraph: store the actual 
call `Expr*` in the CallGraphNode… (authored by lebedev.ri).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74081

Files:
  clang-tools-extra/clang-move/HelperDeclRefGraph.cpp
  clang/include/clang/Analysis/CallGraph.h
  clang/lib/Analysis/CallGraph.cpp

Index: clang/lib/Analysis/CallGraph.cpp
===
--- clang/lib/Analysis/CallGraph.cpp
+++ clang/lib/Analysis/CallGraph.cpp
@@ -66,16 +66,16 @@
 return nullptr;
   }
 
-  void addCalledDecl(Decl *D) {
+  void addCalledDecl(Decl *D, Expr *CallExpr) {
 if (G->includeInGraph(D)) {
   CallGraphNode *CalleeNode = G->getOrInsertNode(D);
-  CallerNode->addCallee(CalleeNode);
+  CallerNode->addCallee({CalleeNode, CallExpr});
 }
   }
 
   void VisitCallExpr(CallExpr *CE) {
 if (Decl *D = getDeclFromCall(CE))
-  addCalledDecl(D);
+  addCalledDecl(D, CE);
 VisitChildren(CE);
   }
 
@@ -89,14 +89,14 @@
 
   void VisitCXXNewExpr(CXXNewExpr *E) {
 if (FunctionDecl *FD = E->getOperatorNew())
-  addCalledDecl(FD);
+  addCalledDecl(FD, E);
 VisitChildren(E);
   }
 
   void VisitCXXConstructExpr(CXXConstructExpr *E) {
 CXXConstructorDecl *Ctor = E->getConstructor();
 if (FunctionDecl *Def = Ctor->getDefinition())
-  addCalledDecl(Def);
+  addCalledDecl(Def, E);
 VisitChildren(E);
   }
 
@@ -122,7 +122,7 @@
   else
 D = IDecl->lookupPrivateClassMethod(Sel);
   if (D) {
-addCalledDecl(D);
+addCalledDecl(D, ME);
 NumObjCCallEdges++;
   }
 }
@@ -207,7 +207,7 @@
   Node = std::make_unique(F);
   // Make Root node a parent of all functions to make sure all are reachable.
   if (F)
-Root->addCallee(Node.get());
+Root->addCallee({Node.get(), /*Call=*/nullptr});
   return Node.get();
 }
 
@@ -230,8 +230,8 @@
 OS << " calls: ";
 for (CallGraphNode::const_iterator CI = N->begin(),
CE = N->end(); CI != CE; ++CI) {
-  assert(*CI != Root && "No one can call the root node.");
-  (*CI)->print(OS);
+  assert(CI->Callee != Root && "No one can call the root node.");
+  CI->Callee->print(OS);
   OS << " ";
 }
 OS << '\n';
Index: clang/include/clang/Analysis/CallGraph.h
===
--- clang/include/clang/Analysis/CallGraph.h
+++ clang/include/clang/Analysis/CallGraph.h
@@ -24,6 +24,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/iterator_range.h"
 #include 
 
 namespace clang {
@@ -136,14 +137,23 @@
 private:
   /// Add the given declaration to the call graph.
   void addNodeForDecl(Decl *D, bool IsGlobal);
-
-  /// Allocate a new node in the graph.
-  CallGraphNode *allocateNewNode(Decl *);
 };
 
 class CallGraphNode {
 public:
-  using CallRecord = CallGraphNode *;
+  struct CallRecord {
+CallGraphNode *Callee;
+Expr *CallExpr;
+
+CallRecord() = default;
+
+CallRecord(CallGraphNode *Callee_, Expr *CallExpr_)
+: Callee(Callee_), CallExpr(CallExpr_) {}
+
+// The call destination is the only important data here,
+// allow to transparently unwrap into it.
+operator CallGraphNode *() const { return Callee; }
+  };
 
 private:
   /// The function/method declaration.
@@ -164,12 +174,18 @@
   const_iterator begin() const { return CalledFunctions.begin(); }
   const_iterator end() const { return CalledFunctions.end(); }
 
+  /// Iterator access to callees/children of the node.
+  llvm::iterator_range callees() {
+return llvm::make_range(begin(), end());
+  }
+  llvm::iterator_range callees() const {
+return llvm::make_range(begin(), end());
+  }
+
   bool empty() const { return CalledFunctions.empty(); }
   unsigned size() const { return CalledFunctions.size(); }
 
-  void addCallee(CallGraphNode *N) {
-CalledFunctions.push_back(N);
-  }
+  void addCallee(CallRecord Call) { CalledFunctions.push_back(Call); }
 
   Decl *getDecl() const { return FD; }
 
@@ -177,11 +193,44 @@
   void dump() const;
 };
 
+// NOTE: we are comparing based on the callee only. So different call records
+// (with different call expressions) to the same callee will compare equal!
+inline bool operator==(const CallGraphNode::CallRecord &LHS,
+   const CallGraphNode::CallRecord &RHS) {
+  return LHS.Callee == RHS.Callee;
+}
+
 } // namespace clang
 
-// Graph traits for iteration, viewing.
 namespace llvm {
 
+// Specialize DenseMapInfo for clang::CallGraphNode::CallRecord.
+template <> struct DenseMapInfo {
+  static inline clang::CallGraphNode::CallRecord getEmptyKey() {
+return clang::CallGraphNode::CallRecord(
+DenseMap

[PATCH] D72362: [clang-tidy] misc-no-recursion: a new check

2020-02-13 Thread Roman Lebedev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG49bffa5f8b79: [clang-tidy] misc-no-recursion: a new check 
(authored by lebedev.ri).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72362

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp
  clang-tools-extra/clang-tidy/misc/NoRecursionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-no-recursion.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp
@@ -0,0 +1,179 @@
+// RUN: %check_clang_tidy %s misc-no-recursion %t
+
+// We don't have the definition of this function,
+// so we can't tell anything about it..
+void external();
+
+// This function is obviously not recursive.
+void no_recursion() {
+}
+
+// Since we don't know what `external()` does,
+// we don't know if this is recursive or not.
+void maybe_no_recursion() {
+  external();
+}
+
+// Function calls itself - obviously a recursion.
+void endless_recursion() {
+  endless_recursion();
+}
+
+// CHECK-NOTES: :[[@LINE-4]]:6: warning: function 'endless_recursion' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-5]]:6: note: example recursive call chain, starting from function 'endless_recursion'
+// CHECK-NOTES: :[[@LINE-5]]:3: note: Frame #1: function 'endless_recursion' calls function 'endless_recursion' here:
+// CHECK-NOTES: :[[@LINE-6]]:3: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+bool external_oracle();
+bool another_external_oracle();
+
+// Function calls itself if some external function said so - recursion.
+void maybe_endless_recursion() {
+  if (external_oracle())
+maybe_endless_recursion();
+}
+
+// CHECK-NOTES: :[[@LINE-5]]:6: warning: function 'maybe_endless_recursion' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-6]]:6: note: example recursive call chain, starting from function 'maybe_endless_recursion'
+// CHECK-NOTES: :[[@LINE-5]]:5: note: Frame #1: function 'maybe_endless_recursion' calls function 'maybe_endless_recursion' here:
+// CHECK-NOTES: :[[@LINE-6]]:5: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+// Obviously-constrained recursion.
+void recursive_countdown(unsigned x) {
+  if (x == 0)
+return;
+  recursive_countdown(x - 1);
+}
+
+// CHECK-NOTES: :[[@LINE-6]]:6: warning: function 'recursive_countdown' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-7]]:6: note: example recursive call chain, starting from function 'recursive_countdown'
+// CHECK-NOTES: :[[@LINE-5]]:3: note: Frame #1: function 'recursive_countdown' calls function 'recursive_countdown' here:
+// CHECK-NOTES: :[[@LINE-6]]:3: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+void indirect_recursion();
+void conditionally_executed() {
+  if (external_oracle())
+indirect_recursion();
+}
+void indirect_recursion() {
+  if (external_oracle())
+conditionally_executed();
+}
+
+// CHECK-NOTES: :[[@LINE-10]]:6: warning: function 'indirect_recursion' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-10]]:6: warning: function 'conditionally_executed' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-12]]:6: note: example recursive call chain, starting from function 'indirect_recursion'
+// CHECK-NOTES: :[[@LINE-6]]:5: note: Frame #1: function 'indirect_recursion' calls function 'conditionally_executed' here:
+// CHECK-NOTES: :[[@LINE-11]]:5: note: Frame #2: function 'conditionally_executed' calls function 'indirect_recursion' here:
+// CHECK-NOTES: :[[@LINE-12]]:5: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+void taint();
+void maybe_selfrecursion_with_two_backedges() {
+  if (external_oracle())
+maybe_selfrecursion_with_two_backedges();
+  taint();
+  if (another_external_oracle())
+maybe_selfrecursion_with_two_backedges();
+}
+
+// CHECK-NOTES: :[[@LINE-8]]:6: warning: function 'maybe_selfrecursion_with_two_backedges' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-9]]:6: note: example recursive call chain, starting from function 'maybe_selfrecursion_with_two_backedges'
+// CHECK-NOTES: :[[@LINE-8]]:5: note: Frame #1: function 'maybe_selfrecursion_with_two_backedges' calls function 'maybe_selfrecursion_with_two_backedges' here:
+// CHECK-

[clang-tools-extra] 49bffa5 - [clang-tidy] misc-no-recursion: a new check

2020-02-13 Thread Roman Lebedev via cfe-commits

Author: Roman Lebedev
Date: 2020-02-13T23:37:53+03:00
New Revision: 49bffa5f8b790b6f180897b2a03840def645d8f0

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

LOG: [clang-tidy] misc-no-recursion: a new check

Summary:
Recursion is a powerful tool, but like any tool
without care it can be dangerous. For example,
if the recursion is unbounded, you will
eventually run out of stack and crash.

You can of course track the recursion depth
but if it is hardcoded, there can always be some
other environment when that depth is too large,
so said magic number would need to be env-dependent.
But then your program's behavior is suddenly more env-dependent.

Also, recursion, while it does not outright stop optimization,
recursive calls are less great than normal calls,
for example they hinder inlining.

Recursion is banned in some coding guidelines:
* SEI CERT DCL56-CPP. Avoid cycles during initialization of static objects
* JPL 2.4 Do not use direct or indirect recursion.
* I'd say it is frowned upon in LLVM, although not banned
And is plain unsupported in some cases:
* OpenCL 1.2, 6.9 Restrictions: i. Recursion is not supported.

So there's clearly a lot of reasons why one might want to
avoid recursion, and replace it with worklist handling.
It would be great to have a enforcement for it though.

This implements such a check.
Here we detect both direct and indirect recursive calls,
although since clang-tidy (unlike clang static analyzer)
is CTU-unaware, if the recursion transcends a single standalone TU,
we will naturally not find it :/

The algorithm is pretty straight-forward:
1. Build call-graph for the entire TU.
   For that, the existing `clang::CallGraph` is re-used,
   although it had to be modified to also track the location of the call.
2. Then, the hard problem: how do we detect recursion?
   Since we have a graph, let's just do the sane thing,
   and look for Strongly Connected Function Declarations - widely known as 
`SCC`.
   For that LLVM provides `llvm::scc_iterator`,
   which is internally an Tarjan's DFS algorithm, and is used throught LLVM,
   so this should be as performant as possible.
3. Now that we've got SCC's, we discard those that don't contain loops.
   Note that there may be more than one loop in SCC!
4. For each loopy SCC, we call out each function, and print a single example
   call graph that shows recursion -- it didn't seem worthwhile enumerating
   every possible loop in SCC, although i suppose it could be implemented.
   * To come up with that call graph cycle example, we start at first SCC node,
 see which callee of the node is within SCC (and is thus known to be in 
cycle),
 and recurse into it until we hit the callee that is already in call stack.

Reviewers: JonasToth, aaron.ballman, ffrankies, Eugene.Zelenko, erichkeane, NoQ

Reviewed By: aaron.ballman

Subscribers: Charusso, Naghasan, bader, riccibruno, mgorny, Anastasia, 
xazax.hun, cfe-commits

Tags: #llvm, #clang

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

Added: 
clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp
clang-tools-extra/clang-tidy/misc/NoRecursionCheck.h
clang-tools-extra/docs/clang-tidy/checks/misc-no-recursion.rst
clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp

Modified: 
clang-tools-extra/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/misc/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
index 3fc152148d6d..7aa14d141fb1 100644
--- a/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
@@ -5,6 +5,7 @@ add_clang_library(clangTidyMiscModule
   MiscTidyModule.cpp
   MisplacedConstCheck.cpp
   NewDeleteOverloadsCheck.cpp
+  NoRecursionCheck.cpp
   NonCopyableObjects.cpp
   NonPrivateMemberVariablesInClassesCheck.cpp
   RedundantExpressionCheck.cpp

diff  --git a/clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp 
b/clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
index ba160d1dba38..e06768c548bd 100644
--- a/clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
@@ -12,6 +12,7 @@
 #include "DefinitionsInHeadersCheck.h"
 #include "MisplacedConstCheck.h"
 #include "NewDeleteOverloadsCheck.h"
+#include "NoRecursionCheck.h"
 #include "NonCopyableObjects.h"
 #include "NonPrivateMemberVariablesInClassesCheck.h"
 #include "RedundantExpressionCheck.h"
@@ -35,6 +36,7 @@ class MiscModule : public ClangTidyModule {
 CheckFactories.registerCheck("misc-misplaced-const");
 CheckFactories.registerCheck(
 "misc

[clang] d68c7b8 - [clang][Analysis] CallGraph: store the actual call `Expr*` in the CallGraphNode::CallRecord

2020-02-13 Thread Roman Lebedev via cfe-commits

Author: Roman Lebedev
Date: 2020-02-13T23:37:53+03:00
New Revision: d68c7b8e3e4d605912ed36a843bbbcaa36234461

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

LOG: [clang][Analysis] CallGraph: store the actual call `Expr*` in the 
CallGraphNode::CallRecord

Summary:
Storing not just the callee, but the actual call may be interesting for some 
use-cases.
In particular, D72362 would like that to better pretty-print the cycles in call 
graph.

Reviewers: NoQ, erichkeane

Reviewed By: NoQ

Subscribers: martong, Charusso, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clang-move/HelperDeclRefGraph.cpp
clang/include/clang/Analysis/CallGraph.h
clang/lib/Analysis/CallGraph.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-move/HelperDeclRefGraph.cpp 
b/clang-tools-extra/clang-move/HelperDeclRefGraph.cpp
index 5495ae044584..271bd3d6ef20 100644
--- a/clang-tools-extra/clang-move/HelperDeclRefGraph.cpp
+++ b/clang-tools-extra/clang-move/HelperDeclRefGraph.cpp
@@ -27,7 +27,7 @@ void HelperDeclRefGraph::print(raw_ostream &OS) const {
 OS << " (" << N << ") ";
 OS << " calls: ";
 for (auto CI = N->begin(), CE = N->end(); CI != CE; ++CI) {
-  (*CI)->print(OS);
+  CI->Callee->print(OS);
   OS << " (" << CI << ") ";
 }
 OS << '\n';
@@ -48,7 +48,7 @@ void HelperDeclRefGraph::addEdge(const Decl *Caller, const 
Decl *Callee) {
   // Allocate a new node, mark it as root, and process it's calls.
   CallGraphNode *CallerNode = getOrInsertNode(const_cast(Caller));
   CallGraphNode *CalleeNode = getOrInsertNode(const_cast(Callee));
-  CallerNode->addCallee(CalleeNode);
+  CallerNode->addCallee({CalleeNode, /*CallExpr=*/nullptr});
 }
 
 void HelperDeclRefGraph::dump() const { print(llvm::errs()); }

diff  --git a/clang/include/clang/Analysis/CallGraph.h 
b/clang/include/clang/Analysis/CallGraph.h
index dae2b58ffc10..0e56d1c00623 100644
--- a/clang/include/clang/Analysis/CallGraph.h
+++ b/clang/include/clang/Analysis/CallGraph.h
@@ -24,6 +24,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/iterator_range.h"
 #include 
 
 namespace clang {
@@ -136,14 +137,23 @@ class CallGraph : public RecursiveASTVisitor {
 private:
   /// Add the given declaration to the call graph.
   void addNodeForDecl(Decl *D, bool IsGlobal);
-
-  /// Allocate a new node in the graph.
-  CallGraphNode *allocateNewNode(Decl *);
 };
 
 class CallGraphNode {
 public:
-  using CallRecord = CallGraphNode *;
+  struct CallRecord {
+CallGraphNode *Callee;
+Expr *CallExpr;
+
+CallRecord() = default;
+
+CallRecord(CallGraphNode *Callee_, Expr *CallExpr_)
+: Callee(Callee_), CallExpr(CallExpr_) {}
+
+// The call destination is the only important data here,
+// allow to transparently unwrap into it.
+operator CallGraphNode *() const { return Callee; }
+  };
 
 private:
   /// The function/method declaration.
@@ -164,12 +174,18 @@ class CallGraphNode {
   const_iterator begin() const { return CalledFunctions.begin(); }
   const_iterator end() const { return CalledFunctions.end(); }
 
+  /// Iterator access to callees/children of the node.
+  llvm::iterator_range callees() {
+return llvm::make_range(begin(), end());
+  }
+  llvm::iterator_range callees() const {
+return llvm::make_range(begin(), end());
+  }
+
   bool empty() const { return CalledFunctions.empty(); }
   unsigned size() const { return CalledFunctions.size(); }
 
-  void addCallee(CallGraphNode *N) {
-CalledFunctions.push_back(N);
-  }
+  void addCallee(CallRecord Call) { CalledFunctions.push_back(Call); }
 
   Decl *getDecl() const { return FD; }
 
@@ -177,11 +193,44 @@ class CallGraphNode {
   void dump() const;
 };
 
+// NOTE: we are comparing based on the callee only. So 
diff erent call records
+// (with 
diff erent call expressions) to the same callee will compare equal!
+inline bool operator==(const CallGraphNode::CallRecord &LHS,
+   const CallGraphNode::CallRecord &RHS) {
+  return LHS.Callee == RHS.Callee;
+}
+
 } // namespace clang
 
-// Graph traits for iteration, viewing.
 namespace llvm {
 
+// Specialize DenseMapInfo for clang::CallGraphNode::CallRecord.
+template <> struct DenseMapInfo {
+  static inline clang::CallGraphNode::CallRecord getEmptyKey() {
+return clang::CallGraphNode::CallRecord(
+DenseMapInfo::getEmptyKey(),
+DenseMapInfo::getEmptyKey());
+  }
+
+  static inline clang::CallGraphNode::CallRecord getTombstoneKey() {
+return clang::CallGraphNode::CallRecord(
+DenseMapInfo::getTombstoneKey(),
+DenseMapInfo::getTombstoneKey());
+  }
+
+  static unsigned 

[PATCH] D72362: [clang-tidy] misc-no-recursion: a new check

2020-02-13 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 244509.
lebedev.ri marked 8 inline comments as done.
lebedev.ri added a comment.

In D72362#1874690 , @aaron.ballman 
wrote:

> LGTM aside from some nits.


Thank you for the review!
Nits addressed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72362

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp
  clang-tools-extra/clang-tidy/misc/NoRecursionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-no-recursion.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp
@@ -0,0 +1,179 @@
+// RUN: %check_clang_tidy %s misc-no-recursion %t
+
+// We don't have the definition of this function,
+// so we can't tell anything about it..
+void external();
+
+// This function is obviously not recursive.
+void no_recursion() {
+}
+
+// Since we don't know what `external()` does,
+// we don't know if this is recursive or not.
+void maybe_no_recursion() {
+  external();
+}
+
+// Function calls itself - obviously a recursion.
+void endless_recursion() {
+  endless_recursion();
+}
+
+// CHECK-NOTES: :[[@LINE-4]]:6: warning: function 'endless_recursion' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-5]]:6: note: example recursive call chain, starting from function 'endless_recursion'
+// CHECK-NOTES: :[[@LINE-5]]:3: note: Frame #1: function 'endless_recursion' calls function 'endless_recursion' here:
+// CHECK-NOTES: :[[@LINE-6]]:3: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+bool external_oracle();
+bool another_external_oracle();
+
+// Function calls itself if some external function said so - recursion.
+void maybe_endless_recursion() {
+  if (external_oracle())
+maybe_endless_recursion();
+}
+
+// CHECK-NOTES: :[[@LINE-5]]:6: warning: function 'maybe_endless_recursion' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-6]]:6: note: example recursive call chain, starting from function 'maybe_endless_recursion'
+// CHECK-NOTES: :[[@LINE-5]]:5: note: Frame #1: function 'maybe_endless_recursion' calls function 'maybe_endless_recursion' here:
+// CHECK-NOTES: :[[@LINE-6]]:5: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+// Obviously-constrained recursion.
+void recursive_countdown(unsigned x) {
+  if (x == 0)
+return;
+  recursive_countdown(x - 1);
+}
+
+// CHECK-NOTES: :[[@LINE-6]]:6: warning: function 'recursive_countdown' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-7]]:6: note: example recursive call chain, starting from function 'recursive_countdown'
+// CHECK-NOTES: :[[@LINE-5]]:3: note: Frame #1: function 'recursive_countdown' calls function 'recursive_countdown' here:
+// CHECK-NOTES: :[[@LINE-6]]:3: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+void indirect_recursion();
+void conditionally_executed() {
+  if (external_oracle())
+indirect_recursion();
+}
+void indirect_recursion() {
+  if (external_oracle())
+conditionally_executed();
+}
+
+// CHECK-NOTES: :[[@LINE-10]]:6: warning: function 'indirect_recursion' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-10]]:6: warning: function 'conditionally_executed' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-12]]:6: note: example recursive call chain, starting from function 'indirect_recursion'
+// CHECK-NOTES: :[[@LINE-6]]:5: note: Frame #1: function 'indirect_recursion' calls function 'conditionally_executed' here:
+// CHECK-NOTES: :[[@LINE-11]]:5: note: Frame #2: function 'conditionally_executed' calls function 'indirect_recursion' here:
+// CHECK-NOTES: :[[@LINE-12]]:5: note: ... which was the starting point of the recursive call chain; there may be other cycles
+
+void taint();
+void maybe_selfrecursion_with_two_backedges() {
+  if (external_oracle())
+maybe_selfrecursion_with_two_backedges();
+  taint();
+  if (another_external_oracle())
+maybe_selfrecursion_with_two_backedges();
+}
+
+// CHECK-NOTES: :[[@LINE-8]]:6: warning: function 'maybe_selfrecursion_with_two_backedges' is within a recursive call chain [misc-no-recursion]
+// CHECK-NOTES: :[[@LINE-9]]:6: note: example recursive call chain, starting from function 'maybe_selfrecursion_with_two_backedges'
+// CHECK-NOTES: :[[@LINE-8]]:5: note: Frame #1: function 'maybe_se

[PATCH] D74081: [clang][Analysis] CallGraph: store the actual call `Expr*` in the CallGraphNode::CallRecord

2020-02-13 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 244508.
lebedev.ri added a comment.
Herald added a subscriber: martong.

Rebased, NFC.

In D74081#1860932 , @NoQ wrote:

> Looks great, thanks!


Thank you for the review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74081

Files:
  clang-tools-extra/clang-move/HelperDeclRefGraph.cpp
  clang/include/clang/Analysis/CallGraph.h
  clang/lib/Analysis/CallGraph.cpp

Index: clang/lib/Analysis/CallGraph.cpp
===
--- clang/lib/Analysis/CallGraph.cpp
+++ clang/lib/Analysis/CallGraph.cpp
@@ -66,16 +66,16 @@
 return nullptr;
   }
 
-  void addCalledDecl(Decl *D) {
+  void addCalledDecl(Decl *D, Expr *CallExpr) {
 if (G->includeInGraph(D)) {
   CallGraphNode *CalleeNode = G->getOrInsertNode(D);
-  CallerNode->addCallee(CalleeNode);
+  CallerNode->addCallee({CalleeNode, CallExpr});
 }
   }
 
   void VisitCallExpr(CallExpr *CE) {
 if (Decl *D = getDeclFromCall(CE))
-  addCalledDecl(D);
+  addCalledDecl(D, CE);
 VisitChildren(CE);
   }
 
@@ -89,14 +89,14 @@
 
   void VisitCXXNewExpr(CXXNewExpr *E) {
 if (FunctionDecl *FD = E->getOperatorNew())
-  addCalledDecl(FD);
+  addCalledDecl(FD, E);
 VisitChildren(E);
   }
 
   void VisitCXXConstructExpr(CXXConstructExpr *E) {
 CXXConstructorDecl *Ctor = E->getConstructor();
 if (FunctionDecl *Def = Ctor->getDefinition())
-  addCalledDecl(Def);
+  addCalledDecl(Def, E);
 VisitChildren(E);
   }
 
@@ -122,7 +122,7 @@
   else
 D = IDecl->lookupPrivateClassMethod(Sel);
   if (D) {
-addCalledDecl(D);
+addCalledDecl(D, ME);
 NumObjCCallEdges++;
   }
 }
@@ -207,7 +207,7 @@
   Node = std::make_unique(F);
   // Make Root node a parent of all functions to make sure all are reachable.
   if (F)
-Root->addCallee(Node.get());
+Root->addCallee({Node.get(), /*Call=*/nullptr});
   return Node.get();
 }
 
@@ -230,8 +230,8 @@
 OS << " calls: ";
 for (CallGraphNode::const_iterator CI = N->begin(),
CE = N->end(); CI != CE; ++CI) {
-  assert(*CI != Root && "No one can call the root node.");
-  (*CI)->print(OS);
+  assert(CI->Callee != Root && "No one can call the root node.");
+  CI->Callee->print(OS);
   OS << " ";
 }
 OS << '\n';
Index: clang/include/clang/Analysis/CallGraph.h
===
--- clang/include/clang/Analysis/CallGraph.h
+++ clang/include/clang/Analysis/CallGraph.h
@@ -24,6 +24,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/iterator_range.h"
 #include 
 
 namespace clang {
@@ -136,14 +137,23 @@
 private:
   /// Add the given declaration to the call graph.
   void addNodeForDecl(Decl *D, bool IsGlobal);
-
-  /// Allocate a new node in the graph.
-  CallGraphNode *allocateNewNode(Decl *);
 };
 
 class CallGraphNode {
 public:
-  using CallRecord = CallGraphNode *;
+  struct CallRecord {
+CallGraphNode *Callee;
+Expr *CallExpr;
+
+CallRecord() = default;
+
+CallRecord(CallGraphNode *Callee_, Expr *CallExpr_)
+: Callee(Callee_), CallExpr(CallExpr_) {}
+
+// The call destination is the only important data here,
+// allow to transparently unwrap into it.
+operator CallGraphNode *() const { return Callee; }
+  };
 
 private:
   /// The function/method declaration.
@@ -164,12 +174,18 @@
   const_iterator begin() const { return CalledFunctions.begin(); }
   const_iterator end() const { return CalledFunctions.end(); }
 
+  /// Iterator access to callees/children of the node.
+  llvm::iterator_range callees() {
+return llvm::make_range(begin(), end());
+  }
+  llvm::iterator_range callees() const {
+return llvm::make_range(begin(), end());
+  }
+
   bool empty() const { return CalledFunctions.empty(); }
   unsigned size() const { return CalledFunctions.size(); }
 
-  void addCallee(CallGraphNode *N) {
-CalledFunctions.push_back(N);
-  }
+  void addCallee(CallRecord Call) { CalledFunctions.push_back(Call); }
 
   Decl *getDecl() const { return FD; }
 
@@ -177,11 +193,44 @@
   void dump() const;
 };
 
+// NOTE: we are comparing based on the callee only. So different call records
+// (with different call expressions) to the same callee will compare equal!
+inline bool operator==(const CallGraphNode::CallRecord &LHS,
+   const CallGraphNode::CallRecord &RHS) {
+  return LHS.Callee == RHS.Callee;
+}
+
 } // namespace clang
 
-// Graph traits for iteration, viewing.
 namespace llvm {
 
+// Specialize DenseMapInfo for clang::CallGraphNode::CallRecord.
+template <> struct DenseMapInfo {
+  static inline clang::CallGraphNode::CallRecord getEmptyKey() {
+return clang::Call

[PATCH] D66919: Warn about zero-parameter K&R definitions in -Wstrict-prototypes

2020-02-13 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added a comment.

Ping @aaron.ballman.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66919



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


[PATCH] D74554: [ASTImporter] Added visibility check for scoped enums.

2020-02-13 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:2600
+  EnumDecl *FoundDef = FoundEnum->getDefinition();
+  if (D->isThisDeclarationADefinition() && FoundDef)
+return Importer.MapImported(D, FoundDef);

shafik wrote:
> Can you explain why we need to check `D->isThisDeclarationADefinition()` 
> 
> Does the test added hit all the combination of cases?
By the time of this check, we already know that D and the existing (found) decl 
are structurally equivalent. If they are both definitions then they must be the 
same, so we keep on with the existing. Actually, this is not unorthodox with 
enums, this is the pattern that we follow with all kind of declarations. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74554



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


[clang-tools-extra] 8c4cf23 - Fix crash in InfinteLoopCheck

2020-02-13 Thread Nathan James via cfe-commits

Author: Nathan James
Date: 2020-02-13T20:20:37Z
New Revision: 8c4cf23dee1ac3f259c4795b275cc9bb1234aa29

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

LOG: Fix crash in InfinteLoopCheck

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
index 00793009ed39..c9dd47ef0cf9 100644
--- a/clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
@@ -153,6 +153,8 @@ static std::string getCondVarNames(const Stmt *Cond) {
 }
 
 static bool isKnownFalse(const Expr &Cond, const ASTContext &Ctx) {
+  if (Cond.isValueDependent())
+return false;
   bool Result = false;
   if (Cond.EvaluateAsBooleanCondition(Result, Ctx))
 return !Result;



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D74571#1875022 , @kkwli0 wrote:

> In D74571#1874950 , @jdoerfert wrote:
>
> > > in order to avoid bug 44587 which requires >9.0.1 to be the build 
> > > compiler?
> >
> > Do we already require CUDA 10 as part of the libomptarget cmake (with a 
> > nice message) to avoid the errors you've seen? We for sure need to.
>
>
> This is a good idea but probably done in a separate patch.


Let's do this to "fix" PR44587.


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

https://reviews.llvm.org/D74571



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


[clang] 3eb1b59 - [OPENMP50][DOCS]Claim iterators and add reference to array shaping

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T15:05:19-05:00
New Revision: 3eb1b59ec0347d60f9809f88cfe7e98c48492621

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

LOG: [OPENMP50][DOCS]Claim iterators and add reference to array shaping
patch, NFC.

Added: 


Modified: 
clang/docs/OpenMPSupport.rst

Removed: 




diff  --git a/clang/docs/OpenMPSupport.rst b/clang/docs/OpenMPSupport.rst
index 12b23fc588c8..98a4a324d67c 100644
--- a/clang/docs/OpenMPSupport.rst
+++ b/clang/docs/OpenMPSupport.rst
@@ -225,7 +225,7 @@ implementation.
 
+--+--+--+---+
 | base language| lambda support
   | :good:`done` | 
  |
 
+--+--+--+---+
-| misc extension   | array shaping 
   | :part:`worked on`| 
  |
+| misc extension   | array shaping 
   | :part:`worked on`| D74144  
  |
 
+--+--+--+---+
 | misc extension   | library shutdown (omp_pause_resource[_all])   
   | :none:`unclaimed parts`  | D55078  
  |
 
+--+--+--+---+
@@ -233,7 +233,7 @@ implementation.
 
+--+--+--+---+
 | misc extension   | conditional modifier for lastprivate clause   
   | :good:`done` | 
  |
 
+--+--+--+---+
-| misc extension   | iterator and multidependences 
   | :none:`unclaimed`| 
  |
+| misc extension   | iterator and multidependences 
   | :part:`claimed`  | 
  |
 
+--+--+--+---+
 | misc extension   | user-defined function variants
   | :part:`worked on`| D67294, D64095  
  |
 
+--+--+--+---+



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


[PATCH] D74569: [clang-scan-deps] Switch to using a ThreadPool

2020-02-13 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

Thanks for the quick response!


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

https://reviews.llvm.org/D74569



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D74571#1875002 , @kkwli0 wrote:

> In D74571#1874947 , @JonChesterfield 
> wrote:
>
> > Do the in tree tests all pass with the 10.2 toolchain? That's not exactly 
> > the same as whether it works but is the closest approximation we have 
> > available.
> >
> > Assuming yes, this patch seems uncontroversial.
>
>
> Yes, in tree tests pass with 10.2.


I do not think it is relevant as those tests don't use CUDA-10.2 specific 
features yet.

Removing the warning here is similar to claiming that C++ compiler supports 
C++17 based on it passing C++ tests for c++11.

If OpenMP needs the warning gone, I'm OK with disabling it for openmp 
compilation, if that's what openmp owners want/need.
The warning should remain enabled otherwise.


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

https://reviews.llvm.org/D74571



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


[clang] 3203e1b - [OPENMP50][DOCS]Update list of supported constructs, NFC.

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T15:02:59-05:00
New Revision: 3203e1bc2e190aeee31a5b037f2535d03f2ca818

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

LOG: [OPENMP50][DOCS]Update list of supported constructs, NFC.

Added: 


Modified: 
clang/docs/OpenMPSupport.rst

Removed: 




diff  --git a/clang/docs/OpenMPSupport.rst b/clang/docs/OpenMPSupport.rst
index 085ef4d66cfc..12b23fc588c8 100644
--- a/clang/docs/OpenMPSupport.rst
+++ b/clang/docs/OpenMPSupport.rst
@@ -217,7 +217,7 @@ implementation.
 
+--+--+--+---+
 | device extension | pointer attachment
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+
-| atomic extension | hints for the atomic construct
   | :part:`worked on`| D51233  
  |
+| atomic extension | hints for the atomic construct
   | :good:`done` | D51233  
  |
 
+--+--+--+---+
 | base language| C11 support   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+
@@ -241,7 +241,7 @@ implementation.
 
+--+--+--+---+
 | misc extension   | prevent new type definitions in clauses   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+
-| memory model extension   | memory model update (seq_cst, acq_rel, 
release, acquire,...) | :none:`unclaimed`|  
 |
+| memory model extension   | memory model update (seq_cst, acq_rel, 
release, acquire,...) | :good:`done` |  
 |
 
+--+--+--+---+
 
 



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


[clang] 0b2eaa3 - Fix MSVC buildbots after ast_type_traits namespace removal

2020-02-13 Thread Reid Kleckner via cfe-commits

Author: Reid Kleckner
Date: 2020-02-13T11:57:00-08:00
New Revision: 0b2eaa373d12dacf58a72fd9e35ea6159a138647

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

LOG: Fix MSVC buildbots after ast_type_traits namespace removal

Added: 


Modified: 
clang/include/clang/ASTMatchers/ASTMatchersInternal.h

Removed: 




diff  --git a/clang/include/clang/ASTMatchers/ASTMatchersInternal.h 
b/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
index 90176bc23467..03eb1f79eea0 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -282,7 +282,7 @@ class DynMatcherInterface
   virtual bool dynMatches(const DynTypedNode &DynNode, ASTMatchFinder *Finder,
   BoundNodesTreeBuilder *Builder) const = 0;
 
-  virtual llvm::Optional TraversalKind() const {
+  virtual llvm::Optional TraversalKind() const {
 return llvm::None;
   }
 };
@@ -1168,10 +1168,10 @@ struct ArgumentAdaptingMatcherFunc {
 
 template 
 class TraversalMatcher : public WrapperMatcherInterface {
-  TraversalKind Traversal;
+  clang::TraversalKind Traversal;
 
 public:
-  explicit TraversalMatcher(TraversalKind TK, const Matcher &ChildMatcher)
+  explicit TraversalMatcher(clang::TraversalKind TK, const Matcher 
&ChildMatcher)
   : TraversalMatcher::WrapperMatcherInterface(ChildMatcher), Traversal(TK) 
{
   }
 
@@ -1181,7 +1181,7 @@ class TraversalMatcher : public 
WrapperMatcherInterface {
   Builder);
   }
 
-  llvm::Optional TraversalKind() const override {
+  llvm::Optional TraversalKind() const override {
 return Traversal;
   }
 };



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


[PATCH] D74569: [clang-scan-deps] Switch to using a ThreadPool

2020-02-13 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D74569



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Kelvin Li via Phabricator via cfe-commits
kkwli0 added a comment.

In D74571#1874950 , @jdoerfert wrote:

> > in order to avoid bug 44587 which requires >9.0.1 to be the build compiler?
>
> Do we already require CUDA 10 as part of the libomptarget cmake (with a nice 
> message) to avoid the errors you've seen? We for sure need to.


This is a good idea but probably done in a separate patch.


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

https://reviews.llvm.org/D74571



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


[PATCH] D74498: [clang-tidy] Fix performance-noexcept-move-constructor-fix.cpp on non-English locale

2020-02-13 Thread Alexandre Ganea via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG47abb43fc364: [clang-tidy] Fix 
performance-noexcept-move-constructor-fix test on non-English… (authored by 
aganea).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74498

Files:
  clang-tools-extra/test/clang-tidy/check_clang_tidy.py


Index: clang-tools-extra/test/clang-tidy/check_clang_tidy.py
===
--- clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -159,7 +159,7 @@
 diff_output = e.output
 
   print('-- Fixes -\n' 
+
-diff_output.decode() +
+diff_output.decode(errors='ignore') +
 '\n--')
 
   if has_check_fixes:


Index: clang-tools-extra/test/clang-tidy/check_clang_tidy.py
===
--- clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -159,7 +159,7 @@
 diff_output = e.output
 
   print('-- Fixes -\n' +
-diff_output.decode() +
+diff_output.decode(errors='ignore') +
 '\n--')
 
   if has_check_fixes:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Kelvin Li via Phabricator via cfe-commits
kkwli0 added a comment.

In D74571#1874947 , @JonChesterfield 
wrote:

> Do the in tree tests all pass with the 10.2 toolchain? That's not exactly the 
> same as whether it works but is the closest approximation we have available.
>
> Assuming yes, this patch seems uncontroversial.


Yes, in tree tests pass with 10.2.


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

https://reviews.llvm.org/D74571



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


[clang-tools-extra] 47abb43 - [clang-tidy] Fix performance-noexcept-move-constructor-fix test on non-English locale

2020-02-13 Thread Alexandre Ganea via cfe-commits

Author: Alexandre Ganea
Date: 2020-02-13T14:46:44-05:00
New Revision: 47abb43fc36433154eb796bd1d098f100503473e

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

LOG: [clang-tidy] Fix performance-noexcept-move-constructor-fix test on 
non-English locale

When running on Windows under the following locale:

D:\llvm-project>python
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getlocale()
('French_Canada', '1252')

This patch fixes the following issue:

# command stderr:
Traceback (most recent call last):
  File 
"D:/llvm-project/clang-tools-extra/test/../test\clang-tidy\check_clang_tidy.py",
 line 249, in 
main()
  File 
"D:/llvm-project/clang-tools-extra/test/../test\clang-tidy\check_clang_tidy.py",
 line 245, in main
run_test_once(args, extra_args)
  File 
"D:/llvm-project/clang-tools-extra/test/../test\clang-tidy\check_clang_tidy.py",
 line 162, in run_test_once
diff_output.decode() +
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 2050: 
invalid continuation byte
This is caused by diff reporting no EOL on the last line, and unfortunately 
this is written in French with accentuation on my locale.

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

Added: 


Modified: 
clang-tools-extra/test/clang-tidy/check_clang_tidy.py

Removed: 




diff  --git a/clang-tools-extra/test/clang-tidy/check_clang_tidy.py 
b/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
index 368b674d2d32..8567c18bf9a0 100755
--- a/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ b/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -159,7 +159,7 @@ def run_test_once(args, extra_args):
 
diff _output = e.output
 
   print('-- Fixes -\n' 
+
-
diff _output.decode() +
+
diff _output.decode(errors='ignore') +
 '\n--')
 
   if has_check_fixes:



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Artem Belevich via Phabricator via cfe-commits
tra requested changes to this revision.
tra added a comment.
This revision now requires changes to proceed.

It's a bit premature to call CUDA-10.2 supported. We can compile using it, but 
clang/llvm has no support for the new things introduced by CUDA-10.2. 
E.g. CUDA-10.2 introduces new PTX version with new instructions (and matching 
clang builtins) 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#ptx-isa-version-6-5

Any code which checks cuda version (and gets 10.2) and tries to use those new 
features will fail.
IMO the warning does serve a valid purpose here indicating that we only intend 
to provide features available in 10.1.

Given that clang provides an option to disable the warning, I don't think this 
change should be applied.


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

https://reviews.llvm.org/D74571



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


[PATCH] D73755: [objc_direct] Small updates to help with adoption.

2020-02-13 Thread Puyan Lotfi via Phabricator via cfe-commits
plotfi added a comment.

@MadCoder Could there be a way to mark objc_direct methods as something like 
__attribute__((visibility("default"))) or __declspec(dllexport) to denote that 
a given method should be directly callable but still retain the metadata to be 
called through an objc_msgSend from an external dylib? Could that help to boost 
adoption?


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

https://reviews.llvm.org/D73755



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Do the in tree tests all pass with the 10.2 toolchain? That's not exactly the 
same as whether it works but is the closest approximation we have available.

Assuming yes, this patch seems uncontroversial.


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

https://reviews.llvm.org/D74571



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


[PATCH] D71775: [ThreadPool] On Windows, extend usage to all CPU sockets and all NUMA groups

2020-02-13 Thread River Riddle via Phabricator via cfe-commits
rriddle accepted this revision.
rriddle added a comment.
This revision is now accepted and ready to land.

(Appeasing herald for MLIR changes).


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

https://reviews.llvm.org/D71775



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


[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a reviewer: ye-luo.
jdoerfert added a comment.

> Do we also want to put this patch to 10.0.0 RC2

Yes, if there is nothing else needed to support 10.2 we should for sure do that.

> in order to avoid bug 44587 which requires >9.0.1 to be the build compiler?

Do we already require CUDA 10 as part of the libomptarget cmake (with a nice 
message) to avoid the errors you've seen? We for sure need to.


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

https://reviews.llvm.org/D74571



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


[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-13 Thread Sean Fertile via Phabricator via cfe-commits
sfertile added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:520
+
+class XLCXXABI final : public ItaniumCXXABI {
+public:

Here would be a good place to add a comment to indicate that XL has several C++ 
ABIs, but this represents the one used in 'xlClang++'.


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

https://reviews.llvm.org/D74015



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


[PATCH] D74572: [WIP][BPF] implement intrinsic function __builtin__btf_type_id()

2020-02-13 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song created this revision.
yonghong-song added reviewers: ast, anakryiko.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, mgorny.
Herald added projects: clang, LLVM.

The builtin signature looks like:

  unsigned type_id = __builtin_btf_type_id(expression);

The "expression" can be a normal C expression such as

  1, var_a, var_a + 4, &var_a, var_b[10]

etc.
The return value returns the BTF type_id for the "expression".


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D74572

Files:
  clang/include/clang/Basic/BuiltinsBPF.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  llvm/include/llvm/IR/IntrinsicsBPF.td
  llvm/lib/Target/BPF/BPF.h
  llvm/lib/Target/BPF/BPFCORE.h
  llvm/lib/Target/BPF/BPFMIPreserveDIType.cpp
  llvm/lib/Target/BPF/BPFPreserveDIType.cpp
  llvm/lib/Target/BPF/BPFTargetMachine.cpp
  llvm/lib/Target/BPF/BTFDebug.cpp
  llvm/lib/Target/BPF/BTFDebug.h
  llvm/lib/Target/BPF/CMakeLists.txt
  llvm/test/CodeGen/BPF/BTF/builtin-btf-type-id.ll

Index: llvm/test/CodeGen/BPF/BTF/builtin-btf-type-id.ll
===
--- /dev/null
+++ llvm/test/CodeGen/BPF/BTF/builtin-btf-type-id.ll
@@ -0,0 +1,131 @@
+; RUN: llc -march=bpfel -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+; RUN: llc -march=bpfeb -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+; RUN: llc -march=bpfel -mattr=+alu32 -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+; RUN: llc -march=bpfeb -mattr=+alu32 -filetype=asm -o - %s | FileCheck -check-prefixes=CHECK %s
+;
+; Source code:
+;   static int (*bpf_log)(unsigned tid, void *data, int data_size) = (void *)999;
+;   struct {
+; char f1[100];
+; typeof(3) f2;
+;   } tmp__abc = {1, 3};
+;   void prog1() {
+; bpf_log(__builtin_btf_type_id(tmp__abc), &tmp__abc, sizeof(tmp__abc));
+;   }
+;   void prog2() {
+; bpf_log(__builtin_btf_type_id(&tmp__abc), &tmp__abc, sizeof(tmp__abc));
+;   }
+;   void prog3() {
+; bpf_log(__builtin_btf_type_id(tmp__abc.f1[3]), &tmp__abc, sizeof(tmp__abc));
+;   }
+; Compilation flag:
+;   clang -target bpf -O2 -g -S -emit-llvm test.c
+
+%struct.anon = type { [100 x i8], i32 }
+
+@tmp__abc = dso_local global { <{ i8, i8, [98 x i8] }>, i32 } { <{ i8, i8, [98 x i8] }> <{ i8 1, i8 3, [98 x i8] zeroinitializer }>, i32 0 }, align 4, !dbg !0
+
+; Function Attrs: nounwind
+define dso_local void @prog1() local_unnamed_addr #0 !dbg !28 {
+entry:
+  %0 = tail call i32 @llvm.bpf.btf.type.id.p0s_struct.anons.i32(%struct.anon* bitcast ({ <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc to %struct.anon*), i32 1), !dbg !31, !llvm.preserve.access.index !7
+  %call = tail call i32 inttoptr (i64 999 to i32 (i32, i8*, i32)*)(i32 %0, i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 0), i32 104) #2, !dbg !32
+  ret void, !dbg !33
+}
+
+; Function Attrs: nounwind readnone
+declare i32 @llvm.bpf.btf.type.id.p0s_struct.anons.i32(%struct.anon*, i32) #1
+
+; Function Attrs: nounwind
+define dso_local void @prog2() local_unnamed_addr #0 !dbg !34 {
+entry:
+  %0 = tail call i32 @llvm.bpf.btf.type.id.p0s_struct.anons.i32(%struct.anon* bitcast ({ <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc to %struct.anon*), i32 0), !dbg !35, !llvm.preserve.access.index !6
+  %call = tail call i32 inttoptr (i64 999 to i32 (i32, i8*, i32)*)(i32 %0, i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 0), i32 104) #2, !dbg !36
+  ret void, !dbg !37
+}
+
+; Function Attrs: nounwind
+define dso_local void @prog3() local_unnamed_addr #0 !dbg !38 {
+entry:
+  %0 = tail call i32 @llvm.bpf.btf.type.id.p0i8.i32(i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 2, i64 1), i32 1), !dbg !39, !llvm.preserve.access.index !11
+  %call = tail call i32 inttoptr (i64 999 to i32 (i32, i8*, i32)*)(i32 %0, i8* getelementptr inbounds ({ <{ i8, i8, [98 x i8] }>, i32 }, { <{ i8, i8, [98 x i8] }>, i32 }* @tmp__abc, i64 0, i32 0, i32 0), i32 104) #2, !dbg !40
+  ret void, !dbg !41
+}
+
+; CHECK-LABEL:   prog1
+; CHECK: r1 = 3
+; CHECK-LABEL:   prog2
+; CHECK: r1 = 10
+; CHECK-LABEL:   prog3
+; CHECK: r1 = 4
+;
+; CHECK: .long   0   # BTF_KIND_STRUCT(id = 3)
+; CHECK-NEXT:.long   67108866# 0x402
+; CHECK-NEXT:.long   104
+; CHECK-NEXT:.long   13
+; CHECK-NEXT:.long   5
+; CHECK-NEXT:.long   0   # 0x0
+; CHECK-NEXT:.long   16
+; CHECK-NEXT:.long   7
+; CHECK-NEXT:.long   800 # 0x320
+; CHECK-NEXT:.long   19  # BTF_KIND_INT(id = 4)
+; CHECK-NEXT:.long   16777216# 0x100
+; CHECK-NEXT:.long   1
+; CHECK-NEXT:.long   16777224# 0x108
+; CHECK: 

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

2020-02-13 Thread Kelvin Li via Phabricator via cfe-commits
kkwli0 created this revision.
kkwli0 added reviewers: jdoerfert, ABataev, JonChesterfield, tra.
Herald added a subscriber: guansong.
kkwli0 edited the summary of this revision.

This patch is to add CUDA 10.2 support.  It essentially removes the warning 
message regarding the CUDA 10.2 toolkit not being supported.  This warning 
causes libomp not being built as the LIBOMP_HAVE_VERSION_SCRIPT_FLAG test 
returns false.

Question to reviewers and others:
Do we also want to put this patch to 10.0.0 RC2 in order to avoid bug 44587 
 which requires >9.0.1 to be the 
build compiler?


https://reviews.llvm.org/D74571

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -634,6 +634,7 @@
   // back-end.
   const char *PtxFeature = nullptr;
   switch(CudaInstallation.version()) {
+case CudaVersion::CUDA_102:
 case CudaVersion::CUDA_101:
   PtxFeature = "+ptx64";
   break;
Index: clang/lib/Basic/Cuda.cpp
===
--- clang/lib/Basic/Cuda.cpp
+++ clang/lib/Basic/Cuda.cpp
@@ -28,6 +28,8 @@
 return "10.0";
   case CudaVersion::CUDA_101:
 return "10.1";
+  case CudaVersion::CUDA_102:
+return "10.2";
   }
   llvm_unreachable("invalid enum");
 }
@@ -42,6 +44,7 @@
   .Case("9.2", CudaVersion::CUDA_92)
   .Case("10.0", CudaVersion::CUDA_100)
   .Case("10.1", CudaVersion::CUDA_101)
+  .Case("10.2", CudaVersion::CUDA_102)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -382,6 +385,8 @@
 return CudaVersion::CUDA_100;
   case 101:
 return CudaVersion::CUDA_101;
+  case 102:
+return CudaVersion::CUDA_102;
   default:
 return CudaVersion::UNKNOWN;
   }
Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -27,7 +27,8 @@
   CUDA_92,
   CUDA_100,
   CUDA_101,
-  LATEST = CUDA_101,
+  CUDA_102,
+  LATEST = CUDA_102,
 };
 const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -634,6 +634,7 @@
   // back-end.
   const char *PtxFeature = nullptr;
   switch(CudaInstallation.version()) {
+case CudaVersion::CUDA_102:
 case CudaVersion::CUDA_101:
   PtxFeature = "+ptx64";
   break;
Index: clang/lib/Basic/Cuda.cpp
===
--- clang/lib/Basic/Cuda.cpp
+++ clang/lib/Basic/Cuda.cpp
@@ -28,6 +28,8 @@
 return "10.0";
   case CudaVersion::CUDA_101:
 return "10.1";
+  case CudaVersion::CUDA_102:
+return "10.2";
   }
   llvm_unreachable("invalid enum");
 }
@@ -42,6 +44,7 @@
   .Case("9.2", CudaVersion::CUDA_92)
   .Case("10.0", CudaVersion::CUDA_100)
   .Case("10.1", CudaVersion::CUDA_101)
+  .Case("10.2", CudaVersion::CUDA_102)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -382,6 +385,8 @@
 return CudaVersion::CUDA_100;
   case 101:
 return CudaVersion::CUDA_101;
+  case 102:
+return CudaVersion::CUDA_102;
   default:
 return CudaVersion::UNKNOWN;
   }
Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -27,7 +27,8 @@
   CUDA_92,
   CUDA_100,
   CUDA_101,
-  LATEST = CUDA_101,
+  CUDA_102,
+  LATEST = CUDA_102,
 };
 const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-13 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L updated this revision to Diff 244476.
Xiangling_L marked 4 inline comments as done.
Xiangling_L added a comment.

Adjust ABI name to `XL`;
Simplify the testcase;


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

https://reviews.llvm.org/D74015

Files:
  clang/include/clang/Basic/TargetCXXABI.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGen/static-init.cpp

Index: clang/test/CodeGen/static-init.cpp
===
--- /dev/null
+++ clang/test/CodeGen/static-init.cpp
@@ -0,0 +1,12 @@
+// RUN: not %clang_cc1 -triple powerpc-ibm-aix-xcoff -S -emit-llvm -x c++ %s \
+// RUN: 2>&1 | FileCheck %s
+
+// RUN: not %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ %s \
+// RUN: 2>&1 | FileCheck %s
+
+struct test {
+  test();
+  ~test();
+} t;
+
+// CHECK: error in backend: Static initialization has not been implemented on XL ABI yet.
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -516,6 +516,16 @@
   }
   bool canCallMismatchedFunctionType() const override { return false; }
 };
+
+class XLCXXABI final : public ItaniumCXXABI {
+public:
+  explicit XLCXXABI(CodeGen::CodeGenModule &CGM)
+  : ItaniumCXXABI(CGM) {}
+
+  void registerGlobalDtor(CodeGenFunction &CGF, const VarDecl &D,
+  llvm::FunctionCallee dtor,
+  llvm::Constant *addr) override;
+};
 }
 
 CodeGen::CGCXXABI *CodeGen::CreateItaniumCXXABI(CodeGenModule &CGM) {
@@ -546,6 +556,9 @@
   case TargetCXXABI::WebAssembly:
 return new WebAssemblyCXXABI(CGM);
 
+  case TargetCXXABI::XL:
+return new XLCXXABI(CGM);
+
   case TargetCXXABI::GenericItanium:
 if (CGM.getContext().getTargetInfo().getTriple().getArch()
 == llvm::Triple::le32) {
@@ -4407,3 +4420,11 @@
 NormalCleanup, cast(CGF.CurrentFuncletPad));
   ItaniumCXXABI::emitBeginCatch(CGF, C);
 }
+
+/// Register a global destructor as best as we know how.
+void XLCXXABI::registerGlobalDtor(CodeGenFunction &CGF, const VarDecl &D,
+  llvm::FunctionCallee dtor,
+  llvm::Constant *addr) {
+  llvm::report_fatal_error("Static initialization has not been implemented on"
+   " XL ABI yet.");
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -83,6 +83,7 @@
   case TargetCXXABI::GenericMIPS:
   case TargetCXXABI::GenericItanium:
   case TargetCXXABI::WebAssembly:
+  case TargetCXXABI::XL:
 return CreateItaniumCXXABI(CGM);
   case TargetCXXABI::Microsoft:
 return CreateMicrosoftCXXABI(CGM);
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -706,6 +706,8 @@
 public:
   AIXTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
+this->TheCXXABI.set(TargetCXXABI::XL);
+
 if (this->PointerWidth == 64) {
   this->WCharType = this->UnsignedInt;
 } else {
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -874,6 +874,7 @@
   case TargetCXXABI::GenericMIPS:
   case TargetCXXABI::GenericItanium:
   case TargetCXXABI::WebAssembly:
+  case TargetCXXABI::XL:
 return CreateItaniumCXXABI(*this);
   case TargetCXXABI::Microsoft:
 return CreateMicrosoftCXXABI(*this);
@@ -10251,6 +10252,7 @@
   case TargetCXXABI::iOS64:
   case TargetCXXABI::WebAssembly:
   case TargetCXXABI::WatchOS:
+  case TargetCXXABI::XL:
 return ItaniumMangleContext::create(*this, getDiagnostics());
   case TargetCXXABI::Microsoft:
 return MicrosoftMangleContext::create(*this, getDiagnostics());
Index: clang/include/clang/Basic/TargetCXXABI.h
===
--- clang/include/clang/Basic/TargetCXXABI.h
+++ clang/include/clang/Basic/TargetCXXABI.h
@@ -109,6 +109,12 @@
 ///   - constructors and destructors return 'this', as in ARM.
 Fuchsia,
 
+/// The XL ABI is a modified version of the Itanium ABI.
+///
+/// The relevant changes from the Itanium ABI are:
+///   - static initialization is adjusted to use sinit and sterm functions;
+XL,
+
 /// The Microsoft ABI is the ABI used by Microsoft Visual Studio (and
 /// compatible compilers).
 ///
@@ -148,6 +154,7 @@
 case WatchOS:
 case GenericMIPS:
 case WebAssembly:
+case XL:
   return true;
 
 case Mi

[PATCH] D74498: [clang-tidy] Fix performance-noexcept-move-constructor-fix.cpp on non-English locale

2020-02-13 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm, if the diff comes out wrong, that will not result in an incorrect 
pass/fail, but only less debugable output.


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

https://reviews.llvm.org/D74498



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


[PATCH] D74513: [OpenMP][NFCI] Use the libFrontend DefaultKind in Clang

2020-02-13 Thread Atmn Patel via Phabricator via cfe-commits
atmnpatel added a comment.

I am unable to commit this myself, can someone commit for me?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74513



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


[PATCH] D74417: [clang][ARC] Remove invalid assertion that can crash clangd

2020-02-13 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added a comment.

In D74417#1874747 , @dgoldman wrote:

> Added but it's still failing due to a different assertion failure, do you 
> think this could be because the abbreviation is different for the ParamVars? 
> I'm not sure how to handle this...


Yeah, that looks to be the problem, the parameter abbreviation is assumed to be 
a literal zero (since it was previously impossible) for the ParmVarDecl case, 
i.e:

  Abv->Add(BitCodeAbbrevOp(0));   // ARCPseudoStrong

But we really want it to look like the VarDecl case, where we actually get a 
bit for it:

  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // isARCPseudoStrong

I think you can fix the crash by changing the BitCodeAbbrevOp(0) to 
BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74417



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


[clang] 2fb6268 - [OPENMP50]Add support for hint clause in atomic directive.

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T13:28:43-05:00
New Revision: 2fb6268854f178609e974002e4781dbdb1074b90

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

LOG: [OPENMP50]Add support for hint clause in atomic directive.

According to OpenMP 5.0, hint clause is alowed to be used in atomic
directives.

Added: 


Modified: 
clang/include/clang/Basic/OpenMPKinds.def
clang/lib/Basic/OpenMPKinds.cpp
clang/test/OpenMP/atomic_ast_print.cpp
clang/test/OpenMP/atomic_messages.c

Removed: 




diff  --git a/clang/include/clang/Basic/OpenMPKinds.def 
b/clang/include/clang/Basic/OpenMPKinds.def
index 13b3438fec2c..dd840b270e63 100644
--- a/clang/include/clang/Basic/OpenMPKinds.def
+++ b/clang/include/clang/Basic/OpenMPKinds.def
@@ -497,6 +497,7 @@ OPENMP_ATOMIC_CLAUSE(acq_rel)
 OPENMP_ATOMIC_CLAUSE(acquire)
 OPENMP_ATOMIC_CLAUSE(release)
 OPENMP_ATOMIC_CLAUSE(relaxed)
+OPENMP_ATOMIC_CLAUSE(hint)
 
 // Clauses allowed for OpenMP directive 'target'.
 OPENMP_TARGET_CLAUSE(if)

diff  --git a/clang/lib/Basic/OpenMPKinds.cpp b/clang/lib/Basic/OpenMPKinds.cpp
index f13364e5378b..70817f8e464a 100644
--- a/clang/lib/Basic/OpenMPKinds.cpp
+++ b/clang/lib/Basic/OpenMPKinds.cpp
@@ -599,8 +599,9 @@ bool clang::isAllowedClauseForDirective(OpenMPDirectiveKind 
DKind,
 }
 break;
   case OMPD_atomic:
-if (OpenMPVersion < 50 && (CKind == OMPC_acq_rel || CKind == OMPC_acquire 
||
-   CKind == OMPC_release || CKind == OMPC_relaxed))
+if (OpenMPVersion < 50 &&
+(CKind == OMPC_acq_rel || CKind == OMPC_acquire ||
+ CKind == OMPC_release || CKind == OMPC_relaxed || CKind == OMPC_hint))
   return false;
 switch (CKind) {
 #define OPENMP_ATOMIC_CLAUSE(Name) 
\

diff  --git a/clang/test/OpenMP/atomic_ast_print.cpp 
b/clang/test/OpenMP/atomic_ast_print.cpp
index 5d8e92c14765..1b55c56ad17f 100644
--- a/clang/test/OpenMP/atomic_ast_print.cpp
+++ b/clang/test/OpenMP/atomic_ast_print.cpp
@@ -104,6 +104,21 @@ T foo(T argc) {
 a = b;
 b++;
   }
+#pragma omp atomic hint(6)
+  a++;
+#pragma omp atomic read hint(6)
+  a = argc;
+#pragma omp atomic hint(6) write
+  a = argc + argc;
+#pragma omp atomic update hint(6)
+  a = a + argc;
+#pragma omp atomic hint(6) capture
+  a = b++;
+#pragma omp atomic capture hint(6)
+  {
+a = b;
+b++;
+  }
   return T();
 }
 
@@ -198,6 +213,21 @@ T foo(T argc) {
 // CHECK-NEXT: a = b;
 // CHECK-NEXT: b++;
 // CHECK-NEXT: }
+// CHECK-NEXT: #pragma omp atomic hint(6)
+// CHECK-NEXT: a++;
+// CHECK-NEXT: #pragma omp atomic read hint(6)
+// CHECK-NEXT: a = argc;
+// CHECK-NEXT: #pragma omp atomic hint(6) write
+// CHECK-NEXT: a = argc + argc;
+// CHECK-NEXT: #pragma omp atomic update hint(6)
+// CHECK-NEXT: a = a + argc;
+// CHECK-NEXT: #pragma omp atomic hint(6) capture
+// CHECK-NEXT: a = b++;
+// CHECK-NEXT: #pragma omp atomic capture hint(6)
+// CHECK-NEXT: {
+// CHECK-NEXT: a = b;
+// CHECK-NEXT: b++;
+// CHECK-NEXT: }
 // CHECK: int a = int();
 // CHECK-NEXT: #pragma omp atomic
 // CHECK-NEXT: a++;
@@ -289,6 +319,21 @@ T foo(T argc) {
 // CHECK-NEXT: a = b;
 // CHECK-NEXT: b++;
 // CHECK-NEXT: }
+// CHECK-NEXT: #pragma omp atomic hint(6)
+// CHECK-NEXT: a++;
+// CHECK-NEXT: #pragma omp atomic read hint(6)
+// CHECK-NEXT: a = argc;
+// CHECK-NEXT: #pragma omp atomic hint(6) write
+// CHECK-NEXT: a = argc + argc;
+// CHECK-NEXT: #pragma omp atomic update hint(6)
+// CHECK-NEXT: a = a + argc;
+// CHECK-NEXT: #pragma omp atomic hint(6) capture
+// CHECK-NEXT: a = b++;
+// CHECK-NEXT: #pragma omp atomic capture hint(6)
+// CHECK-NEXT: {
+// CHECK-NEXT: a = b;
+// CHECK-NEXT: b++;
+// CHECK-NEXT: }
 
 int main(int argc, char **argv) {
   int b = 0;
@@ -384,6 +429,21 @@ int main(int argc, char **argv) {
 a = b;
 b++;
   }
+#pragma omp atomic hint(6)
+  a++;
+#pragma omp atomic read hint(6)
+  a = argc;
+#pragma omp atomic hint(6) write
+  a = argc + argc;
+#pragma omp atomic update hint(6)
+  a = a + argc;
+#pragma omp atomic hint(6) capture
+  a = b++;
+#pragma omp atomic capture hint(6)
+  {
+a = b;
+b++;
+  }
   // CHECK-NEXT: #pragma omp atomic
   // CHECK-NEXT: a++;
   // CHECK-NEXT: #pragma omp atomic read
@@ -474,6 +534,21 @@ int main(int argc, char **argv) {
   // CHECK-NEXT: a = b;
   // CHECK-NEXT: b++;
   // CHECK-NEXT: }
+  // CHECK-NEXT: #pragma omp atomic hint(6)
+  // CHECK-NEXT: a++;
+  // CHECK-NEXT: #pragma omp atomic read hint(6)
+  // CHECK-NEXT: a = argc;
+  // CHECK-NEXT: #pragma omp atomic hint(6) write
+  // CHECK-NEXT: a = argc + argc;
+  // CHECK-NEXT: #pragma omp atomic update hint(6)
+  // CHECK-NEXT: a = a + argc;
+  // CHECK-NEXT: #pragma omp atomic hint(6) capture
+  // CHECK-NEXT: a = b++;
+  // CHECK-NEXT: #pragm

[PATCH] D74569: [clang-scan-deps] Switch to using a ThreadPool

2020-02-13 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea created this revision.
aganea added reviewers: arphaman, dexonsmith, Bigcheese.
Herald added subscribers: llvm-commits, cfe-commits, tschuett, hiraditya.
Herald added projects: clang, LLVM.
aganea updated this revision to Diff 244475.

This was already reviewed as part of D71775 , 
but I wanted:

1. Make sure you were fine with this change.
2. Split out the unrelated bits from D71775  .

Tested with and without LLVM_ENABLE_THREADS.


https://reviews.llvm.org/D74569

Files:
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Support/JSON.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
+#include "llvm/Support/ThreadPool.h"
 #include "llvm/Support/Threading.h"
 #include 
 #include 
@@ -490,6 +491,7 @@
 #else
   unsigned NumWorkers = 1;
 #endif
+  llvm::ThreadPool Pool(NumWorkers);
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(std::make_unique(Service));
@@ -499,7 +501,6 @@
AdjustingCompilations->getAllCompileCommands())
 Inputs.emplace_back(Cmd);
 
-  std::vector WorkerThreads;
   std::atomic HadErrors(false);
   FullDeps FD;
   std::mutex Lock;
@@ -510,8 +511,8 @@
  << " files using " << NumWorkers << " workers\n";
   }
   for (unsigned I = 0; I < NumWorkers; ++I) {
-auto Worker = [I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
-   &DependencyOS, &Errs]() {
+Pool.async([I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
+&DependencyOS, &Errs]() {
   llvm::StringSet<> AlreadySeenModules;
   while (true) {
 const SingleCommandCompilationDatabase *Input;
@@ -543,16 +544,9 @@
 HadErrors = true;
 }
   }
-};
-#if LLVM_ENABLE_THREADS
-WorkerThreads.emplace_back(std::move(Worker));
-#else
-// Run the worker without spawning a thread when threads are disabled.
-Worker();
-#endif
+});
   }
-  for (auto &W : WorkerThreads)
-W.join();
+  Pool.wait();
 
   if (Format == ScanningOutputFormat::Full)
 FD.printFullOutput(llvm::outs());


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Support/JSON.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
+#include "llvm/Support/ThreadPool.h"
 #include "llvm/Support/Threading.h"
 #include 
 #include 
@@ -490,6 +491,7 @@
 #else
   unsigned NumWorkers = 1;
 #endif
+  llvm::ThreadPool Pool(NumWorkers);
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(std::make_unique(Service));
@@ -499,7 +501,6 @@
AdjustingCompilations->getAllCompileCommands())
 Inputs.emplace_back(Cmd);
 
-  std::vector WorkerThreads;
   std::atomic HadErrors(false);
   FullDeps FD;
   std::mutex Lock;
@@ -510,8 +511,8 @@
  << " files using " << NumWorkers << " workers\n";
   }
   for (unsigned I = 0; I < NumWorkers; ++I) {
-auto Worker = [I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
-   &DependencyOS, &Errs]() {
+Pool.async([I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
+&DependencyOS, &Errs]() {
   llvm::StringSet<> AlreadySeenModules;
   while (true) {
 const SingleCommandCompilationDatabase *Input;
@@ -543,16 +544,9 @@
 HadErrors = true;
 }
   }
-};
-#if LLVM_ENABLE_THREADS
-WorkerThreads.emplace_back(std::move(Worker));
-#else
-// Run the worker without spawning a thread when threads are disabled.
-Worker();
-#endif
+});
   }
-  for (auto &W : WorkerThreads)
-W.join();
+  Pool.wait();
 
   if (Format == ScanningOutputFormat::Full)
 FD.printFullOutput(llvm::outs());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74569: [clang-scan-deps] Switch to using a ThreadPool

2020-02-13 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea updated this revision to Diff 244475.

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

https://reviews.llvm.org/D74569

Files:
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Support/JSON.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
+#include "llvm/Support/ThreadPool.h"
 #include "llvm/Support/Threading.h"
 #include 
 #include 
@@ -490,6 +491,7 @@
 #else
   unsigned NumWorkers = 1;
 #endif
+  llvm::ThreadPool Pool(NumWorkers);
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(std::make_unique(Service));
@@ -499,7 +501,6 @@
AdjustingCompilations->getAllCompileCommands())
 Inputs.emplace_back(Cmd);
 
-  std::vector WorkerThreads;
   std::atomic HadErrors(false);
   FullDeps FD;
   std::mutex Lock;
@@ -510,8 +511,8 @@
  << " files using " << NumWorkers << " workers\n";
   }
   for (unsigned I = 0; I < NumWorkers; ++I) {
-auto Worker = [I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
-   &DependencyOS, &Errs]() {
+Pool.async([I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
+&DependencyOS, &Errs]() {
   llvm::StringSet<> AlreadySeenModules;
   while (true) {
 const SingleCommandCompilationDatabase *Input;
@@ -543,16 +544,9 @@
 HadErrors = true;
 }
   }
-};
-#if LLVM_ENABLE_THREADS
-WorkerThreads.emplace_back(std::move(Worker));
-#else
-// Run the worker without spawning a thread when threads are disabled.
-Worker();
-#endif
+});
   }
-  for (auto &W : WorkerThreads)
-W.join();
+  Pool.wait();
 
   if (Format == ScanningOutputFormat::Full)
 FD.printFullOutput(llvm::outs());


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Support/JSON.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
+#include "llvm/Support/ThreadPool.h"
 #include "llvm/Support/Threading.h"
 #include 
 #include 
@@ -490,6 +491,7 @@
 #else
   unsigned NumWorkers = 1;
 #endif
+  llvm::ThreadPool Pool(NumWorkers);
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(std::make_unique(Service));
@@ -499,7 +501,6 @@
AdjustingCompilations->getAllCompileCommands())
 Inputs.emplace_back(Cmd);
 
-  std::vector WorkerThreads;
   std::atomic HadErrors(false);
   FullDeps FD;
   std::mutex Lock;
@@ -510,8 +511,8 @@
  << " files using " << NumWorkers << " workers\n";
   }
   for (unsigned I = 0; I < NumWorkers; ++I) {
-auto Worker = [I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
-   &DependencyOS, &Errs]() {
+Pool.async([I, &Lock, &Index, &Inputs, &HadErrors, &FD, &WorkerTools,
+&DependencyOS, &Errs]() {
   llvm::StringSet<> AlreadySeenModules;
   while (true) {
 const SingleCommandCompilationDatabase *Input;
@@ -543,16 +544,9 @@
 HadErrors = true;
 }
   }
-};
-#if LLVM_ENABLE_THREADS
-WorkerThreads.emplace_back(std::move(Worker));
-#else
-// Run the worker without spawning a thread when threads are disabled.
-Worker();
-#endif
+});
   }
-  for (auto &W : WorkerThreads)
-W.join();
+  Pool.wait();
 
   if (Format == ScanningOutputFormat::Full)
 FD.printFullOutput(llvm::outs());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D73775: [clang-tidy] Cover cases like (b && c && b) in the redundant expression check

2020-02-13 Thread Alexey Romanov via Phabricator via cfe-commits
alexeyr added a comment.

Yes, I do. Thank you (and @Eugene.Zelenko) for your help making this better!


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

https://reviews.llvm.org/D73775



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


LLVM buildmaster will be updated and restarted tonight

2020-02-13 Thread Galina Kistanova via cfe-commits
Hello everyone,

LLVM buildmaster will be updated and restarted after 5PM Pacific time today.

Thanks

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


[PATCH] D74417: [clang][ARC] Remove invalid assertion that can crash clangd

2020-02-13 Thread David Goldman via Phabricator via cfe-commits
dgoldman updated this revision to Diff 244467.
dgoldman added a comment.

- Add test (fails due to different assertion)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74417

Files:
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/PCH/externally-retained.m


Index: clang/test/PCH/externally-retained.m
===
--- /dev/null
+++ clang/test/PCH/externally-retained.m
@@ -0,0 +1,30 @@
+// Test for assertion failure due to objc_externally_retained on a function.
+
+// Without PCH
+// RUN: %clang_cc1 -fsyntax-only -verify -fobjc-arc -include %s %s
+
+// With PCH
+// RUN: %clang_cc1 %s -emit-pch -fobjc-arc -o %t
+// RUN: %clang_cc1 -emit-llvm-only -verify %s -fobjc-arc -include-pch %t 
-debug-info-kind=limited
+
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+//===--===//
+// Header
+
+__attribute__((objc_externally_retained)) void doSomething(id someObject);
+
+id sharedObject = 0;
+
+//===--===//
+#else
+//===--===//
+
+void callDoSomething() {
+  doSomething(sharedObject);
+}
+
+//===--===//
+#endif
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -1089,8 +1089,6 @@
 Record.AddStmt(D->getUninstantiatedDefaultArg());
   Code = serialization::DECL_PARM_VAR;
 
-  assert(!D->isARCPseudoStrong()); // can be true of ImplicitParamDecl
-
   // If the assumptions about the DECL_PARM_VAR abbrev are true, use it.  Here
   // we dynamically check for the properties that we optimize for, but don't
   // know are true of all PARM_VAR_DECLs.


Index: clang/test/PCH/externally-retained.m
===
--- /dev/null
+++ clang/test/PCH/externally-retained.m
@@ -0,0 +1,30 @@
+// Test for assertion failure due to objc_externally_retained on a function.
+
+// Without PCH
+// RUN: %clang_cc1 -fsyntax-only -verify -fobjc-arc -include %s %s
+
+// With PCH
+// RUN: %clang_cc1 %s -emit-pch -fobjc-arc -o %t
+// RUN: %clang_cc1 -emit-llvm-only -verify %s -fobjc-arc -include-pch %t -debug-info-kind=limited
+
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+//===--===//
+// Header
+
+__attribute__((objc_externally_retained)) void doSomething(id someObject);
+
+id sharedObject = 0;
+
+//===--===//
+#else
+//===--===//
+
+void callDoSomething() {
+  doSomething(sharedObject);
+}
+
+//===--===//
+#endif
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -1089,8 +1089,6 @@
 Record.AddStmt(D->getUninstantiatedDefaultArg());
   Code = serialization::DECL_PARM_VAR;
 
-  assert(!D->isARCPseudoStrong()); // can be true of ImplicitParamDecl
-
   // If the assumptions about the DECL_PARM_VAR abbrev are true, use it.  Here
   // we dynamically check for the properties that we optimize for, but don't
   // know are true of all PARM_VAR_DECLs.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74554: [ASTImporter] Added visibility check for scoped enums.

2020-02-13 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:2600
+  EnumDecl *FoundDef = FoundEnum->getDefinition();
+  if (D->isThisDeclarationADefinition() && FoundDef)
+return Importer.MapImported(D, FoundDef);

Can you explain why we need to check `D->isThisDeclarationADefinition()` 

Does the test added hit all the combination of cases?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74554



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


[PATCH] D74417: [clang][ARC] Remove invalid assertion that can crash clangd

2020-02-13 Thread David Goldman via Phabricator via cfe-commits
dgoldman added a comment.

In D74417#1873287 , @erik.pilkington 
wrote:

> This looks good, but please add a testcase.


Added but it's still failing due to a different assertion failure, do you think 
this could be because the abbreviation is different for the ParamVars? I'm not 
sure how to handle this...

  Assertion failed: (V == Op.getLiteralValue() && "Invalid abbrev for 
record!"), function EmitAbbreviatedLiteral, file 
/Users/davg/dev/git_llvm/source/llvm-project/llvm/include/llvm/Bitstream/BitstreamWriter.h,
 line 263.
  Stack dump:
  0.Program arguments: /Users/davg/dev/git_llvm/build/bin/clang -cc1 
-internal-isystem /Users/davg/dev/git_llvm/build/lib/clang/11.0.0/include 
-nostdsysteminc 
/Users/davg/dev/git_llvm/source/llvm-project/clang/test/PCH/externally-retained.m
 -emit-pch -fobjc-arc -o 
/Users/davg/dev/git_llvm/build/tools/clang/test/PCH/Output/externally-retained.m.tmp
  1. parser at end of file
  2.
/Users/davg/dev/git_llvm/source/llvm-project/clang/test/PCH/externally-retained.m:17:63:
 serializing 'someObject'
  0  clang0x00010aa9515c 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
  1  clang0x00010aa95719 
PrintStackTraceSignalHandler(void*) + 25
  2  clang0x00010aa93146 llvm::sys::RunSignalHandlers() 
+ 118
  3  clang0x00010aa992fc SignalHandler(int) + 252
  4  libsystem_platform.dylib 0x7fff67583b5d _sigtramp + 29
  5  clang0x0001122350d8 
llvm::DenseMapInfo::Tombstone + 3253576
  6  libsystem_c.dylib0x7fff6743d6a6 abort + 127
  7  libsystem_c.dylib0x7fff6740620d basename_r + 0
  8  clang0x00010bc4e7f3 void 
llvm::BitstreamWriter::EmitAbbreviatedLiteral(llvm::BitCodeAbbrevOp const&, unsigned long long) + 211
  9  clang0x00010bc4de0c void 
llvm::BitstreamWriter::EmitRecordWithAbbrevImpl(unsigned 
int, llvm::ArrayRef, llvm::StringRef, 
llvm::Optional) + 892
  10 clang0x00010bc4d863 void 
llvm::BitstreamWriter::EmitRecord 
>(unsigned int, llvm::SmallVectorImpl const&, unsigned int) 
+ 307
  11 clang0x00010bebb274 
clang::ASTRecordWriter::Emit(unsigned int, unsigned int) + 84
  12 clang0x00010bf3e19b 
clang::ASTDeclWriter::Emit(clang::Decl*) + 203
  13 clang0x00010bf3de25 
clang::ASTWriter::WriteDecl(clang::ASTContext&, clang::Decl*) + 517
  ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74417



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


[PATCH] D74550: [AArch64][SVE] Add SVE index intrinsic

2020-02-13 Thread Andrzej Warzynski via Phabricator via cfe-commits
andwar added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:10923
+static SDValue LowerSVEIntrinsicIndex(SDNode *N, SelectionDAG &DAG) {
+  SDLoc dl(N);
+  SDValue Op1 = N->getOperand(1);

[nit] This should be `DL`: 
https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74550



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


[PATCH] D74473: [analyzer] StdLibraryFunctionsChecker: Use platform dependent EOF and UCharMax

2020-02-13 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/CheckerHelpers.cpp:114-117
+  const auto MacroIt = llvm::find_if(
+  PP.macros(), [&](const auto &K) { return K.first->getName() == Macro; });
+  if (MacroIt == PP.macro_end())
+return llvm::None;

NoQ wrote:
> martong wrote:
> > Szelethus wrote:
> > > This seems a bit clunky even for the `Preprocessor` -- how about
> > > 
> > > ```lang=c++
> > > const auto *MacroII = PP.getIdentifierInfo(Macro);
> > > if (!MacroII)
> > >   return;
> > > const MacroInfo *MI = PP.getMacroInfo(MacroII);
> > > assert(MI);
> > > ```
> > Ok, but we cannot assert on `MI`, because there may be cases when the macro 
> > is not defined in a TU. In that case we should just return with None.
> What exactly happens when the macro is `#undef`-ined and redefined? We get 
> the last redefinition that's valid at the end of the translation unit, right? 
> Can we check whether there are multiple definitions and guard against that?
Ugh, now that you say it that is a valid concern. I had to deal with that back 
in the day: https://reviews.llvm.org/D52794?id=171962#inline-476352


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74473



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


[PATCH] D74564: libclang: Add static build support for Windows

2020-02-13 Thread Cristian Adam via Phabricator via cfe-commits
cristian.adam added a comment.

Build with this patch being built on GitHub Actions on Windows MSVC, Windows 
MinGW, Linux, macOS: 
https://github.com/cristianadam/llvm-project/actions/runs/38838989


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74564



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


[PATCH] D74214: [clang-tidy] Fix PR#34798 'readability-braces-around-statements breaks statements containing braces.'

2020-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/BracesAroundStatementsCheck.cpp:76-77
+
+  // We need to check that it is not 'InitListExpr' which ends with 
+  // the tokens '};' because it will break the following analysis
+  tok::TokenKind NextTokKind;

ymandel wrote:
> ymandel wrote:
> > aaron.ballman wrote:
> > > Is there evidence that this behavior is desired? I have a hunch that this 
> > > is a bug in Clang -- not all `InitListExpr`s will terminate with a 
> > > semicolon, such as ones that appear as function arguments, like `foo({1, 
> > > 2, 3});`, so I'm surprised to see it included here.
> > On a related note, are you sure the cause of this issue is 
> > `makeFileCharRange`? AFAIK, that does not involve any examination of 
> > tokens. It purely (attempts) to map from potentially a mix of expanded 
> > locations and file locations to purely file locations (and in the same file 
> > for that matter).
> I believe the issue lies with `DeclStmt`, not `InitListExpr`. Specifically, 
> the source range provided by `DeclStmt`.  See https://godbolt.org/z/vVtQZ8. 
> The non-decl statements have an end location on the token before the semi, 
> whereas the decl statements given their end location as the semi.
Ah, yeah, that sounds plausible too (the end location should be before the semi 
in both places). Either way, I think we should be fixing this in the frontend 
rather than trying to hack around it in clang-tidy checks, if at all possible. 
This may require undoing hacks done elsewhere, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74214



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


[PATCH] D72362: [clang-tidy] misc-no-recursion: a new check

2020-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from some nits.




Comment at: clang-tools-extra/clang-tidy/misc/NoRecursionCheck.cpp:70
+
+template  class SmartSmallSetVector {
+public:

lebedev.ri wrote:
> aaron.ballman wrote:
> > Same complaint here about `Smart` -- should probably just be a 
> > `SmallSetVector`.
> There already is a `SmallSetVector`, and it does have different semantics,
> i've added a code comment explaining their differences, PTAL.
> 
> For now, i'd prefer to keep this as-is, but afterwards i suspect
> i might be able to "upstream" this into `SmallSetVector` itself,
> thus getting rid of `SmartSmallSetVector`.
> 
> Let me know if this makes sense?
Okay, that's reasonable enough. Can you add a FIXME suggesting that plan in the 
code?



Comment at: clang-tools-extra/docs/clang-tidy/checks/misc-no-recursion.rst:6
+
+Finds strongly connected functions (by analyzing call graph for SCC's
+that are loops), diagnoses each function in the cycle,

call graph -> the call graph

And you should probably spell out SCC.



Comment at: clang-tools-extra/docs/clang-tidy/checks/misc-no-recursion.rst:8
+that are loops), diagnoses each function in the cycle,
+and displays one example of possible call graph loop (recursion).
+

call graph -> a call graph



Comment at: clang-tools-extra/docs/clang-tidy/checks/misc-no-recursion.rst:8
+that are loops), diagnoses each function in the cycle,
+and displays one example of possible call graph loop (recursion).

lebedev.ri wrote:
> aaron.ballman wrote:
> > Eugene.Zelenko wrote:
> > > It'll be reasonable to add links to relevant coding guidelines.
> > Agreed.
> Is this better?
Looks great!



Comment at: clang-tools-extra/test/clang-tidy/checkers/misc-no-recursion.cpp:127
+}
+
+// CHECK-NOTES: :[[@LINE-14]]:13: warning: function 
'indirect_recursion_with_depth2' is part of call graph loop [misc-no-recursion]

lebedev.ri wrote:
> JonasToth wrote:
> > Does the check find recursion through function pointers? (Probably not? 
> > Should be noted as limitation).
> > 
> > Please add cases from lambdas. And cases where recursion happens in 
> > templates / only with one of multiple instantiations.
> This indeed gets blinded by function pointers, test added.
> 
> As for lambdas, i'm not sure what specifically you mean?
> The lambda itself can't be recursive i think?
> https://godbolt.org/z/GYLRnB
There are techniques to make lambdas recursive, but maybe we don't need to 
catch those (at least not initially). e.g., 
https://riptutorial.com/cplusplus/example/8508/recursive-lambdas


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72362



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


[PATCH] D74473: [analyzer] StdLibraryFunctionsChecker: Use platform dependent EOF and UCharMax

2020-02-13 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/CheckerHelpers.cpp:114-117
+  const auto MacroIt = llvm::find_if(
+  PP.macros(), [&](const auto &K) { return K.first->getName() == Macro; });
+  if (MacroIt == PP.macro_end())
+return llvm::None;

martong wrote:
> Szelethus wrote:
> > This seems a bit clunky even for the `Preprocessor` -- how about
> > 
> > ```lang=c++
> > const auto *MacroII = PP.getIdentifierInfo(Macro);
> > if (!MacroII)
> >   return;
> > const MacroInfo *MI = PP.getMacroInfo(MacroII);
> > assert(MI);
> > ```
> Ok, but we cannot assert on `MI`, because there may be cases when the macro 
> is not defined in a TU. In that case we should just return with None.
What exactly happens when the macro is `#undef`-ined and redefined? We get the 
last redefinition that's valid at the end of the translation unit, right? Can 
we check whether there are multiple definitions and guard against that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74473



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


[PATCH] D73775: [clang-tidy] Cover cases like (b && c && b) in the redundant expression check

2020-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

Still LGTM, thank you! If you need me to commit this on your behalf, I'm happy 
to do so, just let me know. It'll have to wait until next week, though (unless 
someone else does it first).


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

https://reviews.llvm.org/D73775



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


[clang] 43b98ff - [OPENMP][DOCS]Update status of support constructs, NFC.

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T12:28:17-05:00
New Revision: 43b98ffed08a5691dd2d8275b8952569f55f015d

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

LOG: [OPENMP][DOCS]Update status of support constructs, NFC.

Added: 


Modified: 
clang/docs/OpenMPSupport.rst

Removed: 




diff  --git a/clang/docs/OpenMPSupport.rst b/clang/docs/OpenMPSupport.rst
index 945f017183ee..085ef4d66cfc 100644
--- a/clang/docs/OpenMPSupport.rst
+++ b/clang/docs/OpenMPSupport.rst
@@ -199,7 +199,7 @@ implementation.
 
+--+--+--+---+
 | device extension | clause: reverse_offload   
   | :none:`unclaimed parts`  | D52780  
  |
 
+--+--+--+---+
-| device extension | clause: atomic_default_mem_rrder  
   | :none:`unclaimed parts`  | D53513  
  |
+| device extension | clause: atomic_default_mem_orrder 
   | :good:`done` | D53513  
  |
 
+--+--+--+---+
 | device extension | clause: dynamic_allocators
   | :none:`unclaimed parts`  | D53079  
  |
 
+--+--+--+---+



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


[PATCH] D71830: [OpenMP][Part 2] Use reusable OpenMP context/traits handling

2020-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:185
+// An argument of type \p type with name \p name.
+class GenericPointerArgument : Argument {
+  string Type = type;

jdoerfert wrote:
> aaron.ballman wrote:
> > The name seems a bit strange given that it's not a generic pointer, you 
> > specify a type with it. It's unclear whether you are supposed to specify 
> > the pointer type or the base type, which would help a bit. However, it's 
> > unclear to me why we'd want this generic mechanism in the first place. 
> > These classes are intended to help generate code to do checking 
> > automatically, and this design is somewhat at odds with that goal compared 
> > to exposing a custom argument type like we did for `VersionArgument`. Also, 
> > this type is marked optional rather than leaving that up to the caller, and 
> > the default behavior of a generic pointer argument always being default 
> > seems suspect.
> > 
> > I'm not saying "get rid of this", just wondering if you had considered the 
> > more verbose approach and had strong rationale as to why this was a better 
> > way.
> > The name seems a bit strange given that it's not a generic pointer, you 
> > specify a type with it.
> 
> The "template" is generic as it accepts any pointer type. All the code that 
> work with `GenericPointerArgument` don't know what pointer it is, just that 
> it is called "Type". Don't you think that is generic?
> 
> 
> > Also, this type is marked optional rather than leaving that up to the 
> > caller, and the default behavior of a generic pointer argument always being 
> > default seems suspect.
> 
> That's an oversight. I mark it non-optional. I don't get the "always being 
> default" part.
> 
> > However, it's unclear to me why we'd want this generic mechanism in the 
> > first place. 
> > [...]
> > I'm not saying "get rid of this", just wondering if you had considered the 
> > more verbose approach and had strong rationale as to why this was a better 
> > way.
> 
> The "problem" is that we want to keep "complex" information around. The 
> verbose approach is what we are doing right now for a subset of the 
> information. For this subset we already track various variadic expr, variadic 
> unsigned, and variadic string arguments and stitch them together later with 
> complex and careful iteration over all containers at the same time. It's now 
> 5 variadic XXX arguments and it would be >= 7 to support what this approach 
> does.
> 
> This approach subsumes this as we can retain the original structure/nesting 
> in the custom `OMPTraitInfo` object that is part of the `OMPDeclareVariant` 
> instead. [FWIW, in the review for the verbose code we have now, in case you 
> haven't seen that, I asked for a less verbose method to store the information 
> because the iteration over the stuff, once flattend, is so brittle.]
> 
> That said, we can make a specialized argument here instead, e.g., 
> OMPTraitInforArgument, which contains a OMPTraitInfo pointer. I figured this 
> might not be the last time someone wants to keep a complex structure inside 
> an attribute argument and creating new arguments all the time seems a lot of 
> waste (due to all the boilerplate). If you think we should go that route, I 
> will happily try it out.
> 
> (As noted below somewhere, this method avoids a lot of boilerplate by 
> requiring a specialization of one AST reader/writer method.)
> That's an oversight. I mark it non-optional. I don't get the "always being 
> default" part.

Making it non-optional solves my concern. I was just worried that the default 
was surprising.

> That said, we can make a specialized argument here instead, e.g., 
> OMPTraitInforArgument, which contains a OMPTraitInfo pointer. I figured this 
> might not be the last time someone wants to keep a complex structure inside 
> an attribute argument and creating new arguments all the time seems a lot of 
> waste (due to all the boilerplate). If you think we should go that route, I 
> will happily try it out.

As we spoke about on IRC, I would appreciate going with this approach (and I 
think it can even work nicely with the template specialization work done for 
the AST reader and writer, most likely). However, if that turns out to be a lot 
of effort for you, I can probably be okay with the current approach. I just 
dislike the fact that it complicates understanding what arguments the attribute 
actually takes (I no longer understand by looking at Attr.td or in the worst 
case, the tablegen emitter). Having the concrete type in tablegen/emitter is 
more expressive and allows us to generate more stuff in the future.



Comment at: clang/include/clang/Basic/Attr.td:3351
 ExprArgument<"VariantFuncRef">,
-VariadicExprArgument<"Scores">,
-VariadicUnsignedArgument<"CtxSelectorSets">,
-VariadicUnsignedArgument<"CtxSelectors">,
-VariadicStringArgument<"ImplVendors">,
-Var

[clang] e0ca479 - [OPENMP50]Add cancellation support in taskloop-based directives.

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T12:03:43-05:00
New Revision: e0ca4792fa4598359dc5364bcc466f7e78616113

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

LOG: [OPENMP50]Add cancellation support in taskloop-based directives.

According to OpenMP 5.0, cancel and cancellation point constructs are
supported in taskloop directive. Added support for cancellation in
taskloop, master taskloop and parallel master taskloop.

Added: 


Modified: 
clang/include/clang/AST/StmtOpenMP.h
clang/lib/AST/StmtOpenMP.cpp
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Serialization/ASTReaderStmt.cpp
clang/lib/Serialization/ASTWriterStmt.cpp
clang/test/OpenMP/master_taskloop_ast_print.cpp
clang/test/OpenMP/master_taskloop_codegen.cpp
clang/test/OpenMP/nesting_of_regions.cpp
clang/test/OpenMP/parallel_master_taskloop_ast_print.cpp
clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
clang/test/OpenMP/taskloop_ast_print.cpp
clang/test/OpenMP/taskloop_codegen.cpp

Removed: 




diff  --git a/clang/include/clang/AST/StmtOpenMP.h 
b/clang/include/clang/AST/StmtOpenMP.h
index 65f0afece224..55649079bd2b 100644
--- a/clang/include/clang/AST/StmtOpenMP.h
+++ b/clang/include/clang/AST/StmtOpenMP.h
@@ -3070,6 +3070,9 @@ class OMPCancelDirective : public OMPExecutableDirective {
 ///
 class OMPTaskLoopDirective : public OMPLoopDirective {
   friend class ASTStmtReader;
+  /// true if the construct has inner cancel directive.
+  bool HasCancel;
+
   /// Build directive with the given start and end location.
   ///
   /// \param StartLoc Starting location of the directive kind.
@@ -3081,7 +3084,8 @@ class OMPTaskLoopDirective : public OMPLoopDirective {
unsigned CollapsedNum, unsigned NumClauses)
   : OMPLoopDirective(this, OMPTaskLoopDirectiveClass,
  llvm::omp::OMPD_taskloop, StartLoc, EndLoc,
- CollapsedNum, NumClauses) {}
+ CollapsedNum, NumClauses),
+HasCancel(false) {}
 
   /// Build an empty directive.
   ///
@@ -3091,7 +3095,11 @@ class OMPTaskLoopDirective : public OMPLoopDirective {
   explicit OMPTaskLoopDirective(unsigned CollapsedNum, unsigned NumClauses)
   : OMPLoopDirective(this, OMPTaskLoopDirectiveClass,
  llvm::omp::OMPD_taskloop, SourceLocation(),
- SourceLocation(), CollapsedNum, NumClauses) {}
+ SourceLocation(), CollapsedNum, NumClauses),
+HasCancel(false) {}
+
+  /// Set cancel state.
+  void setHasCancel(bool Has) { HasCancel = Has; }
 
 public:
   /// Creates directive with a list of \a Clauses.
@@ -3103,11 +3111,12 @@ class OMPTaskLoopDirective : public OMPLoopDirective {
   /// \param Clauses List of clauses.
   /// \param AssociatedStmt Statement, associated with the directive.
   /// \param Exprs Helper expressions for CodeGen.
+  /// \param HasCancel true if this directive has inner cancel directive.
   ///
   static OMPTaskLoopDirective *
   Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation EndLoc,
  unsigned CollapsedNum, ArrayRef Clauses,
- Stmt *AssociatedStmt, const HelperExprs &Exprs);
+ Stmt *AssociatedStmt, const HelperExprs &Exprs, bool HasCancel);
 
   /// Creates an empty directive with the place
   /// for \a NumClauses clauses.
@@ -3120,6 +3129,9 @@ class OMPTaskLoopDirective : public OMPLoopDirective {
unsigned NumClauses,
unsigned CollapsedNum, EmptyShell);
 
+  /// Return true if current directive has inner cancel directive.
+  bool hasCancel() const { return HasCancel; }
+
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == OMPTaskLoopDirectiveClass;
   }
@@ -3203,6 +3215,9 @@ class OMPTaskLoopSimdDirective : public OMPLoopDirective {
 ///
 class OMPMasterTaskLoopDirective : public OMPLoopDirective {
   friend class ASTStmtReader;
+  /// true if the construct has inner cancel directive.
+  bool HasCancel;
+
   /// Build directive with the given start and end location.
   ///
   /// \param StartLoc Starting location of the directive kind.
@@ -3214,7 +3229,8 @@ class OMPMasterTaskLoopDirective : public 
OMPLoopDirective {
  unsigned CollapsedNum, unsigned NumClauses)
   : OMPLoopDirective(this, OMPMasterTaskLoopDirectiveClass,
  llvm::omp::OMPD_master_taskloop, StartLoc, EndLoc,
- CollapsedNum, NumClauses) {}
+ CollapsedNum, NumClauses),
+HasCancel(false) {}
 
   /// Build an empty directive.
   ///

[PATCH] D73369: [clangd] Simplify "preferred" vs "definition" logic a bit in XRefs AST code.

2020-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

ping :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73369



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


[PATCH] D73696: [clang][Index] Introduce a TemplateParm SymbolKind

2020-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

ping :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73696



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


[PATCH] D74387: [SYCL] Do not diagnose use of __float128

2020-02-13 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon added a comment.

> In D74387#1869845 , @rjmccall wrote:
> 
>> The right approach here is probably what we do in ObjC ARC when we see types 
>> that are illegal in ARC: in system headers, we allow the code but add a 
>> special `UnavailableAttr` to the declaration so that it can't be directly 
>> used.
>>
>> That is straightforward enough that I think you should just do it instead of 
>> leaving this as technical debt.
> 
> 
> I haven't considered something like this, because I'm not familiar with ObjC 
> at all... I will give it a try, thanks.

Hi @rjmccall , I assume, I took a look at this. 
Let's imagine, I will try to diagnose `__float128` type using already 
implemented functionality. It seems like I need to call something like

  S.DelayedDiagnostics.add(
  sema::DelayedDiagnostic::makeForbiddenType(loc,  
  diag::err_type_unsupported, type, "__float128"));
  `

right?
I suppose, then this diagnostic will be saved and emitted inside function named 
`handleDelayedForbiddenType`.
Here it checks that this forbidden type is actually allowed and emits a 
diagnostic if it's not.
The first problem that `handleDelayedForbiddenType` is called too early. We 
don't know in this place whether we are in SYCL device code or not. Because 
basically entry point to SYCL device code is a template function with 
`sycl_kernel` attribute, and every function it calls become a device function. 
So we only know where is device code only after templates instantiation, it 
happens a bit later after `handleDelayedForbiddenType` call.

It seems that the second problem is the same problem which prevented me from 
implementing diagnosing of `__float128` type through CUDA/OMP deferred 
diagnostics (I mentioned my attempt in the last comment 
https://reviews.llvm.org/D74387#1870014). I still need to find best place for 
diagnostic issuing. It seems that there are so many places where type can 
actually be introduced to resulting LLVM IR module, and in some of them I need 
to check some additional conditions to do not prevent `__float128` usage when 
it actually doesn't introduce forbidden type to resulting LLVM IR module.

Please, correct me if I don't understand something or said something wrong. 
I would appreciate if you had some advices.

Thanks a lot.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74387



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


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

2020-02-13 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added subscribers: jwakely, jfb.
fhahn added a comment.

@jwakely it would be great if you could have a brief look at our recent 
proposal for matrix support in Clang and could let us know if you have any 
concerns? The original proposal is being discussed on cfe-dev 
(http://lists.llvm.org/pipermail/cfe-dev/2019-December/064141.html) and the 
discussion continued in January 
http://lists.llvm.org/pipermail/cfe-dev/2020-January/064206.html

We are currently updating the proposal to use operators instead of builtins, 
but it would be good to know if you have any high-level concerns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D74555: [clangd] Add a flag for setting isIncomplete flag true in all responses

2020-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

some drive-by comments:

if this is a client-specific option, wouldn't it be equally hard for client to 
just set this in the LSP layer, instead of telling clangd to do that?

by looking at the current patch, it rather seems like a user-specific option, 
which will help users who want to prevent their editors from re-ranking results.




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:983
+ LSPList.isIncomplete =
+ ClangdServerOpts.AlwaysIncomplete ? true
+   : List->HasMore;

nit: `ClangdServerOpts.AlwaysIncomplete || List->HasMore`



Comment at: clang-tools-extra/clangd/tool/ClangdMain.cpp:405
 
+opt AlwaysIncomplete{
+"always-incomplete",

if we want clients to set it wouldn't it be better to make it an 
`initialization` option instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74555



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


[PATCH] D74564: libclang: Add static build support for Windows

2020-02-13 Thread Cristian Adam via Phabricator via cfe-commits
cristian.adam created this revision.
cristian.adam added reviewers: chapuni, yvvan.
Herald added subscribers: cfe-commits, mgorny.
Herald added a project: clang.

On Linux and macOS it was possible to build libclang statically by configuring 
CMake with:

-D LIBCLANG_BUILD_STATIC=ON
-D LLVM_ENABLE_PIC=OFF

On Windows was not possible. This commit fixes this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D74564

Files:
  clang/include/clang-c/Platform.h
  clang/tools/libclang/CMakeLists.txt


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -77,11 +77,11 @@
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if(LLVM_ENABLE_PIC OR WIN32)
+if(LLVM_ENABLE_PIC)
   set(ENABLE_SHARED SHARED)
 endif()
 
-if((NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC) AND NOT WIN32)
+if(NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC)
   set(ENABLE_STATIC STATIC)
 endif()
 
@@ -114,6 +114,7 @@
   )
 
 if(ENABLE_SHARED)
+  target_compile_definitions(libclang PUBLIC CINDEX_EXPORTS)
   if(WIN32)
 set_target_properties(libclang
   PROPERTIES 
Index: clang/include/clang-c/Platform.h
===
--- clang/include/clang-c/Platform.h
+++ clang/include/clang-c/Platform.h
@@ -18,14 +18,20 @@
 
 LLVM_CLANG_C_EXTERN_C_BEGIN
 
-/* MSVC DLL import/export. */
-#ifdef _MSC_VER
-  #ifdef _CINDEX_LIB_
-#define CINDEX_LINKAGE __declspec(dllexport)
-  #else
-#define CINDEX_LINKAGE __declspec(dllimport)
+/* Windows DLL import/export. */
+#ifdef _WIN32
+  #ifdef CINDEX_EXPORTS
+#ifdef _CINDEX_LIB_
+  #define CINDEX_LINKAGE __declspec(dllexport)
+#else
+  #define CINDEX_LINKAGE __declspec(dllimport)
+#endif
   #endif
-#else
+#elif defined(CINDEX_EXPORTS)
+  #define CINDEX_LINKAGE __attribute__((visibility("default")))
+#endif
+
+#ifndef CINDEX_LINKAGE
   #define CINDEX_LINKAGE
 #endif
 


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -77,11 +77,11 @@
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if(LLVM_ENABLE_PIC OR WIN32)
+if(LLVM_ENABLE_PIC)
   set(ENABLE_SHARED SHARED)
 endif()
 
-if((NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC) AND NOT WIN32)
+if(NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC)
   set(ENABLE_STATIC STATIC)
 endif()
 
@@ -114,6 +114,7 @@
   )
 
 if(ENABLE_SHARED)
+  target_compile_definitions(libclang PUBLIC CINDEX_EXPORTS)
   if(WIN32)
 set_target_properties(libclang
   PROPERTIES 
Index: clang/include/clang-c/Platform.h
===
--- clang/include/clang-c/Platform.h
+++ clang/include/clang-c/Platform.h
@@ -18,14 +18,20 @@
 
 LLVM_CLANG_C_EXTERN_C_BEGIN
 
-/* MSVC DLL import/export. */
-#ifdef _MSC_VER
-  #ifdef _CINDEX_LIB_
-#define CINDEX_LINKAGE __declspec(dllexport)
-  #else
-#define CINDEX_LINKAGE __declspec(dllimport)
+/* Windows DLL import/export. */
+#ifdef _WIN32
+  #ifdef CINDEX_EXPORTS
+#ifdef _CINDEX_LIB_
+  #define CINDEX_LINKAGE __declspec(dllexport)
+#else
+  #define CINDEX_LINKAGE __declspec(dllimport)
+#endif
   #endif
-#else
+#elif defined(CINDEX_EXPORTS)
+  #define CINDEX_LINKAGE __attribute__((visibility("default")))
+#endif
+
+#ifndef CINDEX_LINKAGE
   #define CINDEX_LINKAGE
 #endif
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74562: [OpenMP][OMPIRBuilder] Introducing the `OMPBuilderCBHelpers` helper class

2020-02-13 Thread Fady Ghanim via Phabricator via cfe-commits
fghanim created this revision.
fghanim added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, guansong.
Herald added a project: clang.

This patch introduces a new helper class `OMPBuilderCBHelpers`, 
which will contain all reusable C/C++ language specific function-
alities required by the `OMPIRBuilder`.

Initially, this helper class contains the body and finalization
codegen functionalities implemented using callbacks which were
moved here for reusability among the different directives
implemented in the `OMPIRBuilder`, along with RAIIs for preserving
state prior to emitting outlined and/or inlined OpenMP regions.

In the future this helper class will also contain all the different
call backs required by OpenMP clauses/variable privatization.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D74562

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/parallel_codegen.cpp

Index: clang/test/OpenMP/parallel_codegen.cpp
===
--- clang/test/OpenMP/parallel_codegen.cpp
+++ clang/test/OpenMP/parallel_codegen.cpp
@@ -112,7 +112,7 @@
 // ALL:   define linkonce_odr {{[a-z\_\b]*[ ]?i32}} [[TMAIN]](i8** %argc)
 // ALL:   store i8** %argc, i8*** [[ARGC_ADDR:%.+]],
 // CHECK:   call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 2, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, i{{64|32}})* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], i{{64|32}} %{{.+}})
-// IRBUILDER:   call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 2, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, i{{64|32}})* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], i{{64|32}} %{{.+}})
+// IRBUILDER:   call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 3, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, double**, i{{64|32}})* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], double** [[VAR:%.+]], i{{64|32}} %{{.+}})
 // ALL:  ret i32 0
 // ALL-NEXT:  }
 // ALL-DEBUG:   define linkonce_odr i32 [[TMAIN]](i8** %argc)
@@ -124,12 +124,12 @@
 // CHECK-DEBUG:  [[KMPC_LOC_PSOURCE_REF:%.+]] = getelementptr inbounds %struct.ident_t, %struct.ident_t* [[LOC_2_ADDR]], i32 0, i32 4
 // CHECK-DEBUG-NEXT:  store i8* getelementptr inbounds ([{{.+}} x i8], [{{.+}} x i8]* [[LOC2]], i32 0, i32 0), i8** [[KMPC_LOC_PSOURCE_REF]]
 // CHECK-DEBUG-NEXT:  call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[LOC_2_ADDR]], i32 2, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, i64)* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], i64 %{{.+}})
-// IRBUILDER-DEBUG:   call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @{{.*}}, i32 2, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, i64)* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], i64 %{{.+}})
+// IRBUILDER-DEBUG:   call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @{{.*}}, i32 3, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, double**, i64)* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], double** [[VAR:%.+]], i64 %{{.+}})
 // ALL-DEBUG:  ret i32 0
 // ALL-DEBUG-NEXT:  }
 
 // CHECK:   define internal {{.*}}void [[OMP_OUTLINED]](i32* noalias %.global_tid., i32* noalias %.bound_tid., i8*** dereferenceable({{4|8}}) %argc, i{{64|32}}{{.*}} %{{.+}})
-// IRBUILDER:   define internal {{.*}}void [[OMP_OUTLINED]](i32* noalias %{{.*}}, i32* noalias %{{.*}}, i8*** [[ARGC_REF:%.*]], i{{64|32}}{{.*}} %{{.+}})
+// IRBUILDER:   define internal {{.*}}void [[OMP_OUTLINED]](i32* noalias %{{.*}}, i32* noalias %{{.*}}, i8*** [[ARGC_REF:%.*]], double** [[VAR]], i{{64|32}}{{.*}} %{{.+}})
 // CHECK:   store i8*** %argc, i8 [[ARGC_PTR_ADDR:%.+]],
 // CHECK:   [[ARGC_REF:%.+]] = load i8***, i8 [[ARGC_PTR_ADDR]]
 // ALL: [[ARGC:%.+]] = load i8**, i8*** [[ARGC_REF]]
@@ -140,7 +140,7 @@
 // CHECK-NEXT:  unreachable
 // CHECK-NEXT:  }
 // CHECK-DEBUG:   define internal void [[OMP_OUTLINED_DEBUG:@.+]](i32* noalias %.global_tid., i32* noalias %.bound_tid., i8*** dereferenceable({{4|8}}) %argc, i64 %{{.+}})
-// IRBUILDER-DEBUG:   define internal void [[OMP_OUTLINED_DEBUG:@.+]](i32* noalias %{{.*}}, i32* noalias %{{.*}}, i8*** [[ARGC_REF:%.*]], i64 %{{.+}})
+// IRBUILDER-DEBUG:   define internal void [[OMP_OUTLINED_DEBUG:@.+]](i32* noalias %{{.*}}, i32* noalias %{{.*}}, i8*** [[ARGC_REF:%.*]], double** [[VAR]], i64 %{{.+}})
 // CHECK-DEBUG:   store i8*** %argc, i8 [[ARGC_PTR_

[PATCH] D71734: [Modules] Handle tag types and complain about bad merges in C/Objective-C mode

2020-02-13 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno updated this revision to Diff 244435.
bruno added a comment.

Address Richard's review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71734

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/ODRHash.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Modules/odr_hash-record.c

Index: clang/test/Modules/odr_hash-record.c
===
--- /dev/null
+++ clang/test/Modules/odr_hash-record.c
@@ -0,0 +1,391 @@
+// Clear and create directories
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: mkdir %t/cache
+// RUN: mkdir %t/Inputs
+
+// Build first header file
+// RUN: echo "#define FIRST" >> %t/Inputs/first.h
+// RUN: cat %s   >> %t/Inputs/first.h
+
+// Build second header file
+// RUN: echo "#define SECOND" >> %t/Inputs/second.h
+// RUN: cat %s>> %t/Inputs/second.h
+
+// Test that each header can compile
+// RUN: %clang_cc1 -fsyntax-only -x c %t/Inputs/first.h
+// RUN: %clang_cc1 -fsyntax-only -x c %t/Inputs/second.h
+
+// Build module map file
+// RUN: echo "module FirstModule {" >> %t/Inputs/module.map
+// RUN: echo "header \"first.h\""   >> %t/Inputs/module.map
+// RUN: echo "}">> %t/Inputs/module.map
+// RUN: echo "module SecondModule {">> %t/Inputs/module.map
+// RUN: echo "header \"second.h\""  >> %t/Inputs/module.map
+// RUN: echo "}">> %t/Inputs/module.map
+
+// Run test
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -x c \
+// RUN:   -fmodules -fimplicit-module-maps -fmodules-cache-path=%t/cache \
+// RUN:   -I%t/Inputs -verify %s
+
+#if !defined(FIRST) && !defined(SECOND)
+#include "first.h"
+#include "second.h"
+#endif
+
+#if defined(FIRST)
+struct S1 {};
+struct S1 s1a;
+#elif defined(SECOND)
+struct S1 {};
+#else
+struct S1 s1;
+#endif
+
+#if defined(FIRST)
+struct S2 {
+  int x;
+  int y;
+};
+#elif defined(SECOND)
+struct S2 {
+  int y;
+  int x;
+};
+#else
+struct S2 s2;
+// expected-error@first.h:* {{'S2' has different definitions in different modules; first difference is definition in module 'FirstModule' found field 'x'}}
+// expected-note@second.h:* {{but in 'SecondModule' found field 'y'}}
+#endif
+
+#if defined(FIRST)
+struct S3 {
+  double x;
+};
+#elif defined(SECOND)
+struct S3 {
+  int x;
+};
+#else
+struct S3 s3;
+// expected-error@second.h:* {{'S3::x' from module 'SecondModule' is not present in definition of 'struct S3' in module 'FirstModule'}}
+// expected-note@first.h:* {{declaration of 'x' does not match}}
+#endif
+
+#if defined(FIRST)
+typedef int A;
+struct S4 {
+  A x;
+};
+
+struct S5 {
+  A x;
+};
+#elif defined(SECOND)
+typedef int B;
+struct S4 {
+  B x;
+};
+
+struct S5 {
+  int x;
+};
+#else
+struct S4 s4;
+// expected-error@first.h:* {{'S4' has different definitions in different modules; first difference is definition in module 'FirstModule' found field 'x' with type 'A' (aka 'int')}}
+// expected-note@second.h:* {{but in 'SecondModule' found field 'x' with type 'B' (aka 'int')}}
+
+struct S5 s5;
+// expected-error@first.h:* {{'S5' has different definitions in different modules; first difference is definition in module 'FirstModule' found field 'x' with type 'A' (aka 'int')}}
+// expected-note@second.h:* {{but in 'SecondModule' found field 'x' with type 'int'}}
+#endif
+
+#if defined(FIRST)
+struct S6 {
+  unsigned x;
+};
+#elif defined(SECOND)
+struct S6 {
+  unsigned x : 1;
+};
+#else
+struct S6 s6;
+// expected-error@first.h:* {{'S6' has different definitions in different modules; first difference is definition in module 'FirstModule' found non-bitfield 'x'}}
+// expected-note@second.h:* {{but in 'SecondModule' found bitfield 'x'}}
+#endif
+
+#if defined(FIRST)
+struct S7 {
+  unsigned x : 2;
+};
+#elif defined(SECOND)
+struct S7 {
+  unsigned x : 1;
+};
+#else
+struct S7 s7;
+// expected-error@first.h:* {{'S7' has different definitions in different modules; first difference is definition in module 'FirstModule' found bitfield 'x' with one width expression}}
+// expected-note@second.h:* {{but in 'SecondModule' found bitfield 'x' with different width expression}}
+#endif
+
+#if defined(FIRST)
+struct S8 {
+  unsigned x : 2;
+};
+#elif defined(SECOND)
+struct S8 {
+  unsigned x : 1 + 1;
+};
+#else
+struct S8 s8;
+// expected-error@first.h:* {{'S8' has different definitions in different modules; first difference is definition in module 'FirstModule' found bitfield 'x' with one width expression}}
+// expected-note@second.h:* {{but in 'SecondModule' found bitfield 'x' with different width expression}}
+#endif
+
+#if defined(FIRST)
+struct S12 {
+  unsigned x[5];
+};
+#elif

[PATCH] D71734: [Modules] Handle tag types and complain about bad merges in C/Objective-C mode

2020-02-13 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno marked 3 inline comments as done.
bruno added a comment.

Thanks for taking a look Richard, comments inline.




Comment at: clang/include/clang/AST/Decl.h:4009-4010
+
+  /// Store the ODR hash for this decl.
+  unsigned ODRHash;
 };

rsmith wrote:
> We shouldn't store this here; this will make all `CXXRecordDecl`s larger to 
> store a field they will never look at.
> 
> We have 27 spare trailing bits in `RecordDeclBitfields` (28 if you don't add 
> the `HasODRHash` bit and use 0 to mean "hash not computed"). Can we store 
> this there instead of here?
Makes sense!



Comment at: clang/lib/AST/ODRHash.cpp:480-481
+if (auto *SubRD = dyn_cast(SubDecl)) {
+  if (!SubRD->isCompleteDefinition())
+continue;
+  ID.AddInteger(SubRD->getODRHash());

rsmith wrote:
> This is, at least in principle, not reliable. After definition merging, we 
> could have picked a different definition of this record type as "the" 
> definition. (It's probably not straightforward to get this to happen in 
> practice, and maybe not even possible, but I'm not certain of that.)
> 
> Maybe we could add to `TagDecl` something like
> 
> ```
> bool isThisDeclarationADemotedDefinition() const {
>   return !isThisDeclarationADefinition() && BraceRange.isValid();
> }
> ```
> 
> and then check `isThisDeclarationADefinition() || 
> isThisDeclarationADemotedDefinition()` here? (I'm not sure we always update 
> `BraceRange` properly for demoted definitions either, so maybe that's not 
> quite right.)
There are two things I realized while looking at this:

- What I really intended here was to hash underlying anonymous structs/unions, 
not just any underlying RecordDecl. Will change the logic in 
`ODRHash::AddRecordDecl` do reflect that properly.
- This patch was skipping `RecordDecl`s without definitions during ODR 
diagnostics, I've changed to instead decide at merge time if we want to 
register those Decls for later diagnose, and the new rule is clang skips 
`RecordDecl`s that disagree on whether they have a definition. This should 
still allow clang to diagnose declarations without defintions that have 
different attributes (which I intend to add for specific attributes in future 
patches).

Will update the patch to reflect that. WDYT?



Comment at: clang/lib/Serialization/ASTReader.cpp:9585-9587
+assert(getContext().hasSameType(FirstField->getType(),
+SecondField->getType()));
+

rsmith wrote:
> I don't understand why this assertion would be correct if the above branch 
> can ever be taken. It's possible for two different types to have the same 
> hash, and it looks like we'll assert here if that happens. Should we be 
> branching on `hasSameType` above instead of comparing hashes?
This is trying to cover two things. The first one is to handle nested anonymous 
unions, which might have the same type, but underlying mismatching fields:
```
#if defined(FIRST)
struct AU {
  union {
int a;
  };
};
#elif defined(SECOND)
struct AU {
  union {
char a;
  };
};
#else
struct AU au;
```

The second is to allow for @interfaces (downstream patches at the moment) to 
reuse logic to diagnose fields in `ODRDiagField` without having to add its own 
check for the underlying types. Does that makes sense?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71734



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


[clang] 18789bf - [OPENMP50]Fix handling of clauses in parallel master taskloop directive.

2020-02-13 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-02-13T11:00:01-05:00
New Revision: 18789bfe3a39f69f6cfe6490a24a61ea2ff0b5af

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

LOG: [OPENMP50]Fix handling of clauses in parallel master taskloop directive.

We need to capture correctly the value of num_tasks clause and should
not try to emit the if clause at all in the task region.

Added: 


Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/test/OpenMP/parallel_master_taskloop_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 7181374a73fc..f40018306772 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -2018,12 +2018,14 @@ static void emitCommonSimdLoop(CodeGenFunction &CGF, 
const OMPLoopDirective &S,
 BodyCodeGen(CGF);
   };
   const Expr *IfCond = nullptr;
-  for (const auto *C : S.getClausesOfKind()) {
-if (CGF.getLangOpts().OpenMP >= 50 &&
-(C->getNameModifier() == OMPD_unknown ||
- C->getNameModifier() == OMPD_simd)) {
-  IfCond = C->getCondition();
-  break;
+  if (isOpenMPSimdDirective(S.getDirectiveKind())) {
+for (const auto *C : S.getClausesOfKind()) {
+  if (CGF.getLangOpts().OpenMP >= 50 &&
+  (C->getNameModifier() == OMPD_unknown ||
+   C->getNameModifier() == OMPD_simd)) {
+IfCond = C->getCondition();
+break;
+  }
 }
   }
   if (IfCond) {
@@ -5682,7 +5684,7 @@ void 
CodeGenFunction::EmitOMPParallelMasterTaskLoopDirective(
   Action.Enter(CGF);
   CGF.EmitOMPTaskLoopBasedDirective(S);
 };
-OMPLexicalScope Scope(CGF, S, llvm::None, /*EmitPreInitStmt=*/false);
+OMPLexicalScope Scope(CGF, S, OMPD_parallel, /*EmitPreInitStmt=*/false);
 CGM.getOpenMPRuntime().emitMasterRegion(CGF, TaskLoopCodeGen,
 S.getBeginLoc());
   };

diff  --git a/clang/test/OpenMP/parallel_master_taskloop_codegen.cpp 
b/clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
index 13195e10fa4a..7ab415aa3cfa 100644
--- a/clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
+++ b/clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -x c++ 
-emit-llvm %s -o - -femit-all-decls | FileCheck %s
-// 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 - -femit-all-decls | FileCheck %s
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -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-simd -x c++ 
-emit-llvm %s -o - -femit-all-decls | FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -x c++ -triple x86_64-apple-darwin10 
-emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -x c++ -triple x86_64-apple-darwin10 
-include-pch %t -verify %s -emit-llvm -o - -femit-all-decls | FileCheck 
--check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp-simd 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 // expected-no-diagnostics
 #ifndef HEADER



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


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

2020-02-13 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:84
"  o   - object\n"
+   "  oo  - object; output file is a list of unbundled 
objects\n"
"  gch - precompiled-header\n"

ABataev wrote:
> Hmm, are you going to introduce a new kind of output? It really requires RFC.
This is the offload-bundler tool, right? Who is using that except OpenMP (and 
SYCL)?

Is there a reason for `oo`? `uo` (=unboundled object), or `do` (=device object)?



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:160
+  }
+
   /// Write the header of the bundled file to \a OS based on the information

I don't understand the comment. If \p FileName is a list of outputs, how does 
this work?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74262



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


[PATCH] D73898: [analyzer] StdLibraryFunctionsChecker: Add argument constraints

2020-02-13 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 244430.
martong added a comment.

- Rebase to master


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73898

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints.c

Index: clang/test/Analysis/std-c-library-functions-arg-constraints.c
===
--- /dev/null
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.c
@@ -0,0 +1,22 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -triple x86_64-unknown-linux-gnu
+
+void clang_analyzer_eval(int);
+
+int glob;
+
+typedef struct FILE FILE;
+#define EOF -1
+
+int isalnum(int);
+void test_alnum_concrete() {
+  int ret = isalnum(256); // expected-warning{{Function argument constraint is not satisfied}}
+  (void)ret;
+}
+void test_alnum_symbolic(int x) {
+  int ret = isalnum(x);
+  (void)ret;
+  clang_analyzer_eval(EOF <= x && x <= 255); // expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -51,6 +51,7 @@
 //===--===//
 
 #include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
@@ -61,7 +62,8 @@
 using namespace clang::ento;
 
 namespace {
-class StdLibraryFunctionsChecker : public Checker {
+class StdLibraryFunctionsChecker
+: public Checker {
   /// Below is a series of typedefs necessary to define function specs.
   /// We avoid nesting types here because each additional qualifier
   /// would need to be repeated in every function spec.
@@ -142,6 +144,10 @@
   const CallEvent &Call,
   const Summary &Summary) const;
 
+void checkAsWithinRange(ProgramStateRef State, const CallEvent &Call,
+const Summary &Summary, const BugType &BT,
+CheckerContext &C) const;
+
   public:
 ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary) const {
@@ -155,6 +161,21 @@
   }
   llvm_unreachable("Unknown ValueRange kind!");
 }
+
+void check(ProgramStateRef State, const CallEvent &Call,
+   const Summary &Summary, const BugType &BT,
+   CheckerContext &C) const {
+  switch (Kind) {
+  case OutOfRange:
+llvm_unreachable("Not implemented yet!");
+  case WithinRange:
+checkAsWithinRange(State, Call, Summary, BT, C);
+return;
+  case ComparesToArgument:
+llvm_unreachable("Not implemented yet!");
+  }
+  llvm_unreachable("Unknown ValueRange kind!");
+}
   };
 
   /// The complete list of ranges that defines a single branch.
@@ -163,10 +184,15 @@
   using ArgTypes = std::vector;
   using Ranges = std::vector;
 
-  /// Includes information about function prototype (which is necessary to
-  /// ensure we're modeling the right function and casting values properly),
-  /// approach to invalidation, and a list of branches - essentially, a list
-  /// of list of ranges - essentially, a list of lists of lists of segments.
+  /// Includes information about
+  ///   * function prototype (which is necessary to
+  /// ensure we're modeling the right function and casting values properly),
+  ///   * approach to invalidation,
+  ///   * a list of branches - a list of list of ranges -
+  /// i.e. a list of lists of lists of segments,
+  ///   * a list of argument constraints, that must be true on every branch.
+  /// If these constraints are not satisfied that means a fatal error
+  /// usually resulting in undefined behaviour.
   struct Summary {
 const ArgTypes ArgTys;
 const QualType RetTy;
@@ -181,6 +207,10 @@
   Cases.push_back(VRS);
   return *this;
 }
+Summary &ArgConstraint(ValueRange VR) {
+  ArgConstraints.push_back(VR);
+  return *this;
+}
 
   private:
 static void assertTypeSuitableForSummary(QualType T) {
@@ -216,6 +246,8 @@
   // lazily, and it doesn't change after initialization.
   mutable llvm::StringMap FunctionSummaryMap;
 
+  BugType BT{this, "Unsatisfied argument constraints", categories::LogicError};
+
   // Auxiliary functions to support ArgNo within all structures
   // in a u

[PATCH] D74550: [AArch64][SVE] Add SVE index intrinsic

2020-02-13 Thread Cameron McInally via Phabricator via cfe-commits
cameron.mcinally accepted this revision.
cameron.mcinally added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: tatyana-krasnukha.

LGTM




Comment at: llvm/include/llvm/IR/IntrinsicsAArch64.td:804
+[IntrNoMem]>;
+
   class AdvSIMD_Merged1VectorArg_Intrinsic

Nit: The return type should really be something like llvm_anyintvector_ty, but 
I don't think there's a way to express that right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74550



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


  1   2   >