[PATCH] D81959: [HIP] Enable -amdgpu-internalize-symbols

2020-06-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/lib/Driver/ToolChains/HIP.cpp:64-65
+"-shared",
+"-mllvm",
+"-amdgpu-internalize-symbols",
+"-o",

We should probably add an lld driver flag for this rather than relying on the 
backend option? Is there some regular way to specify internalization that could 
add the target pass instead?


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

https://reviews.llvm.org/D81959



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


[PATCH] D81736: [openmp] Base of tablegen generated OpenMP common declaration

2020-06-16 Thread Valentin Clement via Phabricator via cfe-commits
clementval added a comment.

In D81736#2096336 , @jdoerfert wrote:

> In D81736#2095947 , @clementval 
> wrote:
>
> > In D81736#2093926 , @jdoerfert 
> > wrote:
> >
> > > Assuming this passes all the tests, it looks good to me. Let's wait a day 
> > > or two for people to take a look though :)
> >
> >
> > @jdoerfert Sure let's wait a bit. I see a failure because of some 
> > clang-tidy warnings. How strongly should I fix them? I see some conflict 
> > with other code I see in TableGen.
>
>
> Clang-tidy run by Phab is not binding but if it's reasonable modify it. Keep 
> the TableGen style consistent.


@jdoerfert I made some fix to fit in the TableGen style. So this is ready to 
land on my side.
I'm working on the next patches. One that replace the specific enums in Flang 
to use the one defined here. Another one that continue to replace the MACROS in 
OMPConstants.h/.cpp with TableGen code generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81736



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


[clang] 237c2a2 - DR458: Search template parameter scopes in the right order.

2020-06-16 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-06-16T19:41:14-07:00
New Revision: 237c2a23b6d4fa953f5ae910dccf492db61bb959

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

LOG: DR458: Search template parameter scopes in the right order.

C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to. (Eg, for a class template, you search the template parameter scope
after looking in that class template and its base classes and before
looking in the scope containing the class template.) This is complicated
by the fact that scope lookup within a template parameter scope looks in
a different sequence of places prior to reaching the end of the
declarator-id in the template declaration.

We used to approximate the proper lookup rule with a hack in the scope /
decl context walk inside name lookup. Now we instead compute the lookup
parent for each template parameter scope. This gets the right answer and
as a bonus is substantially simpler and more uniform.

In order to get this right, we now make sure to enter a distinct Scope
for each template parameter scope. (The fact that we didn't before was
already a bug, but not really observable most of the time, since
template parameters can't shadow each other.)

Added: 


Modified: 
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Scope.h
clang/lib/AST/DeclBase.cpp
clang/lib/Parse/ParseExprCXX.cpp
clang/lib/Parse/ParseTemplate.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaLookup.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/test/CXX/drs/dr4xx.cpp
clang/test/CXX/temp/temp.res/temp.local/p8.cpp
clang/test/SemaCXX/lambda-expressions.cpp
clang/www/cxx_dr_status.html

Removed: 




diff  --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 1ae219781c69..31840694da27 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1088,6 +1088,31 @@ class Parser : public CodeCompletionHandler {
 }
   };
 
+  /// Introduces zero or more scopes for parsing. The scopes will all be exited
+  /// when the object is destroyed.
+  class MultiParseScope {
+Parser 
+unsigned NumScopes = 0;
+
+MultiParseScope(const MultiParseScope&) = delete;
+
+  public:
+MultiParseScope(Parser ) : Self(Self) {}
+void Enter(unsigned ScopeFlags) {
+  Self.EnterScope(ScopeFlags);
+  ++NumScopes;
+}
+void Exit() {
+  while (NumScopes) {
+Self.ExitScope();
+--NumScopes;
+  }
+}
+~MultiParseScope() {
+  Exit();
+}
+  };
+
   /// EnterScope - Start a new scope.
   void EnterScope(unsigned ScopeFlags);
 
@@ -3240,7 +3265,7 @@ class Parser : public CodeCompletionHandler {
   DeclaratorContext Context, const ParsedTemplateInfo ,
   ParsingDeclRAIIObject , SourceLocation ,
   ParsedAttributes , AccessSpecifier AS = AS_none);
-  bool ParseTemplateParameters(unsigned Depth,
+  bool ParseTemplateParameters(MultiParseScope , unsigned Depth,
SmallVectorImpl ,
SourceLocation ,
SourceLocation );

diff  --git a/clang/include/clang/Sema/Scope.h 
b/clang/include/clang/Sema/Scope.h
index 9b8f1415a1e3..b7260f15fe1b 100644
--- a/clang/include/clang/Sema/Scope.h
+++ b/clang/include/clang/Sema/Scope.h
@@ -322,8 +322,21 @@ class Scope {
   /// declared in.
   bool isDeclScope(const Decl *D) const { return DeclsInScope.count(D) != 0; }
 
-  DeclContext *getEntity() const { return Entity; }
-  void setEntity(DeclContext *E) { Entity = E; }
+  /// Get the entity corresponding to this scope.
+  DeclContext *getEntity() const {
+return isTemplateParamScope() ? nullptr : Entity;
+  }
+
+  /// Get the DeclContext in which to continue unqualified lookup after a
+  /// lookup in this scope.
+  DeclContext *getLookupEntity() const { return Entity; }
+
+  void setEntity(DeclContext *E) {
+assert(!isTemplateParamScope() &&
+   "entity associated with template param scope");
+Entity = E;
+  }
+  void setLookupEntity(DeclContext *E) { Entity = E; }
 
   /// Determine whether any unrecoverable errors have occurred within this
   /// scope. Note that this may return false even if the scope contains invalid

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index 2aab53f4fa90..50ad0255f838 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -241,7 +241,7 @@ TemplateDecl *Decl::getDescribedTemplate() const {
 }
 
 bool Decl::isTemplated() const {
-  // A declaration is dependent if it is a template or a template pattern, or
+  // A declaration is templated if it is a template or a template 

[clang] 1b8125b - Don't assert if we find a dependently-typed variable in the

2020-06-16 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-06-16T19:41:13-07:00
New Revision: 1b8125b041e28a315e5c5fe64441a2fb07a2f5ea

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

LOG: Don't assert if we find a dependently-typed variable in the
redeclaration chain for an array.

A prior attempt to fix this in r280330 didn't handle the case where the
old variable is dependent and the new one is not.

It is notable and worrying that the test case in this example forms a
redeclaration chain for a non-dependent variable that includes a
declaration with a dependent type. We should probably fix that too.

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/SemaTemplate/array-redeclaration.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index d5d946429e7d..2bf16d138d5a 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -3910,11 +3910,11 @@ void Sema::MergeVarDeclTypes(VarDecl *New, VarDecl *Old,
   if (!NewArray->isIncompleteArrayType() && !NewArray->isDependentType()) {
 for (VarDecl *PrevVD = Old->getMostRecentDecl(); PrevVD;
  PrevVD = PrevVD->getPreviousDecl()) {
-  const ArrayType *PrevVDTy = 
Context.getAsArrayType(PrevVD->getType());
+  QualType PrevVDTy = PrevVD->getType();
   if (PrevVDTy->isIncompleteArrayType() || PrevVDTy->isDependentType())
 continue;
 
-  if (!Context.hasSameType(NewArray, PrevVDTy))
+  if (!Context.hasSameType(New->getType(), PrevVDTy))
 return diagnoseVarDeclTypeMismatch(*this, New, PrevVD);
 }
   }

diff  --git a/clang/test/SemaTemplate/array-redeclaration.cpp 
b/clang/test/SemaTemplate/array-redeclaration.cpp
index 4edee701cfc4..af0a2770291c 100644
--- a/clang/test/SemaTemplate/array-redeclaration.cpp
+++ b/clang/test/SemaTemplate/array-redeclaration.cpp
@@ -31,3 +31,9 @@ void foo3() {
 void foo4() {
   foo3<5>();
 }
+
+namespace NS {
+  int f() { extern int arr[3]; { extern int arr[]; } return 0; }
+  template void g() { extern int arr[3]; extern T arr; }
+  template void g();
+}



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


[PATCH] D81478: [OPENMP50]Codegen for scan directives in parallel for regions.

2020-06-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:3627
+  emitScanBasedDirective(CGF, S, NumIteratorsGen, FirstGen, SecondGen);
+} else {
+  OMPCancelStackRAII CancelRegion(CGF, OMPD_parallel_for, S.hasCancel());

ABataev wrote:
> jdoerfert wrote:
> > This looks pretty much like D81658, right? Could we avoid the duplication 
> > and maybe use a templated function (or something else)?
> The duplication is quite small. Here we don't need to check for lastprivates 
> update, we need to check for the cancellation region. I don't think that the 
> outlined functions are going to be much simpler and easier to read.
I mean, these ~25 lines will exist 3 times at least. 2 times tacking 
lastprivate, which we can do for the third time at no extra cost, and 2 times 
with the cancelation RAII. Any change will need to be duplicated 3 times as 
well, etc.

If we do
```
template
void emitWorksharingHelper(..., bool )
if (llvm::any_of(S.getClausesOfKind(),
 [](const OMPReductionClause *C) {
   return C->getModifier() == OMPC_REDUCTION_inscan;
 })) {
  const auto & = [](CodeGenFunction ) {
OMPLocalDeclMapRAII Scope(CGF);
OMPLoopScope LoopScope(CGF, S);
return CGF.EmitScalarExpr(S.getNumIterations());
  };
  const auto & = [](CodeGenFunction ) {
RAII CancelRegion(CGF, OMPD_for, S.hasCancel());
(void)CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
 emitForLoopBounds,
 emitDispatchForLoopBounds);
// Emit an implicit barrier at the end.
CGF.CGM.getOpenMPRuntime().emitBarrierCall(CGF, S.getBeginLoc(),
   OMPD_for);
  };
  const auto & = [, ](CodeGenFunction ) {
RAII CancelRegion(CGF, OMPD_for, S.hasCancel());
HasLastprivate = CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
 emitForLoopBounds,
 emitDispatchForLoopBounds);
  };
  emitScanBasedDirective(CGF, S, NumIteratorsGen, FirstGen, SecondGen);
} else {
  OMPCancelStackRAII CancelRegion(CGF, OMPD_parallel_for, S.hasCancel());
CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(), 
emitForLoopBounds,
   emitDispatchForLoopBounds);
}
```
We can call it three times:
```
emitWorksharingHelper(...);
emitWorksharingHelper(...);
emitWorksharingHelper(...);
```

Wouldn't that be cleaner?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81478



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


[PATCH] D79411: [VE] Clang toolchain for VE

2020-06-16 Thread Kazushi Marukawa via Phabricator via cfe-commits
kaz7 added reviewers: hfinkel, b-sumner, jmolloy, kparzysz, majnemer, igorb.
kaz7 added a comment.

Add people who reviewed patches adding new target to clang.  Sorry for 
bothering you guys, but I appreciate if you review our patch or give us 
suggestions how to get reviewed.  Thanks in advance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79411



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


[PATCH] D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well.

2020-06-16 Thread JunMa via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4a1776979fd8: [CodeGen][TLS] Set TLS Model for __tls_guard 
as well. (authored by junparser).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81543

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/test/CodeGen/tls-model.c
  clang/test/CodeGen/tls-model.cpp
  clang/test/CodeGenCXX/ms-thread_local.cpp

Index: clang/test/CodeGenCXX/ms-thread_local.cpp
===
--- clang/test/CodeGenCXX/ms-thread_local.cpp
+++ clang/test/CodeGenCXX/ms-thread_local.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -std=c++1y -triple=i686-pc-win32 -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 %s  -std=c++1y -triple=i686-pc-win32 -ftls-model=local-dynamic -emit-llvm -o - | FileCheck %s -check-prefix=CHECK-LD
 
 struct A {
   A();
@@ -8,15 +9,22 @@
 // CHECK-DAG: $"??$a@X@@3UA@@A" = comdat any
 // CHECK-DAG: @"??$a@X@@3UA@@A" = linkonce_odr dso_local thread_local global %struct.A zeroinitializer, comdat, align 1
 // CHECK-DAG: @"??__E?$a@X@@YAXXZ$initializer$" = internal constant void ()* @"??__E?$a@X@@YAXXZ", section ".CRT$XDU", comdat($"??$a@X@@3UA@@A")
+// CHECK-LD-DAG: $"??$a@X@@3UA@@A" = comdat any
+// CHECK-LD-DAG: @"??$a@X@@3UA@@A" = linkonce_odr dso_local thread_local(localdynamic) global %struct.A zeroinitializer, comdat, align 1
+// CHECK-LD-DAG: @"??__E?$a@X@@YAXXZ$initializer$" = internal constant void ()* @"??__E?$a@X@@YAXXZ", section ".CRT$XDU", comdat($"??$a@X@@3UA@@A")
 template 
 thread_local A a = A();
 
 // CHECK-DAG: @"?b@@3UA@@A" = dso_local thread_local global %struct.A zeroinitializer, align 1
 // CHECK-DAG: @"__tls_init$initializer$" = internal constant void ()* @__tls_init, section ".CRT$XDU"
+// CHECK-LD-DAG: @"?b@@3UA@@A" = dso_local thread_local(localdynamic) global %struct.A zeroinitializer, align 1
+// CHECK-LD-DAG: @"__tls_init$initializer$" = internal constant void ()* @__tls_init, section ".CRT$XDU"
 thread_local A b;
 
 // CHECK-LABEL: define internal void @__tls_init()
 // CHECK: call void @"??__Eb@@YAXXZ"
+// CHECK-LD-LABEL: define internal void @__tls_init()
+// CHECK-LD: call void @"??__Eb@@YAXXZ"
 
 thread_local A  = b;
 thread_local A  = c;
@@ -29,3 +37,5 @@
 
 // CHECK: !llvm.linker.options = !{![[dyn_tls_init:[0-9]+]]}
 // CHECK: ![[dyn_tls_init]] = !{!"/include:___dyn_tls_init@12"}
+// CHECK-LD: !llvm.linker.options = !{![[dyn_tls_init:[0-9]+]]}
+// CHECK-LD: ![[dyn_tls_init]] = !{!"/include:___dyn_tls_init@12"}
Index: clang/test/CodeGen/tls-model.cpp
===
--- clang/test/CodeGen/tls-model.cpp
+++ clang/test/CodeGen/tls-model.cpp
@@ -16,29 +16,52 @@
 }
 int __thread __attribute__((tls_model("initial-exec"))) z;
 
+struct S {
+  S();
+  ~S();
+};
+struct T {
+  ~T();
+};
+
+struct S thread_local s1;
+struct T thread_local t1;
+
 // Note that unlike normal C uninitialized global variables,
 // uninitialized TLS variables do NOT have COMMON linkage.
 
 // CHECK-GD: @z1 = global i32 0
-// CHECK-GD: @f.y = internal thread_local global i32 0
 // CHECK-GD: @z2 = global i32 0
 // CHECK-GD: @x = thread_local global i32 0
+// CHECK-GD: @_ZZ1fvE1y = internal thread_local global i32 0
 // CHECK-GD: @z = thread_local(initialexec) global i32 0
+// CHECK-GD: @s1 = thread_local global %struct.S zeroinitializer
+// CHECK-GD: @t1 = thread_local global %struct.T zeroinitializer
+// CHECK-GD: @__tls_guard = internal thread_local global i8 0
 
 // CHECK-LD: @z1 = global i32 0
-// CHECK-LD: @f.y = internal thread_local(localdynamic) global i32 0
 // CHECK-LD: @z2 = global i32 0
 // CHECK-LD: @x = thread_local(localdynamic) global i32 0
+// CHECK-LD: @_ZZ1fvE1y = internal thread_local(localdynamic) global i32 0
 // CHECK-LD: @z = thread_local(initialexec) global i32 0
+// CHECK-LD: @s1 = thread_local(localdynamic) global %struct.S zeroinitializer
+// CHECK-LD: @t1 = thread_local(localdynamic) global %struct.T zeroinitializer
+// CHECK-LD: @__tls_guard = internal thread_local(localdynamic) global i8 0
 
 // CHECK-IE: @z1 = global i32 0
-// CHECK-IE: @f.y = internal thread_local(initialexec) global i32 0
 // CHECK-IE: @z2 = global i32 0
 // CHECK-IE: @x = thread_local(initialexec) global i32 0
+// CHECK-IE: @_ZZ1fvE1y = internal thread_local(initialexec) global i32 0
 // CHECK-IE: @z = thread_local(initialexec) global i32 0
+// CHECK-IE: @s1 = thread_local(initialexec) global %struct.S zeroinitializer
+// CHECK-IE: @t1 = thread_local(initialexec) global %struct.T zeroinitializer
+// CHECK-IE: @__tls_guard = internal thread_local(initialexec) global i8 0
 
 // CHECK-LE: @z1 = global i32 0
-// CHECK-LE: @f.y = internal thread_local(localexec) global i32 0
 // CHECK-LE: @z2 = global i32 0
 // CHECK-LE: @x = 

[PATCH] D81003: [clang] SequenceChecker: Also visit default arguments.

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

Seems reasonable. I think we need similar handling for `CXXDefaultInitExpr`, 
for cases like this:

  int a;
  struct X { int b = ++a; };
  int c = X{} + a;




Comment at: clang/test/SemaCXX/warn-unsequenced.cpp:282-283
+  void test() {
+// TODO: Consider adding a remark indicating the function call where
+// the default argument was used.
+int b;

I think it's important that we handle this in the near future (though I don't 
mind if you'd like to submit this patch as-is and deal with this as a 
follow-on). For a case like:

```
void f(int, int = a++);
// ... some time later ...
f(a);
```

... a warning that only gives the location of the default argument is not 
useful. We need to show both locations (and potentially a path through multiple 
default arguments, I suppose; yuck).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81003



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


[PATCH] D81330: [clang] SequenceChecker: C++17 sequencing rule for overloaded operators.

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

It would be nice to avoid the duplication between the builtin and overloaded 
cases here, but I don't see a good way to do that. LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81330



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


[clang] 4a17769 - [CodeGen][TLS] Set TLS Model for __tls_guard as well.

2020-06-16 Thread Jun Ma via cfe-commits

Author: Jun Ma
Date: 2020-06-17T08:31:13+08:00
New Revision: 4a1776979fd8e9473e433d7ec6f2bbf4bf9523ff

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

LOG: [CodeGen][TLS] Set TLS Model for __tls_guard as well.

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

Added: 
clang/test/CodeGen/tls-model.cpp

Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/CodeGenModule.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/CodeGen/MicrosoftCXXABI.cpp
clang/test/CodeGenCXX/ms-thread_local.cpp

Removed: 
clang/test/CodeGen/tls-model.c



diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 887df8a97f34..79bc51e43f7a 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -971,9 +971,9 @@ static llvm::GlobalVariable::ThreadLocalMode 
GetLLVMTLSModel(StringRef S) {
   .Case("local-exec", llvm::GlobalVariable::LocalExecTLSModel);
 }
 
-static llvm::GlobalVariable::ThreadLocalMode GetLLVMTLSModel(
-CodeGenOptions::TLSModel M) {
-  switch (M) {
+llvm::GlobalVariable::ThreadLocalMode
+CodeGenModule::GetDefaultLLVMTLSModel() const {
+  switch (CodeGenOpts.getDefaultTLSModel()) {
   case CodeGenOptions::GeneralDynamicTLSModel:
 return llvm::GlobalVariable::GeneralDynamicTLSModel;
   case CodeGenOptions::LocalDynamicTLSModel:
@@ -990,7 +990,7 @@ void CodeGenModule::setTLSMode(llvm::GlobalValue *GV, const 
VarDecl ) const {
   assert(D.getTLSKind() && "setting TLS mode on non-TLS var!");
 
   llvm::GlobalValue::ThreadLocalMode TLM;
-  TLM = GetLLVMTLSModel(CodeGenOpts.getDefaultTLSModel());
+  TLM = GetDefaultLLVMTLSModel();
 
   // Override the TLS model if it is explicitly specified.
   if (const TLSModelAttr *Attr = D.getAttr()) {

diff  --git a/clang/lib/CodeGen/CodeGenModule.h 
b/clang/lib/CodeGen/CodeGenModule.h
index 17d42c50728e..d17d652b32f6 100644
--- a/clang/lib/CodeGen/CodeGenModule.h
+++ b/clang/lib/CodeGen/CodeGenModule.h
@@ -790,6 +790,9 @@ class CodeGenModule : public CodeGenTypeCache {
   /// variable declaration D.
   void setTLSMode(llvm::GlobalValue *GV, const VarDecl ) const;
 
+  /// Get LLVM TLS mode from CodeGenOptions.
+  llvm::GlobalVariable::ThreadLocalMode GetDefaultLLVMTLSModel() const;
+
   static llvm::GlobalValue::VisibilityTypes GetLLVMVisibility(Visibility V) {
 switch (V) {
 case DefaultVisibility:   return llvm::GlobalValue::DefaultVisibility;

diff  --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index a4f2780c..f79de5db2d39 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2687,6 +2687,7 @@ void ItaniumCXXABI::EmitThreadLocalInitFuncs(
 llvm::GlobalVariable::InternalLinkage,
 llvm::ConstantInt::get(CGM.Int8Ty, 0), "__tls_guard");
 Guard->setThreadLocal(true);
+Guard->setThreadLocalMode(CGM.GetDefaultLLVMTLSModel());
 
 CharUnits GuardAlign = CharUnits::One();
 Guard->setAlignment(GuardAlign.getAsAlign());

diff  --git a/clang/lib/CodeGen/MicrosoftCXXABI.cpp 
b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
index a9d87f135b65..6f6295a17158 100644
--- a/clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -2523,7 +2523,7 @@ void MicrosoftCXXABI::EmitGuardedInit(CodeGenFunction 
, const VarDecl ,
   GuardVar->setComdat(
   CGM.getModule().getOrInsertComdat(GuardVar->getName()));
 if (D.getTLSKind())
-  GuardVar->setThreadLocal(true);
+  CGM.setTLSMode(GuardVar, D);
 if (GI && !HasPerVariableGuard)
   GI->Guard = GuardVar;
   }

diff  --git a/clang/test/CodeGen/tls-model.c b/clang/test/CodeGen/tls-model.cpp
similarity index 57%
rename from clang/test/CodeGen/tls-model.c
rename to clang/test/CodeGen/tls-model.cpp
index 313c3b1dfd41..872566fcf0be 100644
--- a/clang/test/CodeGen/tls-model.c
+++ b/clang/test/CodeGen/tls-model.cpp
@@ -16,29 +16,52 @@ int f() {
 }
 int __thread __attribute__((tls_model("initial-exec"))) z;
 
+struct S {
+  S();
+  ~S();
+};
+struct T {
+  ~T();
+};
+
+struct S thread_local s1;
+struct T thread_local t1;
+
 // Note that unlike normal C uninitialized global variables,
 // uninitialized TLS variables do NOT have COMMON linkage.
 
 // CHECK-GD: @z1 = global i32 0
-// CHECK-GD: @f.y = internal thread_local global i32 0
 // CHECK-GD: @z2 = global i32 0
 // CHECK-GD: @x = thread_local global i32 0
+// CHECK-GD: @_ZZ1fvE1y = internal thread_local global i32 0
 // CHECK-GD: @z = thread_local(initialexec) global i32 0
+// CHECK-GD: @s1 = thread_local global %struct.S zeroinitializer
+// CHECK-GD: @t1 = thread_local global %struct.T zeroinitializer
+// CHECK-GD: @__tls_guard = internal thread_local global i8 0
 
 // CHECK-LD: @z1 = global i32 0

[PATCH] D81966: [clang][module] Improve -Wincomplete-umbrella

2020-06-16 Thread Zixu Wang via Phabricator via cfe-commits
zixuw abandoned this revision.
zixuw added a comment.

Abandoning this revision because the upstream for this work is not correctly 
tracking the llvm.org branch.
The method `setGenModuleActionWrapper` is available in `apple/master` but not 
in llvm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81966



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


[PATCH] D74166: [AIX][Frontend] Static init implementation for AIX considering no priority

2020-06-16 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:4489
+  // DestructCallBlock, otherwise jump to EndBlock directly.
+  CGF.EmitCXXGuardedInitBranch(NeedsDestruct, DestructCallBlock, EndBlock,
+   CodeGenFunction::GuardKind::VariableGuard, );

Xiangling_L wrote:
> hubert.reinterpretcast wrote:
> > Please add a test for a static local. Note the `branch_weights`. I do not 
> > believe the `branch_weights` associated with guarded initialization for a 
> > static local (what the called function is meant to deal with) is 
> > necessarily appropriate for a branch associated with finalization-on-unload.
> Thank you for pointing this out. I will adjust the function name to 
> `EmitCXXGuardedInitOrDestructBranch` later to match our usage.
> 
> In terms of `branch_weights`,  this is something I am not familiar with. So 
> please correct me if I am wrong. Some of my superficial thoughts would be are 
> we able to apply `branch_weights` on a branch associated with 
> finalization-on-unload? Should it be set as `nullptr`,  because we would not 
> know how many times we will call `__sterm`(and each sterm finalizer 
> contained)?
> 
> BTW, I will add a testcase for a static local and we can update the 
> `branch_weights` part later along with the reviews.
I don't think we want to generate `branch_weights`. We already expect `__sterm` 
to be called rarely. Just changing the function name is not going to help 
though. A caller would need to indicate which of "init" or "destruct" is 
intended.



Comment at: clang/test/CodeGen/static-init.cpp:8
+// RUN:   FileCheck %s
 
 struct test {

Xiangling_L wrote:
> hubert.reinterpretcast wrote:
> > Xiangling_L wrote:
> > > jasonliu wrote:
> > > > Looks like the non-inline comments are easier to get ignored and 
> > > > missed, so I will copy paste the non-inlined comment I previously had:
> > > > ```
> > > > -fregister_global_dtors_with_atexit does not seem to work properly in 
> > > > current implementation.
> > > > We should consider somehow disabling/report_fatal_error it instead of 
> > > > letting it generate invalid code on AIX.
> > > > ```
> > > Thanks for doing so!
> > > 
> > > The semantic of `global_dtors` here on AIX is `__sterm` function, which 
> > > we are never gonna register with `__atexit`. I am thinking we can disable 
> > > it in a follow-up driver patch with the handling of `-fno-use-cxa-atexit`.
> > The semantic of `global_dtors` is not limited to the `__sterm` functions 
> > associated with C++ cleanup actions. With respect to user-declared 
> > `__attribute__((__destructor__))` functions, the option could improve the 
> > interleaving of those cleanup actions with cleanup actions registered by 
> > user-declared `__attribute__((__constructor__))` functions.
> > 
> > This provides that rationale for separating the `__sterm` functions 
> > associated with the C++ cleanup actions from the other "destructor" 
> > functions.
> Yeah, I agree that the semantic of `global_dtors` should contain both 
> `__sterm` and `__attribute__((__destructor__))` dtors. And we do need some 
> rationale to separate `__sterm` and those other `destructor` functions out 
> for AIX.
> 
> However, I doubt the `-fregister_global_dtors_with_atexit` option is 
> something we should use. Cuz dtors with `__attribute__((__destructor__))` 
> actually are equivalent to `__dtor` functions in AIX's semantic which need to 
> be registered with `__atexit`. However, we shouldn't register `__sterm` with 
> `__atexit`. So it seems this option does not work well for AIX either we set 
> it to true or false, and we need to figure something else out when we start 
> supporting `__attribute__((__destructor__))` and 
> `__attribute__((__constructor__))`?
Yes, we should look further into this when `__attribute__((__destructor__))` is 
supported.

The difference between `atexit`-registered functions and `__sterm` functions is 
in whether or not they are run when unloading a module (which termination also 
does).

Thanks for your observation re: the similarity between 
`__attribute__((__destructor__))` functions and the `__dtor` functions. 
Thinking about it a bit, the level of similarity is rather tied to the option 
in question. If we choose to register using `atexit`, we need to consider 
introducing the corresponding `unatexit`. This means that even when the option 
in question is active, we will produce entries into the `global_dtors` array at 
the IR level.



Comment at: clang/test/CodeGen/static-init.cpp:31
+// CHECK: @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] 
[{ i32, void ()*, i8* } { i32 65535, void ()* 
@__sinit8000_clang_510e898aa8d263cac999dd03eeed5b51, i8* null }]
+// CHECK: @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] 
[{ i32, void ()*, i8* } { i32 65535, void ()* 

[PATCH] D81868: [libTooling] Add parser for string representation of `RangeSelector`.

2020-06-16 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 271246.
ymandel added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81868

Files:
  clang/include/clang/Tooling/Transformer/Parsing.h
  clang/lib/Tooling/Transformer/CMakeLists.txt
  clang/lib/Tooling/Transformer/Parsing.cpp
  clang/unittests/Tooling/RangeSelectorTest.cpp

Index: clang/unittests/Tooling/RangeSelectorTest.cpp
===
--- clang/unittests/Tooling/RangeSelectorTest.cpp
+++ clang/unittests/Tooling/RangeSelectorTest.cpp
@@ -10,6 +10,7 @@
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Frontend/ASTUnit.h"
 #include "clang/Tooling/Tooling.h"
+#include "clang/Tooling/Transformer/Parsing.h"
 #include "clang/Tooling/Transformer/SourceCode.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Error.h"
@@ -132,13 +133,36 @@
 int f(int x, int y, int z) { return 3; }
 int g() { return f(/* comment */ 3, 7 /* comment */, 9); }
   )cc";
-  const char *Call = "call";
-  TestMatch Match = matchCode(Code, callExpr().bind(Call));
-  const auto* E = Match.Result.Nodes.getNodeAs(Call);
+  StringRef CallID = "call";
+  ast_matchers::internal::Matcher M = callExpr().bind(CallID);
+  RangeSelector R = before(node(CallID.str()));
+
+  TestMatch Match = matchCode(Code, M);
+  const auto *E = Match.Result.Nodes.getNodeAs(CallID);
   assert(E != nullptr);
   auto ExprBegin = E->getSourceRange().getBegin();
   EXPECT_THAT_EXPECTED(
-  before(node(Call))(Match.Result),
+  R(Match.Result),
+  HasValue(EqualsCharSourceRange(
+  CharSourceRange::getCharRange(ExprBegin, ExprBegin;
+}
+
+TEST(RangeSelectorTest, BeforeOpParsed) {
+  StringRef Code = R"cc(
+int f(int x, int y, int z) { return 3; }
+int g() { return f(/* comment */ 3, 7 /* comment */, 9); }
+  )cc";
+  StringRef CallID = "call";
+  ast_matchers::internal::Matcher M = callExpr().bind(CallID);
+  auto R = parseRangeSelector(R"rs(before(node("call")))rs");
+  ASSERT_THAT_EXPECTED(R, llvm::Succeeded());
+
+  TestMatch Match = matchCode(Code, M);
+  const auto *E = Match.Result.Nodes.getNodeAs(CallID);
+  assert(E != nullptr);
+  auto ExprBegin = E->getSourceRange().getBegin();
+  EXPECT_THAT_EXPECTED(
+  (*R)(Match.Result),
   HasValue(EqualsCharSourceRange(
   CharSourceRange::getCharRange(ExprBegin, ExprBegin;
 }
@@ -169,45 +193,82 @@
HasValue(EqualsCharSourceRange(ExpectedAfter)));
 }
 
-TEST(RangeSelectorTest, RangeOp) {
+// Node-id specific version.
+TEST(RangeSelectorTest, RangeOpNodes) {
   StringRef Code = R"cc(
 int f(int x, int y, int z) { return 3; }
 int g() { return f(/* comment */ 3, 7 /* comment */, 9); }
   )cc";
-  const char *Arg0 = "a0";
-  const char *Arg1 = "a1";
-  StringRef Call = "call";
-  auto Matcher = callExpr(hasArgument(0, expr().bind(Arg0)),
-  hasArgument(1, expr().bind(Arg1)))
- .bind(Call);
+  auto Matcher = callExpr(hasArgument(0, expr().bind("a0")),
+  hasArgument(1, expr().bind("a1")));
+  RangeSelector R = range("a0", "a1");
+  TestMatch Match = matchCode(Code, Matcher);
+  EXPECT_THAT_EXPECTED(select(R, Match), HasValue("3, 7"));
+}
+
+TEST(RangeSelectorTest, RangeOpGeneral) {
+  StringRef Code = R"cc(
+int f(int x, int y, int z) { return 3; }
+int g() { return f(/* comment */ 3, 7 /* comment */, 9); }
+  )cc";
+  auto Matcher = callExpr(hasArgument(0, expr().bind("a0")),
+  hasArgument(1, expr().bind("a1")));
+  RangeSelector R = range(node("a0"), node("a1"));
   TestMatch Match = matchCode(Code, Matcher);
+  EXPECT_THAT_EXPECTED(select(R, Match), HasValue("3, 7"));
+}
 
-  // Node-id specific version:
-  EXPECT_THAT_EXPECTED(select(range(Arg0, Arg1), Match), HasValue("3, 7"));
-  // General version:
-  EXPECT_THAT_EXPECTED(select(range(node(Arg0), node(Arg1)), Match),
-   HasValue("3, 7"));
+TEST(RangeSelectorTest, RangeOpNodesParsed) {
+  StringRef Code = R"cc(
+int f(int x, int y, int z) { return 3; }
+int g() { return f(/* comment */ 3, 7 /* comment */, 9); }
+  )cc";
+  auto Matcher = callExpr(hasArgument(0, expr().bind("a0")),
+  hasArgument(1, expr().bind("a1")));
+  auto R = parseRangeSelector(R"rs(encloseNodes("a0", "a1"))rs");
+  ASSERT_THAT_EXPECTED(R, llvm::Succeeded());
+  TestMatch Match = matchCode(Code, Matcher);
+  EXPECT_THAT_EXPECTED(select(*R, Match), HasValue("3, 7"));
+}
+
+TEST(RangeSelectorTest, RangeOpGeneralParsed) {
+  StringRef Code = R"cc(
+int f(int x, int y, int z) { return 3; }
+int g() { return f(/* comment */ 3, 7 /* comment */, 9); }
+  )cc";
+  auto Matcher = callExpr(hasArgument(0, expr().bind("a0")),
+  hasArgument(1, expr().bind("a1")));
+  auto R = 

[PATCH] D81868: [libTooling] Add parser for string representation of `RangeSelector`.

2020-06-16 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel marked 6 inline comments as done.
ymandel added a comment.

Thanks for the review!




Comment at: clang/lib/Tooling/Transformer/Parsing.cpp:29
+
+namespace {
+using llvm::Error;

gribozavr2 wrote:
> I'm a bit concerned about the abundance of parsers in Clang tooling: we 
> already have a similar language for dynamic AST matchers. I'm concerned about 
> both code duplication as such, and that there are multiple ways to do 
> something.
> 
> Code duplication makes it more difficult to carry out horizontal efforts like 
> improving error reporting.
> 
> Multiple ways to do something makes codebase knowledge less reusable. It 
> might also create language discrepancies that users might notice (for 
> example, I don't remember if `bind(id)` works in dynamic AST matchers or not; 
> we would be better off if range selectors were consistent with that).
> 
> I don't think this particular change decisively tips the scale towards 
> refactoring the parser for dynamic AST matchers to be reusable here; however 
> it is an option worth considering. I think we should be thinking about the 
> total cost of ownership of this code.
> 
> Some future use cases will also need an embeddable language (like AST 
> matchers for the syntax tree, or parsing stencils from strings).
Agreed on these points. We'd like to move ahead with this patch, but have made 
the following changes:
1. Added a FIXME in the implementation file indicating intent to merge with AST 
matcher parser code
2. Modified the accepted language for consistency with AST matchers (and C++ 
code). Node ids must be surrounded by quotes.

One possible complication is that the stencil format-string parser 
(forthcoming) will not easily be merged into a lexer-based parser, given that 
it allows free text for the format string (only the special escape sequences 
have specified structure). So, we will need to find a way to operate both 
scannerless and not if we want a unified parser infrastructure. However, we can 
solve that problem when we come to it.



Comment at: clang/unittests/Tooling/RangeSelectorTest.cpp:271
+  ASSERT_THAT_EXPECTED(R, llvm::Succeeded());
+  EXPECT_THAT_EXPECTED(select(*R, Match), HasValue("3;"));
 }

gribozavr2 wrote:
> I wonder if we could figure out a more direct testing strategy for a parser 
> (that does not necessarily involve using the parsed objects) if we had more 
> advanced parsing infrastructure.
Indeed. That would certainly be preferable. `Stencil`s support the `toString` 
operator for just such testing support.  A generic parse tree would also allow 
direct testing, but then you still need to find a way to test the conversion 
from parse-tree to stencil. So, ultimately, you want to have some reflection on 
the type itself.

I propose that we move `RangeSelector` to implement `MatchComputation` rather 
than `MatchConsumer` to support `toString` and better tests. WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81868



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


[PATCH] D81970: [Clang][Driver] Remove gold linker support for PS4 toolchain

2020-06-16 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 271237.
ychen added a comment.

- clang-format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81970

Files:
  clang/lib/Driver/ToolChains/PS4CPU.cpp
  clang/test/Driver/ps4-linker-non-win.c
  clang/test/Driver/ps4-linker-win.c

Index: clang/test/Driver/ps4-linker-win.c
===
--- clang/test/Driver/ps4-linker-win.c
+++ clang/test/Driver/ps4-linker-win.c
@@ -1,27 +1,19 @@
-// The full path to the gold linker was not found on Windows because the
-// driver fails to add an .exe extension to the name.
-// We check that gold linker's full name (with an extension) is specified
-// on the command line if -fuse-ld=gold, or -shared with no -fuse-ld option
-// are passed. Otherwise, we check that the PS4's linker's full name is
-// specified.
+// This test check that orbis-ld is used for linker all the time. Specifying
+// linker using -fuse-ld causes a error message emitted and compilation fail.
 
 // REQUIRES: system-windows, x86-registered-target
 
 // RUN: mkdir -p %t
 // RUN: touch %t/orbis-ld.exe
-// RUN: touch %t/orbis-ld.gold.exe
-
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -fuse-ld=gold -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
 
 // RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -fuse-ld=ps4 -### 2>&1 \
+// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared \
-// RUN: -fuse-ld=ps4 -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER %s
 
-// CHECK-PS4-GOLD: \\orbis-ld.gold
 // CHECK-PS4-LINKER: \\orbis-ld
+
+// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4 %s -fuse-ld=gold -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=ERROR %s
+
+// ERROR: error: unsupported option '-fuse-ld' for target 'x86_64-scei-ps4'
Index: clang/test/Driver/ps4-linker-non-win.c
===
--- clang/test/Driver/ps4-linker-non-win.c
+++ clang/test/Driver/ps4-linker-non-win.c
@@ -6,16 +6,14 @@
 // RUN: touch %t/orbis-ld
 // RUN: chmod +x %t/orbis-ld
 
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -fuse-ld=gold 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-
 // RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -fuse-ld=ps4 2>&1 \
+// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared \
-// RUN: -fuse-ld=ps4 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER %s
 
 // CHECK-PS4-LINKER: /orbis-ld
+
+// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4 %s -fuse-ld=gold 2>&1 \
+// RUN:   | FileCheck --check-prefix=ERROR %s
+
+// ERROR: error: unsupported option '-fuse-ld' for target 'x86_64-scei-ps4'
Index: clang/lib/Driver/ToolChains/PS4CPU.cpp
===
--- clang/lib/Driver/ToolChains/PS4CPU.cpp
+++ clang/lib/Driver/ToolChains/PS4CPU.cpp
@@ -88,13 +88,13 @@
 CmdArgs.push_back("--dependent-lib=libSceDbgAddressSanitizer_stub_weak.a");
 }
 
-static void ConstructPS4LinkJob(const Tool , Compilation ,
-const JobAction , const InputInfo ,
-const InputInfoList ,
-const ArgList ,
-const char *LinkingOutput) {
+void tools::PS4cpu::Link::ConstructJob(Compilation , const JobAction ,
+   const InputInfo ,
+   const InputInfoList ,
+   const ArgList ,
+   const char *LinkingOutput) const {
   const toolchains::FreeBSD  =
-  static_cast(T.getToolChain());
+  static_cast(getToolChain());
   const Driver  = ToolChain.getDriver();
   ArgStringList CmdArgs;
 
@@ -143,216 +143,17 @@
 CmdArgs.push_back("-lpthread");
   }
 
-  const char *Exec = Args.MakeArgString(ToolChain.GetProgramPath("orbis-ld"));
-
-  C.addCommand(std::make_unique(JA, T, Exec, CmdArgs, 

[PATCH] D81959: [HIP] Enable -amdgpu-internalize-symbols

2020-06-16 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec accepted this revision.
rampitec added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


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

https://reviews.llvm.org/D81959



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


[PATCH] D80301: [yaml][clang-tidy] Fix new line YAML serialization

2020-06-16 Thread Dmitry Polukhin via Phabricator via cfe-commits
DmitryPolukhin updated this revision to Diff 271232.
DmitryPolukhin added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80301

Files:
  clang/include/clang/Tooling/ReplacementsYaml.h
  llvm/lib/Support/YAMLTraits.cpp
  llvm/unittests/Support/YAMLIOTest.cpp

Index: llvm/unittests/Support/YAMLIOTest.cpp
===
--- llvm/unittests/Support/YAMLIOTest.cpp
+++ llvm/unittests/Support/YAMLIOTest.cpp
@@ -274,8 +274,8 @@
 
 TEST(YAMLIO, MultilineStrings) {
   WithStringField Original;
-  Original.str1 = "a multiline string\nfoobarbaz";
-  Original.str2 = "another one\rfoobarbaz";
+  Original.str1 = "a\n\nmultiline\nstring\nfoobarbaz ";
+  Original.str2 = "another one\rfoobarbaz\n";
   Original.str3 = "a one-line string";
 
   std::string Serialized;
@@ -285,10 +285,10 @@
 YOut << Original;
   }
   auto Expected = "---\n"
-  "str1:'a multiline string\n"
-  "foobarbaz'\n"
+  "str1:'a\n\n\n\nmultiline\n\nstring\n\n"
+  "foobarbaz '\n"
   "str2:'another one\r"
-  "foobarbaz'\n"
+  "foobarbaz\n\n'\n"
   "str3:a one-line string\n"
   "...\n";
   ASSERT_EQ(Serialized, Expected);
@@ -305,6 +305,25 @@
   EXPECT_EQ(Original.str1, Deserialized.str1);
   EXPECT_EQ(Original.str2, Deserialized.str2);
   EXPECT_EQ(Original.str3, Deserialized.str3);
+
+  // Check deserialization of single '\n' that should be converted to space.
+  Serialized = "---\n"
+   "str1:'a\n\n\n\nmultiline\n\nstring\n\n"
+   "foobarbaz\n'\n"
+   "str2:'another\none\r"
+   "foobarbaz\n\n'\n"
+   "str3:a one-line string\n"
+   "...\n";
+  {
+Input YIn(Serialized);
+YIn >> Deserialized;
+ASSERT_FALSE(YIn.error())
+<< "Parsing error occurred during deserialization. Serialized string:\n"
+<< Serialized;
+  }
+  EXPECT_EQ(Original.str1, Deserialized.str1);
+  EXPECT_EQ(Original.str2, Deserialized.str2);
+  EXPECT_EQ(Original.str3, Deserialized.str3);
 }
 
 TEST(YAMLIO, NoQuotesForTab) {
Index: llvm/lib/Support/YAMLTraits.cpp
===
--- llvm/lib/Support/YAMLTraits.cpp
+++ llvm/lib/Support/YAMLTraits.cpp
@@ -878,13 +878,38 @@
 }
 
 void ScalarTraits::output(const std::string , void *,
- raw_ostream ) {
-  Out << Val;
+   raw_ostream ) {
+  SmallVector Lines;
+  StringRef(Val).split(Lines, '\n');
+  bool First = true;
+  for (StringRef Line : Lines) {
+if (First)
+  First = false;
+else
+  Out << "\n\n";
+Out << Line;
+  }
 }
 
 StringRef ScalarTraits::input(StringRef Scalar, void *,
- std::string ) {
-  Val = Scalar.str();
+   std::string ) {
+  Val.clear();
+  SmallVector Lines;
+  Scalar.split(Lines, '\n');
+  size_t C = Lines.size();
+  for (size_t I = 0; I < C; ++I) {
+Val += Lines[I];
+// Next empty line means that it was '\n\n' that should convert to '\n'.
+// +2 here because we need separator only if more elements will be added.
+if (I + 2 < C && Lines[I + 1].empty()) {
+  Val += '\n';
+  ++I;
+} else if ((I + 1 < C && !Lines[I + 1].empty()) ||
+   (I + 2 == C && Lines[I + 1].empty())) {
+  // Single '\n' should be converted to space ' '.
+  Val += ' ';
+}
+  }
   return StringRef();
 }
 
Index: clang/include/clang/Tooling/ReplacementsYaml.h
===
--- clang/include/clang/Tooling/ReplacementsYaml.h
+++ clang/include/clang/Tooling/ReplacementsYaml.h
@@ -35,13 +35,7 @@
 
 NormalizedReplacement(const IO &, const clang::tooling::Replacement )
 : FilePath(R.getFilePath()), Offset(R.getOffset()),
-  Length(R.getLength()), ReplacementText(R.getReplacementText()) {
-  size_t lineBreakPos = ReplacementText.find('\n');
-  while (lineBreakPos != std::string::npos) {
-ReplacementText.replace(lineBreakPos, 1, "\n\n");
-lineBreakPos = ReplacementText.find('\n', lineBreakPos + 2);
-  }
-}
+  Length(R.getLength()), ReplacementText(R.getReplacementText()) {}
 
 clang::tooling::Replacement denormalize(const IO &) {
   return clang::tooling::Replacement(FilePath, Offset, Length,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80342: [SVE] Deprecate default false variant of VectorType::get

2020-06-16 Thread Christopher Tetreault via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGeb81c85afdcd: [SVE] Deprecate default false variant of 
VectorType::get (authored by ctetreau).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80342

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/unittests/Analysis/VectorUtilsTest.cpp
  llvm/unittests/CodeGen/LowLevelTypeTest.cpp
  llvm/unittests/FuzzMutate/OperationsTest.cpp
  llvm/unittests/IR/ConstantsTest.cpp
  llvm/unittests/IR/IRBuilderTest.cpp
  llvm/unittests/IR/InstructionsTest.cpp
  llvm/unittests/IR/PatternMatch.cpp
  llvm/unittests/IR/VectorTypesTest.cpp

Index: llvm/unittests/IR/VectorTypesTest.cpp
===
--- llvm/unittests/IR/VectorTypesTest.cpp
+++ llvm/unittests/IR/VectorTypesTest.cpp
@@ -43,15 +43,12 @@
   EXPECT_EQ(V16Int8Ty->getNumElements(), 16U);
   EXPECT_EQ(V16Int8Ty->getElementType()->getScalarSizeInBits(), 8U);
 
-  auto *V8Int32Ty = dyn_cast(VectorType::get(Int32Ty, 8));
+  auto *V8Int32Ty =
+  dyn_cast(VectorType::get(Int32Ty, 8, false));
   ASSERT_NE(nullptr, V8Int32Ty);
   EXPECT_EQ(V8Int32Ty->getNumElements(), 8U);
   EXPECT_EQ(V8Int32Ty->getElementType()->getScalarSizeInBits(), 32U);
 
-  auto *V8Int32TyExplicitFalse =
-  dyn_cast(VectorType::get(Int32Ty, 8, false));
-  EXPECT_VTY_EQ(V8Int32Ty, V8Int32TyExplicitFalse);
-
   auto *V8Int8Ty =
   dyn_cast(VectorType::get(Int8Ty, V8Int32Ty));
   EXPECT_VTY_NE(V8Int32Ty, V8Int8Ty);
Index: llvm/unittests/IR/PatternMatch.cpp
===
--- llvm/unittests/IR/PatternMatch.cpp
+++ llvm/unittests/IR/PatternMatch.cpp
@@ -928,9 +928,9 @@
   //
   //   SP1 = VectorSplat(2, i8 2)
   //   SP2 = VectorSplat(2, i8 %Val)
-  Type *VecTy = VectorType::get(IRB.getInt8Ty(), 2);
+  Type *VecTy = FixedVectorType::get(IRB.getInt8Ty(), 2);
   Type *i32 = IRB.getInt32Ty();
-  Type *i32VecTy = VectorType::get(i32, 2);
+  Type *i32VecTy = FixedVectorType::get(i32, 2);
 
   Value *Val = IRB.CreateAdd(IRB.getInt8(0), IRB.getInt8(1));
   Value *Val2 = IRB.CreateAdd(Val, IRB.getInt8(3));
@@ -1021,7 +1021,7 @@
 
 TEST_F(PatternMatchTest, VectorUndefInt) {
   Type *ScalarTy = IRB.getInt8Ty();
-  Type *VectorTy = VectorType::get(ScalarTy, 4);
+  Type *VectorTy = FixedVectorType::get(ScalarTy, 4);
   Constant *ScalarUndef = UndefValue::get(ScalarTy);
   Constant *VectorUndef = UndefValue::get(VectorTy);
   Constant *ScalarZero = Constant::getNullValue(ScalarTy);
@@ -1086,7 +1086,7 @@
 
 TEST_F(PatternMatchTest, VectorUndefFloat) {
   Type *ScalarTy = IRB.getFloatTy();
-  Type *VectorTy = VectorType::get(ScalarTy, 4);
+  Type *VectorTy = FixedVectorType::get(ScalarTy, 4);
   Constant *ScalarUndef = UndefValue::get(ScalarTy);
   Constant *VectorUndef = UndefValue::get(VectorTy);
   Constant *ScalarZero = Constant::getNullValue(ScalarTy);
Index: llvm/unittests/IR/InstructionsTest.cpp
===
--- llvm/unittests/IR/InstructionsTest.cpp
+++ llvm/unittests/IR/InstructionsTest.cpp
@@ -186,18 +186,18 @@
   Type *Int16Ty = Type::getInt16Ty(C);
   Type *Int32Ty = Type::getInt32Ty(C);
   Type *Int64Ty = Type::getInt64Ty(C);
-  Type *V8x8Ty = VectorType::get(Int8Ty, 8);
-  Type *V8x64Ty = VectorType::get(Int64Ty, 8);
+  Type *V8x8Ty = FixedVectorType::get(Int8Ty, 8);
+  Type *V8x64Ty = FixedVectorType::get(Int64Ty, 8);
   Type *X86MMXTy = Type::getX86_MMXTy(C);
 
   Type *HalfTy = Type::getHalfTy(C);
   Type *FloatTy = Type::getFloatTy(C);
   Type *DoubleTy = Type::getDoubleTy(C);
 
-  Type *V2Int32Ty = VectorType::get(Int32Ty, 2);
-  Type *V2Int64Ty = VectorType::get(Int64Ty, 2);
-  Type *V4Int16Ty = VectorType::get(Int16Ty, 4);
-  Type *V1Int16Ty = VectorType::get(Int16Ty, 1);
+  Type *V2Int32Ty = FixedVectorType::get(Int32Ty, 2);
+  Type *V2Int64Ty = FixedVectorType::get(Int64Ty, 2);
+  Type *V4Int16Ty = FixedVectorType::get(Int16Ty, 4);
+  Type *V1Int16Ty = FixedVectorType::get(Int16Ty, 1);
 
   Type *VScaleV2Int32Ty = VectorType::get(Int32Ty, 2, true);
   Type *VScaleV2Int64Ty = VectorType::get(Int64Ty, 2, true);
@@ -210,16 +210,16 @@
   Type *Int32PtrAS1Ty = PointerType::get(Int32Ty, 1);
   Type *Int64PtrAS1Ty = PointerType::get(Int64Ty, 1);
 
-  Type *V2Int32PtrAS1Ty = VectorType::get(Int32PtrAS1Ty, 2);
-  Type *V2Int64PtrAS1Ty = VectorType::get(Int64PtrAS1Ty, 2);
-  Type *V4Int32PtrAS1Ty = VectorType::get(Int32PtrAS1Ty, 4);
+  Type *V2Int32PtrAS1Ty = FixedVectorType::get(Int32PtrAS1Ty, 2);
+  Type *V2Int64PtrAS1Ty = FixedVectorType::get(Int64PtrAS1Ty, 2);
+  Type *V4Int32PtrAS1Ty = FixedVectorType::get(Int32PtrAS1Ty, 4);
   Type *VScaleV4Int32PtrAS1Ty = VectorType::get(Int32PtrAS1Ty, 4, true);
-  Type *V4Int64PtrAS1Ty = VectorType::get(Int64PtrAS1Ty, 4);
+  Type *V4Int64PtrAS1Ty = FixedVectorType::get(Int64PtrAS1Ty, 

[PATCH] D81972: [NFC] Cleanup of EmitCXXGlobalInitFunc() and EmitCXXGlobalDtorFunc()

2020-06-16 Thread Jason Liu via Phabricator via cfe-commits
jasonliu added inline comments.



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:596
   }
 
+  // Include the filename in the symbol name. Including "sub_" matches gcc

I think this patch is missing what @hubert.reinterpretcast mentioned in 
https://reviews.llvm.org/D74166?id=269900#inline-751064
which is an early return like this:

```
 if (CXXGlobalInits.empty())
return;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81972



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


[PATCH] D81975: [clangd] Add command line option for ClangTidyConfig

2020-06-16 Thread Nathan James via Phabricator via cfe-commits
njames93 created this revision.
njames93 added reviewers: sammccall, kadircet, hokein.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Adds a command line flag `clang-tidy-config` for specifing configuration of 
checks, in much the same way that clang-tidy does.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81975

Files:
  clang-tools-extra/clangd/test/clang-tidy-config.test
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -149,6 +149,15 @@
 init(""),
 };
 
+opt ClangTidyConfig{
+"clang-tidy-config",
+cat(Features),
+desc("Specifies a YAML/JSON configuration for when running clang-tidy "
+ "checks (this will override clang-tidy files). Only meaningful when "
+ "-clang-tidy flag is on"),
+init(""),
+};
+
 opt CodeCompletionParse{
 "completion-parse",
 cat(Features),
@@ -714,10 +723,23 @@
 tidy::ClangTidyOptions OverrideClangTidyOptions;
 if (!ClangTidyChecks.empty())
   OverrideClangTidyOptions.Checks = ClangTidyChecks;
-ClangTidyOptProvider = std::make_unique(
-tidy::ClangTidyGlobalOptions(),
-/* Default */ EmptyDefaults,
-/* Override */ OverrideClangTidyOptions, FSProvider.getFileSystem());
+if (ClangTidyConfig.empty()) {
+  ClangTidyOptProvider = std::make_unique(
+  tidy::ClangTidyGlobalOptions(),
+  /* Default */ EmptyDefaults,
+  /* Override */ OverrideClangTidyOptions, FSProvider.getFileSystem());
+} else {
+  llvm::ErrorOr ParsedConfig =
+  tidy::parseConfiguration(ClangTidyConfig);
+  if (!ParsedConfig) {
+elog("Invalid -clang-tidy-config: {0}",
+ ParsedConfig.getError().message());
+return 1;
+  }
+  ClangTidyOptProvider = std::make_unique(
+  tidy::ClangTidyGlobalOptions(), EmptyDefaults, *ParsedConfig,
+  OverrideClangTidyOptions);
+}
 Opts.GetClangTidyOptions = [&](llvm::vfs::FileSystem &,
llvm::StringRef File) {
   // This function must be thread-safe and tidy option providers are not.
Index: clang-tools-extra/clangd/test/clang-tidy-config.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/clang-tidy-config.test
@@ -0,0 +1,40 @@
+# RUN: clangd -lit-test -clang-tidy-config="{CheckOptions: [{key: 
readability-identifier-naming.FunctionCase, value: camelBack}], Checks: 
'-*,readability-identifier-naming' }" < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///foo.c","languageId":"c","text":"void
 BadName();"}}}
+#  CHECK:  "method": "textDocument/publishDiagnostics",
+# CHECK-NEXT:  "params": {
+# CHECK-NEXT:"diagnostics": [
+# CHECK-NEXT:  {
+# CHECK-NEXT:"code": "readability-identifier-naming",
+# CHECK-NEXT:"message": "Invalid case style for function 'BadName' 
(fix available)",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 12,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 5,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"severity": 2,
+# CHECK-NEXT:"source": "clang-tidy"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"uri": "file://{{.*}}/foo.c",
+# CHECK-NEXT:"version": 0
+# CHECK-NEXT:  }
+---
+{"jsonrpc":"2.0","id":2,"method":"sync","params":null}
+---
+{"jsonrpc":"2.0","method":"textDocument/didClose","params":{"textDocument":{"uri":"test:///foo.c"}}}
+#  CHECK:  "method": "textDocument/publishDiagnostics",
+# CHECK-NEXT:  "params": {
+# CHECK-NEXT:"diagnostics": [],
+# CHECK-NEXT:"uri": "file://{{.*}}/foo.c"
+# CHECK-NEXT:  }
+---
+{"jsonrpc":"2.0","id":5,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -149,6 +149,15 @@
 init(""),
 };
 
+opt ClangTidyConfig{
+"clang-tidy-config",
+cat(Features),
+desc("Specifies a YAML/JSON configuration for when running clang-tidy "
+ "checks (this will override clang-tidy files). Only meaningful when "
+ "-clang-tidy flag is on"),
+init(""),
+};
+
 opt CodeCompletionParse{
 

[PATCH] D80944: Add begin source location for the attributed statement created from PragmaLoopHint decorated loop

2020-06-16 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added a comment.

In D80944#2095564 , @erichkeane wrote:

> Note that this causes a regression (reported here) 
> https://bugs.llvm.org/show_bug.cgi?id=46336
>
> The assert added here breaks in the case where a pragma loop attribute is 
> combined with a C++ attribute.


Resolved with
4676cf444ea2678660ee48279be99efde4bf60e9 

8c6c606cdc72c3ddd55f382d91ef1afc3cb9f2a8 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80944



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


[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

2020-06-16 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen updated this revision to Diff 271221.
cchen added a comment.

Fix based on feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/target_update_ast_print.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp

Index: clang/test/OpenMP/target_update_to_messages.cpp
===
--- clang/test/OpenMP/target_update_to_messages.cpp
+++ clang/test/OpenMP/target_update_to_messages.cpp
@@ -79,6 +79,10 @@
 #pragma omp target update to(*(*(this->ptr)+a+this->ptr)) // le45-error {{expected expression containing only member accesses and/or array sections based on named variables}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(*(this+this)) // expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}} expected-error {{invalid operands to binary expression ('S8 *' and 'S8 *')}}
 {}
+
+double marr[10][5][10];
+#pragma omp target update to(marr [0:] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+{}
   }
 };
 
Index: clang/test/OpenMP/target_update_messages.cpp
===
--- clang/test/OpenMP/target_update_messages.cpp
+++ clang/test/OpenMP/target_update_messages.cpp
@@ -1,6 +1,8 @@
-// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le45 -fopenmp -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le50 -fopenmp -fopenmp-version=50 -ferror-limit 100 %s -Wuninitialized
 
-// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le45 -fopenmp-simd -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le50 -fopenmp-simd -fopenmp-version=50 -ferror-limit 100 %s -Wuninitialized
 
 void xxx(int argc) {
   int x; // expected-note {{initialize the variable 'x' to silence this warning}}
@@ -36,5 +38,21 @@
   {
 foo();
   }
+
+  double marr[10][5][10];
+#pragma omp target update to(marr [0:] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+  {}
+#pragma omp target update from(marr [0:] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+
+  int arr[4][3][2][1];
+#pragma omp target update to(arr [0:2] [2:4][:2][1]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+  {}
+#pragma omp target update from(arr [0:2] [2:4][:2][1]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+
+  double ***dptr;
+#pragma omp target update to(dptr [0:2] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le50-error 2 {{section length is unspecified and cannot be inferred because subscripted value is an array of unknown bound}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+  {}
+#pragma omp target update from(dptr [0:2] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le50-error 2 {{section length is unspecified and cannot be inferred because subscripted value is an array of unknown bound}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+
   return tmain(argc, argv);
 }
Index: clang/test/OpenMP/target_update_codegen.cpp
===
--- clang/test/OpenMP/target_update_codegen.cpp
+++ clang/test/OpenMP/target_update_codegen.cpp
@@ -1059,5 +1059,283 @@
   #pragma omp target update from(([sa][5])f)
 }
 
+#endif
+
+///==///
+// RUN: %clang_cc1 -DCK19 -verify -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix CK19 

[PATCH] D81949: [clang-tidy] Extend InheritParentConfig to CommandLineConfig

2020-06-16 Thread Dmitry Polukhin via Phabricator via cfe-commits
DmitryPolukhin accepted this revision.
DmitryPolukhin 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/D81949/new/

https://reviews.llvm.org/D81949



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


[PATCH] D81970: [Clang][Driver] Remove gold linker support for PS4 toolchain

2020-06-16 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 271218.
ychen added a comment.

- update test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81970

Files:
  clang/lib/Driver/ToolChains/PS4CPU.cpp
  clang/test/Driver/ps4-linker-non-win.c
  clang/test/Driver/ps4-linker-win.c

Index: clang/test/Driver/ps4-linker-win.c
===
--- clang/test/Driver/ps4-linker-win.c
+++ clang/test/Driver/ps4-linker-win.c
@@ -1,27 +1,20 @@
-// The full path to the gold linker was not found on Windows because the
-// driver fails to add an .exe extension to the name.
-// We check that gold linker's full name (with an extension) is specified
-// on the command line if -fuse-ld=gold, or -shared with no -fuse-ld option
-// are passed. Otherwise, we check that the PS4's linker's full name is
-// specified.
+// This test check that orbis-ld is used for linker all the time. Specifying
+// linker using -fuse-ld causes a error message emitted and compilation fail.
 
 // REQUIRES: system-windows, x86-registered-target
 
 // RUN: mkdir -p %t
 // RUN: touch %t/orbis-ld.exe
-// RUN: touch %t/orbis-ld.gold.exe
-
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -fuse-ld=gold -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
 
 // RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -fuse-ld=ps4 -### 2>&1 \
+// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared \
-// RUN: -fuse-ld=ps4 -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER %s
 
-// CHECK-PS4-GOLD: \\orbis-ld.gold
 // CHECK-PS4-LINKER: \\orbis-ld
+
+// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4 %s -fuse-ld=gold -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=ERROR %s
+
+// ERROR: error: unsupported option '-fuse-ld' for target 'x86_64-scei-ps4'
+
Index: clang/test/Driver/ps4-linker-non-win.c
===
--- clang/test/Driver/ps4-linker-non-win.c
+++ clang/test/Driver/ps4-linker-non-win.c
@@ -6,16 +6,15 @@
 // RUN: touch %t/orbis-ld
 // RUN: chmod +x %t/orbis-ld
 
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -fuse-ld=gold 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-
 // RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -fuse-ld=ps4 2>&1 \
+// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared \
-// RUN: -fuse-ld=ps4 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER %s
 
 // CHECK-PS4-LINKER: /orbis-ld
+
+// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4 %s -fuse-ld=gold 2>&1 \
+// RUN:   | FileCheck --check-prefix=ERROR %s
+
+// ERROR: error: unsupported option '-fuse-ld' for target 'x86_64-scei-ps4'
+
Index: clang/lib/Driver/ToolChains/PS4CPU.cpp
===
--- clang/lib/Driver/ToolChains/PS4CPU.cpp
+++ clang/lib/Driver/ToolChains/PS4CPU.cpp
@@ -88,13 +88,13 @@
 CmdArgs.push_back("--dependent-lib=libSceDbgAddressSanitizer_stub_weak.a");
 }
 
-static void ConstructPS4LinkJob(const Tool , Compilation ,
-const JobAction , const InputInfo ,
-const InputInfoList ,
-const ArgList ,
-const char *LinkingOutput) {
+void tools::PS4cpu::Link::ConstructJob(Compilation , const JobAction ,
+   const InputInfo ,
+   const InputInfoList ,
+   const ArgList ,
+   const char *LinkingOutput) const {
   const toolchains::FreeBSD  =
-  static_cast(T.getToolChain());
+  static_cast(getToolChain());
   const Driver  = ToolChain.getDriver();
   ArgStringList CmdArgs;
 
@@ -143,216 +143,17 @@
 CmdArgs.push_back("-lpthread");
   }
 
-  const char *Exec = Args.MakeArgString(ToolChain.GetProgramPath("orbis-ld"));
-
-  C.addCommand(std::make_unique(JA, T, Exec, CmdArgs, 

[clang] eb81c85 - [SVE] Deprecate default false variant of VectorType::get

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

Author: Christopher Tetreault
Date: 2020-06-16T15:16:11-07:00
New Revision: eb81c85afdcd3aa6d5e3c1ab73821a659630b799

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

LOG: [SVE] Deprecate default false variant of VectorType::get

Reviewers: efriedma, fpetrogalli, kmclaughlin, huntergr

Reviewed By: fpetrogalli

Subscribers: cfe-commits, tschuett, rkruppe, psnobl, llvm-commits

Tags: #llvm, #clang

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

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
llvm/include/llvm/IR/DerivedTypes.h
llvm/unittests/Analysis/VectorUtilsTest.cpp
llvm/unittests/CodeGen/LowLevelTypeTest.cpp
llvm/unittests/FuzzMutate/OperationsTest.cpp
llvm/unittests/IR/ConstantsTest.cpp
llvm/unittests/IR/IRBuilderTest.cpp
llvm/unittests/IR/InstructionsTest.cpp
llvm/unittests/IR/PatternMatch.cpp
llvm/unittests/IR/VectorTypesTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index c3cfed34eeba..3b3ea5e95705 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -6149,25 +6149,25 @@ Value *CodeGenFunction::EmitCommonNeonBuiltinExpr(
   case NEON::BI__builtin_neon_vbfdot_v:
   case NEON::BI__builtin_neon_vbfdotq_v: {
 llvm::Type *InputTy =
-   llvm::VectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
+llvm::FixedVectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
 llvm::Type *Tys[2] = { Ty, InputTy };
 return EmitNeonCall(CGM.getIntrinsic(Int, Tys), Ops, "vbfdot");
   }
   case NEON::BI__builtin_neon_vbfmmlaq_v: {
 llvm::Type *InputTy =
-   llvm::VectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
+llvm::FixedVectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
 llvm::Type *Tys[2] = { Ty, InputTy };
 return EmitNeonCall(CGM.getIntrinsic(Int, Tys), Ops, "vbfmmla");
   }
   case NEON::BI__builtin_neon_vbfmlalbq_v: {
 llvm::Type *InputTy =
-   llvm::VectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
+llvm::FixedVectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
 llvm::Type *Tys[2] = { Ty, InputTy };
 return EmitNeonCall(CGM.getIntrinsic(Int, Tys), Ops, "vbfmlalb");
   }
   case NEON::BI__builtin_neon_vbfmlaltq_v: {
 llvm::Type *InputTy =
-   llvm::VectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
+llvm::FixedVectorType::get(Int8Ty, Ty->getPrimitiveSizeInBits() / 8);
 llvm::Type *Tys[2] = { Ty, InputTy };
 return EmitNeonCall(CGM.getIntrinsic(Int, Tys), Ops, "vbfmlalt");
   }

diff  --git a/llvm/include/llvm/IR/DerivedTypes.h 
b/llvm/include/llvm/IR/DerivedTypes.h
index 25eb783cf6cd..3618447168be 100644
--- a/llvm/include/llvm/IR/DerivedTypes.h
+++ b/llvm/include/llvm/IR/DerivedTypes.h
@@ -443,8 +443,20 @@ class VectorType : public Type {
 
   /// This static method is the primary way to construct an VectorType.
   static VectorType *get(Type *ElementType, ElementCount EC);
+
+  /// Base class getter that specifically constructs a FixedVectorType. This
+  /// function is deprecated, and will be removed after LLVM 11 ships. Since
+  /// this always returns a FixedVectorType via a base VectorType pointer,
+  /// FixedVectorType::get(Type *, unsigned) is strictly better since no cast 
is
+  /// required to call getNumElements() on the result.
+  LLVM_ATTRIBUTE_DEPRECATED(
+  inline static VectorType *get(Type *ElementType, unsigned NumElements),
+  "The base class version of get with the scalable argument defaulted to "
+  "false is deprecated. Either call VectorType::get(Type *, unsigned, "
+  "bool) and pass false, or call FixedVectorType::get(Type *, unsigned).");
+
   static VectorType *get(Type *ElementType, unsigned NumElements,
- bool Scalable = false) {
+ bool Scalable) {
 return VectorType::get(ElementType, {NumElements, Scalable});
   }
 
@@ -537,6 +549,10 @@ class VectorType : public Type {
   }
 };
 
+inline VectorType *VectorType::get(Type *ElementType, unsigned NumElements) {
+  return VectorType::get(ElementType, NumElements, false);
+}
+
 /// Class to represent fixed width SIMD vectors
 class FixedVectorType : public VectorType {
 protected:

diff  --git a/llvm/unittests/Analysis/VectorUtilsTest.cpp 
b/llvm/unittests/Analysis/VectorUtilsTest.cpp
index cf58fba37382..69e5285e8731 100644
--- a/llvm/unittests/Analysis/VectorUtilsTest.cpp
+++ b/llvm/unittests/Analysis/VectorUtilsTest.cpp
@@ -77,7 +77,7 @@ struct BasicTest : public testing::Test {
 } // namespace
 
 TEST_F(BasicTest, isSplat) {
-  Value *UndefVec = UndefValue::get(VectorType::get(IRB.getInt8Ty(), 4));
+  Value *UndefVec = 

[PATCH] D80342: [SVE] Deprecate default false variant of VectorType::get

2020-06-16 Thread Christopher Tetreault via Phabricator via cfe-commits
ctetreau updated this revision to Diff 271217.
ctetreau added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

catch stragglers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80342

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/unittests/Analysis/VectorUtilsTest.cpp
  llvm/unittests/CodeGen/LowLevelTypeTest.cpp
  llvm/unittests/FuzzMutate/OperationsTest.cpp
  llvm/unittests/IR/ConstantsTest.cpp
  llvm/unittests/IR/IRBuilderTest.cpp
  llvm/unittests/IR/InstructionsTest.cpp
  llvm/unittests/IR/PatternMatch.cpp
  llvm/unittests/IR/VectorTypesTest.cpp

Index: llvm/unittests/IR/VectorTypesTest.cpp
===
--- llvm/unittests/IR/VectorTypesTest.cpp
+++ llvm/unittests/IR/VectorTypesTest.cpp
@@ -43,15 +43,12 @@
   EXPECT_EQ(V16Int8Ty->getNumElements(), 16U);
   EXPECT_EQ(V16Int8Ty->getElementType()->getScalarSizeInBits(), 8U);
 
-  auto *V8Int32Ty = dyn_cast(VectorType::get(Int32Ty, 8));
+  auto *V8Int32Ty =
+  dyn_cast(VectorType::get(Int32Ty, 8, false));
   ASSERT_NE(nullptr, V8Int32Ty);
   EXPECT_EQ(V8Int32Ty->getNumElements(), 8U);
   EXPECT_EQ(V8Int32Ty->getElementType()->getScalarSizeInBits(), 32U);
 
-  auto *V8Int32TyExplicitFalse =
-  dyn_cast(VectorType::get(Int32Ty, 8, false));
-  EXPECT_VTY_EQ(V8Int32Ty, V8Int32TyExplicitFalse);
-
   auto *V8Int8Ty =
   dyn_cast(VectorType::get(Int8Ty, V8Int32Ty));
   EXPECT_VTY_NE(V8Int32Ty, V8Int8Ty);
Index: llvm/unittests/IR/PatternMatch.cpp
===
--- llvm/unittests/IR/PatternMatch.cpp
+++ llvm/unittests/IR/PatternMatch.cpp
@@ -928,9 +928,9 @@
   //
   //   SP1 = VectorSplat(2, i8 2)
   //   SP2 = VectorSplat(2, i8 %Val)
-  Type *VecTy = VectorType::get(IRB.getInt8Ty(), 2);
+  Type *VecTy = FixedVectorType::get(IRB.getInt8Ty(), 2);
   Type *i32 = IRB.getInt32Ty();
-  Type *i32VecTy = VectorType::get(i32, 2);
+  Type *i32VecTy = FixedVectorType::get(i32, 2);
 
   Value *Val = IRB.CreateAdd(IRB.getInt8(0), IRB.getInt8(1));
   Value *Val2 = IRB.CreateAdd(Val, IRB.getInt8(3));
@@ -1021,7 +1021,7 @@
 
 TEST_F(PatternMatchTest, VectorUndefInt) {
   Type *ScalarTy = IRB.getInt8Ty();
-  Type *VectorTy = VectorType::get(ScalarTy, 4);
+  Type *VectorTy = FixedVectorType::get(ScalarTy, 4);
   Constant *ScalarUndef = UndefValue::get(ScalarTy);
   Constant *VectorUndef = UndefValue::get(VectorTy);
   Constant *ScalarZero = Constant::getNullValue(ScalarTy);
@@ -1086,7 +1086,7 @@
 
 TEST_F(PatternMatchTest, VectorUndefFloat) {
   Type *ScalarTy = IRB.getFloatTy();
-  Type *VectorTy = VectorType::get(ScalarTy, 4);
+  Type *VectorTy = FixedVectorType::get(ScalarTy, 4);
   Constant *ScalarUndef = UndefValue::get(ScalarTy);
   Constant *VectorUndef = UndefValue::get(VectorTy);
   Constant *ScalarZero = Constant::getNullValue(ScalarTy);
Index: llvm/unittests/IR/InstructionsTest.cpp
===
--- llvm/unittests/IR/InstructionsTest.cpp
+++ llvm/unittests/IR/InstructionsTest.cpp
@@ -186,18 +186,18 @@
   Type *Int16Ty = Type::getInt16Ty(C);
   Type *Int32Ty = Type::getInt32Ty(C);
   Type *Int64Ty = Type::getInt64Ty(C);
-  Type *V8x8Ty = VectorType::get(Int8Ty, 8);
-  Type *V8x64Ty = VectorType::get(Int64Ty, 8);
+  Type *V8x8Ty = FixedVectorType::get(Int8Ty, 8);
+  Type *V8x64Ty = FixedVectorType::get(Int64Ty, 8);
   Type *X86MMXTy = Type::getX86_MMXTy(C);
 
   Type *HalfTy = Type::getHalfTy(C);
   Type *FloatTy = Type::getFloatTy(C);
   Type *DoubleTy = Type::getDoubleTy(C);
 
-  Type *V2Int32Ty = VectorType::get(Int32Ty, 2);
-  Type *V2Int64Ty = VectorType::get(Int64Ty, 2);
-  Type *V4Int16Ty = VectorType::get(Int16Ty, 4);
-  Type *V1Int16Ty = VectorType::get(Int16Ty, 1);
+  Type *V2Int32Ty = FixedVectorType::get(Int32Ty, 2);
+  Type *V2Int64Ty = FixedVectorType::get(Int64Ty, 2);
+  Type *V4Int16Ty = FixedVectorType::get(Int16Ty, 4);
+  Type *V1Int16Ty = FixedVectorType::get(Int16Ty, 1);
 
   Type *VScaleV2Int32Ty = VectorType::get(Int32Ty, 2, true);
   Type *VScaleV2Int64Ty = VectorType::get(Int64Ty, 2, true);
@@ -210,16 +210,16 @@
   Type *Int32PtrAS1Ty = PointerType::get(Int32Ty, 1);
   Type *Int64PtrAS1Ty = PointerType::get(Int64Ty, 1);
 
-  Type *V2Int32PtrAS1Ty = VectorType::get(Int32PtrAS1Ty, 2);
-  Type *V2Int64PtrAS1Ty = VectorType::get(Int64PtrAS1Ty, 2);
-  Type *V4Int32PtrAS1Ty = VectorType::get(Int32PtrAS1Ty, 4);
+  Type *V2Int32PtrAS1Ty = FixedVectorType::get(Int32PtrAS1Ty, 2);
+  Type *V2Int64PtrAS1Ty = FixedVectorType::get(Int64PtrAS1Ty, 2);
+  Type *V4Int32PtrAS1Ty = FixedVectorType::get(Int32PtrAS1Ty, 4);
   Type *VScaleV4Int32PtrAS1Ty = VectorType::get(Int32PtrAS1Ty, 4, true);
-  Type *V4Int64PtrAS1Ty = VectorType::get(Int64PtrAS1Ty, 4);
+  Type *V4Int64PtrAS1Ty = FixedVectorType::get(Int64PtrAS1Ty, 4);
 
-  Type 

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

2020-06-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:7927
+  CurStrides.push_back(CurStride);
+  DI++;
+}

Use preincrement



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8243
+IsFirstComponentList, L.IsImplicit, CurNonContigInfo,
+/*OverlappedElements=*/llvm::None);
 

No need to add `/*OverlappedElements=*/llvm::None` here, it is default value.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8900-8902
+  if (IsNonContiguous) {
+if (Info.Offsets.empty())
+  return;

Better just to have something like this:
```
if (!IsNonContiguous || Info.Offsets.empty() || Info.NumberOfPtrs == 0)
  return;
...
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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


[PATCH] D81972: [NFC] Cleanup of EmitCXXGlobalInitFunc() and EmitCXXGlobalDtorFunc()

2020-06-16 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L created this revision.
Xiangling_L added reviewers: jasonliu, hubert.reinterpretcast.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
Xiangling_L edited the summary of this revision.

Tidy up some code of `EmitCXXGlobalInitFunc()` and `EmitCXXGlobalDtorFunc()`as 
the pre-work of [AIX][Frontend] Static init implementation for AIX considering 
no priority [https://reviews.llvm.org/D74166] patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81972

Files:
  clang/lib/CodeGen/CGDeclCXX.cpp


Index: clang/lib/CodeGen/CGDeclCXX.cpp
===
--- clang/lib/CodeGen/CGDeclCXX.cpp
+++ clang/lib/CodeGen/CGDeclCXX.cpp
@@ -533,6 +533,23 @@
   CXXThreadLocals.clear();
 }
 
+static StringRef getTransformedFileName(llvm::Module ,
+SmallString<128> ) {
+  FileName = llvm::sys::path::filename(M.getName());
+
+  if (FileName.empty())
+FileName = "";
+
+  for (size_t i = 0; i < FileName.size(); ++i) {
+// Replace everything that's not [a-zA-Z0-9._] with a _. This set happens
+// to be the set of C preprocessing numbers.
+if (!isPreprocessingNumberBody(FileName[i]))
+  FileName[i] = '_';
+  }
+
+  return FileName;
+}
+
 void
 CodeGenModule::EmitCXXGlobalInitFunc() {
   while (!CXXGlobalInits.empty() && !CXXGlobalInits.back())
@@ -577,22 +594,15 @@
 PrioritizedCXXGlobalInits.clear();
   }
 
-  // Include the filename in the symbol name. Including "sub_" matches gcc and
-  // makes sure these symbols appear lexicographically behind the symbols with
-  // priority emitted above.
-  SmallString<128> FileName = llvm::sys::path::filename(getModule().getName());
-  if (FileName.empty())
-FileName = "";
-
-  for (size_t i = 0; i < FileName.size(); ++i) {
-// Replace everything that's not [a-zA-Z0-9._] with a _. This set happens
-// to be the set of C preprocessing numbers.
-if (!isPreprocessingNumberBody(FileName[i]))
-  FileName[i] = '_';
-  }
-
+  // Include the filename in the symbol name. Including "sub_" matches gcc
+  // and makes sure these symbols appear lexicographically behind the symbols
+  // with priority emitted above.
+  SmallString<128> FileName;
   llvm::Function *Fn = CreateGlobalInitOrDestructFunction(
-  FTy, llvm::Twine("_GLOBAL__sub_I_", FileName), FI);
+  FTy,
+  llvm::Twine("_GLOBAL__sub_I_",
+  getTransformedFileName(getModule(), FileName)),
+  FI);
 
   CodeGenFunction(*this).GenerateCXXGlobalInitFunc(Fn, CXXGlobalInits);
   AddGlobalCtor(Fn);
@@ -631,6 +641,7 @@
 
   CodeGenFunction(*this).GenerateCXXGlobalDtorsFunc(Fn, CXXGlobalDtors);
   AddGlobalDtor(Fn);
+  CXXGlobalDtors.clear();
 }
 
 /// Emit the code necessary to initialize the given global variable.


Index: clang/lib/CodeGen/CGDeclCXX.cpp
===
--- clang/lib/CodeGen/CGDeclCXX.cpp
+++ clang/lib/CodeGen/CGDeclCXX.cpp
@@ -533,6 +533,23 @@
   CXXThreadLocals.clear();
 }
 
+static StringRef getTransformedFileName(llvm::Module ,
+SmallString<128> ) {
+  FileName = llvm::sys::path::filename(M.getName());
+
+  if (FileName.empty())
+FileName = "";
+
+  for (size_t i = 0; i < FileName.size(); ++i) {
+// Replace everything that's not [a-zA-Z0-9._] with a _. This set happens
+// to be the set of C preprocessing numbers.
+if (!isPreprocessingNumberBody(FileName[i]))
+  FileName[i] = '_';
+  }
+
+  return FileName;
+}
+
 void
 CodeGenModule::EmitCXXGlobalInitFunc() {
   while (!CXXGlobalInits.empty() && !CXXGlobalInits.back())
@@ -577,22 +594,15 @@
 PrioritizedCXXGlobalInits.clear();
   }
 
-  // Include the filename in the symbol name. Including "sub_" matches gcc and
-  // makes sure these symbols appear lexicographically behind the symbols with
-  // priority emitted above.
-  SmallString<128> FileName = llvm::sys::path::filename(getModule().getName());
-  if (FileName.empty())
-FileName = "";
-
-  for (size_t i = 0; i < FileName.size(); ++i) {
-// Replace everything that's not [a-zA-Z0-9._] with a _. This set happens
-// to be the set of C preprocessing numbers.
-if (!isPreprocessingNumberBody(FileName[i]))
-  FileName[i] = '_';
-  }
-
+  // Include the filename in the symbol name. Including "sub_" matches gcc
+  // and makes sure these symbols appear lexicographically behind the symbols
+  // with priority emitted above.
+  SmallString<128> FileName;
   llvm::Function *Fn = CreateGlobalInitOrDestructFunction(
-  FTy, llvm::Twine("_GLOBAL__sub_I_", FileName), FI);
+  FTy,
+  llvm::Twine("_GLOBAL__sub_I_",
+  getTransformedFileName(getModule(), FileName)),
+  FI);
 
   CodeGenFunction(*this).GenerateCXXGlobalInitFunc(Fn, CXXGlobalInits);
   AddGlobalCtor(Fn);
@@ -631,6 +641,7 @@
 
   CodeGenFunction(*this).GenerateCXXGlobalDtorsFunc(Fn, CXXGlobalDtors);
   

[PATCH] D80681: [clang][SourceManager] cache Macro Expansions

2020-06-16 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

> I've seen quite nice benchmarks for kernel build times in the issues you've 
> mentioned it would be nice if you could back that claim with similar data(not 
> that I don't take your word for it, I just love tables and I am jealous that 
> kernel has some but we don't :( )

Heh, those were painstakingly written in markdown by hand, using 
`CC="/usr/bin/time -v clang"` to test.  The weren't statistically significant 
(N=1), nor were they autogenerated.  My claims about builds of LLVM are 
similarly non-scientific in terms of statistical significance.

> I can say this patch LG from my side, but my understanding of this code isn't 
> quite strong so I would wait for a couple more days to see if someone else 
> will chime in.
>  Also forgot to say, thanks a lot for taking your time to investigate this 
> issue and coming up with a patch!

That's ok, I think generally finding someone to take the time to review pieces 
of a large project is generally difficult, and that contributors should feel 
empowered to be able to sign off on modifications to code they themselves did 
not write.  Thank you for taking the time to review it!

I will break this up into 3 patches, and ask you kindly to review once I have 
them ready.  I will post them here, too, in case other reviewers or subscribers 
would like to follow along, then I'll Abandon this revision.




Comment at: clang/include/clang/Basic/SourceManager.h:1747
   return getLoadedSLocEntryByID(ID, Invalid);
-return getLocalSLocEntry(static_cast(ID), Invalid);
+return getLocalSLocEntry(static_cast(ID));
   }

kadircet wrote:
> i think this deserves its separate patch.
> 
> We still can satisfy the interface requirements of libclang by introducing 
> another member `getLocalSLocEntryWithInvalid` and change the assertion into 
> an if check, populating `Invalid` in case of failure, what to return is more 
> tricky though it is a const ref, I suppose we can return a dummy entry.
> 
> Feel free to keep the newly added calls without an `Invalid` argument, but I 
> wouldn't modify the already existing ones in this patch.
> the interface requirements of libclang 

Oh? I must have missed that. Can you tell me more about that interface?  I 
would have thought this would fail to build if I messed up an interface?



Comment at: clang/lib/Basic/SourceManager.cpp:896
+FileID Res = FileID::get(MiddleIndex);
+if (isOffsetInLocalFileID(Res, SLocOffset)) {
+  // Remember it.  We have good locality across FileID lookups.

kadircet wrote:
> we already call getLocalSLocEntry for `MiddleIndex` above, moreover we even 
> early exit `if (SlocOffset < MidOffset)` which is the second case in your new 
> function. So I would say we could even gain more by:
> 
> ```
> const auto  = getLocalSLocEntry(MiddleIndex);
> auto MidOffset = SLocForMiddle.getOffset();
> .
> .
> .
> if (MiddleIndex + 1 ==LocalSLocEntryTable.size() || SLocOffset < 
> getLocalSLocEntry(MiddleIndex + 1).getOffset()) {
> // we've got a hit!
> }
> ```
> 
> That way you also wouldn't need to introduce a new function.
> 
> Even though there's value in new helpers, IMO `SourceManager` is already 
> complicated and has enough variants of each function to shoot yourself in the 
> foot. If you want feel free to put a FIXME saying `we can extract a 
> isOffsetInLocalFile helper from these lines if usage is more spread`.
> 
> 
> Again I would say this is worth doing in a separate patch. As it should be a 
> clear win for all.
Ah, right! This is a great suggestion! And it looks correct to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80681



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


[PATCH] D81920: [clangd] Change FSProvider::getFileSystem to take CurrentWorkingDirectory

2020-06-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Looks like an improvement but I don't like the `(".")` in various places.

Maybe make the param optional and don't cd if it's none?
I wouldn't give it a default arg though, the idea is to force a choice.




Comment at: clang-tools-extra/clangd/ClangdServer.cpp:187
+Opts.ClangTidyOpts =
+GetClangTidyOptions(*FSProvider.getFileSystem("."), File);
   Opts.SuggestMissingIncludes = SuggestMissingIncludes;

Not sure what to do in this patch, but ultimately I don't think we must/should 
pass an FS of any form into this callback.
(Doesn't make sense to assume getting options needs the FS, embedders can use 
the context to know what version of the FS to use if needed)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81920



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


[PATCH] D81970: [Clang][Driver] Remove gold linker support for PS4 toolchain

2020-06-16 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen created this revision.
ychen added a reviewer: probinson.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81970

Files:
  clang/lib/Driver/ToolChains/PS4CPU.cpp
  clang/test/Driver/ps4-linker-non-win.c
  clang/test/Driver/ps4-linker-win.c

Index: clang/test/Driver/ps4-linker-win.c
===
--- clang/test/Driver/ps4-linker-win.c
+++ clang/test/Driver/ps4-linker-win.c
@@ -1,27 +1,32 @@
-// The full path to the gold linker was not found on Windows because the
-// driver fails to add an .exe extension to the name.
-// We check that gold linker's full name (with an extension) is specified
-// on the command line if -fuse-ld=gold, or -shared with no -fuse-ld option
-// are passed. Otherwise, we check that the PS4's linker's full name is
-// specified.
+// This test check that orbis-ld is used for linker all the time. Specifying
+// linker using -fuse-ld causes a error message emitted and compilation fail.
 
 // REQUIRES: system-windows, x86-registered-target
 
 // RUN: mkdir -p %t
 // RUN: touch %t/orbis-ld.exe
-// RUN: touch %t/orbis-ld.gold.exe
-
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -fuse-ld=gold -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
 
 // RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -fuse-ld=ps4 -### 2>&1 \
+// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared \
-// RUN: -fuse-ld=ps4 -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER %s
 
-// CHECK-PS4-GOLD: \\orbis-ld.gold
 // CHECK-PS4-LINKER: \\orbis-ld
+
+// RUN: env "PATH=%t;%PATH%;" %clang -### -target x86_64-scei-ps4 -flto=thin %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PS4-LTO-THIN %s
+// RUN: env "PATH=%t;%PATH%;" %clang -### -target x86_64-scei-ps4 -flto=full %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PS4-LTO-FULL %s
+// RUN: env "PATH=%t;%PATH%;" %clang -### -target x86_64-scei-ps4  %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PS4-NO-LTO-THIN --check-prefix=CHECK-PS4-NO-LTO-FULL %s
+
+// CHECK-PS4-LTO-THIN: --lto=thin
+// CHECK-PS4-LTO-FULL: --lto=full
+// CHECK-PS4-NO-LTO-THIN-NOT: --lto=thin
+// CHECK-PS4-NO-LTO-FULL-NOT: --lto=full
+
+// RUN: env "PATH=%t;%PATH%;" %clang -target x86_64-scei-ps4 %s -fuse-ld=gold -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=ERROR %s
+
+// ERROR: error: unsupported option '-fuse-ld' for target 'x86_64-scei-ps4'
+
Index: clang/test/Driver/ps4-linker-non-win.c
===
--- clang/test/Driver/ps4-linker-non-win.c
+++ clang/test/Driver/ps4-linker-non-win.c
@@ -6,16 +6,15 @@
 // RUN: touch %t/orbis-ld
 // RUN: chmod +x %t/orbis-ld
 
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -fuse-ld=gold 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-
 // RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -fuse-ld=ps4 2>&1 \
+// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4  %s -shared \
-// RUN: -fuse-ld=ps4 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER %s
 
 // CHECK-PS4-LINKER: /orbis-ld
+
+// RUN: env "PATH=%t:%PATH%" %clang -### -target x86_64-scei-ps4 %s -fuse-ld=gold 2>&1 \
+// RUN:   | FileCheck --check-prefix=ERROR %s
+
+// ERROR: error: unsupported option '-fuse-ld' for target 'x86_64-scei-ps4'
+
Index: clang/lib/Driver/ToolChains/PS4CPU.cpp
===
--- clang/lib/Driver/ToolChains/PS4CPU.cpp
+++ clang/lib/Driver/ToolChains/PS4CPU.cpp
@@ -88,13 +88,13 @@
 CmdArgs.push_back("--dependent-lib=libSceDbgAddressSanitizer_stub_weak.a");
 }
 
-static void ConstructPS4LinkJob(const Tool , Compilation ,
-const JobAction , const InputInfo ,
-const InputInfoList ,
-const ArgList ,
-const char *LinkingOutput) {
+void tools::PS4cpu::Link::ConstructJob(Compilation , const JobAction ,
+   

[PATCH] D81967: [clang-tools-extra] Prevent linking to duplicate .a libs and dylib

2020-06-16 Thread Michaล‚ Gรณrny via Phabricator via cfe-commits
mgorny added a comment.
Herald added a subscriber: wuzish.

For the record, this seems to trigger some command-line option parser problem:

   TEST 'Clang Tools :: 
clang-tidy/infrastructure/invalid-command-line.cpp' FAILED  
 
  Script:   
 
  --
 
  : 'RUN: at line 1';   not clang-tidy --invalid-arg 2>&1 | FileCheck 
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure$
  invalid-command-line.cpp  
 
  --
 
  Exit Code: 1  
 

 
  Command Output (stderr):  
 
  --
 
  
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure/invalid-command-line.cpp:4:16:
 error: CHECK-NEXT: expected string no
  t found in input  
 
  // CHECK-NEXT: clang-tidy{{(\.exe)?}}: Did you mean '--extra-arg'?
 
 ^  
 
  :2:1: note: scanning from here 
 
  clang-tidy: Did you mean '--enable-pre'?  
 
  ^

 
  Input file:   
  Check file: 
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure/invalid-command-line.cpp


 
  -dump-input=help describes the format of the following dump. 

 
  Full input was:   
 
  <<
 
  1: error: [CommonOptionsParser]: clang-tidy: Unknown command line 
argument '--invalid-arg'. Try: 'clang-tidy --help'   
  2: clang-tidy: Did you mean '--enable-pre'?   
 
  next:4 X~~~ error: no match found 
 
  >>
 

I'm going to investigate further tomorrow.


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

https://reviews.llvm.org/D81967



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


[PATCH] D81967: [clang-tools-extra] Prevent linking to duplicate .a libs and dylib

2020-06-16 Thread Michaล‚ Gรณrny via Phabricator via cfe-commits
mgorny created this revision.
mgorny added reviewers: alexfh, hokein, sammccall, ilya-biryukov, kadircet, 
ioeric, bkramer, aaron.ballman, klimek, juliehockett.
Herald added subscribers: sstefan1, phosek, usaxena95, lebedev.ri, arphaman, 
jkorous, kbarton, nemanjai.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: lebedev.ri.
mgorny added a comment.
Herald added a subscriber: wuzish.

For the record, this seems to trigger some command-line option parser problem:

   TEST 'Clang Tools :: 
clang-tidy/infrastructure/invalid-command-line.cpp' FAILED  
 
  Script:   
 
  --
 
  : 'RUN: at line 1';   not clang-tidy --invalid-arg 2>&1 | FileCheck 
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure$
  invalid-command-line.cpp  
 
  --
 
  Exit Code: 1  
 

 
  Command Output (stderr):  
 
  --
 
  
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure/invalid-command-line.cpp:4:16:
 error: CHECK-NEXT: expected string no
  t found in input  
 
  // CHECK-NEXT: clang-tidy{{(\.exe)?}}: Did you mean '--extra-arg'?
 
 ^  
 
  :2:1: note: scanning from here 
 
  clang-tidy: Did you mean '--enable-pre'?  
 
  ^

 
  Input file:   
  Check file: 
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure/invalid-command-line.cpp


 
  -dump-input=help describes the format of the following dump. 

 
  Full input was:   
 
  <<
 
  1: error: [CommonOptionsParser]: clang-tidy: Unknown command line 
argument '--invalid-arg'. Try: 'clang-tidy --help'   
  2: clang-tidy: Did you mean '--enable-pre'?   
 
  next:4 X~~~ error: no match found 
 
  >>
 

I'm going to investigate further tomorrow.


Fix various tool libraries not to link to clang's .a libraries and dylib
simultaneously.  This may cause breakage, in particular through
duplicate command-line option declarations.


https://reviews.llvm.org/D81967

Files:
  clang-tools-extra/clang-apply-replacements/CMakeLists.txt
  

[PATCH] D80712: [SVE] Add checks for no warnings in SVE tests

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

LGTM


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

https://reviews.llvm.org/D80712



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


[PATCH] D81938: [InferAddressSpaces] Handle the pair of `ptrtoint`/`inttoptr`.

2020-06-16 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

In D81938#2096500 , @arsenm wrote:

> I'm not entirely convinced this is safe in all contexts. I think you can 
> argue that this is safe if it directly feeds a memory instruction, as the 
> access would be undefined if it weren't valid to do the no-op cast. However, 
> I'm not sure if this is safe if used purely in arithmetic contexts. If you're 
> just comparing the reinterpreted pointer values for example, I don't think 
> that would be undefined


Would it be safe if we double-check the target hook and ensure that's a no-op 
`addrspacecast` between address spaces?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81938



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


[PATCH] D81869: Modify FPFeatures to use delta not absolute settings to solve PCH compatibility problems

2020-06-16 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/include/clang/AST/Expr.h:2280
   }
+  FPOptionsOverride getFPFeatures(const LangOptions ) const {
+if (UnaryOperatorBits.HasFPFeatures)

I would call this one getFPOptionOverrides or getOverriddenFPOptions.  If 
you're going to have a getFPFeatures, it really ought to be the other one โ€” 
although since we're changing pretty much all of the call sites, we might as 
well rename it to getFPOptions (or getFPOptionsInEffect, that seems fine, too).



Comment at: clang/include/clang/Basic/LangOptions.h:758
+  unsigned allow_reciprocal_disabled : 1;
+  unsigned approx_func_disabled : 1;
 };

As an alternative storage strategy, I would suggest:

- in FPOptions, use an integer and masks instead of bit-fields
- in FPOptionsOverride, store the same integer from FPOptions plus the active 
override mask

This will make the merge and extract operations really painless.  It can get a 
little boilerplate, though, so I'd recommend also introducing an "x-macro" file:

```
// clang/Basic/FPOptions.def
// OPTION(name, type, width, previousName)
OPTION(FPContractMode, LangOptions::FPModeKind, 2, First)
OPTION(RoundingMode, RoundingMode, 3, FPContractMode)
...
OPTION(AllowReciprocal, bool, 1, NoSignedZeros)
...
#undef OPTION

...

class FPOptions {
public:
  // We start by defining the layout.
  using storage_type = uint16_t;

  // Define a fake option named "First" so that we have a PREVIOUS even for the 
real first option.
  static constexpr storage_type FirstShift = 0,  FirstWidth = 0;
#define OPTION(NAME, TYPE, WIDTH, PREVIOUS) \
  static constexpr storage_type NAME#Shift = PREVIOUS#Shift + PREVIOUS#Width; \
  static constexpr storage_type NAME#Width = width; \
  static constexpr storage_type NAME#Mask = ((1 << NAME#Width) - 1) << 
NAME#Shift;
#include "clang/Basic/FPOptions.def"

private:
  storage_type Value;

public:
  // Now you can define constructors and so on.
  FPOptions() : Value(0) {}

  bool operator==(FPOptions other) const {
return Value == other.Value;
  }
  bool operator!=(FPOptionsOverride other) const {
return Value != other.Value;
  }

  storage_type getAsOpaqueInt() const { return Value; }
  static FPOptions getFromOpaqueInt(storage_type value) {
 FPOptions result; 
 result.Value = value;
 return result;
  }

  // We can define most of the accessors automatically:
#define OPTION(NAME, TYPE, WIDTH, PREVIOUS) \
  TYPE get#NAME() const { \
return TYPE((Value & NAME#Mask) >> NAME#Shift);  \
  } \
  void set#NAME(TYPE value) { \
Value = (Value & ~NAME#Mask) | (storage_type(value) << NAME#Shift); \
  }
#include "clang/Basic/FPOptions.def"
};

// The override type is then basically just that, plus a mask about whether 
fields are actually set in it:
class FPOptionsOverride {
  FPOptions Options;
  FPOptions::storage_type OverrideMask = 0;

public:
  FPOptionsOverride() {}

  bool hasAnyOverrides() const {
return OverrideMask != 0;
  }

  FPOptions applyOverrides(FPOptions base) {
return FPOptions::getFromOpaqueInt(base.getAsOpaqueInt()
 | (OverrideMask & Options.getAsOpaqueInt()));
  }

  bool operator==(FPOptionsOverride other) const {
return Options == other.Options && OverrideMask == other.OverrideMask;
  }
  bool operator!=(FPOptionsOverride other) const {
return !(*this == other);
  }

#define OPTION(NAME, TYPE, WIDTH, PREVIOUS) \
  bool has#NAME#Override() const { \
return OverrideMask & NAME#Mask; \
  } \
  TYPE get#NAME#Override() const { \
assert(has#NAME#Override()); \
return Options.get#NAME();
  } \
  void clear#NAME#Override() { \
/* Clear the actual value so that we don't have spurious differences when 
testing equality. */ \
Options.set#NAME(TYPE(0)); \
OverrideMask &= ~NAME#Mask; \
  } \
  void set#NAME#Override(TYPE value) { \
Options.set#NAME(value); \
OverrideMask |= NAME#Mask; \
 }
#include "clang/Basic/FPOptions.def"
};
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81869



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


[PATCH] D81672: [Driver] When forcing a crash call abort to get the correct diagnostic

2020-06-16 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added inline comments.



Comment at: clang/tools/driver/driver.cpp:518
+  CRC.DumpStackAndCleanupOnFailure = true;
+  CRC.RunSafely([&]() { abort(); });
 }

The only concern I have is that a unrelated call stack will be printed.
Could you possibly add (and use here) a function along the lines of 
`emitBugReportMsg() { errs() << BugReportMsg; }`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81672



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


[PATCH] D81923: [clang-tidy] Add modernize-use-ranges check.

2020-06-16 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 271191.
njames93 marked 4 inline comments as done.
njames93 added a comment.

Tweaked documentation


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81923

Files:
  clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
  clang-tools-extra/clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tools-extra/clang-tidy/modernize/UseRangesCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseRangesCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-ranges.rst
  clang-tools-extra/test/clang-tidy/checkers/modernize-use-ranges.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-use-ranges.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-use-ranges.cpp
@@ -0,0 +1,156 @@
+// RUN: %check_clang_tidy -std=c++20 %s modernize-use-ranges %t
+
+// Ensure no warnings are generated when not in c++20 mode
+// RUN: clang-tidy %s -checks=-*,modernize-use-ranges --warnings-as-errors=modernize-use-ranges --extra-arg=-std=c++17
+
+namespace std {
+
+class sequenced_policy {};
+class parallel_policy {};
+class parallel_unsequenced_policy {};
+class unsequenced_policy {};
+
+template 
+auto begin(Container ) -> decltype(C.begin());
+template 
+auto cbegin(Container ) -> decltype(C.cbegin());
+
+template 
+auto end(Container ) -> decltype(C.end());
+template 
+auto cend(Container ) -> decltype(C.cend());
+
+template 
+T *begin(T ()[N]) noexcept;
+
+template 
+T *end(T ()[N]) noexcept;
+
+template 
+class vector {
+public:
+  using iterator = T *;
+  using const_iterator = const T *;
+
+  iterator begin();
+  const_iterator begin() const;
+  const_iterator cbegin() const;
+
+  iterator end();
+  const_iterator end() const;
+  const_iterator cend() const;
+};
+
+template 
+InputIt find(InputIt First, InputIt Last, const T );
+
+template 
+ForwardIt find(ExecutionPolicy &, ForwardIt First, ForwardIt Last, const T );
+
+template 
+bool equal(InputIt1 First1, InputIt1 Last1,
+   InputIt2 First2);
+template 
+bool equal(ExecutionPolicy &, ForwardIt1 First1, ForwardIt1 Last1,
+   ForwardIt2 First2);
+template 
+bool equal(InputIt1 First1, InputIt1 Last1,
+   InputIt2 First2, InputIt2 Last2);
+template 
+bool equal(ExecutionPolicy &, ForwardIt1 First1, ForwardIt1 Last1,
+   ForwardIt2 First2, ForwardIt2 Last2);
+
+template 
+bool includes(InputIt1 First1, InputIt1 Last1,
+  InputIt2 First2, InputIt2 Last2);
+template 
+bool includes(ExecutionPolicy &, ForwardIt1 First1, ForwardIt1 Last1,
+  ForwardIt2 First2, ForwardIt2 Last2);
+
+} // namespace std
+
+void goodBeginEndCalls(const std::vector ) {
+  std::find(Vec.begin(), Vec.end(), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(Vec.cbegin(), Vec.cend(), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(std::begin(Vec), std::end(Vec), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(std::cbegin(Vec), std::cend(Vec), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(std::parallel_policy(), Vec.begin(), Vec.end(), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+
+  // CHECK-FIXES:  std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(std::parallel_policy(), Vec, 1);
+  // CHECK-FIXES-NEXT: //
+}
+
+void badBeginEndCalls(const std::vector ,
+  const std::vector ) {
+  // end, begin.
+  std::find(Vec.end(), Vec.begin(), 1);
+  std::find(Vec.cend(), Vec.cbegin(), 1);
+  std::find(std::end(Vec), std::begin(Vec), 1);
+  std::find(std::cend(Vec), std::cbegin(Vec), 1);
+
+  // begin, begin.
+  std::find(Vec.begin(), Vec.begin(), 1);
+  // end, end.
+  std::find(Vec.end(), Vec.end(), 1);
+
+  // Different containers, definitely bad, but not what this check is for.
+  std::find(Vec.begin(), Vec2.end(), 1);
+}
+
+void maybeDualArg(const std::vector , std::vector ) {
+  std::equal(Vec1.begin(), Vec1.end(), Vec2.begin());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace equal with std::ranges::equal
+  std::equal(Vec1.begin(), Vec1.end(), Vec2.begin(), Vec2.end());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace equal with std::ranges::equal
+  std::equal(std::sequenced_policy(), Vec1.begin(), Vec1.end(), Vec2.begin());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace 

[PATCH] D81869: Modify FPFeatures to use delta not absolute settings to solve PCH compatibility problems

2020-06-16 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 271188.
mibintc added a comment.

This version passes all the lit tests, i believe it's functional tho' maybe not 
elegant.
I still need to add a test case that PCH behaves as desired, and that the 
floating point command line options from PCH create do not clobber command line 
options from compilations that use a pch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81869

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Basic/LangOptions.cpp
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
  clang/lib/Frontend/Rewrite/RewriteObjC.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaPseudoObject.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  llvm/include/llvm/ADT/FloatingPointMode.h

Index: llvm/include/llvm/ADT/FloatingPointMode.h
===
--- llvm/include/llvm/ADT/FloatingPointMode.h
+++ llvm/include/llvm/ADT/FloatingPointMode.h
@@ -40,6 +40,7 @@
   NearestTiesToAway = 4,///< roundTiesToAway.
 
   // Special values.
+  Unset = 6,  ///< Denotes an unset value, (for clang, must fit in 3 bits)
   Dynamic = 7,///< Denotes mode unknown at compile time.
   Invalid = -1///< Denotes invalid value.
 };
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -3960,7 +3960,7 @@
 }
 
 /// Write an FP_PRAGMA_OPTIONS block for the given FPOptions.
-void ASTWriter::WriteFPPragmaOptions(const FPOptions ) {
+void ASTWriter::WriteFPPragmaOptions(const FPOptionsOverride ) {
   RecordData::value_type Record[] = {Opts.getAsOpaqueInt()};
   Stream.EmitRecord(FP_PRAGMA_OPTIONS, Record);
 }
@@ -4790,7 +4790,7 @@
   WriteReferencedSelectorsPool(SemaRef);
   WriteLateParsedTemplates(SemaRef);
   WriteIdentifierTable(PP, SemaRef.IdResolver, isModule);
-  WriteFPPragmaOptions(SemaRef.getCurFPFeatures());
+  WriteFPPragmaOptions(SemaRef.CurFPFeatureOverrides());
   WriteOpenCLExtensions(SemaRef);
   WriteOpenCLExtensionTypes(SemaRef);
   WriteCUDAPragmas(SemaRef);
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -689,7 +689,7 @@
   E->setOperatorLoc(readSourceLocation());
   E->setCanOverflow(Record.readInt());
   if (hasFP_Features)
-E->setStoredFPFeatures(FPOptions(Record.readInt()));
+E->setStoredFPFeatures(FPOptionsOverride(Record.readInt()));
 }
 
 void ASTStmtReader::VisitOffsetOfExpr(OffsetOfExpr *E) {
@@ -1072,7 +1072,7 @@
   E->setRHS(Record.readSubExpr());
   E->setOperatorLoc(readSourceLocation());
   if (hasFP_Features)
-E->setStoredFPFeatures(FPOptions(Record.readInt()));
+E->setStoredFPFeatures(FPOptionsOverride(Record.readInt()));
 }
 
 void ASTStmtReader::VisitCompoundAssignOperator(CompoundAssignOperator *E) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -7843,7 +7843,8 @@
   // FIXME: What happens if these are changed by a module import?
   if (!FPPragmaOptions.empty()) {
 assert(FPPragmaOptions.size() == 1 && "Wrong number of FP_PRAGMA_OPTIONS");
-SemaObj->CurFPFeatures = FPOptions(FPPragmaOptions[0]);
+FPOptionsOverride NewOverrides(FPPragmaOptions[0]);
+SemaObj->CurFPFeatures = NewOverrides.mergeOverrides(SemaObj->getLangOpts());
   }
 
   SemaObj->OpenCLFeatures.copy(OpenCLExtensions);
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -10563,8 +10563,9 @@
 return getDerived().RebuildBinaryOperator(
 E->getOperatorLoc(), E->getOpcode(), LHS.get(), RHS.get());
   Sema::FPFeaturesStateRAII FPFeaturesState(getSema());
-  getSema().CurFPFeatures = E->getFPFeatures(getSema().getLangOpts());
-
+  

[PATCH] D81966: [clang][module] Improve -Wincomplete-umbrella

2020-06-16 Thread Zixu Wang via Phabricator via cfe-commits
zixuw created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
zixuw added reviewers: arphaman, rsmith, bruno.
Herald added a subscriber: dexonsmith.

Change the warning message for `-Wincomplete-umbrella` to report the
location of the umbrella header;
Add a fix-it hint to include uncovered headers in the umbrella header.

rdar://57095551


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81966

Files:
  clang/include/clang/Rewrite/Frontend/FrontendActions.h
  clang/lib/Frontend/Rewrite/FrontendActions.cpp
  clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/test/Modules/Inputs/incomplete-umbrella/normal-module/A1.h
  clang/test/Modules/Inputs/incomplete-umbrella/normal-module/A2.h
  clang/test/Modules/Inputs/incomplete-umbrella/normal-module/Umbrella.h
  clang/test/Modules/Inputs/incomplete-umbrella/normal-module/module.modulemap
  clang/test/Modules/incomplete-umbrella-fixit.m
  clang/test/Modules/incomplete-umbrella.m

Index: clang/test/Modules/incomplete-umbrella.m
===
--- clang/test/Modules/incomplete-umbrella.m
+++ clang/test/Modules/incomplete-umbrella.m
@@ -6,8 +6,12 @@
 #import 
 @import Foo.Private;
 
-// CHECK: warning: umbrella header for module 'Foo' does not include header 'Bar.h'
-// CHECK: warning: umbrella header for module 'Foo.Private' does not include header 'Baz.h'
+// CHECK: While building module 'Foo' imported from {{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :1:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]Headers[/\]}}FooPublic.h:2:1: warning: umbrella header for module 'Foo' does not include header 'Bar.h'
+// CHECK: While building module 'Foo' imported from {{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :2:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]PrivateHeaders[/\]}}Foo.h:2:1: warning: umbrella header for module 'Foo.Private' does not include header 'Baz.h'
 int foo() {
   int a = BAR_PUBLIC;
   int b = BAZ_PRIVATE;
Index: clang/test/Modules/incomplete-umbrella-fixit.m
===
--- /dev/null
+++ clang/test/Modules/incomplete-umbrella-fixit.m
@@ -0,0 +1,10 @@
+// RUN: rm -rf %t
+// RUN: cp -R %S/Inputs/incomplete-umbrella/normal-module %t
+// RUN: %clang_cc1 -fmodules -fmodule-map-file=%t/module.modulemap -fmodules-cache-path=%t -Wno-everything -Wincomplete-umbrella -fixit %s && FileCheck %t/Umbrella.h --input-file %t/Umbrella.h --match-full-lines
+// RUN: %clang_cc1 -fmodules -fmodule-map-file=%t/module.modulemap -fmodules-cache-path=%t -Wno-everything -Wincomplete-umbrella -Werror %s
+
+@import A;
+
+int foo() {
+  return 0;
+}
Index: clang/test/Modules/Inputs/incomplete-umbrella/normal-module/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/incomplete-umbrella/normal-module/module.modulemap
@@ -0,0 +1,4 @@
+module A {
+  umbrella header "Umbrella.h"
+  export *
+}
Index: clang/test/Modules/Inputs/incomplete-umbrella/normal-module/Umbrella.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/incomplete-umbrella/normal-module/Umbrella.h
@@ -0,0 +1,3 @@
+// Umbrella.h
+// CHECK: #import "A1.h"
+// CHECK: #import "A2.h"
Index: clang/test/Modules/Inputs/incomplete-umbrella/normal-module/A2.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/incomplete-umbrella/normal-module/A2.h
@@ -0,0 +1 @@
+// A2.h
Index: clang/test/Modules/Inputs/incomplete-umbrella/normal-module/A1.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/incomplete-umbrella/normal-module/A1.h
@@ -0,0 +1 @@
+// A1.h
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -263,10 +263,11 @@
 }
 
 void Preprocessor::diagnoseMissingHeaderInUmbrellaDir(const Module ) {
-  assert(Mod.getUmbrellaHeader() && "Module must use umbrella header");
-  SourceLocation StartLoc =
-  SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID());
-  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header, StartLoc))
+  const auto  = Mod.getUmbrellaHeader();
+  assert(UmbrellaHeader.Entry && "Module must use umbrella header");
+  const FileID  = SourceMgr.translateFile(UmbrellaHeader.Entry);
+  SourceLocation EndLoc = SourceMgr.getLocForEndOfFile(File);
+  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header, EndLoc))
 return;
 
   ModuleMap  = getHeaderSearchInfo().getModuleMap();
@@ -291,8 +292,26 @@
   // Find the relative path that would access this header.
   SmallString<128> RelativePath;
   computeRelativePath(FileMgr, Dir, 

[clang] 0f631bd - Revert "[OPENMP50]Codegen for scan directive in for simd regions."

2020-06-16 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-06-16T17:01:59-04:00
New Revision: 0f631bd3bb6496fbca96a450719a9e99837de6c0

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

LOG: Revert "[OPENMP50]Codegen for scan directive in for simd regions."

This reverts commit 6e78a3086a7f563cc55d2ba83a8697b3320857fb to solve
the problem with mem leak.

Added: 


Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp

Removed: 
clang/test/OpenMP/for_simd_scan_codegen.cpp



diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 803e262bd8cd..5b05577543fc 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -3261,34 +3261,9 @@ void CodeGenFunction::EmitOMPForSimdDirective(const 
OMPForSimdDirective ) {
   bool HasLastprivates = false;
   auto & = [, ](CodeGenFunction ,
   PrePostActionTy &) {
-if (llvm::any_of(S.getClausesOfKind(),
- [](const OMPReductionClause *C) {
-   return C->getModifier() == OMPC_REDUCTION_inscan;
- })) {
-  const auto & = [](CodeGenFunction ) {
-OMPLocalDeclMapRAII Scope(CGF);
-OMPLoopScope LoopScope(CGF, S);
-return CGF.EmitScalarExpr(S.getNumIterations());
-  };
-  const auto & = [](CodeGenFunction ) {
-(void)CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
- emitForLoopBounds,
- emitDispatchForLoopBounds);
-// Emit an implicit barrier at the end.
-CGF.CGM.getOpenMPRuntime().emitBarrierCall(CGF, S.getBeginLoc(),
-   OMPD_for);
-  };
-  const auto & = [, ](CodeGenFunction ) {
-HasLastprivates = CGF.EmitOMPWorksharingLoop(S, 
S.getEnsureUpperBound(),
- emitForLoopBounds,
- 
emitDispatchForLoopBounds);
-  };
-  emitScanBasedDirective(CGF, S, NumIteratorsGen, FirstGen, SecondGen);
-} else {
-  HasLastprivates = CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
-   emitForLoopBounds,
-   emitDispatchForLoopBounds);
-}
+HasLastprivates = CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
+ emitForLoopBounds,
+ emitDispatchForLoopBounds);
   };
   {
 auto LPCRegion =

diff  --git a/clang/test/OpenMP/for_simd_scan_codegen.cpp 
b/clang/test/OpenMP/for_simd_scan_codegen.cpp
deleted file mode 100644
index 2c7f53a0aa36..
--- a/clang/test/OpenMP/for_simd_scan_codegen.cpp
+++ /dev/null
@@ -1,312 +0,0 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -std=c++11 -triple 
x86_64-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 
%s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -std=c++11 -triple 
x86_64-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck --check-prefix SIMD-ONLY0 %s
-// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
-// expected-no-diagnostics
-#ifndef HEADER
-#define HEADER
-
-void foo();
-void bar();
-
-// CHECK: define void @{{.*}}baz{{.*}}(i32 %n)
-void baz(int n) {
-  static float a[10];
-  static double b;
-  // CHECK: call i8* @llvm.stacksave()
-  // CHECK: [[A_BUF_SIZE:%.+]] = mul nuw i64 10, [[NUM_ELEMS:%[^,]+]]
-
-  // float a_buffer[10][n];
-  // CHECK: [[A_BUF:%.+]] = alloca float, i64 [[A_BUF_SIZE]],
-
-  // double b_buffer[10];
-  // CHECK: [[B_BUF:%.+]] = alloca double, i64 10,
-#pragma omp for simd reduction(inscan, +:a[:n], b)
-  for (int i = 0; i < 10; ++i) {
-// CHECK: call void @__kmpc_for_static_init_4(
-// CHECK: call i8* @llvm.stacksave()
-// CHECK: store float 0.00e+00, float* %
-// CHECK: store double 0.00e+00, double* [[B_PRIV_ADDR:%.+]],
-// CHECK: br label %[[DISPATCH:[^,]+]]
-// CHECK: [[INPUT_PHASE:.+]]:
-// CHECK: call void @{{.+}}foo{{.+}}()
-
-// a_buffer[i][0..n] = a_priv[[0..n];
-// CHECK: [[BASE_IDX_I:%.+]] = 

Re: [PATCH] D81953: [clang-tidy] warnings-as-error no longer exits with ErrorCount

2020-06-16 Thread Jon Roelofs via cfe-commits
I didnโ€™t have a specific use case in mind for it, so no preference either
way.

LGTM as well

On Tue, Jun 16, 2020 at 1:05 PM Aaron Ballman via Phabricator <
revi...@reviews.llvm.org> wrote:

> aaron.ballman accepted this revision.
> aaron.ballman added a comment.
> This revision is now accepted and ready to land.
>
> LGTM unless @jroelofs has a reason why the code was originally written
> that way, but can you add test coverage for it?
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D81953/new/
>
> https://reviews.llvm.org/D81953
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D81658: [OPENMP50]Codegen for scan directive in for simd regions.

2020-06-16 Thread Alexey Bataev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6e78a3086a7f: [OPENMP50]Codegen for scan directive in for 
simd regions. (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81658

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

Index: clang/test/OpenMP/for_simd_scan_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/for_simd_scan_codegen.cpp
@@ -0,0 +1,312 @@
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -x c++ -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -std=c++11 -triple x86_64-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple x86_64-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=50 -x c++ -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -std=c++11 -triple x86_64-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple x86_64-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+void foo();
+void bar();
+
+// CHECK: define void @{{.*}}baz{{.*}}(i32 %n)
+void baz(int n) {
+  static float a[10];
+  static double b;
+  // CHECK: call i8* @llvm.stacksave()
+  // CHECK: [[A_BUF_SIZE:%.+]] = mul nuw i64 10, [[NUM_ELEMS:%[^,]+]]
+
+  // float a_buffer[10][n];
+  // CHECK: [[A_BUF:%.+]] = alloca float, i64 [[A_BUF_SIZE]],
+
+  // double b_buffer[10];
+  // CHECK: [[B_BUF:%.+]] = alloca double, i64 10,
+#pragma omp for simd reduction(inscan, +:a[:n], b)
+  for (int i = 0; i < 10; ++i) {
+// CHECK: call void @__kmpc_for_static_init_4(
+// CHECK: call i8* @llvm.stacksave()
+// CHECK: store float 0.00e+00, float* %
+// CHECK: store double 0.00e+00, double* [[B_PRIV_ADDR:%.+]],
+// CHECK: br label %[[DISPATCH:[^,]+]]
+// CHECK: [[INPUT_PHASE:.+]]:
+// CHECK: call void @{{.+}}foo{{.+}}()
+
+// a_buffer[i][0..n] = a_priv[[0..n];
+// CHECK: [[BASE_IDX_I:%.+]] = load i32, i32* [[IV_ADDR:%.+]],
+// CHECK: [[BASE_IDX:%.+]] = zext i32 [[BASE_IDX_I]] to i64
+// CHECK: [[IDX:%.+]] = mul nsw i64 [[BASE_IDX]], [[NUM_ELEMS]]
+// CHECK: [[A_BUF_IDX:%.+]] = getelementptr inbounds float, float* [[A_BUF]], i64 [[IDX]]
+// CHECK: [[A_PRIV:%.+]] = getelementptr inbounds [10 x float], [10 x float]* [[A_PRIV_ADDR:%.+]], i64 0, i64 0
+// CHECK: [[BYTES:%.+]] = mul nuw i64 [[NUM_ELEMS:%.+]], 4
+// CHECK: [[DEST:%.+]] = bitcast float* [[A_BUF_IDX]] to i8*
+// CHECK: [[SRC:%.+]] = bitcast float* [[A_PRIV]] to i8*
+// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}[[DEST]], i8* {{.*}}[[SRC]], i64 [[BYTES]], i1 false)
+
+// b_buffer[i] = b_priv;
+// CHECK: [[B_BUF_IDX:%.+]] = getelementptr inbounds double, double* [[B_BUF]], i64 [[BASE_IDX]]
+// CHECK: [[B_PRIV:%.+]] = load double, double* [[B_PRIV_ADDR]],
+// CHECK: store double [[B_PRIV]], double* [[B_BUF_IDX]],
+// CHECK: br label %[[LOOP_CONTINUE:.+]]
+
+// CHECK: [[DISPATCH]]:
+// CHECK: br label %[[INPUT_PHASE]]
+// CHECK: [[LOOP_CONTINUE]]:
+// CHECK: call void @llvm.stackrestore(i8* %
+// CHECK: call void @__kmpc_for_static_fini(
+// CHECK: call void @__kmpc_barrier(
+foo();
+#pragma omp scan inclusive(a[:n], b)
+// CHECK: [[LOG2_10:%.+]] = call double @llvm.log2.f64(double 1.00e+01)
+// CHECK: [[CEIL_LOG2_10:%.+]] = call double @llvm.ceil.f64(double [[LOG2_10]])
+// CHECK: [[CEIL_LOG2_10_INT:%.+]] = fptoui double [[CEIL_LOG2_10]] to i32
+// CHECK: br label %[[OUTER_BODY:[^,]+]]
+// CHECK: [[OUTER_BODY]]:
+// CHECK: [[K:%.+]] = phi i32 [ 0, %{{.+}} ], [ [[K_NEXT:%.+]], %{{.+}} ]
+// CHECK: [[K2POW:%.+]] = phi i64 [ 1, %{{.+}} ], [ [[K2POW_NEXT:%.+]], %{{.+}} ]
+// CHECK: [[CMP:%.+]] = icmp uge i64 9, [[K2POW]]
+// CHECK: br i1 [[CMP]], label %[[INNER_BODY:[^,]+]], label %[[INNER_EXIT:[^,]+]]
+// CHECK: [[INNER_BODY]]:
+// CHECK: [[I:%.+]] = phi i64 [ 9, %[[OUTER_BODY]] ], [ [[I_PREV:%.+]], %{{.+}} ]
+
+// a_buffer[i] += a_buffer[i-pow(2, k)];
+// CHECK: [[IDX:%.+]] = mul nsw i64 [[I]], [[NUM_ELEMS]]
+// CHECK: [[A_BUF_IDX:%.+]] = getelementptr inbounds float, float* [[A_BUF]], i64 [[IDX]]
+// CHECK: [[IDX_SUB_K2POW:%.+]] = sub nuw i64 [[I]], [[K2POW]]
+// CHECK: [[IDX:%.+]] = mul nsw i64 [[IDX_SUB_K2POW]], [[NUM_ELEMS]]
+// CHECK: [[A_BUF_IDX_SUB_K2POW:%.+]] = getelementptr inbounds float, float* 

[PATCH] D81959: [HIP] Enable -amdgpu-internalize-symbols

2020-06-16 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D81959#2096616 , @arsenm wrote:

> Isn't the internalization implied by LTO? I thought part of the appeal of LTO 
> is killing this off


How does LTO know that the kernels need to be kept?


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

https://reviews.llvm.org/D81959



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


[PATCH] D78903: [Driver] Add option -fproc-stat-report

2020-06-16 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:3782
+  = Cmd.getProcessStatistics();
+  if (ProcStat) {
+if (PrintProcessStat) {

In the case where `!ProcStat`, I am wondering if we shouldn't emit zero values, 
in the report file at least. Otherwise if an invocation fails, it won't be 
there in the report and we might wonder why. Emitting 0 might indicate that 
something went wrong.



Comment at: clang/lib/Driver/Driver.cpp:3814
+  llvm::raw_fd_ostream OS(StatReportFile, EC, 
llvm::sys::fs::OF_Append);
+  if (!EC) {
+if (auto L = OS.tryToLock())

If the goal is to report accurate information, maybe it's worth looping here a 
bit in case of an error, to give the chance to other clang.exe instances to 
release the file lock? What do you think? (same for `tryToLock`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78903



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


[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

2020-06-16 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen updated this revision to Diff 271183.
cchen added a comment.

Fix Int64Ty issue (The bitNum of APInt I used before is 32)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/target_update_ast_print.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp

Index: clang/test/OpenMP/target_update_to_messages.cpp
===
--- clang/test/OpenMP/target_update_to_messages.cpp
+++ clang/test/OpenMP/target_update_to_messages.cpp
@@ -79,6 +79,10 @@
 #pragma omp target update to(*(*(this->ptr)+a+this->ptr)) // le45-error {{expected expression containing only member accesses and/or array sections based on named variables}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(*(this+this)) // expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}} expected-error {{invalid operands to binary expression ('S8 *' and 'S8 *')}}
 {}
+
+double marr[10][5][10];
+#pragma omp target update to(marr [0:] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+{}
   }
 };
 
Index: clang/test/OpenMP/target_update_messages.cpp
===
--- clang/test/OpenMP/target_update_messages.cpp
+++ clang/test/OpenMP/target_update_messages.cpp
@@ -1,6 +1,8 @@
-// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le45 -fopenmp -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le50 -fopenmp -fopenmp-version=50 -ferror-limit 100 %s -Wuninitialized
 
-// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le45 -fopenmp-simd -ferror-limit 100 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,le50 -fopenmp-simd -fopenmp-version=50 -ferror-limit 100 %s -Wuninitialized
 
 void xxx(int argc) {
   int x; // expected-note {{initialize the variable 'x' to silence this warning}}
@@ -36,5 +38,21 @@
   {
 foo();
   }
+
+  double marr[10][5][10];
+#pragma omp target update to(marr [0:] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+  {}
+#pragma omp target update from(marr [0:] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+
+  int arr[4][3][2][1];
+#pragma omp target update to(arr [0:2] [2:4][:2][1]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+  {}
+#pragma omp target update from(arr [0:2] [2:4][:2][1]) // le45-error {{array section does not specify contiguous storage}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+
+  double ***dptr;
+#pragma omp target update to(dptr [0:2] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le50-error 2 {{section length is unspecified and cannot be inferred because subscripted value is an array of unknown bound}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+  {}
+#pragma omp target update from(dptr [0:2] [2:4] [1:2]) // le45-error {{array section does not specify contiguous storage}} le50-error 2 {{section length is unspecified and cannot be inferred because subscripted value is an array of unknown bound}} le45-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+
   return tmain(argc, argv);
 }
Index: clang/test/OpenMP/target_update_codegen.cpp
===
--- clang/test/OpenMP/target_update_codegen.cpp
+++ clang/test/OpenMP/target_update_codegen.cpp
@@ -1059,5 +1059,283 @@
   #pragma omp target update from(([sa][5])f)
 }
 
+#endif
+
+///==///
+// RUN: %clang_cc1 -DCK19 -verify -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | 

[PATCH] D81953: [clang-tidy] warnings-as-error no longer exits with ErrorCount

2020-06-16 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

In D81953#2096388 , @aaron.ballman 
wrote:

> LGTM unless @jroelofs has a reason why the code was originally written that 
> way, but can you add test coverage for it?


How would you suggest I add test coverage for this, afaik llvm-lit doesn't seem 
to handle checking specific exit codes, only whether is was 0 or not. 
There are already test cases for a non-zero exit code with 
`-warnings-as-errors`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81953



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


[clang] 6e78a30 - [OPENMP50]Codegen for scan directive in for simd regions.

2020-06-16 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-06-16T16:13:27-04:00
New Revision: 6e78a3086a7f563cc55d2ba83a8697b3320857fb

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

LOG: [OPENMP50]Codegen for scan directive in for simd regions.

Summary:
Added codegen for scan directives in parallel for regions.

Emits the code for the directive with inscan reductions.
Original code:
```
 #pragma omp for simd reduction(inscan, op : ...)
for(...) {
  ;
  #pragma omp scan (in)exclusive(...)
  
}
```
is transformed to something:
```
size num_iters = ;
 buffer[num_iters];
 #pragma omp for simd
for (i: 0..) {
  ;
  buffer[i] = red;
}
 #pragma omp barrier
for (int k = 0; k != ceil(log2(num_iters)); ++k)
for (size cnt = last_iter; cnt >= pow(2, k); --k)
  buffer[i] op= buffer[i-pow(2,k)];
 #pragma omp for simd
for (0..) {
  red = InclusiveScan ? buffer[i] : buffer[i-1];
  ;
}
```

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin

Tags: #clang

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

Added: 
clang/test/OpenMP/for_simd_scan_codegen.cpp

Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 5b05577543fc..803e262bd8cd 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -3261,9 +3261,34 @@ void CodeGenFunction::EmitOMPForSimdDirective(const 
OMPForSimdDirective ) {
   bool HasLastprivates = false;
   auto & = [, ](CodeGenFunction ,
   PrePostActionTy &) {
-HasLastprivates = CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
- emitForLoopBounds,
- emitDispatchForLoopBounds);
+if (llvm::any_of(S.getClausesOfKind(),
+ [](const OMPReductionClause *C) {
+   return C->getModifier() == OMPC_REDUCTION_inscan;
+ })) {
+  const auto & = [](CodeGenFunction ) {
+OMPLocalDeclMapRAII Scope(CGF);
+OMPLoopScope LoopScope(CGF, S);
+return CGF.EmitScalarExpr(S.getNumIterations());
+  };
+  const auto & = [](CodeGenFunction ) {
+(void)CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
+ emitForLoopBounds,
+ emitDispatchForLoopBounds);
+// Emit an implicit barrier at the end.
+CGF.CGM.getOpenMPRuntime().emitBarrierCall(CGF, S.getBeginLoc(),
+   OMPD_for);
+  };
+  const auto & = [, ](CodeGenFunction ) {
+HasLastprivates = CGF.EmitOMPWorksharingLoop(S, 
S.getEnsureUpperBound(),
+ emitForLoopBounds,
+ 
emitDispatchForLoopBounds);
+  };
+  emitScanBasedDirective(CGF, S, NumIteratorsGen, FirstGen, SecondGen);
+} else {
+  HasLastprivates = CGF.EmitOMPWorksharingLoop(S, S.getEnsureUpperBound(),
+   emitForLoopBounds,
+   emitDispatchForLoopBounds);
+}
   };
   {
 auto LPCRegion =

diff  --git a/clang/test/OpenMP/for_simd_scan_codegen.cpp 
b/clang/test/OpenMP/for_simd_scan_codegen.cpp
new file mode 100644
index ..2c7f53a0aa36
--- /dev/null
+++ b/clang/test/OpenMP/for_simd_scan_codegen.cpp
@@ -0,0 +1,312 @@
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -std=c++11 -triple 
x86_64-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 
%s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -std=c++11 -triple 
x86_64-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck --check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+void foo();
+void bar();
+
+// CHECK: define void @{{.*}}baz{{.*}}(i32 %n)
+void baz(int n) {
+  static float a[10];
+  static double b;
+  // CHECK: call i8* @llvm.stacksave()
+  // CHECK: [[A_BUF_SIZE:%.+]] = mul nuw i64 10, 

[PATCH] D80758: [PowerPC] Add -m[no-]power10-vector clang and llvm option

2020-06-16 Thread Ahsan Saghir via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG37e72f47a41d: [PowerPC] Add -m[no-]power10-vector clang and 
llvm option (authored by saghir).

Changed prior to commit:
  https://reviews.llvm.org/D80758?vs=268893=271179#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80758

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/test/Driver/ppc-dependent-options.cpp
  clang/test/Driver/ppc-features.cpp
  llvm/lib/Target/PowerPC/PPC.td
  llvm/lib/Target/PowerPC/PPCSubtarget.cpp
  llvm/lib/Target/PowerPC/PPCSubtarget.h

Index: llvm/lib/Target/PowerPC/PPCSubtarget.h
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.h
+++ llvm/lib/Target/PowerPC/PPCSubtarget.h
@@ -105,6 +105,7 @@
   bool HasP8Crypto;
   bool HasP9Vector;
   bool HasP9Altivec;
+  bool HasP10Vector;
   bool HasPrefixInstrs;
   bool HasPCRelativeMemops;
   bool HasFCPSGN;
@@ -262,6 +263,7 @@
   bool hasP8Crypto() const { return HasP8Crypto; }
   bool hasP9Vector() const { return HasP9Vector; }
   bool hasP9Altivec() const { return HasP9Altivec; }
+  bool hasP10Vector() const { return HasP10Vector; }
   bool hasPrefixInstrs() const { return HasPrefixInstrs; }
   bool hasPCRelativeMemops() const { return HasPCRelativeMemops; }
   bool hasMFOCRF() const { return HasMFOCRF; }
Index: llvm/lib/Target/PowerPC/PPCSubtarget.cpp
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.cpp
+++ llvm/lib/Target/PowerPC/PPCSubtarget.cpp
@@ -78,6 +78,7 @@
   HasP8Crypto = false;
   HasP9Vector = false;
   HasP9Altivec = false;
+  HasP10Vector = false;
   HasPrefixInstrs = false;
   HasPCRelativeMemops = false;
   HasFCPSGN = false;
Index: llvm/lib/Target/PowerPC/PPC.td
===
--- llvm/lib/Target/PowerPC/PPC.td
+++ llvm/lib/Target/PowerPC/PPC.td
@@ -216,6 +216,10 @@
 "Enable POWER9 vector instructions",
 [FeatureISA3_0, FeatureP8Vector,
  FeatureP9Altivec]>;
+def FeatureP10Vector  : SubtargetFeature<"power10-vector", "HasP10Vector",
+ "true",
+ "Enable POWER10 vector instructions",
+ [FeatureISA3_1, FeatureP9Vector]>;
 // A separate feature for this even though it is equivalent to P9Vector
 // because this is a feature of the implementation rather than the architecture
 // and may go away with future CPU's.
@@ -337,7 +341,7 @@
   // still exist with the exception of those we know are Power9 specific.
   list P10AdditionalFeatures =
 [DirectivePwr10, FeatureISA3_1, FeaturePrefixInstrs,
- FeaturePCRelativeMemops];
+ FeaturePCRelativeMemops, FeatureP10Vector];
   list P10SpecificFeatures = [];
   list P10InheritableFeatures =
 !listconcat(P9InheritableFeatures, P10AdditionalFeatures);
Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -150,6 +150,12 @@
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-power8-vector -mpower8-vector -### -o %t.o 2>&1 | FileCheck -check-prefix=CHECK-P8VECTOR %s
 // CHECK-P8VECTOR: "-target-feature" "+power8-vector"
 
+// RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-power10-vector -### -o %t.o 2>&1 | FileCheck -check-prefix=CHECK-NOP10VECTOR %s
+// CHECK-NOP10VECTOR: "-target-feature" "-power10-vector"
+
+// RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-power10-vector -mpower10-vector -### -o %t.o 2>&1 | FileCheck -check-prefix=CHECK-P10VECTOR %s
+// CHECK-P10VECTOR: "-target-feature" "+power10-vector"
+
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-crbits -### -o %t.o 2>&1 | FileCheck -check-prefix=CHECK-NOCRBITS %s
 // CHECK-NOCRBITS: "-target-feature" "-crbits"
 
Index: clang/test/Driver/ppc-dependent-options.cpp
===
--- clang/test/Driver/ppc-dependent-options.cpp
+++ clang/test/Driver/ppc-dependent-options.cpp
@@ -58,6 +58,14 @@
 // RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 -mpower9-vector %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=CHECK-NVSX-MULTI
 
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power10 -std=c++11 %s 2>&1 | FileCheck %s \
+// RUN: -check-prefix=CHECK-DEFAULT-P10
+
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power10 -std=c++11 -mno-vsx -mpower10-vector %s 2>&1 | \
+// RUN: FileCheck %s -check-prefix=CHECK-NVSX-P10V
+
 #ifdef __VSX__
 static_assert(false, "VSX 

[PATCH] D81959: [HIP] Enable -amdgpu-internalize-symbols

2020-06-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

Isn't the internalization implied by LTO? I thought part of the appeal of LTO 
is killing this off


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

https://reviews.llvm.org/D81959



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


[PATCH] D81304: [llvm][SveEmitter] Emit the bfloat version of `svld1ro`.

2020-06-16 Thread Francesco Petrogalli via Phabricator via cfe-commits
fpetrogalli updated this revision to Diff 271178.
fpetrogalli marked 3 inline comments as done.
fpetrogalli added a comment.

Fix formatting issues, remove an unnecessary empty line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81304

Files:
  clang/include/clang/Basic/AArch64SVEACLETypes.def
  clang/include/clang/Basic/arm_sve.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/test/AST/ast-dump-aarch64-sve-types.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1ro-bfloat.c
  clang/unittests/AST/ASTImporterTest.cpp
  clang/unittests/AST/SizelessTypesTest.cpp
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -65,7 +65,7 @@
 
 class SVEType {
   TypeSpec TS;
-  bool Float, Signed, Immediate, Void, Constant, Pointer;
+  bool Float, Signed, Immediate, Void, Constant, Pointer, BFloat;
   bool DefaultType, IsScalable, Predicate, PredicatePattern, PrefetchOp;
   unsigned Bitwidth, ElementBitwidth, NumVectors;
 
@@ -74,9 +74,9 @@
 
   SVEType(TypeSpec TS, char CharMod)
   : TS(TS), Float(false), Signed(true), Immediate(false), Void(false),
-Constant(false), Pointer(false), DefaultType(false), IsScalable(true),
-Predicate(false), PredicatePattern(false), PrefetchOp(false),
-Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+Constant(false), Pointer(false), BFloat(false), DefaultType(false),
+IsScalable(true), Predicate(false), PredicatePattern(false),
+PrefetchOp(false), Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
 if (!TS.empty())
   applyTypespec();
 applyModifier(CharMod);
@@ -93,9 +93,11 @@
   bool isVoid() const { return Void & !Pointer; }
   bool isDefault() const { return DefaultType; }
   bool isFloat() const { return Float; }
-  bool isInteger() const { return !Float && !Predicate; }
+  bool isBFloat() const { return BFloat; }
+  bool isFloatingPoint() const { return Float || BFloat; }
+  bool isInteger() const { return !isFloatingPoint() && !Predicate; }
   bool isScalarPredicate() const {
-return !Float && Predicate && NumVectors == 0;
+return !isFloatingPoint() && Predicate && NumVectors == 0;
   }
   bool isPredicateVector() const { return Predicate; }
   bool isPredicatePattern() const { return PredicatePattern; }
@@ -362,7 +364,7 @@
 
   if (isVoidPointer())
 S += "v";
-  else if (!Float)
+  else if (!isFloatingPoint())
 switch (ElementBitwidth) {
 case 1: S += "b"; break;
 case 8: S += "c"; break;
@@ -372,15 +374,19 @@
 case 128: S += "LLLi"; break;
 default: llvm_unreachable("Unhandled case!");
 }
-  else
+  else if (isFloat())
 switch (ElementBitwidth) {
 case 16: S += "h"; break;
 case 32: S += "f"; break;
 case 64: S += "d"; break;
 default: llvm_unreachable("Unhandled case!");
 }
+  else if (isBFloat()) {
+assert(ElementBitwidth == 16 && "Not a valid BFloat.");
+S += "y";
+  }
 
-  if (!isFloat()) {
+  if (!isFloatingPoint()) {
 if ((isChar() || isPointer()) && !isVoidPointer()) {
   // Make chars and typed pointers explicitly signed.
   if (Signed)
@@ -421,13 +427,15 @@
   else {
 if (isScalableVector())
   S += "sv";
-if (!Signed && !Float)
+if (!Signed && !isFloatingPoint())
   S += "u";
 
 if (Float)
   S += "float";
 else if (isScalarPredicate() || isPredicateVector())
   S += "bool";
+else if (isBFloat())
+  S += "bfloat";
 else
   S += "int";
 
@@ -481,6 +489,10 @@
   Float = true;
   ElementBitwidth = 64;
   break;
+case 'b':
+  BFloat = true;
+  ElementBitwidth = 16;
+  break;
 default:
   llvm_unreachable("Unhandled type code!");
 }
@@ -534,6 +546,7 @@
   case 'P':
 Signed = true;
 Float = false;
+BFloat = false;
 Predicate = true;
 Bitwidth = 16;
 ElementBitwidth = 1;
@@ -784,7 +797,6 @@
   BaseTypeSpec(BT), Class(Class), Guard(Guard.str()),
   MergeSuffix(MergeSuffix.str()), BaseType(BT, 'd'), Flags(Flags),
   ImmChecks(Checks.begin(), Checks.end()) {
-
   // Types[0] is the return value.
   for (unsigned I = 0; I < Proto.size(); ++I) {
 SVEType T(BaseTypeSpec, Proto[I]);
@@ -848,6 +860,8 @@
   TypeCode = T.isSigned() ? 's' : 'u';
 else if (T.isPredicateVector())
   TypeCode = 'b';
+else if (T.isBFloat())
+  TypeCode = "bf";
 else
   TypeCode = 'f';
 Ret.replace(Pos, NumChars, TypeCode + utostr(T.getElementSizeInBits()));
@@ -923,6 +937,11 @@
 }
   }
 
+  if (T.isBFloat()) {
+assert(T.getElementSizeInBits() == 16 && "Not a valid BFloat.");
+return encodeEltType("EltTyBFloat16");
+  }
+
   

[PATCH] D81951: [OPENMP]Fix PR46347: several ordered directives in a single region.

2020-06-16 Thread Alexey Bataev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3488e8c21cec: [OPENMP]Fix PR46347: several ordered 
directives in a single region. (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81951

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/ordered_messages.cpp

Index: clang/test/OpenMP/ordered_messages.cpp
===
--- clang/test/OpenMP/ordered_messages.cpp
+++ clang/test/OpenMP/ordered_messages.cpp
@@ -61,6 +61,17 @@
   foo();
 }
   }
+  #pragma omp for ordered
+  for (int i = 0; i < 10; ++i) {
+#pragma omp ordered // expected-note {{previous 'ordered' directive used here}}
+{
+  foo();
+}
+#pragma omp ordered // expected-error {{exactly one 'ordered' directive must appear in the loop body of an enclosing directive}}
+{
+  foo();
+}
+  }
   #pragma omp ordered simd simd // expected-error {{directive '#pragma omp ordered' cannot contain more than one 'simd' clause}}
   {
 foo();
@@ -79,7 +90,18 @@
   foo();
 }
   }
-  #pragma omp for simd
+  #pragma omp simd
+  for (int i = 0; i < 10; ++i) {
+#pragma omp ordered simd // expected-note {{previous 'ordered' directive used here}}
+{
+  foo();
+}
+#pragma omp ordered simd // expected-error {{exactly one 'ordered' directive must appear in the loop body of an enclosing directive}}
+{
+  foo();
+}
+  }
+#pragma omp for simd
   for (int i = 0; i < 10; ++i) {
 #pragma omp ordered // expected-error {{OpenMP constructs may not be nested inside a simd region}}
 {
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -169,6 +169,7 @@
 bool LoopStart = false;
 bool BodyComplete = false;
 SourceLocation PrevScanLocation;
+SourceLocation PrevOrderedLocation;
 SourceLocation InnerTeamsRegionLoc;
 /// Reference to the taskgroup task_reduction reference expression.
 Expr *TaskgroupReductionRef = nullptr;
@@ -848,6 +849,21 @@
 const SharingMapTy *Top = getSecondOnStackOrNull();
 return Top ? Top->PrevScanLocation : SourceLocation();
   }
+  /// Mark that parent region already has ordered directive.
+  void setParentHasOrderedDirective(SourceLocation Loc) {
+if (SharingMapTy *Parent = getSecondOnStackOrNull())
+  Parent->PrevOrderedLocation = Loc;
+  }
+  /// Return true if current region has inner ordered construct.
+  bool doesParentHasOrderedDirective() const {
+const SharingMapTy *Top = getSecondOnStackOrNull();
+return Top ? Top->PrevOrderedLocation.isValid() : false;
+  }
+  /// Returns the location of the previously specified ordered directive.
+  SourceLocation getParentOrderedDirectiveLoc() const {
+const SharingMapTy *Top = getSecondOnStackOrNull();
+return Top ? Top->PrevOrderedLocation : SourceLocation();
+  }
 
   /// Set collapse value for the region.
   void setAssociatedLoops(unsigned Val) {
@@ -9187,9 +9203,10 @@
   // Check that only one instance of scan directives is used in the same outer
   // region.
   if (DSAStack->doesParentHasScanDirective()) {
-Diag(StartLoc, diag::err_omp_several_scan_directives_in_region);
+Diag(StartLoc, diag::err_omp_several_directives_in_region) << "scan";
 Diag(DSAStack->getParentScanDirectiveLoc(),
- diag::note_omp_previous_scan_directive);
+ diag::note_omp_previous_directive)
+<< "scan";
 return StmtError();
   }
   DSAStack->setParentHasScanDirective(StartLoc);
@@ -9265,6 +9282,22 @@
   if ((!AStmt && !DependFound) || ErrorFound)
 return StmtError();
 
+  // OpenMP 5.0, 2.17.9, ordered Construct, Restrictions.
+  // During execution of an iteration of a worksharing-loop or a loop nest
+  // within a worksharing-loop, simd, or worksharing-loop SIMD region, a thread
+  // must not execute more than one ordered region corresponding to an ordered
+  // construct without a depend clause.
+  if (!DependFound) {
+if (DSAStack->doesParentHasOrderedDirective()) {
+  Diag(StartLoc, diag::err_omp_several_directives_in_region) << "ordered";
+  Diag(DSAStack->getParentOrderedDirectiveLoc(),
+   diag::note_omp_previous_directive)
+  << "ordered";
+  return StmtError();
+}
+DSAStack->setParentHasOrderedDirective(StartLoc);
+  }
+
   if (AStmt) {
 assert(isa(AStmt) && "Captured statement expected");
 
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9937,10 +9937,10 @@
   "cannot nest 'critical' regions having the same name %0">;
 def 

[PATCH] D81304: [llvm][SveEmitter] Emit the bfloat version of `svld1ro`.

2020-06-16 Thread Francesco Petrogalli via Phabricator via cfe-commits
fpetrogalli added inline comments.



Comment at: clang/include/clang/Basic/AArch64SVEACLETypes.def:44
 #define SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId, NumEls, ElBits,
\
-IsSigned, IsFP)
\
+IsSigned, IsFP, IsBF)\
   SVE_TYPE(Name, Id, SingletonId)

sdesmalen wrote:
> nit: odd formatting (of the last `\`), did you use clang-format?
Yes, but `def` files are left untouched. I fixed it.



Comment at: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ld1ro-bfloat.c:1
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE_MATMUL_FP64 
-D__ARM_FEATURE_BF16_SCALAR_ARITHMETIC -D__ARM_FEATURE_SVE -triple 
aarch64-none-linux-gnu -target-feature +sve -target-feature +bf16 
-fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE_MATMUL_FP64 
-D__ARM_FEATURE_BF16_SCALAR_ARITHMETIC -D__ARM_FEATURE_SVE 
-DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve 
-target-feature +bf16 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall 
-emit-llvm -o - %s | FileCheck %s

sdesmalen wrote:
> stuij wrote:
> > There should be no dependency on `-fallow-half-arguments-and-returns`. For 
> > bfloat we should use `-mfloat-abi hard`. Does this work for `-mfloat-abi 
> > softfp`?
> `-fallow-half-arguments-and-returns` isn't strictly needed for this test, we 
> just use the same RUN line for all the ACLE tests and we needed this for 
> `__fp16` in some of the tests.
> 
> I don't believe that `-mfloat-abi softfp` is supported for AArch64.
@stuij - the following lines work, one with `softfp` and one with `hard`:

```
// RUN: %clang_cc1 -D__ARM_FEATURE_SVE_MATMUL_FP64 
-D__ARM_FEATURE_BF16_SCALAR_ARITHMETIC -D__ARM_FEATURE_SVE 
-DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve 
-target\
-feature +bf16 -mfloat-abi softfp -fallow-half-arguments-and-returns -S -O1 
-Werror -Wall -emit-llvm -o - %s | FileCheck %s
// RUN: %clang_cc1 -D__ARM_FEATURE_SVE_MATMUL_FP64 
-D__ARM_FEATURE_BF16_SCALAR_ARITHMETIC -D__ARM_FEATURE_SVE 
-DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve 
-target\
-feature +bf16 -mfloat-abi hard -fallow-half-arguments-and-returns -S -O1 
-Werror -Wall -emit-llvm -o - %s | FileCheck %s
```

@sdesmalen I am not an experer here, but there is a test which targets aarch64 
that uses `softfp` (see `clang/test/CodeGen/arm-bf16-params-returns.c`). The 
following line in that test clearly targets `aarch64`:

```
// RUN: %clang_cc1 -triple aarch64-arm-none-eabi -target-abi aapcs -mfloat-abi 
softfp -target-feature +bf16 -target-feature +neon -emit-llvm -O2 -o - %s | opt 
-S -mem2reg -sroa | FileCheck %s \
--check-prefix=CHECK64-SOFTFP
```

@both - should I update the test with the two extra RUN lines mentioned up in 
the message?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81304



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


[PATCH] D81964: [clangd] Make use of preamble bounds from the patch inside ReplayPreamble

2020-06-16 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Clangd was using bounds from the stale preamble, which might result in
crashes. For example:

  #include "a.h"
  #include "b.h" // this line is newly inserted
  #include "c.h"

PreambleBounds for the baseline only contains first two lines, but
ReplayPreamble logic contains an include from the third line. This would
result in a crash as we only lex preamble part of the current file
during ReplayPreamble.

This patch adds a `preambleBounds` method to PreamblePatch, which can be
used to figure out preamble bounds for the current version of the file.
Then uses it when attaching ReplayPreamble, so that it can lex the
up-to-date preamble region.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81964

Files:
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -488,6 +488,51 @@
   EXPECT_EQ(DecompLoc.first, SM.getMainFileID());
   EXPECT_EQ(SM.getLineNumber(DecompLoc.first, DecompLoc.second), 3U);
 }
+
+TEST(PreamblePatch, ModifiedBounds) {
+  struct {
+llvm::StringLiteral Baseline;
+llvm::StringLiteral Modified;
+  } Cases[] = {
+  // Size increased
+  {
+  "",
+  R"cpp(
+#define FOO
+FOO)cpp",
+  },
+  // Stayed same
+  {"#define FOO", "#define BAR"},
+  // Got smaller
+  {
+  R"cpp(
+#define FOO
+#undef FOO)cpp",
+  "#define FOO"},
+  };
+
+  for (const auto  : Cases) {
+auto TU = TestTU::withCode(Case.Baseline);
+auto BaselinePreamble = TU.preamble();
+ASSERT_TRUE(BaselinePreamble);
+
+Annotations Modified(Case.Modified);
+TU.Code = Modified.code().str();
+MockFSProvider FSProvider;
+auto PP = PreamblePatch::create(testPath(TU.Filename),
+TU.inputs(FSProvider), *BaselinePreamble);
+
+IgnoreDiagnostics Diags;
+auto CI = buildCompilerInvocation(TU.inputs(FSProvider), Diags);
+ASSERT_TRUE(CI);
+
+const auto ExpectedBounds =
+Lexer::ComputePreamble(Case.Modified, *CI->getLangOpts());
+EXPECT_EQ(PP.preambleBounds().Size, ExpectedBounds.Size);
+EXPECT_EQ(PP.preambleBounds().PreambleEndsAtStartOfLine,
+  ExpectedBounds.PreambleEndsAtStartOfLine);
+  }
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
+++ clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
@@ -444,24 +444,76 @@
 EXPECT_EQ(SkippedFiles[I].kind(), tok::header_name);
   }
 
+  TU.AdditionalFiles["a.h"] = "";
+  TU.AdditionalFiles["b.h"] = "";
+  TU.AdditionalFiles["c.h"] = "";
   // Make sure replay logic works with patched preambles.
-  TU.Code = "";
-  StoreDiags Diags;
+  llvm::StringLiteral Baseline = R"cpp(
+#include "a.h"
+#include "c.h")cpp";
   MockFSProvider FS;
+  TU.Code = Baseline.str();
   auto Inputs = TU.inputs(FS);
-  auto CI = buildCompilerInvocation(Inputs, Diags);
-  auto EmptyPreamble =
-  buildPreamble(testPath(TU.Filename), *CI, Inputs, true, nullptr);
-  ASSERT_TRUE(EmptyPreamble);
-  TU.Code = "#include ";
+  auto BaselinePreamble = TU.preamble();
+  ASSERT_TRUE(BaselinePreamble);
+
+  // First make sure we don't crash on various modifications to the preamble.
+  llvm::StringLiteral Cases[] = {
+  // clang-format off
+  // New include in middle.
+  R"cpp(
+#include "a.h"
+#include "b.h"
+#include "c.h")cpp",
+  // New include at top.
+  R"cpp(
+#include "b.h"
+#include "a.h"
+#include "c.h")cpp",
+  // New include at bottom.
+  R"cpp(
+#include "a.h"
+#include "c.h"
+#include "b.h")cpp",
+  // Same size with a missing include.
+  R"cpp(
+#include "a.h"
+#include "b.h")cpp",
+  // Smaller with no new includes.
+  R"cpp(
+#include "a.h")cpp",
+  // Smaller with a new includes.
+  R"cpp(
+#include "b.h")cpp",
+  // clang-format on
+  };
+  for (llvm::StringLiteral Case : Cases) {
+TU.Code = Case.str();
+
+IgnoreDiagnostics Diags;
+auto CI = buildCompilerInvocation(TU.inputs(FS), Diags);
+auto PatchedAST = ParsedAST::build(testPath(TU.Filename), TU.inputs(FS),
+   

[PATCH] D81718: [Analyzer][NFC] Add methods `getReturnObject()` and `getArgObject()` to `CallEvent`

2020-06-16 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ requested changes to this revision.
NoQ added a comment.
This revision now requires changes to proceed.

In D81718#2095965 , 
@baloghadamsoftware wrote:

> Your test case unfortunately does not test what you want, because raw 
> pointers are not supported yet


It tests exactly what i want: the correctness of your code in //this very 
patch// that was written to handle //this very case// for which you never even 
bothered figuring out the correct solution but you already wrote //a large 
amount of code// (including some code in this patch) //with zero test 
coverage// to demonstrate correctness of your solution.

As of now you wrote your new two functions to return some value in every case. 
However, only some of these cases are covered with tests; in other cases the 
value was basically chosen randomly. The way you added unittests in order to 
make sure this completely random value stays random rather than correct doesn't 
count as testing.

In D81718#2096020 , 
@baloghadamsoftware wrote:

> What is the correct solution then? To put branches all over the code of the 
> checkers? Surely not.


That's literally how test-driven development works. First you write tests, then 
you write any code that covers them, and //only then// you figure out how to 
reuse code. This is because correctness is completely orthogonal to prettiness; 
arguing that my solution is incorrect "because it's ugly" is ridiculous. This 
is why test-driven development recommends starting with a correct-but-ugly 
solution, not with an incorrect-but-pretty solution: first you figure out how 
to solve the problem at all, then refactor.

I will not discuss this further unless all the dead code that you're 
refactoring is either covered with LIT tests or removed.


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

https://reviews.llvm.org/D81718



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


[clang] 8d4a806 - Revert "remove gold linker"

2020-06-16 Thread Yuanfang Chen via cfe-commits

Author: Yuanfang Chen
Date: 2020-06-16T13:05:53-07:00
New Revision: 8d4a806ef0b988200111b7d99f792361bcd3f7d1

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

LOG: Revert "remove gold linker"

This reverts commit 719c87edc58018a0e9f3ee04305e081d4b582c2b.

Checked in by accident. Sorry.

Added: 


Modified: 
clang/lib/Driver/ToolChains/PS4CPU.cpp
clang/test/Driver/ps4-linker-non-win.c
clang/test/Driver/ps4-linker-win.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/PS4CPU.cpp 
b/clang/lib/Driver/ToolChains/PS4CPU.cpp
index 379b88017b0e..ebeed3803e06 100644
--- a/clang/lib/Driver/ToolChains/PS4CPU.cpp
+++ b/clang/lib/Driver/ToolChains/PS4CPU.cpp
@@ -88,13 +88,13 @@ void tools::PS4cpu::addSanitizerArgs(const ToolChain ,
 CmdArgs.push_back("--dependent-lib=libSceDbgAddressSanitizer_stub_weak.a");
 }
 
-void tools::PS4cpu::Link::ConstructJob(Compilation , const JobAction ,
-   const InputInfo ,
-   const InputInfoList ,
-   const ArgList ,
-   const char *LinkingOutput) const {
+static void ConstructPS4LinkJob(const Tool , Compilation ,
+const JobAction , const InputInfo ,
+const InputInfoList ,
+const ArgList ,
+const char *LinkingOutput) {
   const toolchains::FreeBSD  =
-  static_cast(getToolChain());
+  static_cast(T.getToolChain());
   const Driver  = ToolChain.getDriver();
   ArgStringList CmdArgs;
 
@@ -143,17 +143,216 @@ void tools::PS4cpu::Link::ConstructJob(Compilation , 
const JobAction ,
 CmdArgs.push_back("-lpthread");
   }
 
-  if (Args.hasArg(options::OPT_fuse_ld_EQ)) {
-D.Diag(diag::err_drv_unsupported_opt_for_target)
-<< "-fuse-ld" << getToolChain().getTriple().str();
+  const char *Exec = Args.MakeArgString(ToolChain.GetProgramPath("orbis-ld"));
+
+  C.addCommand(std::make_unique(JA, T, Exec, CmdArgs, Inputs));
+}
+
+static void ConstructGoldLinkJob(const Tool , Compilation ,
+ const JobAction , const InputInfo ,
+ const InputInfoList ,
+ const ArgList ,
+ const char *LinkingOutput) {
+  const toolchains::FreeBSD  =
+  static_cast(T.getToolChain());
+  const Driver  = ToolChain.getDriver();
+  ArgStringList CmdArgs;
+
+  // Silence warning for "clang -g foo.o -o foo"
+  Args.ClaimAllArgs(options::OPT_g_Group);
+  // and "clang -emit-llvm foo.o -o foo"
+  Args.ClaimAllArgs(options::OPT_emit_llvm);
+  // and for "clang -w foo.o -o foo". Other warning options are already
+  // handled somewhere else.
+  Args.ClaimAllArgs(options::OPT_w);
+
+  if (!D.SysRoot.empty())
+CmdArgs.push_back(Args.MakeArgString("--sysroot=" + D.SysRoot));
+
+  if (Args.hasArg(options::OPT_pie))
+CmdArgs.push_back("-pie");
+
+  if (Args.hasArg(options::OPT_static)) {
+CmdArgs.push_back("-Bstatic");
+  } else {
+if (Args.hasArg(options::OPT_rdynamic))
+  CmdArgs.push_back("-export-dynamic");
+CmdArgs.push_back("--eh-frame-hdr");
+if (Args.hasArg(options::OPT_shared)) {
+  CmdArgs.push_back("-Bshareable");
+} else {
+  CmdArgs.push_back("-dynamic-linker");
+  CmdArgs.push_back("/libexec/ld-elf.so.1");
+}
+CmdArgs.push_back("--enable-new-dtags");
+  }
+
+  if (Output.isFilename()) {
+CmdArgs.push_back("-o");
+CmdArgs.push_back(Output.getFilename());
+  } else {
+assert(Output.isNothing() && "Invalid output.");
+  }
+
+  if(!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs))
+AddPS4SanitizerArgs(ToolChain, CmdArgs);
+
+  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
+const char *crt1 = nullptr;
+if (!Args.hasArg(options::OPT_shared)) {
+  if (Args.hasArg(options::OPT_pg))
+crt1 = "gcrt1.o";
+  else if (Args.hasArg(options::OPT_pie))
+crt1 = "Scrt1.o";
+  else
+crt1 = "crt1.o";
+}
+if (crt1)
+  CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath(crt1)));
+
+CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crti.o")));
+
+const char *crtbegin = nullptr;
+if (Args.hasArg(options::OPT_static))
+  crtbegin = "crtbeginT.o";
+else if (Args.hasArg(options::OPT_shared) || Args.hasArg(options::OPT_pie))
+  crtbegin = "crtbeginS.o";
+else
+  crtbegin = "crtbegin.o";
+
+CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath(crtbegin)));
+  }
+
+  Args.AddAllArgs(CmdArgs, options::OPT_L);
+  ToolChain.AddFilePathLibArgs(Args, CmdArgs);
+  

[clang] 8c6c606 - [Clang] Add a "#pragma unroll" test case for correct error reporting

2020-06-16 Thread Yuanfang Chen via cfe-commits

Author: Yuanfang Chen
Date: 2020-06-16T13:03:32-07:00
New Revision: 8c6c606cdc72c3ddd55f382d91ef1afc3cb9f2a8

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

LOG: [Clang] Add a "#pragma unroll" test case for correct error reporting

For PR46336.

Added: 


Modified: 
clang/test/Parser/pragma-unroll.cpp

Removed: 




diff  --git a/clang/test/Parser/pragma-unroll.cpp 
b/clang/test/Parser/pragma-unroll.cpp
index fb713812877e..c89cf49a0020 100644
--- a/clang/test/Parser/pragma-unroll.cpp
+++ b/clang/test/Parser/pragma-unroll.cpp
@@ -55,6 +55,15 @@ void test(int *List, int Length) {
 #pragma nounroll
 /* expected-error {{expected a for, while, or do-while loop to follow '#pragma 
nounroll'}} */ int l = Length;
 
+  switch (i) {
+  case 1:
+#pragma unroll
+/* expected-error {{expected a for, while, or do-while loop to follow '#pragma 
unroll'}} */ [[fallthrough]];
+  case 2:
+for (int i = 0; i < 10; ++i);
+break;
+  }
+
 #pragma unroll 4
 /* expected-error {{incompatible directives 'unroll(disable)' and '#pragma 
unroll(4)'}} */ #pragma clang loop unroll(disable)
   while (i-10 < Length) {



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


[clang] 719c87e - remove gold linker

2020-06-16 Thread Yuanfang Chen via cfe-commits

Author: Yuanfang Chen
Date: 2020-06-16T13:03:31-07:00
New Revision: 719c87edc58018a0e9f3ee04305e081d4b582c2b

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

LOG: remove gold linker

Added: 


Modified: 
clang/lib/Driver/ToolChains/PS4CPU.cpp
clang/test/Driver/ps4-linker-non-win.c
clang/test/Driver/ps4-linker-win.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/PS4CPU.cpp 
b/clang/lib/Driver/ToolChains/PS4CPU.cpp
index ebeed3803e06..379b88017b0e 100644
--- a/clang/lib/Driver/ToolChains/PS4CPU.cpp
+++ b/clang/lib/Driver/ToolChains/PS4CPU.cpp
@@ -88,13 +88,13 @@ void tools::PS4cpu::addSanitizerArgs(const ToolChain ,
 CmdArgs.push_back("--dependent-lib=libSceDbgAddressSanitizer_stub_weak.a");
 }
 
-static void ConstructPS4LinkJob(const Tool , Compilation ,
-const JobAction , const InputInfo ,
-const InputInfoList ,
-const ArgList ,
-const char *LinkingOutput) {
+void tools::PS4cpu::Link::ConstructJob(Compilation , const JobAction ,
+   const InputInfo ,
+   const InputInfoList ,
+   const ArgList ,
+   const char *LinkingOutput) const {
   const toolchains::FreeBSD  =
-  static_cast(T.getToolChain());
+  static_cast(getToolChain());
   const Driver  = ToolChain.getDriver();
   ArgStringList CmdArgs;
 
@@ -143,216 +143,17 @@ static void ConstructPS4LinkJob(const Tool , 
Compilation ,
 CmdArgs.push_back("-lpthread");
   }
 
-  const char *Exec = Args.MakeArgString(ToolChain.GetProgramPath("orbis-ld"));
-
-  C.addCommand(std::make_unique(JA, T, Exec, CmdArgs, Inputs));
-}
-
-static void ConstructGoldLinkJob(const Tool , Compilation ,
- const JobAction , const InputInfo ,
- const InputInfoList ,
- const ArgList ,
- const char *LinkingOutput) {
-  const toolchains::FreeBSD  =
-  static_cast(T.getToolChain());
-  const Driver  = ToolChain.getDriver();
-  ArgStringList CmdArgs;
-
-  // Silence warning for "clang -g foo.o -o foo"
-  Args.ClaimAllArgs(options::OPT_g_Group);
-  // and "clang -emit-llvm foo.o -o foo"
-  Args.ClaimAllArgs(options::OPT_emit_llvm);
-  // and for "clang -w foo.o -o foo". Other warning options are already
-  // handled somewhere else.
-  Args.ClaimAllArgs(options::OPT_w);
-
-  if (!D.SysRoot.empty())
-CmdArgs.push_back(Args.MakeArgString("--sysroot=" + D.SysRoot));
-
-  if (Args.hasArg(options::OPT_pie))
-CmdArgs.push_back("-pie");
-
-  if (Args.hasArg(options::OPT_static)) {
-CmdArgs.push_back("-Bstatic");
-  } else {
-if (Args.hasArg(options::OPT_rdynamic))
-  CmdArgs.push_back("-export-dynamic");
-CmdArgs.push_back("--eh-frame-hdr");
-if (Args.hasArg(options::OPT_shared)) {
-  CmdArgs.push_back("-Bshareable");
-} else {
-  CmdArgs.push_back("-dynamic-linker");
-  CmdArgs.push_back("/libexec/ld-elf.so.1");
-}
-CmdArgs.push_back("--enable-new-dtags");
-  }
-
-  if (Output.isFilename()) {
-CmdArgs.push_back("-o");
-CmdArgs.push_back(Output.getFilename());
-  } else {
-assert(Output.isNothing() && "Invalid output.");
-  }
-
-  if(!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs))
-AddPS4SanitizerArgs(ToolChain, CmdArgs);
-
-  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
-const char *crt1 = nullptr;
-if (!Args.hasArg(options::OPT_shared)) {
-  if (Args.hasArg(options::OPT_pg))
-crt1 = "gcrt1.o";
-  else if (Args.hasArg(options::OPT_pie))
-crt1 = "Scrt1.o";
-  else
-crt1 = "crt1.o";
-}
-if (crt1)
-  CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath(crt1)));
-
-CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crti.o")));
-
-const char *crtbegin = nullptr;
-if (Args.hasArg(options::OPT_static))
-  crtbegin = "crtbeginT.o";
-else if (Args.hasArg(options::OPT_shared) || Args.hasArg(options::OPT_pie))
-  crtbegin = "crtbeginS.o";
-else
-  crtbegin = "crtbegin.o";
-
-CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath(crtbegin)));
-  }
-
-  Args.AddAllArgs(CmdArgs, options::OPT_L);
-  ToolChain.AddFilePathLibArgs(Args, CmdArgs);
-  Args.AddAllArgs(CmdArgs, options::OPT_T_Group);
-  Args.AddAllArgs(CmdArgs, options::OPT_e);
-  Args.AddAllArgs(CmdArgs, options::OPT_s);
-  Args.AddAllArgs(CmdArgs, options::OPT_t);
-  Args.AddAllArgs(CmdArgs, options::OPT_r);
-
-  if (Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
-

[clang] 3488e8c - [OPENMP]Fix PR46347: several ordered directives in a single region.

2020-06-16 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-06-16T15:53:14-04:00
New Revision: 3488e8c21cec8bac7dabd8f6b7c642dbace31d65

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

LOG: [OPENMP]Fix PR46347: several ordered directives in a single region.

Summary:
According to OpenMP, During execution of an iteration of a worksharing-loop or 
a loop nest within a worksharing-loop, simd, or worksharing-loop SIMD region, a 
thread must not execute more than one ordered region corresponding to an 
ordered construct without a depend clause.
Need to report an error in this case.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaOpenMP.cpp
clang/test/OpenMP/ordered_messages.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index b0a6184906c2..52fc40771228 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9937,10 +9937,10 @@ def err_omp_prohibited_region_critical_same_name : 
Error<
   "cannot nest 'critical' regions having the same name %0">;
 def note_omp_previous_critical_region : Note<
   "previous 'critical' region starts here">;
-def err_omp_several_scan_directives_in_region : Error<
-  "exactly one 'scan' directive must appear in the loop body of an enclosing 
directive">;
-def note_omp_previous_scan_directive : Note<
-  "previous 'scan' directive used here">;
+def err_omp_several_directives_in_region : Error<
+  "exactly one '%0' directive must appear in the loop body of an enclosing 
directive">;
+def note_omp_previous_directive : Note<
+  "previous '%0' directive used here">;
 def err_omp_sections_not_compound_stmt : Error<
   "the statement for '#pragma omp sections' must be a compound statement">;
 def err_omp_parallel_sections_not_compound_stmt : Error<

diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 68b3ba930c46..f2b29e6356c1 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -169,6 +169,7 @@ class DSAStackTy {
 bool LoopStart = false;
 bool BodyComplete = false;
 SourceLocation PrevScanLocation;
+SourceLocation PrevOrderedLocation;
 SourceLocation InnerTeamsRegionLoc;
 /// Reference to the taskgroup task_reduction reference expression.
 Expr *TaskgroupReductionRef = nullptr;
@@ -848,6 +849,21 @@ class DSAStackTy {
 const SharingMapTy *Top = getSecondOnStackOrNull();
 return Top ? Top->PrevScanLocation : SourceLocation();
   }
+  /// Mark that parent region already has ordered directive.
+  void setParentHasOrderedDirective(SourceLocation Loc) {
+if (SharingMapTy *Parent = getSecondOnStackOrNull())
+  Parent->PrevOrderedLocation = Loc;
+  }
+  /// Return true if current region has inner ordered construct.
+  bool doesParentHasOrderedDirective() const {
+const SharingMapTy *Top = getSecondOnStackOrNull();
+return Top ? Top->PrevOrderedLocation.isValid() : false;
+  }
+  /// Returns the location of the previously specified ordered directive.
+  SourceLocation getParentOrderedDirectiveLoc() const {
+const SharingMapTy *Top = getSecondOnStackOrNull();
+return Top ? Top->PrevOrderedLocation : SourceLocation();
+  }
 
   /// Set collapse value for the region.
   void setAssociatedLoops(unsigned Val) {
@@ -9187,9 +9203,10 @@ StmtResult 
Sema::ActOnOpenMPScanDirective(ArrayRef Clauses,
   // Check that only one instance of scan directives is used in the same outer
   // region.
   if (DSAStack->doesParentHasScanDirective()) {
-Diag(StartLoc, diag::err_omp_several_scan_directives_in_region);
+Diag(StartLoc, diag::err_omp_several_directives_in_region) << "scan";
 Diag(DSAStack->getParentScanDirectiveLoc(),
- diag::note_omp_previous_scan_directive);
+ diag::note_omp_previous_directive)
+<< "scan";
 return StmtError();
   }
   DSAStack->setParentHasScanDirective(StartLoc);
@@ -9265,6 +9282,22 @@ StmtResult 
Sema::ActOnOpenMPOrderedDirective(ArrayRef Clauses,
   if ((!AStmt && !DependFound) || ErrorFound)
 return StmtError();
 
+  // OpenMP 5.0, 2.17.9, ordered Construct, Restrictions.
+  // During execution of an iteration of a worksharing-loop or a loop nest
+  // within a worksharing-loop, simd, or worksharing-loop SIMD region, a thread
+  // must not execute more than one ordered region corresponding to an ordered
+  // construct without a depend clause.
+  if (!DependFound) {
+if (DSAStack->doesParentHasOrderedDirective()) {
+  Diag(StartLoc, 

[clang] 37e72f4 - [PowerPC] Add -m[no-]power10-vector clang and llvm option

2020-06-16 Thread Ahsan Saghir via cfe-commits

Author: Ahsan Saghir
Date: 2020-06-16T14:47:35-05:00
New Revision: 37e72f47a41d83bd2509798a304f2f30ae094488

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

LOG: [PowerPC] Add -m[no-]power10-vector clang and llvm option

Summary: This patch adds command line option for enabling power10-vector 
support.

Reviewers: hfinkel, nemanjai, lei, amyk, #powerpc

Reviewed By: lei, amyk, #powerpc

Subscribers: wuzish, kbarton, hiraditya, shchenz, cfe-commits, llvm-commits

Tags: #llvm, #clang, #powerpc

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Basic/Targets/PPC.cpp
clang/lib/Basic/Targets/PPC.h
clang/test/Driver/ppc-dependent-options.cpp
clang/test/Driver/ppc-features.cpp
llvm/lib/Target/PowerPC/PPC.td
llvm/lib/Target/PowerPC/PPCSubtarget.cpp
llvm/lib/Target/PowerPC/PPCSubtarget.h

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 1f4fea9a0be5..d8de2a5ae475 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2385,6 +2385,10 @@ def mpower9_vector : Flag<["-"], "mpower9-vector">,
 Group;
 def mno_power9_vector : Flag<["-"], "mno-power9-vector">,
 Group;
+def mpower10_vector : Flag<["-"], "mpower10-vector">,
+Group;
+def mno_power10_vector : Flag<["-"], "mno-power10-vector">,
+Group;
 def mpower8_crypto : Flag<["-"], "mcrypto">,
 Group;
 def mnopower8_crypto : Flag<["-"], "mno-crypto">,

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 230548d06caa..f0de2bf070ea 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -54,6 +54,8 @@ bool 
PPCTargetInfo::handleTargetFeatures(std::vector ,
   HasFloat128 = true;
 } else if (Feature == "+power9-vector") {
   HasP9Vector = true;
+} else if (Feature == "+power10-vector") {
+  HasP10Vector = true;
 } else if (Feature == "+pcrelative-memops") {
   HasPCRelativeMemops = true;
 } else if (Feature == "+spe") {
@@ -193,6 +195,8 @@ void PPCTargetInfo::getTargetDefines(const LangOptions 
,
 Builder.defineMacro("__FLOAT128__");
   if (HasP9Vector)
 Builder.defineMacro("__POWER9_VECTOR__");
+  if (HasP10Vector)
+Builder.defineMacro("__POWER10_VECTOR__");
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
@@ -227,6 +231,7 @@ void PPCTargetInfo::getTargetDefines(const LangOptions 
,
 // - direct-move
 // - float128
 // - power9-vector
+// - power10-vector
 // then go ahead and error since the customer has expressed an incompatible
 // set of options.
 static bool ppcUserFeaturesCheck(DiagnosticsEngine ,
@@ -248,6 +253,7 @@ static bool ppcUserFeaturesCheck(DiagnosticsEngine ,
   Found |= FindVSXSubfeature("+direct-move", "-mdirect-move");
   Found |= FindVSXSubfeature("+float128", "-mfloat128");
   Found |= FindVSXSubfeature("+power9-vector", "-mpower9-vector");
+  Found |= FindVSXSubfeature("+power10-vector", "-mpower10-vector");
 
   // Return false if any vsx subfeatures was found.
   return !Found;
@@ -348,6 +354,7 @@ bool PPCTargetInfo::initFeatureMap(
 void PPCTargetInfo::addP10SpecificFeatures(
 llvm::StringMap ) const {
   Features["htm"] = false; // HTM was removed for P10.
+  Features["power10-vector"] = true;
   Features["pcrelative-memops"] = true;
   return;
 }
@@ -372,6 +379,7 @@ bool PPCTargetInfo::hasFeature(StringRef Feature) const {
   .Case("extdiv", HasExtDiv)
   .Case("float128", HasFloat128)
   .Case("power9-vector", HasP9Vector)
+  .Case("power10-vector", HasP10Vector)
   .Case("pcrelative-memops", HasPCRelativeMemops)
   .Case("spe", HasSPE)
   .Default(false);
@@ -387,12 +395,15 @@ void 
PPCTargetInfo::setFeatureEnabled(llvm::StringMap ,
  .Case("direct-move", true)
  .Case("power8-vector", true)
  .Case("power9-vector", true)
+ .Case("power10-vector", true)
  .Case("float128", true)
  .Default(false);
 if (FeatureHasVSX)
   Features["vsx"] = Features["altivec"] = true;
 if (Name == "power9-vector")
   Features["power8-vector"] = true;
+else if (Name == "power10-vector")
+  Features["power8-vector"] = Features["power9-vector"] = true;
 if (Name == "pcrel")
   Features["pcrelative-memops"] = true;
 else
@@ -402,9 +413,12 @@ void 
PPCTargetInfo::setFeatureEnabled(llvm::StringMap ,
 // features.
 if ((Name == "altivec") || (Name == "vsx"))
   Features["vsx"] = 

[PATCH] D81424: Driver: Accept multiple --config options if filenames are the same

2020-06-16 Thread Tom Stellard via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd970ab63e22e: Driver: Accept multiple --config options if 
filenames are the same (authored by tstellar).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81424

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/config-file.c


Index: clang/test/Driver/config-file.c
===
--- clang/test/Driver/config-file.c
+++ clang/test/Driver/config-file.c
@@ -71,3 +71,8 @@
 // RUN: %clang --config-system-dir=%S/Inputs/config 
--config-user-dir=%S/Inputs/config2 --config config-4 -S %s -o /dev/null -v 
2>&1 | FileCheck %s -check-prefix CHECK-PRECEDENCE
 // CHECK-PRECEDENCE: Configuration file: 
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
 // CHECK-PRECEDENCE: -Wall
+
+
+//--- Duplicate --config options are allowed if the value is the same
+// RUN: %clang --config-system-dir=%S/Inputs/config 
--config-user-dir=%S/Inputs/config2 --config config-4 --config config-4 -S %s 
-o /dev/null -v 2>&1 | FileCheck %s -check-prefix CHECK-SAME-CONFIG
+// CHECK-SAME-CONFIG: Configuration file: 
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -833,8 +833,12 @@
 std::vector ConfigFiles =
 CLOptions->getAllArgValues(options::OPT_config);
 if (ConfigFiles.size() > 1) {
-  Diag(diag::err_drv_duplicate_config);
-  return true;
+  if (!std::all_of(
+  ConfigFiles.begin(), ConfigFiles.end(),
+  [ConfigFiles](std::string s) { return s == ConfigFiles[0]; })) {
+Diag(diag::err_drv_duplicate_config);
+return true;
+  }
 }
 
 if (!ConfigFiles.empty()) {


Index: clang/test/Driver/config-file.c
===
--- clang/test/Driver/config-file.c
+++ clang/test/Driver/config-file.c
@@ -71,3 +71,8 @@
 // RUN: %clang --config-system-dir=%S/Inputs/config --config-user-dir=%S/Inputs/config2 --config config-4 -S %s -o /dev/null -v 2>&1 | FileCheck %s -check-prefix CHECK-PRECEDENCE
 // CHECK-PRECEDENCE: Configuration file: {{.*}}Inputs{{.}}config2{{.}}config-4.cfg
 // CHECK-PRECEDENCE: -Wall
+
+
+//--- Duplicate --config options are allowed if the value is the same
+// RUN: %clang --config-system-dir=%S/Inputs/config --config-user-dir=%S/Inputs/config2 --config config-4 --config config-4 -S %s -o /dev/null -v 2>&1 | FileCheck %s -check-prefix CHECK-SAME-CONFIG
+// CHECK-SAME-CONFIG: Configuration file: {{.*}}Inputs{{.}}config2{{.}}config-4.cfg
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -833,8 +833,12 @@
 std::vector ConfigFiles =
 CLOptions->getAllArgValues(options::OPT_config);
 if (ConfigFiles.size() > 1) {
-  Diag(diag::err_drv_duplicate_config);
-  return true;
+  if (!std::all_of(
+  ConfigFiles.begin(), ConfigFiles.end(),
+  [ConfigFiles](std::string s) { return s == ConfigFiles[0]; })) {
+Diag(diag::err_drv_duplicate_config);
+return true;
+  }
 }
 
 if (!ConfigFiles.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D81959: [HIP] Enable -amdgpu-internalize-symbols

2020-06-16 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added reviewers: arsenm, rampitec, tra, ashi1.
Herald added subscribers: t-tye, tpr, dstuttard, wdng, kzhuravl.

Enable -amdgpu-internalize-symbols to eliminate unused functions and global 
variables
for whole program to speed up compilation and improve performance.

For -fno-gpu-rdc, -amdgpu-internalize-symbols is passed to clang -cc1.

For -fgpu-rdc, -amdgpu-internalize-symbols is passed to lld.


https://reviews.llvm.org/D81959

Files:
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/Driver/hip-link-save-temps.hip
  clang/test/Driver/hip-save-temps.hip
  clang/test/Driver/hip-toolchain-no-rdc.hip
  clang/test/Driver/hip-toolchain-rdc-separate.hip
  clang/test/Driver/hip-toolchain-rdc.hip

Index: clang/test/Driver/hip-toolchain-rdc.hip
===
--- clang/test/Driver/hip-toolchain-rdc.hip
+++ clang/test/Driver/hip-toolchain-rdc.hip
@@ -37,7 +37,8 @@
 // CHECK-NOT: "*.llvm-link"
 // CHECK-NOT: ".*opt"
 // CHECK-NOT: ".*llc"
-// CHECK: {{".*lld.*"}} {{.*}} "-o" "[[IMG_DEV1:.*.out]]" [[A_BC1]] [[B_BC1]]
+// CHECK: {{".*lld.*"}} {{.*}} "-mllvm" "-amdgpu-internalize-symbols"
+// CHECK-SAME: "-o" "[[IMG_DEV1:.*.out]]" [[A_BC1]] [[B_BC1]]
 
 // CHECK: [[CLANG]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
@@ -62,7 +63,8 @@
 // CHECK-NOT: "*.llvm-link"
 // CHECK-NOT: ".*opt"
 // CHECK-NOT: ".*llc"
-// CHECK: {{".*lld.*"}} {{.*}} "-o" "[[IMG_DEV2:.*.out]]" [[A_BC2]] [[B_BC2]]
+// CHECK: {{".*lld.*"}} {{.*}} "-mllvm" "-amdgpu-internalize-symbols"
+// CHECK-SAME: "-o" "[[IMG_DEV2:.*.out]]" [[A_BC2]] [[B_BC2]]
 
 // CHECK: [[CLANG]] "-cc1" "-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-aux-triple" "amdgcn-amd-amdhsa"
Index: clang/test/Driver/hip-toolchain-rdc-separate.hip
===
--- clang/test/Driver/hip-toolchain-rdc-separate.hip
+++ clang/test/Driver/hip-toolchain-rdc-separate.hip
@@ -97,12 +97,14 @@
 // LINK-NOT: "*.llvm-link"
 // LINK-NOT: ".*opt"
 // LINK-NOT: ".*llc"
-// LINK: {{".*lld.*"}} {{.*}} "-o" "[[IMG_DEV1:.*.out]]" "[[A_BC1]]" "[[B_BC1]]"
+// LINK: {{".*lld.*"}} {{.*}} "-mllvm" "-amdgpu-internalize-symbols"
+// LINK-SAME: "-o" "[[IMG_DEV1:.*.out]]" "[[A_BC1]]" "[[B_BC1]]"
 
 // LINK-NOT: "*.llvm-link"
 // LINK-NOT: ".*opt"
 // LINK-NOT: ".*llc"
-// LINK: {{".*lld.*"}} {{.*}} "-o" "[[IMG_DEV2:.*.out]]" "[[A_BC2]]" "[[B_BC2]]"
+// LINK: {{".*lld.*"}} {{.*}} "-mllvm" "-amdgpu-internalize-symbols"
+// LINK-SAME: "-o" "[[IMG_DEV2:.*.out]]" "[[A_BC2]]" "[[B_BC2]]"
 
 // LINK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
 // LINK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
Index: clang/test/Driver/hip-toolchain-no-rdc.hip
===
--- clang/test/Driver/hip-toolchain-no-rdc.hip
+++ clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -38,7 +38,8 @@
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-obj"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
-// CHECK-SAME: "-fcuda-is-device" "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
+// CHECK-SAME: "-fcuda-is-device" "-mllvm" "-amdgpu-internalize-symbols"
+// CHECK-SAME: "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
 // CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-target-cpu" "gfx803"
@@ -60,7 +61,8 @@
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-obj"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
-// CHECK-SAME: "-fcuda-is-device" "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
+// CHECK-SAME: "-fcuda-is-device" "-mllvm" "-amdgpu-internalize-symbols"
+// CHECK-SAME: "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
 // CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-target-cpu" "gfx900"
@@ -98,7 +100,8 @@
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-obj"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
-// CHECK-SAME: "-fcuda-is-device" "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
+// CHECK-SAME: "-fcuda-is-device" "-mllvm" "-amdgpu-internalize-symbols"
+// CHECK-SAME: "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
 // CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-target-cpu" "gfx803"
@@ -120,7 +123,8 @@
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-obj"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
-// CHECK-SAME: "-fcuda-is-device" "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
+// CHECK-SAME: "-fcuda-is-device" "-mllvm" "-amdgpu-internalize-symbols"
+// CHECK-SAME: "-fcuda-allow-variadic-functions" "-fvisibility" "hidden"
 // CHECK-SAME: 

[PATCH] D81861: [HIP] Do not use llvm-link/opt/llc for -fgpu-rdc

2020-06-16 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/test/Driver/hip-toolchain-no-rdc.hip:164
+// LKONLY-NOT: llvm-link
+// LKONLY-NOT: opt
+// LKONLY-NOT: llc

arsenm wrote:
> yamauchi wrote:
> > Hi, this test seems to fail for me because I happen to have the string 
> > "opt" in the "InstallDir" file path to the clang binary in my workstation, 
> > like
> > 
> > clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
> > 6bc2b042f4a9e8d912901679bd4614d46f6fafed)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /opt/llvm-project/build/bin
> > 
> > Is there a way for this check pattern to be refined to avoid this issue?
> I think the negative checks aren't really necessary
it can be changed to

// LINK-NOT: {{".*/opt"}}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81861



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


[PATCH] D79719: [AIX] Implement AIX special alignment rule about double/long double

2020-06-16 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:660
+  /// When there are OverlappingEmptyFields existing in the aggregate, the
+  /// flag shows if the following first non-overlappingEmptyField has been
+  /// handled, if any.

I suggest to replace (if correct) "non-overlappingEmptyField" with "non-empty 
or empty-but-non-overlapping field".




Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:662
+  /// handled, if any.
+  bool FirstNonOverlappingEmptyFieldHandled; 
+

Having "handled" at the front is a better indication (aside from the type) that 
"field" is not the main term. Also, minor nit: there's trailing whitespace at 
the end of the line here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79719



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


[PATCH] D81330: [clang] SequenceChecker: C++17 sequencing rule for overloaded operators.

2020-06-16 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno added a comment.

@rsmith Friendly ping on this patch and D81003 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81330



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


[PATCH] D81938: [InferAddressSpaces] Handle the pair of `ptrtoint`/`inttoptr`.

2020-06-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

I'm not entirely convinced this is safe in all contexts. I think you can argue 
that this is safe if it directly feeds a memory instruction, as the access 
would be undefined if it weren't valid to do the no-op cast. However, I'm not 
sure if this is safe if used purely in arithmetic contexts. If you're just 
comparing the reinterpreted pointer values for example, I don't think that 
would be undefined


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81938



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


[PATCH] D81958: [clangd] Add library to semantically strip flags by name.

2020-06-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added reviewers: adamcz, hokein.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov.
Herald added a project: clang.

This is designed for tweaking compile commands by specifying flags to add/remove
in a config file. Something like:

  CompileFlags: { Remove: -fcolor-diagnostics }

Having users tweak raw argv (e.g. with a regex) is going to end in tears: bugs
around clang-cl, xclang, aliases, joined-vs-separate args etc are inevitable.

This isn't in tooling because of the performance choices: build a big table
up-front to make subsequent actions fast. Maybe it should be though.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81958

Files:
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/CompileCommands.h
  clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp

Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -185,6 +185,108 @@
 }
 #endif
 
+static std::string strip(llvm::StringRef Arg, llvm::StringRef Argv) {
+  llvm::SmallVector Parts;
+  llvm::SplitString(Argv, Parts);
+  std::vector Args = {Parts.begin(), Parts.end()};
+  ArgStripper S;
+  S.strip(Arg);
+  S.process(Args);
+  return llvm::join(Args, " ");
+}
+
+TEST(ArgStripperTest, Spellings) {
+  // May use alternate prefixes.
+  EXPECT_EQ(strip("-pedantic", "clang -pedantic foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-pedantic", "clang --pedantic foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("--pedantic", "clang -pedantic foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("--pedantic", "clang --pedantic foo.cc"), "clang foo.cc");
+  // May use alternate names.
+  EXPECT_EQ(strip("-x", "clang -x c++ foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-x", "clang --language=c++ foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("--language=", "clang -x c++ foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("--language=", "clang --language=c++ foo.cc"),
+"clang foo.cc");
+}
+
+TEST(ArgStripperTest, UnknownFlag) {
+  EXPECT_EQ(strip("-xyzzy", "clang -xyzzy foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-xyz*", "clang -xyzzy foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-xyzzy", "clang -Xclang -xyzzy foo.cc"), "clang foo.cc");
+}
+
+TEST(ArgStripperTest, Xclang) {
+  // Flags may be -Xclang escaped.
+  EXPECT_EQ(strip("-ast-dump", "clang -Xclang -ast-dump foo.cc"),
+"clang foo.cc");
+  // Args may be -Xclang escaped.
+  EXPECT_EQ(strip("-add-plugin", "clang -Xclang -add-plugin -Xclang z foo.cc"),
+"clang foo.cc");
+}
+
+TEST(ArgStripperTest, ClangCL) {
+  // /I is a synonym for -I in clang-cl mode only.
+  // Not stripped by default.
+  EXPECT_EQ(strip("-I", "clang -I /usr/inc /Interesting/file.cc"),
+"clang /Interesting/file.cc");
+  // Stripped when invoked as clang-cl.
+  EXPECT_EQ(strip("-I", "clang-cl -I /usr/inc /Interesting/file.cc"),
+"clang-cl");
+  // Stripped when invoked as CL.EXE
+  EXPECT_EQ(strip("-I", "CL.EXE -I /usr/inc /Interesting/file.cc"), "CL.EXE");
+  // Stripped when passed --driver-mode=cl.
+  EXPECT_EQ(strip("-I", "cc -I /usr/inc /Interesting/file.cc --driver-mode=cl"),
+"cc --driver-mode=cl");
+}
+
+TEST(ArgStripperTest, ArgStyles) {
+  // Flag
+  EXPECT_EQ(strip("-Qn", "clang -Qn foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-Qn", "clang -QnZ foo.cc"), "clang -QnZ foo.cc");
+  // Joined
+  EXPECT_EQ(strip("-std=", "clang -std= foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-std=", "clang -std=c++11 foo.cc"), "clang foo.cc");
+  // Separate
+  EXPECT_EQ(strip("-mllvm", "clang -mllvm X foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-mllvm", "clang -mllvmX foo.cc"), "clang -mllvmX foo.cc");
+  // RemainingArgsJoined
+  EXPECT_EQ(strip("/link", "clang-cl /link b c d foo.cc"), "clang-cl");
+  EXPECT_EQ(strip("/link", "clang-cl /linka b c d foo.cc"), "clang-cl");
+  // CommaJoined
+  EXPECT_EQ(strip("-Wl,", "clang -Wl,x,y foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-Wl,", "clang -Wl, foo.cc"), "clang foo.cc");
+  // MultiArg
+  EXPECT_EQ(strip("-segaddr", "clang -segaddr a b foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-segaddr", "clang -segaddra b foo.cc"),
+"clang -segaddra b foo.cc");
+  // JoinedOrSeparate
+  EXPECT_EQ(strip("-G", "clang -GX foo.cc"), "clang foo.cc");
+  EXPECT_EQ(strip("-G", "clang -G X foo.cc"), "clang foo.cc");
+  // JoinedAndSeparate
+  EXPECT_EQ(strip("-plugin-arg-", "clang -cc1 -plugin-arg-X Y foo.cc"),
+"clang -cc1 foo.cc");
+  EXPECT_EQ(strip("-plugin-arg-", "clang -cc1 -plugin-arg- Y foo.cc"),
+"clang -cc1 foo.cc");
+}
+
+TEST(ArgStripperTest, EndOfList) {
+  // When we hit the end-of-args prematurely, we don't crash.
+  // We consume the incomplete 

[PATCH] D81938: [InferAddressSpaces] Handle the pair of `ptrtoint`/`inttoptr`.

2020-06-16 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

In D81938#2095982 , @tra wrote:

> In D81938#2095869 , @hliao wrote:
>
> > In D81938#2095828 , @lebedev.ri 
> > wrote:
> >
> > > This should be two separate patches - inferaddressspace and SROA.
> >
> >
> > Yes, I prepared that into 2 commits but `arc` combines them together.
>
>
> I usually put the patches into separate branches, with one having the other 
> one as an upstream branch and then do arc diff with each branch checked out.
>  The downside is that you will need to rebase infer-branch every time you 
> update sroa-branch.
>  Another approach that may work is to set arc config to only consider the 
> checked out commit only. `arc set-config base "arc:this, arc:prompt"` should 
> do that.


Thanks for the ar option approach. I usually do the same thing creating a bunch 
of local branches to separate individual changes. It's quite cumbersome to 
maintain them. More than 80 local branches are really difficult to maintain. 
Will try that arc option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81938



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


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir updated this revision to Diff 271164.
saghir added a comment.

Updated comment for allowing __int128 for vector bool.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/DeclSpec.cpp
  clang/test/Parser/altivec-bool-128.c
  clang/test/Parser/cxx-altivec-bool-128.cpp
  clang/test/Parser/p10-vector-bool-128.c

Index: clang/test/Parser/p10-vector-bool-128.c
===
--- /dev/null
+++ clang/test/Parser/p10-vector-bool-128.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-cpu pwr10 -target-feature +altivec -target-feature +vsx -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-cpu pwr10 -target-feature +altivec -target-feature +vsx -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Test legitimate uses of 'vector bool __int128' with VSX.
+__vector bool __int128 v1_bi128;
+__vector __bool __int128 v2_bi128;
+vector bool __int128 v3_bi128;
+vector __bool __int128 v4_bi128;
Index: clang/test/Parser/cxx-altivec-bool-128.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx-altivec-bool-128.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify -std=c++11 %s
+#include 
+
+// Test 'vector bool __int128' type.
+
+// These should have errors.
+__vector bool __int128 v1_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool __int128 v2_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool __int128 v3_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool __int128 v4_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool unsigned __int128 v5_bi128; // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool signed __int128 v6_bi128;   // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool unsigned __int128 v7_bi128;   // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool signed __int128 v8_bi128; // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool signed __int128 v9_bi128; // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool signed __int128 v10_bi128;  // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
Index: clang/test/Parser/altivec-bool-128.c
===
--- /dev/null
+++ clang/test/Parser/altivec-bool-128.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify %s
+
+// Test 'vector bool __int128' type.
+
+// These should have errors.
+__vector bool __int128 v1_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool __int128 v2_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool __int128 v3_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool __int128 v4_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool unsigned __int128 v5_bi128; // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool signed __int128 v6_bi128;   // expected-error {{cannot use 

[PATCH] D81938: [InferAddressSpaces] Handle the pair of `ptrtoint`/`inttoptr`.

2020-06-16 Thread Michael Liao via Phabricator via cfe-commits
hliao updated this revision to Diff 271162.
hliao added a comment.

Fix constant expression handling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81938

Files:
  clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
  llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp
  llvm/test/Transforms/InferAddressSpaces/noop-ptrint-pair.ll

Index: llvm/test/Transforms/InferAddressSpaces/noop-ptrint-pair.ll
===
--- /dev/null
+++ llvm/test/Transforms/InferAddressSpaces/noop-ptrint-pair.ll
@@ -0,0 +1,45 @@
+; RUN: opt -S -o - -infer-address-spaces %s | FileCheck %s
+
+target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-ni:7"
+target triple = "amdgcn-amd-amdhsa"
+
+; CHECK-LABEL: @noop_ptrint_pair(
+; CHECK-NEXT: store i32 0, i32 addrspace(1)* %{{.*}}
+; CHECK-NEXT: ret void
+define void @noop_ptrint_pair(i32 addrspace(1)* %x.coerce) {
+  %1 = ptrtoint i32 addrspace(1)* %x.coerce to i64
+  %2 = inttoptr i64 %1 to i32*
+  store i32 0, i32* %2
+  ret void
+}
+
+; CHECK-LABEL: @non_noop_ptrint_pair(
+; CHECK-NEXT: ptrtoint i32 addrspace(3)* %{{.*}} to i64
+; CHECK-NEXT: inttoptr i64 %{{.*}} to i32*
+; CHECK-NEXT: store i32 0, i32* %{{.*}}
+; CHECK-NEXT: ret void
+define void @non_noop_ptrint_pair(i32 addrspace(3)* %x.coerce) {
+  %1 = ptrtoint i32 addrspace(3)* %x.coerce to i64
+  %2 = inttoptr i64 %1 to i32*
+  store i32 0, i32* %2
+  ret void
+}
+
+@g = addrspace(1) global i32 0, align 4
+@l = addrspace(3) global i32 0, align 4
+
+; CHECK-LABEL: @noop_ptrint_pair_ce(
+; CHECK-NEXT: store i32 0, i32 addrspace(1)* @g
+; CHECK-NEXT: ret void
+define void @noop_ptrint_pair_ce() {
+  store i32 0, i32* inttoptr (i64 ptrtoint (i32 addrspace(1)* @g to i64) to i32*)
+  ret void
+}
+
+; CHECK-LABEL: @non_noop_ptrint_pair_ce(
+; CHECK-NEXT: store i32 0, i32* inttoptr (i64 ptrtoint (i32 addrspace(3)* @l to i64) to i32*)
+; CHECK-NEXT: ret void
+define void @non_noop_ptrint_pair_ce() {
+  store i32 0, i32* inttoptr (i64 ptrtoint (i32 addrspace(3)* @l to i64) to i32*)
+  ret void
+}
Index: llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp
===
--- llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp
+++ llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp
@@ -143,6 +143,7 @@
 /// InferAddressSpaces
 class InferAddressSpaces : public FunctionPass {
   const TargetTransformInfo *TTI = nullptr;
+  const DataLayout *DL = nullptr;
 
   /// Target specific address space which uses of should be replaced if
   /// possible.
@@ -219,10 +220,25 @@
 INITIALIZE_PASS(InferAddressSpaces, DEBUG_TYPE, "Infer address spaces",
 false, false)
 
+static bool isNoopPtrIntCastPair(const Operator *I2P, const DataLayout *DL) {
+  assert(I2P->getOpcode() == Instruction::IntToPtr);
+  auto *P2I = dyn_cast(I2P->getOperand(0));
+  if (!P2I || P2I->getOpcode() != Instruction::PtrToInt)
+return false;
+  // The pair of `ptrtoint`/`inttoptr` is a no-op cast if both of them are
+  // no-op casts.
+  return CastInst::isNoopCast(Instruction::CastOps(I2P->getOpcode()),
+  I2P->getOperand(0)->getType(), I2P->getType(),
+  *DL) &&
+ CastInst::isNoopCast(Instruction::CastOps(P2I->getOpcode()),
+  P2I->getOperand(0)->getType(), P2I->getType(),
+  *DL);
+}
+
 // Returns true if V is an address expression.
 // TODO: Currently, we consider only phi, bitcast, addrspacecast, and
 // getelementptr operators.
-static bool isAddressExpression(const Value ) {
+static bool isAddressExpression(const Value , const DataLayout *DL) {
   const Operator *Op = dyn_cast();
   if (!Op)
 return false;
@@ -241,6 +257,8 @@
 const IntrinsicInst *II = dyn_cast();
 return II && II->getIntrinsicID() == Intrinsic::ptrmask;
   }
+  case Instruction::IntToPtr:
+return isNoopPtrIntCastPair(Op, DL);
   default:
 return false;
   }
@@ -249,7 +267,8 @@
 // Returns the pointer operands of V.
 //
 // Precondition: V is an address expression.
-static SmallVector getPointerOperands(const Value ) {
+static SmallVector getPointerOperands(const Value ,
+  const DataLayout *DL) {
   const Operator  = cast(V);
   switch (Op.getOpcode()) {
   case Instruction::PHI: {
@@ -269,6 +288,11 @@
"unexpected intrinsic call");
 return {II.getArgOperand(0)};
   }
+  case Instruction::IntToPtr: {
+assert(isNoopPtrIntCastPair(, DL));
+auto *P2I = cast(Op.getOperand(0));
+return {P2I->getOperand(0)};
+  }
   default:
 llvm_unreachable("Unexpected instruction type.");
   }
@@ -337,13 +361,13 @@
   // expressions.
   if (ConstantExpr *CE = 

[PATCH] D81672: [Driver] When forcing a crash call abort to get the correct diagnostic

2020-06-16 Thread John Brawn via Phabricator via cfe-commits
john.brawn added reviewers: aganea, rnk.
john.brawn added a comment.

Added a couple of reviewers that have recently worked on CrashRecoveryContext.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81672



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


[PATCH] D81951: [OPENMP]Fix PR46347: several ordered directives in a single region.

2020-06-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D81951#2096397 , @jdoerfert wrote:

> LGTM, can you add the nested ordered + depend test case too, assuming we 
> don't have it.


We have such tests in ordered_ast_print.cpp and ordered_codegen.cpp tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81951



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


[clang] d970ab6 - Driver: Accept multiple --config options if filenames are the same

2020-06-16 Thread Tom Stellard via cfe-commits

Author: Tom Stellard
Date: 2020-06-16T12:23:57-07:00
New Revision: d970ab63e22eb5918774953da6b99ac27e5832a0

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

LOG: Driver: Accept multiple --config options if filenames are the same

Summary:
We're trying to use the --config options to pass distro specific
options for Fedora via the CFLAGS variable.  However, some projects
end up using the CFLAGS variable multiple times in their command line,
which leads to an error when --config is used.

This patch resolves this issue by allowing more than one --config option
on the command line as long as the file names are the same.

Reviewers: sepavloff, hfinkel

Reviewed By: sepavloff

Subscribers: cfe-commits, llvm-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/config-file.c

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 3add665c1156..a8442d2cd0af 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -833,8 +833,12 @@ bool Driver::loadConfigFile() {
 std::vector ConfigFiles =
 CLOptions->getAllArgValues(options::OPT_config);
 if (ConfigFiles.size() > 1) {
-  Diag(diag::err_drv_duplicate_config);
-  return true;
+  if (!std::all_of(
+  ConfigFiles.begin(), ConfigFiles.end(),
+  [ConfigFiles](std::string s) { return s == ConfigFiles[0]; })) {
+Diag(diag::err_drv_duplicate_config);
+return true;
+  }
 }
 
 if (!ConfigFiles.empty()) {

diff  --git a/clang/test/Driver/config-file.c b/clang/test/Driver/config-file.c
index 04127d404f67..fde7260ecd73 100644
--- a/clang/test/Driver/config-file.c
+++ b/clang/test/Driver/config-file.c
@@ -71,3 +71,8 @@
 // RUN: %clang --config-system-dir=%S/Inputs/config 
--config-user-dir=%S/Inputs/config2 --config config-4 -S %s -o /dev/null -v 
2>&1 | FileCheck %s -check-prefix CHECK-PRECEDENCE
 // CHECK-PRECEDENCE: Configuration file: 
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
 // CHECK-PRECEDENCE: -Wall
+
+
+//--- Duplicate --config options are allowed if the value is the same
+// RUN: %clang --config-system-dir=%S/Inputs/config 
--config-user-dir=%S/Inputs/config2 --config config-4 --config config-4 -S %s 
-o /dev/null -v 2>&1 | FileCheck %s -check-prefix CHECK-SAME-CONFIG
+// CHECK-SAME-CONFIG: Configuration file: 
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg



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


[PATCH] D74166: [AIX][Frontend] Static init implementation for AIX considering no priority

2020-06-16 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:4489
+  // DestructCallBlock, otherwise jump to EndBlock directly.
+  CGF.EmitCXXGuardedInitBranch(NeedsDestruct, DestructCallBlock, EndBlock,
+   CodeGenFunction::GuardKind::VariableGuard, );

hubert.reinterpretcast wrote:
> Please add a test for a static local. Note the `branch_weights`. I do not 
> believe the `branch_weights` associated with guarded initialization for a 
> static local (what the called function is meant to deal with) is necessarily 
> appropriate for a branch associated with finalization-on-unload.
Thank you for pointing this out. I will adjust the function name to 
`EmitCXXGuardedInitOrDestructBranch` later to match our usage.

In terms of `branch_weights`,  this is something I am not familiar with. So 
please correct me if I am wrong. Some of my superficial thoughts would be are 
we able to apply `branch_weights` on a branch associated with 
finalization-on-unload? Should it be set as `nullptr`,  because we would not 
know how many times we will call `__sterm`(and each sterm finalizer contained)?

BTW, I will add a testcase for a static local and we can update the 
`branch_weights` part later along with the reviews.



Comment at: clang/test/CodeGen/static-init.cpp:8
+// RUN:   FileCheck %s
 
 struct test {

hubert.reinterpretcast wrote:
> Xiangling_L wrote:
> > jasonliu wrote:
> > > Looks like the non-inline comments are easier to get ignored and missed, 
> > > so I will copy paste the non-inlined comment I previously had:
> > > ```
> > > -fregister_global_dtors_with_atexit does not seem to work properly in 
> > > current implementation.
> > > We should consider somehow disabling/report_fatal_error it instead of 
> > > letting it generate invalid code on AIX.
> > > ```
> > Thanks for doing so!
> > 
> > The semantic of `global_dtors` here on AIX is `__sterm` function, which we 
> > are never gonna register with `__atexit`. I am thinking we can disable it 
> > in a follow-up driver patch with the handling of `-fno-use-cxa-atexit`.
> The semantic of `global_dtors` is not limited to the `__sterm` functions 
> associated with C++ cleanup actions. With respect to user-declared 
> `__attribute__((__destructor__))` functions, the option could improve the 
> interleaving of those cleanup actions with cleanup actions registered by 
> user-declared `__attribute__((__constructor__))` functions.
> 
> This provides that rationale for separating the `__sterm` functions 
> associated with the C++ cleanup actions from the other "destructor" functions.
Yeah, I agree that the semantic of `global_dtors` should contain both `__sterm` 
and `__attribute__((__destructor__))` dtors. And we do need some rationale to 
separate `__sterm` and those other `destructor` functions out for AIX.

However, I doubt the `-fregister_global_dtors_with_atexit` option is something 
we should use. Cuz dtors with `__attribute__((__destructor__))` actually are 
equivalent to `__dtor` functions in AIX's semantic which need to be registered 
with `__atexit`. However, we shouldn't register `__sterm` with `__atexit`. So 
it seems this option does not work well for AIX either we set it to true or 
false, and we need to figure something else out when we start supporting 
`__attribute__((__destructor__))` and `__attribute__((__constructor__))`?



Comment at: clang/test/CodeGen/static-init.cpp:31
+// CHECK: @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] 
[{ i32, void ()*, i8* } { i32 65535, void ()* 
@__sinit8000_clang_510e898aa8d263cac999dd03eeed5b51, i8* null }]
+// CHECK: @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] 
[{ i32, void ()*, i8* } { i32 65535, void ()* 
@__sterm8000_clang_510e898aa8d263cac999dd03eeed5b51, i8* null }]
+

hubert.reinterpretcast wrote:
> hubert.reinterpretcast wrote:
> > Okay, the restricted scope of this patch seems to landed in a place where 
> > how the `llvm.global_dtors` array will be handled is not indicated...
> > 
> > The backend should implement the semantics of the IR construct. When 
> > handling said array in the IR, it seems the method to handle the requisite 
> > semantics would be to generate an alias (with the appropriate linkage for 
> > the linker to pick it up) that is named using the `__sinit`/`__sterm` 
> > convention. Which is to say that at least some part of the naming should 
> > eventually move into the LLVM side and out of Clang.
> > 
> > Please update the description of this patch to indicate that:
> > 
> >   - The `llvm.global_ctors` and `llvm.global_dtors` functionality has not 
> > yet been implemented on AIX.
> >   - This patch temporarily side-steps the need to implement that 
> > functionality.
> >   - The apparent uses of that functionality in this patch (with respect to 
> > the name of the functions involved) are 

[PATCH] D74166: [AIX][Frontend] Static init implementation for AIX considering no priority

2020-06-16 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L updated this revision to Diff 271156.
Xiangling_L marked 35 inline comments as done.
Xiangling_L added a comment.

Renamed some functions;
Add one more test;
etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74166

Files:
  clang/include/clang/AST/Mangle.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/CodeGen/CGCXXABI.h
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/aix-constructor-attribute.cpp
  clang/test/CodeGen/aix-destructor-attribute.cpp
  clang/test/CodeGen/aix-init-priority-attribute.cpp
  clang/test/CodeGen/static-init.cpp

Index: clang/test/CodeGen/static-init.cpp
===
--- clang/test/CodeGen/static-init.cpp
+++ clang/test/CodeGen/static-init.cpp
@@ -1,12 +1,175 @@
-// RUN: not %clang_cc1 -triple powerpc-ibm-aix-xcoff -S -emit-llvm -x c++ %s \
-// RUN: -o /dev/null 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -S -emit-llvm -x c++ \
+// RUN: -fno-use-cxa-atexit -std=c++2a < %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,CHECK32 %s
 
-// RUN: not %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ %s \
-// RUN: -o /dev/null 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -S -emit-llvm -x c++ \
+// RUN: -fno-use-cxa-atexit -std=c++2a < %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,CHECK64 %s
 
-struct test {
-  test();
-  ~test();
-} t;
+namespace test1 {
+  struct Test1 {
+Test1();
+~Test1();
+  } t1, t2;
+} // namespace test1
 
-// CHECK: error in backend: Static initialization has not been implemented on XL ABI yet.
+namespace test2 {
+  int foo() { return 3; }
+  int x = foo();
+} // namespace test2
+
+namespace test3 {
+  struct Test3 {
+constexpr Test3() {};
+~Test3() {};
+  };
+
+  constinit Test3 t;
+} // namespace test3
+
+namespace test4 {
+  struct Test4 { 
+Test4();
+~Test4();
+  };
+
+  void f() {
+static Test4 staticLocal;
+  }
+} // namespace test4
+
+// CHECK: @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @__sinit8000_clang_1145401da454a7baad10bfe313c46638, i8* null }]
+// CHECK: @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @__sterm8000_clang_1145401da454a7baad10bfe313c46638, i8* null }]
+
+// CHECK: define internal void @__cxx_global_var_init() #0 {
+// CHECK: entry:
+// CHECK:   call void @_ZN5test15Test1C1Ev(%"struct.test1::Test1"* @_ZN5test12t1E)
+// CHECK:   %0 = call i32 @atexit(void ()* @__dtor__ZN5test12t1E) #3
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @__dtor__ZN5test12t1E() #0 {
+// CHECK: entry:
+// CHECK:   call void @_ZN5test15Test1D1Ev(%"struct.test1::Test1"* @_ZN5test12t1E)
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: declare i32 @atexit(void ()*)
+
+// CHECK: define internal void @__finalize__ZN5test12t1E() #0 {
+// CHECK: entry:
+// CHECK:   %0 = call i32 @unatexit(void ()* @__dtor__ZN5test12t1E) #3
+// CHECK:   %needs_destruct = icmp eq i32 %0, 0
+// CHECK:   br i1 %needs_destruct, label %destruct.call, label %destruct.end
+
+// CHECK: destruct.call:
+// CHECK:   call void @__dtor__ZN5test12t1E()
+// CHECK:   br label %destruct.end
+
+// CHECK: destruct.end:
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: declare i32 @unatexit(void ()*)
+
+// CHECK: define internal void @__cxx_global_var_init.1() #0 {
+// CHECK: entry:
+// CHECK:   call void @_ZN5test15Test1C1Ev(%"struct.test1::Test1"* @_ZN5test12t2E)
+// CHECK:   %0 = call i32 @atexit(void ()* @__dtor__ZN5test12t2E)
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @__dtor__ZN5test12t2E() #0 {
+// CHECK: entry:
+// CHECK:   call void @_ZN5test15Test1D1Ev(%"struct.test1::Test1"* @_ZN5test12t2E)
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @__finalize__ZN5test12t2E() #0 {
+// CHECK: entry:
+// CHECK:   %0 = call i32 @unatexit(void ()* @__dtor__ZN5test12t2E)
+// CHECK:   %needs_destruct = icmp eq i32 %0, 0
+// CHECK:   br i1 %needs_destruct, label %destruct.call, label %destruct.end
+
+// CHECK: destruct.call:
+// CHECK:   call void @__dtor__ZN5test12t2E()
+// CHECK:   br label %destruct.end
+
+// CHECK: destruct.end:
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void @__cxx_global_var_init.2() #0 {
+// CHECK: entry:
+// CHECK32: %call = call i32 @_ZN5test23fooEv()
+// CHECK64: %call = call signext i32 @_ZN5test23fooEv()
+// CHECK:   store i32 %call, i32* @_ZN5test21xE
+// CHECK:   ret void
+// CHECK: }
+
+// CHECK: define internal void 

[PATCH] D81951: [OPENMP]Fix PR46347: several ordered directives in a single region.

2020-06-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM, can you add the nested ordered + depend test case too, assuming we don't 
have it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81951



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


[PATCH] D75844: [clang] Set begin loc on GNU attribute parsed attrs

2020-06-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D75844#2076260 , @tbaeder wrote:

> I'm looking at this again and I am not sure how it is meant to work. For 
> example in `Parser::parseClassSpecifier` in `ParseDeclCXX.cpp`.
>  Here `attrs` is a local variable of type `ParsedAttributesWithRange`, 
> already before my patch. `attrs` is then passed to
>
> 1. `MaybeParseGNUAttributes`
> 2. `MaybeParseMicrosoftDeclSpecs`
> 3. `ParseMicrosoftInheritanceClassAttributes`
> 4. `MaybeParseCXX11Attributes`
>
>   and later `parseClassSpecifier` calls `ProhibitAttributes(attrs)` a few 
> times. `ProhibitAttributes` in turn will not do anything if the given attrs 
> have an invalid (i.e. unset) range. So, how could they ever have a valid 
> range set? All the four functions above only take a  `ParsedAttributes`, no 
> range.
>
>   This is one of the cases that now (that `MaybeParseGNUAttributes` sets the 
> range of the given `attrs` if it really parses attributes) generates errors 
> in various test cases. For example in 
> `clang/test/AST/ast-print-record-decl.c`: File 
> /home/tbaeder/llvm-project/clang/test/AST/ast-print-record-decl.c Line 209: 
> an attribute list cannot appear here
>
>   Am I missing something?


I don't think you're missing anything -- the state of the system is currently 
inconsistent. From (possibly faulty) memory, we previously only tracked the 
minimum of location information for attribute source locations and some parts 
of the system relied on invalid source locations to convey meaning that it 
shouldn't have. This is compounded by the fact that the different attribute 
syntaxes (gnu, C++, declspec, etc) have been worked on at different times with 
different assumptions about source locations, but are all generalized in the 
same parsed attributes data structure. Now that you're starting to more 
consistently track source location information across syntaxes, you're hitting 
some fallout from those inconsistencies. Hopefully there's not so much fallout 
that it cannot be handled though (if there is, please speak up and we can try 
to explore other options).


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

https://reviews.llvm.org/D75844



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


[PATCH] D81953: [clang-tidy] warnings-as-error no longer exits with ErrorCount

2020-06-16 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 unless @jroelofs has a reason why the code was originally written that 
way, but can you add test coverage for it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81953



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


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Lei Huang via Phabricator via cfe-commits
lei added inline comments.



Comment at: clang/lib/Sema/DeclSpec.cpp:1170
 
   // Only 'short' and 'long long' are valid with vector bool. (PIM 2.1)
   if ((TypeSpecWidth != TSW_unspecified) && (TypeSpecWidth != TSW_short) &&

Do we not need to add a check for int128 to this check as well? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816



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


[PATCH] D81478: [OPENMP50]Codegen for scan directives in parallel for regions.

2020-06-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev marked an inline comment as done.
ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:3627
+  emitScanBasedDirective(CGF, S, NumIteratorsGen, FirstGen, SecondGen);
+} else {
+  OMPCancelStackRAII CancelRegion(CGF, OMPD_parallel_for, S.hasCancel());

jdoerfert wrote:
> This looks pretty much like D81658, right? Could we avoid the duplication and 
> maybe use a templated function (or something else)?
The duplication is quite small. Here we don't need to check for lastprivates 
update, we need to check for the cancellation region. I don't think that the 
outlined functions are going to be much simpler and easier to read.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81478



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


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Lei Huang via Phabricator via cfe-commits
lei added inline comments.



Comment at: clang/lib/Sema/DeclSpec.cpp:1155
+  // TODO: Update comment with correct Programming Interface Manual
+  // version once it is available. __int128 has also been added
+  // to vector bool for Power10.

saghir wrote:
> lei wrote:
> > Not sure what you mean here.
> Earlier comment had the Programming Interface Manual version number (PIM 
> 2.1); asserting only char/int were valid with vector bool. 
> This patch adds __int128, so the comment needs to be updated with the latest 
> version of the document once it is available.
Maybe need to add a TODO in all the sections of code, that you update, where it 
mentions PIM 2.1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816



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


[PATCH] D81861: [HIP] Do not use llvm-link/opt/llc for -fgpu-rdc

2020-06-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/test/Driver/hip-toolchain-no-rdc.hip:164
+// LKONLY-NOT: llvm-link
+// LKONLY-NOT: opt
+// LKONLY-NOT: llc

yamauchi wrote:
> Hi, this test seems to fail for me because I happen to have the string "opt" 
> in the "InstallDir" file path to the clang binary in my workstation, like
> 
> clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
> 6bc2b042f4a9e8d912901679bd4614d46f6fafed)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /opt/llvm-project/build/bin
> 
> Is there a way for this check pattern to be refined to avoid this issue?
I think the negative checks aren't really necessary


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81861



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


[PATCH] D81641: [SYCL][OpenMP] Implement thread-local storage restriction

2020-06-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.

In D81641#2096114 , @Fznamznon wrote:

> In D81641#2088446 , @jdoerfert wrote:
>
> > OpenMP has the same restriction (no surprise I guess). Thanks for the ping!
> >
> > I think we do not emit diagnosis right now: https://godbolt.org/z/srDkXZ
> >  I think we also should diagnose this the same way, though it might be 
> > beyond the scope of this patch: https://godbolt.org/z/rRZFi4
>
>
> Alright, now the first case that you pointed is diagnosed as well.


Nice, thanks a lot!

> The second case is not diagnosed at all and I agree that it seems beyond the 
> scope of this patch, because it looks like using of `#pragma omp task untied` 
> doesn't trigger emission of deferred diagnostics.

Yeah, we need to track untied tasks first. Not as part of this though.

LGTM :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81641



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


[PATCH] D81881: [OPENMP]Fix overflow during counting the number of iterations.

2020-06-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

In D81881#2095509 , @ABataev wrote:

> In D81881#2094062 , @jdoerfert wrote:
>
> > So the idea is to do the trip count computation with defined overflow 
> > behavior, e.g., without `nsw/nuw` in IR, right?
>
>
> Not quite. If we can predict that there is no overflow, everything remains 
> the same as before. If we cannot do this, the trip count calculations are 
> performed on unsigned types instead of signed. It does not just drop 
> `nuw/nsw` flags, but also uses `udiv`, `zext` etc. instead of `sdiv`, `sext` 
> etc. Plus, it tries to reorganize the operations a little bit to avoid 
> possible overflow.


Makes sense. LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81881



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


[PATCH] D81736: [openmp] Base of tablegen generated OpenMP common declaration

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

In D81736#2095947 , @clementval wrote:

> In D81736#2093926 , @jdoerfert wrote:
>
> > Assuming this passes all the tests, it looks good to me. Let's wait a day 
> > or two for people to take a look though :)
>
>
> @jdoerfert Sure let's wait a bit. I see a failure because of some clang-tidy 
> warnings. How strongly should I fix them? I see some conflict with other code 
> I see in TableGen.


Clang-tidy run by Phab is not binding but if it's reasonable modify it. Keep 
the TableGen style consistent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81736



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


[PATCH] D81478: [OPENMP50]Codegen for scan directives in parallel for regions.

2020-06-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:3627
+  emitScanBasedDirective(CGF, S, NumIteratorsGen, FirstGen, SecondGen);
+} else {
+  OMPCancelStackRAII CancelRegion(CGF, OMPD_parallel_for, S.hasCancel());

This looks pretty much like D81658, right? Could we avoid the duplication and 
maybe use a templated function (or something else)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81478



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


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir updated this revision to Diff 271144.
saghir added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/DeclSpec.cpp
  clang/test/Parser/altivec-bool-128.c
  clang/test/Parser/cxx-altivec-bool-128.cpp
  clang/test/Parser/p10-vector-bool-128.c

Index: clang/test/Parser/p10-vector-bool-128.c
===
--- /dev/null
+++ clang/test/Parser/p10-vector-bool-128.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-cpu pwr10 -target-feature +altivec -target-feature +vsx -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-cpu pwr10 -target-feature +altivec -target-feature +vsx -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Test legitimate uses of 'vector bool __int128' with VSX.
+__vector bool __int128 v1_bi128;
+__vector __bool __int128 v2_bi128;
+vector bool __int128 v3_bi128;
+vector __bool __int128 v4_bi128;
Index: clang/test/Parser/cxx-altivec-bool-128.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx-altivec-bool-128.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify -std=c++11 %s
+#include 
+
+// Test 'vector bool __int128' type.
+
+// These should have errors.
+__vector bool __int128 v1_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool __int128 v2_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool __int128 v3_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool __int128 v4_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool unsigned __int128 v5_bi128; // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool signed __int128 v6_bi128;   // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool unsigned __int128 v7_bi128;   // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool signed __int128 v8_bi128; // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool signed __int128 v9_bi128; // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool signed __int128 v10_bi128;  // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
Index: clang/test/Parser/altivec-bool-128.c
===
--- /dev/null
+++ clang/test/Parser/altivec-bool-128.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify %s
+
+// Test 'vector bool __int128' type.
+
+// These should have errors.
+__vector bool __int128 v1_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool __int128 v2_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool __int128 v3_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool __int128 v4_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool unsigned __int128 v5_bi128; // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool signed __int128 v6_bi128;   // expected-error {{cannot use 'signed' with '__vector bool'}} 

[PATCH] D81658: [OPENMP50]Codegen for scan directive in for simd regions.

2020-06-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM. Nice :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81658



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


[PATCH] D81861: [HIP] Do not use llvm-link/opt/llc for -fgpu-rdc

2020-06-16 Thread Hiroshi Yamauchi via Phabricator via cfe-commits
yamauchi added inline comments.



Comment at: clang/test/Driver/hip-toolchain-no-rdc.hip:164
+// LKONLY-NOT: llvm-link
+// LKONLY-NOT: opt
+// LKONLY-NOT: llc

Hi, this test seems to fail for me because I happen to have the string "opt" in 
the "InstallDir" file path to the clang binary in my workstation, like

clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
6bc2b042f4a9e8d912901679bd4614d46f6fafed)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm-project/build/bin

Is there a way for this check pattern to be refined to avoid this issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81861



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


[PATCH] D81868: [libTooling] Add parser for string representation of `RangeSelector`.

2020-06-16 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/include/clang/Tooling/Transformer/Parsing.h:1
+//===--- Parsing.h - Parsing library for Transformer -*- C++ -*-===//
+//

Please pad the first line to match the other line (throughout the patch).



Comment at: clang/include/clang/Tooling/Transformer/Parsing.h:27
+
+/// Parses a string-representation of a \c RangeSelector. The grammar of these
+/// strings is closely based on the (sub)grammar of \c RangeSelectors as they'd

"string representation"



Comment at: clang/lib/Tooling/Transformer/Parsing.cpp:29
+
+namespace {
+using llvm::Error;

I'm a bit concerned about the abundance of parsers in Clang tooling: we already 
have a similar language for dynamic AST matchers. I'm concerned about both code 
duplication as such, and that there are multiple ways to do something.

Code duplication makes it more difficult to carry out horizontal efforts like 
improving error reporting.

Multiple ways to do something makes codebase knowledge less reusable. It might 
also create language discrepancies that users might notice (for example, I 
don't remember if `bind(id)` works in dynamic AST matchers or not; we would be 
better off if range selectors were consistent with that).

I don't think this particular change decisively tips the scale towards 
refactoring the parser for dynamic AST matchers to be reusable here; however it 
is an option worth considering. I think we should be thinking about the total 
cost of ownership of this code.

Some future use cases will also need an embeddable language (like AST matchers 
for the syntax tree, or parsing stencils from strings).



Comment at: clang/unittests/Tooling/RangeSelectorTest.cpp:271
+  ASSERT_THAT_EXPECTED(R, llvm::Succeeded());
+  EXPECT_THAT_EXPECTED(select(*R, Match), HasValue("3;"));
 }

I wonder if we could figure out a more direct testing strategy for a parser 
(that does not necessarily involve using the parsed objects) if we had more 
advanced parsing infrastructure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81868



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


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Lei Huang via Phabricator via cfe-commits
lei added inline comments.



Comment at: clang/test/Parser/altivec-bool-128.c:2
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature 
+altivec -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature 
+altivec -fsyntax-only -verify %s
+

saghir wrote:
> lei wrote:
> > test for `-mcpu=pwr10 -target-feature -power10-vector` and `-mcpu=pwr10 
> > -target-feature -vsx`
> > same for cxx-altivec-bool-128.cpp
> This test basically checks that `VSX` needs to be enabled to have `vector 
> bool __int128` type work.
Yes.   I am asking you to add a test to check that `power10-vector` is also 
needed to be enabled for this type to work.
eg. this type should not be enabled for `-mcpu=pwr10 -target-feature +vsx 
-target-feature -power10-vector`



Comment at: clang/test/Parser/p10-vector-bool-128.c:2
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature 
+altivec -target-feature +vsx -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature 
+altivec -target-feature +vsx -fsyntax-only -verify %s
+// expected-no-diagnostics

saghir wrote:
> lei wrote:
> > add run line for feature `cpu=pwr10 +power10-vector`
> Added `pwr10`.
> `vector bool __int128` type should work with `pwr10` and `vsx` enabled, 
> `power10-vector` is not needed explicitly.
`cpu=pwr10 -vsx +power10-vector`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816



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


[PATCH] D79830: Add support of __builtin_expect_with_probability

2020-06-16 Thread Zhi Zhuang via Phabricator via cfe-commits
LukeZhuang added a comment.

@rsmith Hi, could you please take a look at my revision since last comment? 
Thank you!


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

https://reviews.llvm.org/D79830



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


[PATCH] D71199: [clang-tidy] New check cppcoreguidelines-prefer-member-initializer

2020-06-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp:29
+public:
+  Simple2() : n (0) {
+x = 0.0;

baloghadamsoftware wrote:
> aaron.ballman wrote:
> > By my reading of the core guideline 
> > (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c48-prefer-in-class-initializers-to-member-initializers-in-constructors-for-constant-initializers),
> >  it looks like `n` should also be diagnosed because all of the constructors 
> > in the class initialize the member to the same constant value. Is there a 
> > reason to deviate from the rule (or have I missed something)?
> > 
> > Also, I'd like to see a test case like:
> > ```
> > class C {
> >   int n;
> > public:
> >   C() { n = 0; }
> >   explicit C(int) { n = 12; }
> > };
> > ```
> This check only cares for initializations inside the body (rule `C.49`, but 
> if the proper fix is to convert them to default member initializer according 
> to rule `C.48` then we follow that rule in the fix). For initializations 
> implemented as constructor member initializers but according to `C.48` they 
> should have been implemented as default member initializers we already have 
> check `modernize-use-default-member-init`.
Thank you for the explanation. I have the feeling that these two rules are 
going to have some really weird interactions together. For instance, the 
example you added at my request shows behavior I can't easily explain as a user:
```
class Complex19 {
  int n;
  // CHECK-FIXES: int n{0};
public:
  Complex19() {
n = 0;
// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in an 
in-class default member initializer 
[cppcoreguidelines-prefer-member-initializer]
// CHECK-FIXES: {{^\ *$}}
  }

  explicit Complex19(int) {
// CHECK-FIXES: Complex19(int) : n(12) {
n = 12;
// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a 
member initializer of the constructor 
[cppcoreguidelines-prefer-member-initializer]
// CHECK-FIXES: {{^\ *$}}
  }

  ~Complex19() = default;
};
```
Despite both constructors having the assignment expression `n = ;` one 
gets one diagnostic + fixit and the other gets a different diagnostic + fixit.

Also, from reading C.49, I don't see anything about using in-class 
initialization. I see C.49 as being about avoiding the situation where the ctor 
runs a constructor for a data member only to then immediately in the ctor body 
make an assignment to that member. You don't need to initialize then 
reinitialize when you can use a member init list to construct the object 
properly initially.


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

https://reviews.llvm.org/D71199



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


[PATCH] D81953: [clang-tidy] warnings-as-error no longer exits with ErrorCount

2020-06-16 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

lgtm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81953



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


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir updated this revision to Diff 271137.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/DeclSpec.cpp
  clang/test/Parser/altivec-bool-128.c
  clang/test/Parser/cxx-altivec-bool-128.cpp
  clang/test/Parser/p10-vector-bool-128.c

Index: clang/test/Parser/p10-vector-bool-128.c
===
--- /dev/null
+++ clang/test/Parser/p10-vector-bool-128.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-cpu pwr10 -target-feature +altivec -target-feature +vsx -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-cpu pwr10 -target-feature +altivec -target-feature +vsx -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Test legitimate uses of 'vector bool __int128' with VSX.
+__vector bool __int128 v1_bi128;
+__vector __bool __int128 v2_bi128;
+vector bool __int128 v3_bi128;
+vector __bool __int128 v4_bi128;
Index: clang/test/Parser/cxx-altivec-bool-128.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx-altivec-bool-128.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify -std=c++11 %s
+#include 
+
+// Test 'vector bool __int128' type.
+
+// These should have errors.
+__vector bool __int128 v1_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool __int128 v2_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool __int128 v3_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool __int128 v4_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool unsigned __int128 v5_bi128; // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool signed __int128 v6_bi128;   // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool unsigned __int128 v7_bi128;   // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool signed __int128 v8_bi128; // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool signed __int128 v9_bi128; // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool signed __int128 v10_bi128;  // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
Index: clang/test/Parser/altivec-bool-128.c
===
--- /dev/null
+++ clang/test/Parser/altivec-bool-128.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature +altivec -fsyntax-only -verify %s
+
+// Test 'vector bool __int128' type.
+
+// These should have errors.
+__vector bool __int128 v1_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector __bool __int128 v2_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector bool __int128 v3_bi128;// expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+vector __bool __int128 v4_bi128;  // expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool unsigned __int128 v5_bi128; // expected-error {{cannot use 'unsigned' with '__vector bool'}} expected-error {{use of '__int128' with '__vector bool' requires VSX support enabled (on POWER10 or later)}}
+__vector bool signed __int128 v6_bi128;   // expected-error {{cannot use 'signed' with '__vector bool'}} expected-error {{use of '__int128' with '__vector 

[PATCH] D81953: [clang-tidy] warnings-as-error no longer exits with ErrorCount

2020-06-16 Thread Nathan James via Phabricator via cfe-commits
njames93 created this revision.
njames93 added reviewers: alexfh, jroelofs, aaron.ballman.
Herald added subscribers: cfe-commits, xazax.hun.
Herald added a project: clang.

When using `-warnings-as-errors`, If there are any warnings promoted to errors, 
clang-tidy exits with the number of warnings. This really isn't needed and can 
cause issues when the number of warnings doesn't fit into 8 bits as POSIX 
terminals aren't designed to handle more than that.
This addresses https://bugs.llvm.org/show_bug.cgi?id=46305.

Bug originally added in D15528 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81953

Files:
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp


Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -478,7 +478,7 @@
   llvm::errs() << WErrorCount << " warning" << Plural << " treated as 
error"
<< Plural << "\n";
 }
-return WErrorCount;
+return 1;
   }
 
   if (FoundErrors) {


Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -478,7 +478,7 @@
   llvm::errs() << WErrorCount << " warning" << Plural << " treated as error"
<< Plural << "\n";
 }
-return WErrorCount;
+return 1;
   }
 
   if (FoundErrors) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D81816: [PowerPC] Add support for vector bool __int128 for Power10

2020-06-16 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir marked 4 inline comments as done.
saghir added inline comments.



Comment at: clang/lib/Sema/DeclSpec.cpp:1155
+  // TODO: Update comment with correct Programming Interface Manual
+  // version once it is available. __int128 has also been added
+  // to vector bool for Power10.

lei wrote:
> Not sure what you mean here.
Earlier comment had the Programming Interface Manual version number (PIM 2.1); 
asserting only char/int were valid with vector bool. 
This patch adds __int128, so the comment needs to be updated with the latest 
version of the document once it is available.



Comment at: clang/test/Parser/altivec-bool-128.c:2
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature 
+altivec -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature 
+altivec -fsyntax-only -verify %s
+

lei wrote:
> test for `-mcpu=pwr10 -target-feature -power10-vector` and `-mcpu=pwr10 
> -target-feature -vsx`
> same for cxx-altivec-bool-128.cpp
This test basically checks that `VSX` needs to be enabled to have `vector bool 
__int128` type work.



Comment at: clang/test/Parser/p10-vector-bool-128.c:1
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature 
+altivec -target-feature +vsx -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature 
+altivec -target-feature +vsx -fsyntax-only -verify %s

amyk wrote:
> Just curious but does the RUN line require `pwr10`?
Added `pwr10`.



Comment at: clang/test/Parser/p10-vector-bool-128.c:2
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu -target-feature 
+altivec -target-feature +vsx -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -target-feature 
+altivec -target-feature +vsx -fsyntax-only -verify %s
+// expected-no-diagnostics

lei wrote:
> add run line for feature `cpu=pwr10 +power10-vector`
Added `pwr10`.
`vector bool __int128` type should work with `pwr10` and `vsx` enabled, 
`power10-vector` is not needed explicitly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81816



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


[PATCH] D81837: [ARM][bfloat] Removing lowering of bfloat arguments and returns from Clang's CodeGen

2020-06-16 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment.

Pretty straightforward, LGTM. I'd suggest rewording the title (presumably 
commit message summary) into something like "Do not coerce bfloat arguments and 
returns to integers", as we're obviously still lowering C and C++ to LLVM LR.ยงยง


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81837



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


[PATCH] D81951: [OPENMP]Fix PR46347: several ordered directives in a single region.

2020-06-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: sstefan1, guansong, yaxunl.
Herald added a project: clang.

According to OpenMP, During execution of an iteration of a worksharing-loop or 
a loop nest within a worksharing-loop, simd, or worksharing-loop SIMD region, a 
thread must not execute more than one ordered region corresponding to an 
ordered construct without a depend clause.
Need to report an error in this case.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81951

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/ordered_messages.cpp

Index: clang/test/OpenMP/ordered_messages.cpp
===
--- clang/test/OpenMP/ordered_messages.cpp
+++ clang/test/OpenMP/ordered_messages.cpp
@@ -61,6 +61,17 @@
   foo();
 }
   }
+  #pragma omp for ordered
+  for (int i = 0; i < 10; ++i) {
+#pragma omp ordered // expected-note {{previous 'ordered' directive used here}}
+{
+  foo();
+}
+#pragma omp ordered // expected-error {{exactly one 'ordered' directive must appear in the loop body of an enclosing directive}}
+{
+  foo();
+}
+  }
   #pragma omp ordered simd simd // expected-error {{directive '#pragma omp ordered' cannot contain more than one 'simd' clause}}
   {
 foo();
@@ -79,7 +90,18 @@
   foo();
 }
   }
-  #pragma omp for simd
+  #pragma omp simd
+  for (int i = 0; i < 10; ++i) {
+#pragma omp ordered simd // expected-note {{previous 'ordered' directive used here}}
+{
+  foo();
+}
+#pragma omp ordered simd // expected-error {{exactly one 'ordered' directive must appear in the loop body of an enclosing directive}}
+{
+  foo();
+}
+  }
+#pragma omp for simd
   for (int i = 0; i < 10; ++i) {
 #pragma omp ordered // expected-error {{OpenMP constructs may not be nested inside a simd region}}
 {
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -169,6 +169,7 @@
 bool LoopStart = false;
 bool BodyComplete = false;
 SourceLocation PrevScanLocation;
+SourceLocation PrevOrderedLocation;
 SourceLocation InnerTeamsRegionLoc;
 /// Reference to the taskgroup task_reduction reference expression.
 Expr *TaskgroupReductionRef = nullptr;
@@ -848,6 +849,21 @@
 const SharingMapTy *Top = getSecondOnStackOrNull();
 return Top ? Top->PrevScanLocation : SourceLocation();
   }
+  /// Mark that parent region already has ordered directive.
+  void setParentHasOrderedDirective(SourceLocation Loc) {
+if (SharingMapTy *Parent = getSecondOnStackOrNull())
+  Parent->PrevOrderedLocation = Loc;
+  }
+  /// Return true if current region has inner ordered construct.
+  bool doesParentHasOrderedDirective() const {
+const SharingMapTy *Top = getSecondOnStackOrNull();
+return Top ? Top->PrevOrderedLocation.isValid() : false;
+  }
+  /// Returns the location of the previously specified ordered directive.
+  SourceLocation getParentOrderedDirectiveLoc() const {
+const SharingMapTy *Top = getSecondOnStackOrNull();
+return Top ? Top->PrevOrderedLocation : SourceLocation();
+  }
 
   /// Set collapse value for the region.
   void setAssociatedLoops(unsigned Val) {
@@ -9187,9 +9203,10 @@
   // Check that only one instance of scan directives is used in the same outer
   // region.
   if (DSAStack->doesParentHasScanDirective()) {
-Diag(StartLoc, diag::err_omp_several_scan_directives_in_region);
+Diag(StartLoc, diag::err_omp_several_directives_in_region) << "scan";
 Diag(DSAStack->getParentScanDirectiveLoc(),
- diag::note_omp_previous_scan_directive);
+ diag::note_omp_previous_directive)
+<< "scan";
 return StmtError();
   }
   DSAStack->setParentHasScanDirective(StartLoc);
@@ -9265,6 +9282,22 @@
   if ((!AStmt && !DependFound) || ErrorFound)
 return StmtError();
 
+  // OpenMP 5.0, 2.17.9, ordered Construct, Restrictions.
+  // During execution of an iteration of a worksharing-loop or a loop nest
+  // within a worksharing-loop, simd, or worksharing-loop SIMD region, a thread
+  // must not execute more than one ordered region corresponding to an ordered
+  // construct without a depend clause.
+  if (!DependFound) {
+if (DSAStack->doesParentHasOrderedDirective()) {
+  Diag(StartLoc, diag::err_omp_several_directives_in_region) << "ordered";
+  Diag(DSAStack->getParentOrderedDirectiveLoc(),
+   diag::note_omp_previous_directive)
+  << "ordered";
+  return StmtError();
+}
+DSAStack->setParentHasOrderedDirective(StartLoc);
+  }
+
   if (AStmt) {
 assert(isa(AStmt) && "Captured statement expected");
 
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- 

[PATCH] D81451: [ARM][Clang] Removing lowering of half-precision FP arguments and returns from Clang's CodeGen

2020-06-16 Thread Ties Stuij via Phabricator via cfe-commits
stuij added a comment.

In D81451#2092997 , @pratlucas wrote:

> Hi @stuij,
>
> The changes to the backend only handle the half (f16) type itself, not 
> vectors that have it as their base type.
>
> From what I've checked on the AAPCS, the rules for handling those types are a 
> bit different and they would require their own handling in the backend's 
> calling convention lowering.
>  I haven't looked into the backend's handling of those types in detail, but I 
> believe a similar approach to the one taken for f16 would be possible for the 
> vector types as well.


Fair enough. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81451



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


  1   2   3   >