date:20190822

Re: r369591 - [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-22 Thread Diana Picus via cfe-commits

Hi Matthias,

It seems this is breaking some of our AArch64 bots:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/19691
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-global-isel/builds/12022

You probably didn't notice it because something else also failed in
that build and then the bots just remained red.
I haven't looked into too much detail, but AFAICT this is only
happening with gcc-7 (our other AArch64 bots which run clang-6 seem to
be ok with it). Is this a problem with the compiler or with the code?

Thanks,
Diana

On Thu, 22 Aug 2019 at 00:07, Matthias Gehre via cfe-commits
 wrote:
>
> Author: mgehre
> Date: Wed Aug 21 15:08:59 2019
> New Revision: 369591
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369591&view=rev
> Log:
> [LifetimeAnalysis] Support more STL idioms (template forward declaration and 
> DependentNameType)
>
> Summary:
> This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ 
> (the typedef for iterator
> on the template is a DependentNameType - we can only put the gsl::Pointer 
> attribute
> on the underlaying record after instantiation)
>
> inference of gsl::Pointer on std::vector::iterator with libc++ (the class was 
> forward-declared,
> we added the gsl::Pointer on the canonical decl (the forward decl), and later 
> when the
> template was instantiated, there was no attribute on the definition so it was 
> not instantiated).
>
> and a duplicate gsl::Pointer on some class with libstdc++ (we first added an 
> attribute to
> a incomplete instantiation, and then another was copied from the template 
> definition
> when the instantiation was completed).
>
> We now add the attributes to all redeclarations to fix thos issues and make 
> their usage easier.
>
> Reviewers: gribozavr
>
> Subscribers: Szelethus, xazax.hun, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D66179
>
> Added:
> cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaAttr.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
> cfe/trunk/unittests/Sema/CMakeLists.txt
>
> Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaAttr.cpp Wed Aug 21 15:08:59 2019
> @@ -88,13 +88,11 @@ void Sema::AddMsStructLayoutForRecord(Re
>  template 
>  static void addGslOwnerPointerAttributeIfNotExisting(ASTContext &Context,
>   CXXRecordDecl *Record) {
> -  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -  if (Canonical->hasAttr() || Canonical->hasAttr())
> +  if (Record->hasAttr() || Record->hasAttr())
>  return;
>
> -  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
> -   /*DerefType*/ nullptr,
> -   /*Spelling=*/0));
> +  for (Decl *Redecl : Record->redecls())
> +Redecl->addAttr(Attribute::CreateImplicit(Context, 
> /*DerefType=*/nullptr));
>  }
>
>  void Sema::inferGslPointerAttribute(NamedDecl *ND,
> @@ -189,8 +187,7 @@ void Sema::inferGslOwnerPointerAttribute
>
>// Handle classes that directly appear in std namespace.
>if (Record->isInStdNamespace()) {
> -CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -if (Canonical->hasAttr() || Canonical->hasAttr())
> +if (Record->hasAttr() || Record->hasAttr())
>return;
>
>  if (StdOwners.count(Record->getName()))
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Aug 21 15:08:59 2019
> @@ -4592,9 +4592,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -D->addAttr(::new (S.Context)
> -   OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> - AL.getAttributeSpellingListIndex()));
> +for (Decl *Redecl : D->redecls()) {
> +  Redecl->addAttr(::new (S.Context)
> +  OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> +AL.getAttributeSpellingListIndex()));
> +}
>} else {
>  if (checkAttrMutualExclusion(S, D, AL))
>return;
> @@ -4609,9 +4611,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -

[PATCH] D66538: [AST] AST structural equivalence to work internally with pairs.

2019-08-22 Thread Balázs Kéri via Phabricator via cfe-commits

balazske marked an inline comment as done.
balazske added inline comments.



Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:1586
-  if (EquivToD1)
-return EquivToD1 == D2->getCanonicalDecl();
 

It looks like that the original code is correct in the decision of structural 
equivalence of the original pair. If we have an (A,B) and (A,C) to compare, B 
and C are in different decl chain, then (A,B) or (A,C) will be non-equivalent 
(unless B and C are equivalent, but what to do in this case?). The problem was 
that the code assumed that in this case always A and B (or A and C) are 
non-equivalent. If `NonEquivalentDecls` is not filled in this case (or not used 
at all) the problem does not exist.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66538



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

[PATCH] D60465: [ASTImporter] Error handling fix in ImportDefinition_New.

2019-08-22 Thread Balázs Kéri via Phabricator via cfe-commits

balazske abandoned this revision.
balazske added a comment.

This change is obsolete in the current code. Casting related changes do not 
look important (and should be a new patch anyway).


Repository:
  rC Clang

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

https://reviews.llvm.org/D60465



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

[PATCH] D66541: [clangd] Send highlighting diff beyond the end of the file.

2019-08-22 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom accepted this revision.
jvikstrom added a comment.
This revision is now accepted and ready to land.

It feels a bit strange to be sending highlighting (even if they are empty)  
beyond eof. But I guess the proposal does not specify this and it would make 
life for the vscode extension (much) simpler.
Theia also does not crash from this and if we apply decorations to vscode 
outside the file nothing happens as well so I guess it should be fine. (even 
when vscode finally implements this feature into lsp)

Just had the comment about comparing HighlightigLine objects instead of using 
matchers but up to you.




Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:625
+  testing::UnorderedElementsAre(
+  testing::AllOf(LineNumber(3), EmptyHighlightings()),
+  testing::AllOf(LineNumber(4), EmptyHighlightings(;

Maybe create the HighlightingLine objects for Line 3 and 4 and add them 
directly in the `UnorderedElementsAre` because then we don't have to create the 
matchers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66541



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

r369629 - Remove an unused function, suppress -Wunused-function warning.

2019-08-22 Thread Haojian Wu via cfe-commits

Author: hokein
Date: Thu Aug 22 01:49:41 2019
New Revision: 369629

URL: http://llvm.org/viewvc/llvm-project?rev=369629&view=rev
Log:
Remove an unused function, suppress -Wunused-function warning.

Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp?rev=369629&r1=369628&r2=369629&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp Thu Aug 22 
01:49:41 2019
@@ -51,7 +51,6 @@ public:
   // 1) isa: The parameter is non-null, returns boolean.
   // 2) isa_and_nonnull: The parameter is null or non-null, returns boolean.
   bool evalCall(const CallEvent &Call, CheckerContext &C) const;
-  void checkDeadSymbols(SymbolReaper &SR, CheckerContext &C) const;
 
 private:
   // These are known in the LLVM project. The pairs are in the following form:
@@ -415,11 +414,6 @@ bool CastValueChecker::evalCall(const Ca
   return true;
 }
 
-void CastValueChecker::checkDeadSymbols(SymbolReaper &SR,
-CheckerContext &C) const {
-  C.addTransition(removeDeadCasts(C.getState(), SR));
-}
-
 void ento::registerCastValueChecker(CheckerManager &Mgr) {
   Mgr.registerChecker();
 }


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

[PATCH] D66397: [Diagnostics] Improve -Wxor-used-as-pow

2019-08-22 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

>> I think adding parens and casts are fairly well-understood to suppress 
>> warnings.

It should work here as well. #define ALPHA_OFFSET (3). Did anobody from 
Chromium try it?

>> They have varying levels of C++ proficiency

I consider things like hex decimals or parens to silence as a quite basic 
knowledge.

>> We have to be careful about which warnings we enable

I dont want off by default warning - useless. If there are still infinite macro 
concerns, I will revert just base patch.


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

https://reviews.llvm.org/D66397



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

[clang-tools-extra] r369631 - [clangd] The ClangdServer::EnableHiddenFeatures is not used any more.

2019-08-22 Thread Haojian Wu via cfe-commits

Author: hokein
Date: Thu Aug 22 02:01:04 2019
New Revision: 369631

URL: http://llvm.org/viewvc/llvm-project?rev=369631&view=rev
Log:
[clangd] The ClangdServer::EnableHiddenFeatures is not used any more.

Remove it.

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.h

Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=369631&r1=369630&r2=369631&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.h Thu Aug 22 02:01:04 2019
@@ -324,7 +324,6 @@ private:
   // If this is true, suggest include insertion fixes for diagnostic errors 
that
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
-  bool EnableHiddenFeatures = false;
 
   std::function TweakFilter;
 


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

r369633 - Revert r369458 "[DebugInfo] Add debug location to dynamic atexit destructor"

2019-08-22 Thread Hans Wennborg via cfe-commits

Author: hans
Date: Thu Aug 22 02:07:25 2019
New Revision: 369633

URL: http://llvm.org/viewvc/llvm-project?rev=369633&view=rev
Log:
Revert r369458 "[DebugInfo] Add debug location to dynamic atexit destructor"

It causes the build to fail with

"inlinable function call in a function with debug info must have a !dbg 
location"

in Chromium. See llvm-commits thread for more info.

(This also reverts the follow-up in r369474.)

> Fixes PR43012
>
> Differential Revision: https://reviews.llvm.org/D66328

Removed:
cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=369633&r1=369632&r2=369633&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Aug 22 02:07:25 2019
@@ -3564,8 +3564,7 @@ void CGDebugInfo::EmitFunctionStart(Glob
   if (Name.startswith("\01"))
 Name = Name.substr(1);
 
-  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
-  (isa(D) && GD.getDynamicInitKind() == DynamicInitKind::AtExit)) 
{
+  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
 Flags |= llvm::DINode::FlagArtificial;
 // Artificial functions should not silently reuse CurLoc.
 CurLoc = SourceLocation();

Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=369633&r1=369632&r2=369633&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Thu Aug 22 02:07:25 2019
@@ -247,8 +247,6 @@ llvm::Function *CodeGenFunction::createA
 
   CGF.StartFunction(GlobalDecl(&VD, DynamicInitKind::AtExit),
 CGM.getContext().VoidTy, fn, FI, FunctionArgList());
-  // Emit an artificial location for this function.
-  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
 
   llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
 

Removed: cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp?rev=369632&view=auto
==
--- cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp (removed)
@@ -1,20 +0,0 @@
-// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm %s -gcodeview 
-debug-info-kind=limited -o - | FileCheck %s
-
-struct a {
-  ~a();
-};
-template  struct c : a {
-  c(void (b::*)());
-};
-struct B {
-  virtual void e();
-};
-c *d() { static c f(&B::e); return &f; }
-
-// CHECK: define internal void @"??__Ff@?1??d@@YAPEAU?$c@UBXZ@YAXXZ"()
-// CHECK-SAME: !dbg ![[SUBPROGRAM:[0-9]+]] {
-// CHECK: call void @"??1?$c@UBQEAA@XZ"(%struct.c* 
@"?f@?1??d@@YAPEAU?$c@UBXZ@4U2@A"), !dbg ![[LOCATION:[0-9]+]]
-// CHECK-NEXT: ret void, !dbg ![[LOCATION]]
-// CHECK: ![[SUBPROGRAM]] = distinct !DISubprogram(name: "`dynamic atexit 
destructor for 'f'"
-// CHECK-SAME: flags: DIFlagArtificial
-// CHECK: ![[LOCATION]] = !DILocation(line: 0, scope: ![[SUBPROGRAM]])

Modified: cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp?rev=369633&r1=369632&r2=369633&view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp Thu Aug 22 
02:07:25 2019
@@ -30,24 +30,24 @@ A FooTpl::sdm_tpl(sizeof(U) + sizeof(
 template A FooTpl::sdm_tpl;
 
 // CHECK-NOKEXT: !DISubprogram(name: "__cxx_global_var_init",{{.*}} line: 
15,{{.*}} DISPFlagLocalToUnit | DISPFlagDefinition
-// CHECK-NOKEXT: !DISubprogram(name: "__dtor_glob",{{.*}}: DISPFlagLocalToUnit 
| DISPFlagDefinition
+// CHECK-NOKEXT: !DISubprogram(name: "__dtor_glob",{{.*}} line: 15,{{.*}} 
DISPFlagLocalToUnit | DISPFlagDefinition
 // CHECK-NOKEXT: !DISubprogram(name: "__cxx_global_var_init.1",{{.*}} line: 
16,{{.*}} DISPFlagLocalToUnit | DISPFlagDefinition
 // CHECK-NOKEXT: !DISubprogram(name: "__cxx_global_array_dtor",{{.*}} line: 
16,{{.*}} DISPFlagLocalToUnit | DISPFlagDefinition
-// CHECK-NOKEXT: !DISubprogram(name: "__dtor_array",{{.*}}: 
DISPFlagLocalToUnit | DISPFlagDefinition
-// CHECK-NOKEXT: !DISubprogram(name: "__dtor__ZZ3foovE4stat",{{.*}} 
DISPFlagLocalToUnit | DISPFlagDefinition
+// CHECK-NOKEXT: !DISubprogram(name: "__dtor_array",{{.*}} line: 16,{{.*}} 
DISPFlagLocalToUnit | DISPFlagDefinition
+// CHECK-NOKEXT: !DISubprogram(name: "__dtor__ZZ3foovE4stat",{{

Re: r369458 - [DebugInfo] Add debug location to dynamic atexit destructor

2019-08-22 Thread Hans Wennborg via cfe-commits

This broke the Chromium build, see
https://bugs.chromium.org/p/chromium/issues/detail?id=996618#c1 for a
reproducer.

I've reverted in r369633.


On Wed, Aug 21, 2019 at 12:08 AM Alexandre Ganea via cfe-commits
 wrote:
>
> Author: aganea
> Date: Tue Aug 20 15:09:49 2019
> New Revision: 369458
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369458&view=rev
> Log:
> [DebugInfo] Add debug location to dynamic atexit destructor
>
> Fixes PR43012
>
> Differential Revision: https://reviews.llvm.org/D66328
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=369458&r1=369457&r2=369458&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Aug 20 15:09:49 2019
> @@ -3564,7 +3564,8 @@ void CGDebugInfo::EmitFunctionStart(Glob
>if (Name.startswith("\01"))
>  Name = Name.substr(1);
>
> -  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
> +  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
> +  (isa(D) && GD.getDynamicInitKind() == 
> DynamicInitKind::AtExit)) {
>  Flags |= llvm::DINode::FlagArtificial;
>  // Artificial functions should not silently reuse CurLoc.
>  CurLoc = SourceLocation();
>
> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=369458&r1=369457&r2=369458&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Tue Aug 20 15:09:49 2019
> @@ -247,6 +247,8 @@ llvm::Function *CodeGenFunction::createA
>
>CGF.StartFunction(GlobalDecl(&VD, DynamicInitKind::AtExit),
>  CGM.getContext().VoidTy, fn, FI, FunctionArgList());
> +  // Emit an artificial location for this function.
> +  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
>
>llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
>
>
> Added: cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp?rev=369458&view=auto
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp (added)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp Tue Aug 20 15:09:49 
> 2019
> @@ -0,0 +1,20 @@
> +// RUN: %clang_cc1 -emit-llvm %s -gcodeview -debug-info-kind=limited -o - | 
> FileCheck %s
> +
> +struct a {
> +  ~a();
> +};
> +template  struct c : a {
> +  c(void (b::*)());
> +};
> +struct B {
> +  virtual void e();
> +};
> +c *d() { static c f(&B::e); return &f; }
> +
> +// CHECK: define internal void @"??__Ff@?1??d@@YAPEAU?$c@UBXZ@YAXXZ"()
> +// CHECK-SAME: !dbg ![[SUBPROGRAM:[0-9]+]] {
> +// CHECK: call void @"??1?$c@UBQEAA@XZ"(%struct.c* 
> @"?f@?1??d@@YAPEAU?$c@UBXZ@4U2@A"), !dbg ![[LOCATION:[0-9]+]]
> +// CHECK-NEXT: ret void, !dbg ![[LOCATION]]
> +// CHECK: ![[SUBPROGRAM]] = distinct !DISubprogram(name: "`dynamic atexit 
> destructor for 'f'"
> +// CHECK-SAME: flags: DIFlagArtificial
> +// CHECK: ![[LOCATION]] = !DILocation(line: 0, scope: ![[SUBPROGRAM]])
>
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp?rev=369458&r1=369457&r2=369458&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp Tue Aug 20 
> 15:09:49 2019
> @@ -30,24 +30,24 @@ A FooTpl::sdm_tpl(sizeof(U) + sizeof(
>  template A FooTpl::sdm_tpl;
>
>  // CHECK-NOKEXT: !DISubprogram(name: "__cxx_global_var_init",{{.*}} line: 
> 15,{{.*}} DISPFlagLocalToUnit | DISPFlagDefinition
> -// CHECK-NOKEXT: !DISubprogram(name: "__dtor_glob",{{.*}} line: 15,{{.*}} 
> DISPFlagLocalToUnit | DISPFlagDefinition
> +// CHECK-NOKEXT: !DISubprogram(name: "__dtor_glob",{{.*}}: 
> DISPFlagLocalToUnit | DISPFlagDefinition
>  // CHECK-NOKEXT: !DISubprogram(name: "__cxx_global_var_init.1",{{.*}} line: 
> 16,{{.*}} DISPFlagLocalToUnit | DISPFlagDefinition
>  // CHECK-NOKEXT: !DISubprogram(name: "__cxx_global_array_dtor",{{.*}} line: 
> 16,{{.*}} DISPFlagLocalToUnit | DISPFlagDefinition
> -// CHECK-NOKEXT: !DISubprogram(name: "__dtor_array",{{.*}} line: 16,{{.*}} 
> DISPFlagLocalToUnit | DISPFlagDefinition
> -// CHECK-NOKEXT: !DISubprogram(name: "__dtor__ZZ3foovE4stat",{{.*}} line: 
> 19,{{.*}} DISPFlagLocalToUnit | DISPFl

[PATCH] D66578: Remove \brief commands from doxygen comments.

2019-08-22 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM. Kill it with fire


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66578



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

[PATCH] D66538: [AST] AST structural equivalence to work internally with pairs.

2019-08-22 Thread Gabor Marton via Phabricator via cfe-commits

martong added inline comments.



Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:1586
-  if (EquivToD1)
-return EquivToD1 == D2->getCanonicalDecl();
 

balazske wrote:
> It looks like that the original code is correct in the decision of structural 
> equivalence of the original pair. If we have an (A,B) and (A,C) to compare, B 
> and C are in different decl chain, then (A,B) or (A,C) will be non-equivalent 
> (unless B and C are equivalent, but what to do in this case?). The problem 
> was that the code assumed that in this case always A and B (or A and C) are 
> non-equivalent. If `NonEquivalentDecls` is not filled in this case (or not 
> used at all) the problem does not exist.
I have a déjá vu feeling. We already had tried to get rid of the redecl chain 
comparison:
https://github.com/Ericsson/clang/pull/382/files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66538



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

[PATCH] D66538: [AST] AST structural equivalence to work internally with pairs.

2019-08-22 Thread Gabor Marton via Phabricator via cfe-commits

martong added inline comments.



Comment at: clang/unittests/AST/StructuralEquivalenceTest.cpp:1323
+NonEquivalentDecls.end());
+  EXPECT_EQ(NonEquivalentDecls.find(std::make_pair(y1, y2)),
+NonEquivalentDecls.end());

This should be `EXPECT_NE` ! Because `void y(A*)` is not eq to `void y(B*)`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66538



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

[PATCH] D66541: [clangd] Send highlighting diff beyond the end of the file.

2019-08-22 Thread Haojian Wu via Phabricator via cfe-commits

hokein marked an inline comment as done.
hokein added inline comments.



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:625
+  testing::UnorderedElementsAre(
+  testing::AllOf(LineNumber(3), EmptyHighlightings()),
+  testing::AllOf(LineNumber(4), EmptyHighlightings(;

jvikstrom wrote:
> Maybe create the HighlightingLine objects for Line 3 and 4 and add them 
> directly in the `UnorderedElementsAre` because then we don't have to create 
> the matchers.
we prefer to use gtest matchers in the unittest as they are easier to 
understand, and provide better error messages (when the tests fail).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66541



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

[PATCH] D66302: [SVE][Inline-Asm] Support for SVE asm operands

2019-08-22 Thread Kerry McLaughlin via Phabricator via cfe-commits

kmclaughlin updated this revision to Diff 216574.
kmclaughlin added a comment.

- Changed printAsmRegInClass in AArch64AsmPrinter.cpp to accept //unsigned 
AltName// instead of //bool isVector//
- Added a comment to explain the test in aarch64-sve-asm-negative.ll


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

https://reviews.llvm.org/D66302

Files:
  docs/LangRef.rst
  lib/Target/AArch64/AArch64AsmPrinter.cpp
  lib/Target/AArch64/AArch64ISelLowering.cpp
  lib/Target/AArch64/AArch64InstrInfo.cpp
  lib/Target/AArch64/AArch64SVEInstrInfo.td
  test/CodeGen/AArch64/aarch64-sve-asm-negative.ll
  test/CodeGen/AArch64/aarch64-sve-asm.ll
  test/CodeGen/AArch64/arm64-inline-asm.ll

Index: test/CodeGen/AArch64/arm64-inline-asm.ll
===
--- test/CodeGen/AArch64/arm64-inline-asm.ll
+++ test/CodeGen/AArch64/arm64-inline-asm.ll
@@ -138,6 +138,8 @@
   %a = alloca [2 x float], align 4
   %arraydecay = getelementptr inbounds [2 x float], [2 x float]* %a, i32 0, i32 0
   %0 = load <2 x float>, <2 x float>* %data, align 8
+  call void asm sideeffect "ldr ${1:z}, [$0]\0A", "r,w"(float* %arraydecay, <2 x float> %0) nounwind
+  ; CHECK: ldr {{z[0-9]+}}, [{{x[0-9]+}}]
   call void asm sideeffect "ldr ${1:q}, [$0]\0A", "r,w"(float* %arraydecay, <2 x float> %0) nounwind
   ; CHECK: ldr {{q[0-9]+}}, [{{x[0-9]+}}]
   call void asm sideeffect "ldr ${1:d}, [$0]\0A", "r,w"(float* %arraydecay, <2 x float> %0) nounwind
Index: test/CodeGen/AArch64/aarch64-sve-asm.ll
===
--- /dev/null
+++ test/CodeGen/AArch64/aarch64-sve-asm.ll
@@ -0,0 +1,44 @@
+; RUN: llc < %s -mtriple aarch64-none-linux-gnu -mattr=+sve -stop-after=finalize-isel | FileCheck %s --check-prefix=CHECK
+
+target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-none-linux-gnu"
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_3b = COPY [[ARG1]]
+define  @test_svadd_i8( %Zn,  %Zm) {
+  %1 = tail call  asm "add $0.b, $1.b, $2.b", "=w,w,y"( %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_4b = COPY [[ARG1]]
+define  @test_svsub_i64( %Zn,  %Zm) {
+  %1 = tail call  asm "sub $0.d, $1.d, $2.d", "=w,w,x"( %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_3b = COPY [[ARG1]]
+define  @test_svfmul_f16( %Zn,  %Zm) {
+  %1 = tail call  asm "fmul $0.h, $1.h, $2.h", "=w,w,y"( %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_4b = COPY [[ARG1]]
+define  @test_svfmul_f( %Zn,  %Zm) {
+  %1 = tail call  asm "fmul $0.s, $1.s, $2.s", "=w,w,x"( %Zn,  %Zm)
+  ret  %1
+}
Index: test/CodeGen/AArch64/aarch64-sve-asm-negative.ll
===
--- /dev/null
+++ test/CodeGen/AArch64/aarch64-sve-asm-negative.ll
@@ -0,0 +1,12 @@
+; RUN: not llc -mtriple aarch64-none-linux-gnu -mattr=+neon -o %t.s -filetype=asm %s 2>&1 | FileCheck %s
+
+; The 'y' constraint only applies to SVE vector registers (Z0-Z7)
+; The test below ensures that we get an appropriate error should the
+; constraint be used with a Neon register.
+
+; Function Attrs: nounwind readnone
+; CHECK: error: couldn't allocate input reg for constraint 'y'
+define <4 x i32> @test_neon(<4 x i32> %in1, <4 x i32> %in2) {
+  %1 = tail call <4 x i32> asm "add $0.4s, $1.4s, $2.4s", "=w,w,y"(<4 x i32> %in1, <4 x i32> %in2)
+  ret <4 x i32> %1
+}
Index: lib/Target/AArch64/AArch64SVEInstrInfo.td
===
--- lib/Target/AArch64/AArch64SVEInstrInfo.td
+++ lib/Target/AArch64/AArch64SVEInstrInfo.td
@@ -1020,6 +1020,56 @@
   (FCMGT_PPzZZ_S PPR32:$Zd, PPR3bAny:$Pg, ZPR32:$Zn, ZPR32:$Zm), 0>;
   def : InstAlias<"fcmlt $Zd, $Pg/z, $Zm, $Zn",
   (FCMGT_PPzZZ_D PPR64:$Zd, PPR3bAny:$Pg, ZPR64:$Zn, ZPR64:$Zm), 0>;
+
+  def : Pat<(nxv16i8 (bitconvert (nxv8i16 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv4i32 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv2i64 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv8f16 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv4f32 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv2f64 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+
+  def : Pat<(nxv8i16

[PATCH] D66538: [AST] AST structural equivalence to work internally with pairs.

2019-08-22 Thread Balázs Kéri via Phabricator via cfe-commits

balazske marked an inline comment as done.
balazske added inline comments.



Comment at: clang/unittests/AST/StructuralEquivalenceTest.cpp:1323
+NonEquivalentDecls.end());
+  EXPECT_EQ(NonEquivalentDecls.find(std::make_pair(y1, y2)),
+NonEquivalentDecls.end());

martong wrote:
> This should be `EXPECT_NE` ! Because `void y(A*)` is not eq to `void y(B*)`
We have no guarantee that every non-equivalent Decl will be collected in 
`NonEquivalentDecls`, in this concrete case only the `(A1,B2)` pair is inserted 
(this is why the test passes). This line is to be removed, probably the last 
line too (it is an implementation detail that `(A1,B2)` is inserted but not 
even `(C1,C2)`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66538



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

[PATCH] D66018: [ARM] Take into account -mcpu and -mfpu options while handling 'crypto' feature

2019-08-22 Thread Diogo N. Sampaio via Phabricator via cfe-commits

dnsampaio added a comment.

Hi @krisb,
thanks for looking into this, and sorry for the delay, was out for a week.




Comment at: lib/Driver/ToolChains/Arch/ARM.cpp:486-490
+  if (ArchKind == llvm::ARM::ArchKind::ARMV8A ||
+  ArchKind == llvm::ARM::ArchKind::ARMV8_1A ||
+  ArchKind == llvm::ARM::ArchKind::ARMV8_2A ||
+  ArchKind == llvm::ARM::ArchKind::ARMV8_3A ||
+  ArchKind == llvm::ARM::ArchKind::ARMV8_4A) {

Could we do something a little more permanent here, for example it is already 
missing ARMV8_5A.
Digging I found the function `StringRef arm::getLLVMArchSuffixForARM(StringRef 
CPU, StringRef Arch, const llvm::Triple &Triple)`.
Perhaps just testing  
`(llvm::ARM::parseArchVersion(arm::getLLVMArchSuffixForARM(StringRef CPU, 
StringRef Arch, const llvm::Triple &Triple)) >= 8)`
would do a better job.




Comment at: lib/Driver/ToolChains/Arch/ARM.cpp:659
   llvm::ARM::ArchKind ArchKind;
-  if (CPU == "generic") {
+  if (CPU == "generic" || CPU.empty()) {
 std::string ARMArch = tools::arm::getARMArch(Arch, Triple);

Good catch.


Repository:
  rC Clang

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

https://reviews.llvm.org/D66018



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

[PATCH] D64695: [clang-format] Modified SortIncludes and IncludeCategories to priority for sorting #includes within the Group Category.

2019-08-22 Thread Manikishan Ghantasala via Phabricator via cfe-commits

Manikishan updated this revision to Diff 216576.
Manikishan edited the summary of this revision.
Manikishan added a comment.

I have removed the introduction to the NetBSDStyle, as there are some styles 
that are needed to implemented before launching the NetBSD style.


Repository:
  rC Clang

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

https://reviews.llvm.org/D64695

Files:
  docs/ClangFormatStyleOptions.rst
  include/clang/Tooling/Inclusions/HeaderIncludes.h
  include/clang/Tooling/Inclusions/IncludeStyle.h
  lib/Format/Format.cpp
  lib/Tooling/Inclusions/HeaderIncludes.cpp
  lib/Tooling/Inclusions/IncludeStyle.cpp
  unittests/Format/SortIncludesTest.cpp

Index: unittests/Format/SortIncludesTest.cpp
===
--- unittests/Format/SortIncludesTest.cpp
+++ unittests/Format/SortIncludesTest.cpp
@@ -70,6 +70,78 @@
  {tooling::Range(25, 1)}));
 }
 
+
+TEST_F(SortIncludesTest, SortedIncludesUsingSortPriorityAttribute) {
+  FmtStyle.IncludeStyle.IncludeBlocks = tooling::IncludeStyle::IBS_Regroup;
+  FmtStyle.IncludeStyle.IncludeCategories = {
+  {"^", 1, 0},
+  {"^", 1, 1},
+  {"^", 8, 10},
+  {"^\".*\\.h\"", 10, 12}};
+  EXPECT_EQ("#include \n"  
+  "#include \n"  
+  "#include \n"  
+  "#include \n" 
+  "#include \n"
+  "#include \n"
+  "\n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "\n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "\n"
+  "#include \n"
+  "\n"
+  "#include \"pathnames.h\"\n",
+  sort("#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"  
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \"pathnames.h\"\n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"));
+}
+TEST_F(SortIncludesTest, SortPriorityNotDefined) {
+  FmtStyle = getLLVMStyle();
+  EXPECT_EQ("#include \"FormatTestUtils.h\"\n"
+"#include \"clang/Format/Format.h\"\n"
+"#include \"llvm/ADT/None.h\"\n"
+"#include \"llvm/Support/Debug.h\"\n"
+"#include \"gtest/gtest.h\"\n",
+sort("#include \"clang/Format/Format.h\"\n"
+"#include \"llvm/ADT/None.h\"\n"
+"#include \"FormatTestUtils.h\"\n"
+"#include \"gtest/gtest.h\"\n"
+"#include \"llvm/Support/Debug.h\"\n"));
+}
+
 TEST_F(SortIncludesTest, NoReplacementsForValidIncludes) {
   // Identical #includes have led to a failure with an unstable sort.
   std::string Code = "#include \n"
Index: lib/Tooling/Inclusions/IncludeStyle.cpp
===
--- lib/Tooling/Inclusions/IncludeStyle.cpp
+++ lib/Tooling/Inclusions/IncludeStyle.cpp
@@ -17,6 +17,7 @@
 IO &IO, IncludeStyle::IncludeCategory &Category) {
   IO.mapOptional("Regex", Category.Regex);
   IO.mapOptional("Priority", Category.Priority);
+  IO.mapOptional("SortPriority", Category.SortPriority);
 }
 
 void ScalarEnumerationTraits::enumeration(
Index: lib/Tooling/Inclusions/HeaderIncludes.cpp
===
--- lib/Tooling/Inclusions/HeaderIncludes.cpp
+++ lib/Tooling/Inclusions/HeaderIncludes.cpp
@@ -199,6 +199,19 @@
   return Ret;
 }
 
+int IncludeCategoryManager::getSortIncludePriority(StringRef IncludeName, bool CheckMainHeader) const {
+  int Ret = INT_MAX;
+  for (unsigned i = 0, e = CategoryRegexs.size(); i != e; ++i)
+if (CategoryRegexs[i].match(IncludeName)) {
+  Ret = Style.IncludeCategories[i].SortPriority;
+  if(Ret == 0)
+Ret = Style.IncludeCategories[i].Priority;
+  break;
+}
+  if (CheckMainHeader && IsMainFile && Ret > 0 && isMainHeader(IncludeName))
+Ret = 0;
+  return Ret;
+}
 bool IncludeCategoryManager::isMainHeader(StringRef IncludeName) const {
   if (!IncludeName.startswith("\""))
 return false;
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1727,6 +1727,7 @@
   StringRef Text;
   unsigned Offset;
   int Category;
+  int Priority;
 };
 
 struct JavaImportDirective {
@@ -1790,6 +1791,7 @@
 ArrayRef Ranges, StringRef FileName,
 StringRef Code, tooling::Replacements &Replaces,
 unsigned *Cursor) {
+  tooling::IncludeCategoryManager Categories(Style.IncludeStyle, FileName);
   unsigned IncludesBeginOffset = Includes.front().Offset;
   unsigned IncludesEndOffset =
   Includes.back().Offse

[PATCH] D64695: [clang-format] Modified SortIncludes and IncludeCategories to priority for sorting #includes within the Group Category.

2019-08-22 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D64695



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

[PATCH] D66336: [ASTImporter] Add development internals docs

2019-08-22 Thread Gabor Marton via Phabricator via cfe-commits

martong updated this revision to Diff 216579.
martong marked an inline comment as done.
martong added a comment.

- Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66336

Files:
  clang/docs/InternalsManual.rst

Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -1447,6 +1447,495 @@
 are not ``Redeclarable`` -- in that case, a ``Mergeable`` base class is used
 instead).
 
+The ASTImporter
+---
+
+The ``ASTImporter`` class imports nodes of an ``ASTContext`` into another
+``ASTContext``. Please refer to the document :doc:`ASTImporter: Merging Clang
+ASTs ` for an introduction. And please read through the
+high-level `description of the import algorithm
+`_, this is essential for
+understanding further implementation details of the importer.
+
+.. _templated:
+
+Abstract Syntax Graph
+^
+
+Despite the name, the Clang AST is not a tree. It is a directed graph with
+cycles. One example of a cycle is the connection between a
+``ClassTemplateDecl`` and its "templated" ``CXXRecordDecl``. The *templated*
+``CXXRecordDecl`` represents all the fields and methods inside the class
+template, while the ``ClassTemplateDecl`` holds the information which is
+related to being a template, i.e. template arguments, etc. We can get the
+*templated* class (the ``CXXRecordDecl``) of a ``ClassTemplateDecl`` with
+``ClassTemplateDecl::getTemplatedDec()``. And we can get back a pointer of the
+"described" class template from the *templated* class:
+``CXXRecordDecl::getDescribedTemplate()``. So, this is a cycle between two
+nodes: between the *templated* and the *described* node. There may be various
+other kinds of cycles in the AST especially in case of declarations.
+
+.. _structural-eq:
+
+Structural Equivalency
+^^
+
+Importing one AST node copies that node into the destination ``ASTContext``. To
+copy one node means that we create a new node in the "to" context then we set
+its properties to be equal to the properties of the source node. Before the
+copy, we make sure that the source node is not *structurally equivalent* to any
+existing node in the destination context. If it happens to be equivalent then
+we skip the copy.
+
+The informal definition of structural equivalency is the following:
+Two nodes are **structurally equivalent** if they are
+
+- builtin types and refer to the same type, e.g. ``int`` and ``int`` are
+  structurally equivalent,
+- function types and all their parameters have structurally equivalent types,
+- record types and all their fields in order of their definition have the same
+  identifier names and structurally equivalent types,
+- variable or function declarations and they have the same identifier name and
+  their types are structurally equivalent.
+
+In C, two types are structurally equivalent if they are *compatible types*. For
+a formal definition of *compatible types*, please refer to 6.2.7/1 in the C11
+standard. However, there is no definition for *compatible types* in the C++
+standard. Still, we extend the definition of structural equivalency to
+templates and their instantiations similarly: besides checking the previously
+mentioned properties, we have to check for equivalent template
+parameters/arguments, etc.
+
+The structural equivalent check can be and is used independently from the
+ASTImporter, e.g. the ``clang::Sema`` class uses it also.
+
+The equivalence of nodes may depend on the equivalency of other pairs of nodes.
+Thus, the check is implemented as a parallel graph traversal. We traverse
+through the nodes of both graphs at the same time. The actual implementation is
+similar to breadth-first-search. Let's say we start the traverse with the 
+pair of nodes. Whenever the traversal reaches a pair  then the following
+statements are true:
+
+- A and X are nodes from the same ASTContext.
+- B and Y are nodes from the same ASTContext.
+- A and B may or may not be from the same ASTContext.
+- if A == X (pointer equivalency) then (there is a cycle during the traverse)
+
+  - A and B are structurally equivalent if and only if
+
+- B and Y are part of the same redeclaration chain,
+- All dependent nodes on the path from  to  are structurally
+  equivalent.
+
+When we compare two classes or enums and one of them is incomplete or has
+unloaded external lexical declarations then we cannot descend to compare their
+contained declarations. So in these cases they are considered equal if they
+have the same names. This is the way how we compare forward declarations with
+definitions.
+
+.. TODO Should we elaborate the actual implementation of the graph traversal,
+.. which is a very weird BFS traversal?
+
+Redeclaration Chains
+
+
+The early version of the ``ASTImporter``'s

[PATCH] D66336: [ASTImporter] Add development internals docs

2019-08-22 Thread Gabor Marton via Phabricator via cfe-commits

martong marked 6 inline comments as done.
martong added a comment.

Thanks for the review!




Comment at: clang/docs/InternalsManual.rst:1470
+*templated* class (the ``CXXRecordDecl``) of a ``ClassTemplateDecl`` with
+``ClassTemplateDecl::getTemplatedDec()``. And we can get back a pointer of the
+"described" class template from the *templated* class:

a_sidorin wrote:
> TemplatedDec_l_?
Could you please elaborate, I don't get the meaning of the comment.



Comment at: clang/docs/InternalsManual.rst:1528
+
+When we compare two classes or enums and one of them is incomplete or has
+unloaded external lexical declarations then we cannot descend to compare their

a_sidorin wrote:
> I think we can extend this to point that import of all named declarations is 
> preceded by name lookup.
I would not put that here,  because in this section we describe the structural 
equivalency, which can be used independently from the import mechanism.

Plus, we mention that explicitly in the prerequisite User document of 
ASTImporter ( LibASTImporter.rst)
We also mention it later, in this section: "Lookup Problems".




Comment at: clang/docs/InternalsManual.rst:1660
+context. Consequently, calling a declaration's ``::Create()`` function directly
+would lead to errors, please don't do that!
+

balazske wrote:
> We can mention that there is still the probability of having an infinite 
> import recursion if things are imported from each other in wrong way. (From a 
> visitor for `A` import of `B` is requested before create of node `A` and the 
> same in visitor for `B`. The new `A` node is not yet created and not in 
> `ImportedDecls` when import of `B` is reached.) The best is to have no import 
> of other nodes in a visitor for `A` before create of node `A`. Or if really 
> needed (for example in the template case) only for type `B` that does not the 
> same thing with type `A`.
Ok, I added that, but rephrased to connect smoother to the context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66336



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

r369641 - [OpenCL] Fix declaration of enqueue_marker

2019-08-22 Thread Yaxun Liu via cfe-commits

Author: yaxunl
Date: Thu Aug 22 04:18:59 2019
New Revision: 369641

URL: http://llvm.org/viewvc/llvm-project?rev=369641&view=rev
Log:
[OpenCL] Fix declaration of enqueue_marker

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

Modified:
cfe/trunk/lib/Headers/opencl-c.h

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=369641&r1=369640&r2=369641&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Thu Aug 22 04:18:59 2019
@@ -15350,7 +15350,7 @@ ndrange_t __ovld ndrange_3D(const size_t
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3]);
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3], const size_t[3]);
 
-int __ovld enqueue_marker(queue_t, uint, const __private clk_event_t*, 
__private clk_event_t*);
+int __ovld enqueue_marker(queue_t, uint, const clk_event_t*, clk_event_t*);
 
 void __ovld retain_event(clk_event_t);
 


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

[PATCH] D66512: [OpenCL] Fix declaration of enqueue_marker

2019-08-22 Thread Yaxun Liu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL369641: [OpenCL] Fix declaration of enqueue_marker (authored 
by yaxunl, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66512?vs=216319&id=216582#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66512

Files:
  cfe/trunk/lib/Headers/opencl-c.h


Index: cfe/trunk/lib/Headers/opencl-c.h
===
--- cfe/trunk/lib/Headers/opencl-c.h
+++ cfe/trunk/lib/Headers/opencl-c.h
@@ -15350,7 +15350,7 @@
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3]);
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3], const size_t[3]);
 
-int __ovld enqueue_marker(queue_t, uint, const __private clk_event_t*, 
__private clk_event_t*);
+int __ovld enqueue_marker(queue_t, uint, const clk_event_t*, clk_event_t*);
 
 void __ovld retain_event(clk_event_t);
 


Index: cfe/trunk/lib/Headers/opencl-c.h
===
--- cfe/trunk/lib/Headers/opencl-c.h
+++ cfe/trunk/lib/Headers/opencl-c.h
@@ -15350,7 +15350,7 @@
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3]);
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3], const size_t[3]);
 
-int __ovld enqueue_marker(queue_t, uint, const __private clk_event_t*, __private clk_event_t*);
+int __ovld enqueue_marker(queue_t, uint, const clk_event_t*, clk_event_t*);
 
 void __ovld retain_event(clk_event_t);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66584: [clang-format] Support .mjs module javascript extension in clang-format

2019-08-22 Thread Fergal Daly via Phabricator via cfe-commits

fergald created this revision.
fergald added a reviewer: MaskRay.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

PR43085.

This causes .mjs files to be treated as javascript. .mjs is the extension for 
module-javascript. Module javascript is not compatible with non-module java 
script as it uses the "export" and "import" keywords which are only legal in 
module-javascript. As such it uses a different file extension.


Repository:
  rC Clang

https://reviews.llvm.org/D66584

Files:
  lib/Format/Format.cpp


Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -2411,8 +2411,9 @@
 static FormatStyle::LanguageKind getLanguageByFileName(StringRef FileName) {
   if (FileName.endswith(".java"))
 return FormatStyle::LK_Java;
-  if (FileName.endswith_lower(".js") || FileName.endswith_lower(".ts"))
-return FormatStyle::LK_JavaScript; // JavaScript or TypeScript.
+  if (FileName.endswith_lower(".js") || FileName.endswith_lower(".ts") ||
+  FileName.endswith_lower(".mjs"))
+return FormatStyle::LK_JavaScript; // (module) JavaScript or TypeScript.
   if (FileName.endswith(".m") || FileName.endswith(".mm"))
 return FormatStyle::LK_ObjC;
   if (FileName.endswith_lower(".proto") ||


Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -2411,8 +2411,9 @@
 static FormatStyle::LanguageKind getLanguageByFileName(StringRef FileName) {
   if (FileName.endswith(".java"))
 return FormatStyle::LK_Java;
-  if (FileName.endswith_lower(".js") || FileName.endswith_lower(".ts"))
-return FormatStyle::LK_JavaScript; // JavaScript or TypeScript.
+  if (FileName.endswith_lower(".js") || FileName.endswith_lower(".ts") ||
+  FileName.endswith_lower(".mjs"))
+return FormatStyle::LK_JavaScript; // (module) JavaScript or TypeScript.
   if (FileName.endswith(".m") || FileName.endswith(".mm"))
 return FormatStyle::LK_ObjC;
   if (FileName.endswith_lower(".proto") ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r369647 - Revert r369402 "win: Enable /Zc:twoPhase by default if targeting MSVC 2017 update 3 or newer"

2019-08-22 Thread Hans Wennborg via cfe-commits

Author: hans
Date: Thu Aug 22 06:15:36 2019
New Revision: 369647

URL: http://llvm.org/viewvc/llvm-project?rev=369647&view=rev
Log:
Revert r369402 "win: Enable /Zc:twoPhase by default if targeting MSVC 2017 
update 3 or newer"

This broke compiling some ASan tests with never versions of MSVC/the Win
SDK, see https://crbug.com/996675

> MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
> so should clang-cl:
> https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
>
> clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
> or if that's not passed it tries to check what the installed version of
> MSVC is and uses that, and failing that it uses a default version that's
> currently 1911. So this changes the default if no -fmsc-version flag is
> passed and no installed MSVC is detected. (It also changes the default
> if -fmsc-version is passed or MSVC is detected, and either indicates
> _MSC_VER >= 1911.)
>
> As mentioned in the MSDN article, the Windows SDK header files in
> version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
> versions do not work correctly with /Zc:twoPhase. If you need to use
> these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
> the old behavior.
>
> Fixes PR43032.
>
> Differential Revision: https://reviews.llvm.org/D66394

Modified:
cfe/trunk/docs/ReleaseNotes.rst
cfe/trunk/include/clang/Driver/CLCompatOptions.td
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=369647&r1=369646&r2=369647&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Thu Aug 22 06:15:36 2019
@@ -90,9 +90,6 @@ Attribute Changes in Clang
 Windows Support
 ---
 
-- clang-cl now defaults to ``/Zc:twoPhase`` if targeting MSVC2017 update 3 or
-  later (``_MSC_VER`` >= 1911). This matches MSVC's behavior. Explicitly pass
-  ``/Zc:twoPhase-`` to restore the old behavior.
 - ...
 
 C Language Changes in Clang

Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=369647&r1=369646&r2=369647&view=diff
==
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Thu Aug 22 06:15:36 2019
@@ -235,10 +235,10 @@ def _SLASH_Zc_trigraphs : CLFlag<"Zc:tri
 def _SLASH_Zc_trigraphs_off : CLFlag<"Zc:trigraphs-">,
   HelpText<"Disable trigraphs (default)">, Alias;
 def _SLASH_Zc_twoPhase : CLFlag<"Zc:twoPhase">,
-  HelpText<"Enable two-phase name lookup in templates (default)">,
+  HelpText<"Enable two-phase name lookup in templates">,
   Alias;
 def _SLASH_Zc_twoPhase_ : CLFlag<"Zc:twoPhase-">,
-  HelpText<"Disable two-phase name lookup in templates">,
+  HelpText<"Disable two-phase name lookup in templates (default)">,
   Alias;
 def _SLASH_Z7 : CLFlag<"Z7">,
   HelpText<"Enable CodeView debug information in object files">;

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=369647&r1=369646&r2=369647&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Thu Aug 22 06:15:36 2019
@@ -4883,14 +4883,12 @@ void Clang::ConstructJob(Compilation &C,
 !IsWindowsMSVC || IsMSVC2015Compatible))
 CmdArgs.push_back("-fno-threadsafe-statics");
 
-  // -fno-delayed-template-parsing is default, except when targeting MSVC
-  // earlier than MSVC 2017 15.3 (_MSC_VER 1911).  Windows SDK versions
-  // 10.0.15063.0 (Creators Update or Redstone 2) and earlier require this to
-  // parse.
-  bool IsMSVCBefore2017Update3 = !MSVT.empty() && MSVT < VersionTuple(19, 11);
+  // -fno-delayed-template-parsing is default, except when targeting MSVC.
+  // Many old Windows SDK versions require this to parse.
+  // FIXME: MSVC introduced /Zc:twoPhase- to disable this behavior in their
+  // compiler. We should be able to disable this by default at some point.
   if (Args.hasFlag(options::OPT_fdelayed_template_parsing,
-   options::OPT_fno_delayed_template_parsing,
-   IsMSVCBefore2017Update3))
+   options::OPT_fno_delayed_template_parsing, IsWindowsMSVC))
 CmdArgs.push_back("-fdelayed-template-parsing");
 
   // -fgnu-keywords default varies depending on language; only pass if

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=369647&r1=369646&r2=369647&view=diff
=

Re: r369402 - win: Enable /Zc:twoPhase by default if targeting MSVC 2017 update 3 or newer

2019-08-22 Thread Hans Wennborg via cfe-commits

Reverted in r369647 due to
https://bugs.chromium.org/p/chromium/issues/detail?id=996675

On Tue, Aug 20, 2019 at 6:26 PM Nico Weber via cfe-commits
 wrote:
>
> Author: nico
> Date: Tue Aug 20 09:28:11 2019
> New Revision: 369402
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369402&view=rev
> Log:
> win: Enable /Zc:twoPhase by default if targeting MSVC 2017 update 3 or newer
>
> MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
> so should clang-cl:
> https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
>
> clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
> or if that's not passed it tries to check what the installed version of
> MSVC is and uses that, and failing that it uses a default version that's
> currently 1911. So this changes the default if no -fmsc-version flag is
> passed and no installed MSVC is detected. (It also changes the default
> if -fmsc-version is passed or MSVC is detected, and either indicates
> _MSC_VER >= 1911.)
>
> As mentioned in the MSDN article, the Windows SDK header files in
> version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
> versions do not work correctly with /Zc:twoPhase. If you need to use
> these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
> the old behavior.
>
> Fixes PR43032.
>
> Differential Revision: https://reviews.llvm.org/D66394
>
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/include/clang/Driver/CLCompatOptions.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/test/Driver/cl-options.c
>
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=369402&r1=369401&r2=369402&view=diff
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Tue Aug 20 09:28:11 2019
> @@ -90,6 +90,9 @@ Attribute Changes in Clang
>  Windows Support
>  ---
>
> +- clang-cl now defaults to ``/Zc:twoPhase`` if targeting MSVC2017 update 3 or
> +  later (``_MSC_VER`` >= 1911). This matches MSVC's behavior. Explicitly pass
> +  ``/Zc:twoPhase-`` to restore the old behavior.
>  - ...
>
>  C Language Changes in Clang
>
> Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=369402&r1=369401&r2=369402&view=diff
> ==
> --- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
> +++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Aug 20 09:28:11 2019
> @@ -235,10 +235,10 @@ def _SLASH_Zc_trigraphs : CLFlag<"Zc:tri
>  def _SLASH_Zc_trigraphs_off : CLFlag<"Zc:trigraphs-">,
>HelpText<"Disable trigraphs (default)">, Alias;
>  def _SLASH_Zc_twoPhase : CLFlag<"Zc:twoPhase">,
> -  HelpText<"Enable two-phase name lookup in templates">,
> +  HelpText<"Enable two-phase name lookup in templates (default)">,
>Alias;
>  def _SLASH_Zc_twoPhase_ : CLFlag<"Zc:twoPhase-">,
> -  HelpText<"Disable two-phase name lookup in templates (default)">,
> +  HelpText<"Disable two-phase name lookup in templates">,
>Alias;
>  def _SLASH_Z7 : CLFlag<"Z7">,
>HelpText<"Enable CodeView debug information in object files">;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=369402&r1=369401&r2=369402&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Tue Aug 20 09:28:11 2019
> @@ -4883,12 +4883,14 @@ void Clang::ConstructJob(Compilation &C,
>  !IsWindowsMSVC || IsMSVC2015Compatible))
>  CmdArgs.push_back("-fno-threadsafe-statics");
>
> -  // -fno-delayed-template-parsing is default, except when targeting MSVC.
> -  // Many old Windows SDK versions require this to parse.
> -  // FIXME: MSVC introduced /Zc:twoPhase- to disable this behavior in their
> -  // compiler. We should be able to disable this by default at some point.
> +  // -fno-delayed-template-parsing is default, except when targeting MSVC
> +  // earlier than MSVC 2017 15.3 (_MSC_VER 1911).  Windows SDK versions
> +  // 10.0.15063.0 (Creators Update or Redstone 2) and earlier require this to
> +  // parse.
> +  bool IsMSVCBefore2017Update3 = !MSVT.empty() && MSVT < VersionTuple(19, 
> 11);
>if (Args.hasFlag(options::OPT_fdelayed_template_parsing,
> -   options::OPT_fno_delayed_template_parsing, IsWindowsMSVC))
> +   options::OPT_fno_delayed_template_parsing,
> +   IsMSVCBefore2017Update3))
>  CmdArgs.push_back("-fdelayed-template-parsing");
>
>// -fgnu-keywords default varies depending on language; only pass if
>
> Modified

[PATCH] D66559: [OPENMP] Update the diagnosis message for canonical loop form

2019-08-22 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added a comment.

`!=` form is part of OpenMP 5.0. It would be good to allow this form for OpenMP 
5.0 only and emit this new error message only for OpenMP 5.0


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66559



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-22 Thread Sam Elliott via Phabricator via cfe-commits

lenary updated this revision to Diff 216594.
lenary added a comment.
Herald added a subscriber: pzheng.

Update MaxAtomicPromote width to treat it like an ABI feature, and set it to 128


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57450

Files:
  clang/lib/Basic/Targets/RISCV.h
  clang/test/CodeGen/riscv-atomics.c

Index: clang/test/CodeGen/riscv-atomics.c
===
--- /dev/null
+++ clang/test/CodeGen/riscv-atomics.c
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -triple riscv32 -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32I
+// RUN: %clang_cc1 -triple riscv32 -target-feature +a -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32IA
+// RUN: %clang_cc1 -triple riscv64 -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64I
+// RUN: %clang_cc1 -triple riscv64 -target-feature +a -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64IA
+
+// This test demonstrates that MaxAtomicInlineWidth is set appropriately when
+// the atomics instruction set extension is enabled.
+
+#include 
+#include 
+
+void test_i8_atomics(_Atomic(int8_t) * a, int8_t b) {
+  // RV32I:  call zeroext i8 @__atomic_load_1
+  // RV32I:  call void @__atomic_store_1
+  // RV32I:  call zeroext i8 @__atomic_fetch_add_1
+  // RV32IA: load atomic i8, i8* %a seq_cst, align 1
+  // RV32IA: store atomic i8 %b, i8* %a seq_cst, align 1
+  // RV32IA: atomicrmw add i8* %a, i8 %b seq_cst
+  // RV64I:  call zeroext i8 @__atomic_load_1
+  // RV64I:  call void @__atomic_store_1
+  // RV64I:  call zeroext i8 @__atomic_fetch_add_1
+  // RV64IA: load atomic i8, i8* %a seq_cst, align 1
+  // RV64IA: store atomic i8 %b, i8* %a seq_cst, align 1
+  // RV64IA: atomicrmw add i8* %a, i8 %b seq_cst
+  __c11_atomic_load(a, memory_order_seq_cst);
+  __c11_atomic_store(a, b, memory_order_seq_cst);
+  __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
+
+void test_i32_atomics(_Atomic(int32_t) * a, int32_t b) {
+  // RV32I:  call i32 @__atomic_load_4
+  // RV32I:  call void @__atomic_store_4
+  // RV32I:  call i32 @__atomic_fetch_add_4
+  // RV32IA: load atomic i32, i32* %a seq_cst, align 4
+  // RV32IA: store atomic i32 %b, i32* %a seq_cst, align 4
+  // RV32IA: atomicrmw add i32* %a, i32 %b seq_cst
+  // RV64I:  call signext i32 @__atomic_load_4
+  // RV64I:  call void @__atomic_store_4
+  // RV64I:  call signext i32 @__atomic_fetch_add_4
+  // RV64IA: load atomic i32, i32* %a seq_cst, align 4
+  // RV64IA: store atomic i32 %b, i32* %a seq_cst, align 4
+  // RV64IA: atomicrmw add i32* %a, i32 %b seq_cst
+  __c11_atomic_load(a, memory_order_seq_cst);
+  __c11_atomic_store(a, b, memory_order_seq_cst);
+  __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
+
+void test_i64_atomics(_Atomic(int64_t) * a, int64_t b) {
+  // RV32I:  call i64 @__atomic_load_8
+  // RV32I:  call void @__atomic_store_8
+  // RV32I:  call i64 @__atomic_fetch_add_8
+  // RV32IA: call i64 @__atomic_load_8
+  // RV32IA: call void @__atomic_store_8
+  // RV32IA: call i64 @__atomic_fetch_add_8
+  // RV64I:  call i64 @__atomic_load_8
+  // RV64I:  call void @__atomic_store_8
+  // RV64I:  call i64 @__atomic_fetch_add_8
+  // RV64IA: load atomic i64, i64* %a seq_cst, align 8
+  // RV64IA: store atomic i64 %b, i64* %a seq_cst, align 8
+  // RV64IA: atomicrmw add i64* %a, i64 %b seq_cst
+  __c11_atomic_load(a, memory_order_seq_cst);
+  __c11_atomic_store(a, b, memory_order_seq_cst);
+  __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -93,6 +93,13 @@
 }
 return false;
   }
+
+  void setMaxAtomicWidth() override {
+MaxAtomicPromoteWidth = 128;
+
+if (HasA)
+  MaxAtomicInlineWidth = 32;
+  }
 };
 class LLVM_LIBRARY_VISIBILITY RISCV64TargetInfo : public RISCVTargetInfo {
 public:
@@ -110,6 +117,13 @@
 }
 return false;
   }
+
+  void setMaxAtomicWidth() override {
+MaxAtomicPromoteWidth = 128;
+
+if (HasA)
+  MaxAtomicInlineWidth = 64;
+  }
 };
 } // namespace targets
 } // namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66588: [ARM NEON] Avoid duplicated decarations

2019-08-22 Thread Diogo N. Sampaio via Phabricator via cfe-commits

dnsampaio created this revision.
dnsampaio added reviewers: t.p.northover, ostannard.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

The declaration of arm neon intrinsics that are
"big endian safe" print the same code for big
and small endian targets.
This patch avoids duplicates by checking if an
intrinsic is safe to have a single definition.
(decreases header 6030 lines out of 73k).


Repository:
  rC Clang

https://reviews.llvm.org/D66588

Files:
  utils/TableGen/NeonEmitter.cpp


Index: utils/TableGen/NeonEmitter.cpp
===
--- utils/TableGen/NeonEmitter.cpp
+++ utils/TableGen/NeonEmitter.cpp
@@ -1889,6 +1889,11 @@
 }
 
 std::string Intrinsic::generate() {
+  // Avoid duplicated code for big and small endians
+  if (BigEndianSafe) {
+generateImpl(false, "", "");
+return OS.str();
+  }
   // Little endian intrinsics are simple and don't require any argument
   // swapping.
   OS << "#ifdef __LITTLE_ENDIAN__\n";


Index: utils/TableGen/NeonEmitter.cpp
===
--- utils/TableGen/NeonEmitter.cpp
+++ utils/TableGen/NeonEmitter.cpp
@@ -1889,6 +1889,11 @@
 }
 
 std::string Intrinsic::generate() {
+  // Avoid duplicated code for big and small endians
+  if (BigEndianSafe) {
+generateImpl(false, "", "");
+return OS.str();
+  }
   // Little endian intrinsics are simple and don't require any argument
   // swapping.
   OS << "#ifdef __LITTLE_ENDIAN__\n";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r369093 - [RISCV] Add inline asm constraint A for RISC-V

2019-08-22 Thread Hans Wennborg via cfe-commits

Merged to release_90 in r369649.

On Fri, Aug 16, 2019 at 12:22 PM Lewis Revill via cfe-commits
 wrote:
>
> Author: lewis-revill
> Date: Fri Aug 16 03:23:56 2019
> New Revision: 369093
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369093&view=rev
> Log:
> [RISCV] Add inline asm constraint A for RISC-V
>
> This allows the constraint A to be used in inline asm for RISC-V, which
> allows an address held in a register to be used.
>
> This patch adds the minimal amount of code required to get operands with
> the right constraints to compile.
>
> Differential Revision: https://reviews.llvm.org/D54295
>
>
> Modified:
> cfe/trunk/lib/Basic/Targets/RISCV.cpp
> cfe/trunk/test/CodeGen/riscv-inline-asm.c
>
> Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=369093&r1=369092&r2=369093&view=diff
> ==
> --- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Fri Aug 16 03:23:56 2019
> @@ -75,6 +75,10 @@ bool RISCVTargetInfo::validateAsmConstra
>  // A floating-point register.
>  Info.setAllowsRegister();
>  return true;
> +  case 'A':
> +// An address that is held in a general-purpose register.
> +Info.setAllowsMemory();
> +return true;
>}
>  }
>
>
> Modified: cfe/trunk/test/CodeGen/riscv-inline-asm.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv-inline-asm.c?rev=369093&r1=369092&r2=369093&view=diff
> ==
> --- cfe/trunk/test/CodeGen/riscv-inline-asm.c (original)
> +++ cfe/trunk/test/CodeGen/riscv-inline-asm.c Fri Aug 16 03:23:56 2019
> @@ -38,3 +38,9 @@ void test_f() {
>  // CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
>asm volatile ("" :: "f"(d));
>  }
> +
> +void test_A(int *p) {
> +// CHECK-LABEL: define void @test_A(i32* %p)
> +// CHECK: call void asm sideeffect "", "*A"(i32* %p)
> +  asm volatile("" :: "A"(*p));
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-22 Thread Sam Elliott via Phabricator via cfe-commits

lenary added a comment.

Cross linking to the relevant psABI pull request (still pending): 
https://github.com/riscv/riscv-elf-psabi-doc/pull/112


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57450



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

[PATCH] D66397: [Diagnostics] Improve -Wxor-used-as-pow

2019-08-22 Thread Bruno Ricci via Phabricator via cfe-commits

riccibruno added a comment.

> This should not warn. Please verify that patch was applied correctly and you 
> use newly built clang with this patch. (I use arc patch DX)

You were right, I messed up on my side. Sorry about the noise !

I don't have much to add to the macro yes/no discussion but I have added some 
inline comments.




Comment at: lib/Sema/SemaExpr.cpp:9449
+  }
+
+  if (LHSInt->getValue().getBitWidth() != RHSInt->getValue().getBitWidth())

This will miss literals with a unary +, like `10 ^ +8`. I am not finding any 
code sample on `codesearch.isocpp.org` with this pattern, but you could imagine 
someone writing code like :


```
#define EXPONENT 10

res1 = 10 ^ +EXPONENT;
res2 = 10 ^ -EXPONENT;
```

WDYT  ?



Comment at: lib/Sema/SemaExpr.cpp:9469
+  const llvm::APInt XorValue = LeftSideValue ^ RightSideValue;
+
+  std::string LHSStr = Lexer::getSourceText(

You could bailout early if the values are such that no diagnostics is ever 
going to be issued, before doing any source range/string manipulations (ie: do 
all the tests on the values first).



Comment at: lib/Sema/SemaExpr.cpp:9506
+return;
+
+  bool SuggestXor = S.getLangOpts().CPlusPlus || 
S.getPreprocessor().isMacroDefined("xor");

Maybe put the slightly more expensive `find` last in the condition.



Comment at: lib/Sema/SemaExpr.cpp:9674
+RHS.get());
+
   // Enforce type constraints: C99 6.5.6p3.

I think that this will miss code like `(2 ^ 64) - 1u` since `IgnoreParens()` 
will not skip any implicit casts added by `UsualArithmeticConversions`. (Also 
`IgnoreParens()` skips a bunch of other things, but it does not seem relevant 
here).

Also, in `CheckBitwiseOperands` `diagnoseXorMisusedAsPow` is called before 
`UsualArithmeticConversions` and not after. I am wondering if it is possible 
for `diagnoseXorMisusedAsPow` to be called with invalid arguments in 
`CheckBitwiseOperands` ?


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

https://reviews.llvm.org/D66397



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

[PATCH] D53476: [clang-cl] Allowed -fopenmp work and link openmp library from per-runtime library directory

2019-08-22 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

It looks like it was never committed.

Peiyuan, what's the status here?


Repository:
  rC Clang

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

https://reviews.llvm.org/D53476



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

[PATCH] D66590: [clangd] Fix toHalfOpenFileRange where start/end endpoints are in different files due to #include

2019-08-22 Thread Sam McCall via Phabricator via cfe-commits

sammccall created this revision.
sammccall added a reviewer: SureYeaah.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

https://github.com/clangd/clangd/issues/129


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66590

Files:
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/SourceCodeTests.cpp

Index: clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
===
--- clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
+++ clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
@@ -11,9 +11,11 @@
 #include "SourceCode.h"
 #include "TestTU.h"
 #include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Format/Format.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/raw_os_ostream.h"
+#include "llvm/Testing/Support/Annotations.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -505,6 +507,53 @@
   CheckRange("f");
 }
 
+TEST(SourceCodeTests, HalfOpenFileRangePathologicalPreprocessor) {
+  const char *Case = R"cpp(
+#define MACRO while(1)
+void test() {
+[[#include "Expand.inc"
+br^eak]];
+}
+  )cpp";
+  Annotations Test(Case);
+  auto TU = TestTU::withCode(Test.code());
+  TU.AdditionalFiles["Expand.inc"] = "MACRO\n";
+  auto AST = TU.build();
+
+  const auto &Func = cast(findDecl(AST, "test"));
+  const auto &Body = cast(Func.getBody());
+  const auto &Loop = cast(*Body->child_begin());
+  llvm::Optional Range = toHalfOpenFileRange(
+  AST.getSourceManager(), AST.getASTContext().getLangOpts(),
+  Loop->getSourceRange());
+  ASSERT_TRUE(Range) << "Failed to get file range";
+  EXPECT_EQ(AST.getSourceManager().getFileOffset(Range->getBegin()),
+Test.llvm::Annotations::range().Begin);
+  EXPECT_EQ(AST.getSourceManager().getFileOffset(Range->getEnd()),
+Test.llvm::Annotations::range().End);
+}
+
+TEST(SourceCodeTests, IncludeHashLoc) {
+  const char *Case = R"cpp(
+$foo^#include "foo.inc"
+#define HEADER "bar.inc"
+  $bar^#  include HEADER
+  )cpp";
+  Annotations Test(Case);
+  auto TU = TestTU::withCode(Test.code());
+  TU.AdditionalFiles["foo.inc"] = "int foo;\n";
+  TU.AdditionalFiles["bar.inc"] = "int bar;\n";
+  auto AST = TU.build();
+  const auto& SM = AST.getSourceManager();
+
+  FileID Foo = SM.getFileID(findDecl(AST, "foo").getLocation());
+  EXPECT_EQ(SM.getFileOffset(includeHashLoc(Foo, SM)),
+Test.llvm::Annotations::point("foo"));
+  FileID Bar = SM.getFileID(findDecl(AST, "bar").getLocation());
+  EXPECT_EQ(SM.getFileOffset(includeHashLoc(Bar, SM)),
+Test.llvm::Annotations::point("foo"));
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -346,6 +346,25 @@
   }
 }
 
+TEST(SelectionTest, PathologicalPreprocessor) {
+  const char *Case = R"cpp(
+#define MACRO while(1)
+void test() {
+#include "Expand.inc"
+br^eak;
+}
+  )cpp";
+  Annotations Test(Case);
+  auto TU = TestTU::withCode(Test.code());
+  TU.AdditionalFiles["Expand.inc"] = "MACRO\n";
+  auto AST = TU.build();
+  EXPECT_THAT(AST.getDiagnostics(), ::testing::IsEmpty());
+  auto T = makeSelectionTree(Case, AST);
+
+  EXPECT_EQ("BreakStmt", T.commonAncestor()->kind());
+  EXPECT_EQ("WhileStmt", T.commonAncestor()->Parent->kind());
+}
+
 TEST(SelectionTest, Implicit) {
   const char* Test = R"cpp(
 struct S { S(const char*); };
Index: clang-tools-extra/clangd/SourceCode.h
===
--- clang-tools-extra/clangd/SourceCode.h
+++ clang-tools-extra/clangd/SourceCode.h
@@ -83,6 +83,11 @@
 /// the main file.
 bool isInsideMainFile(SourceLocation Loc, const SourceManager &SM);
 
+/// Returns the #include location through which IncludedFIle was loaded.
+/// Where SM.getIncludeLoc() returns the location of the *filename*, which may
+/// be in a macro, includeHashLoc() returns the location of the #.
+SourceLocation includeHashLoc(FileID IncludedFile, const SourceManager &SM);
+
 /// Returns true if the token at Loc is spelled in the source code.
 /// This is not the case for:
 ///   * symbols formed via macro concatenation, the spelling location will
Index: clang-tools-extra/clangd/SourceCode.cpp
===
--- clang-tools-extra/clangd/SourceCode.cpp
+++ clang-tools-extra/clangd/SourceCode.cpp
@@ -264,6 +264,29 @@
   return L == R.getEnd() || halfOpenRangeContains(Mgr, R, L);
 }
 
+SourceLocation includeHashLoc(FileID Incl

[PATCH] D66590: [clangd] Fix toHalfOpenFileRange where start/end endpoints are in different files due to #include

2019-08-22 Thread Sam McCall via Phabricator via cfe-commits

sammccall updated this revision to Diff 216609.
sammccall added a comment.

kick phabricator to try to get it to mail


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66590

Files:
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/SourceCodeTests.cpp

Index: clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
===
--- clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
+++ clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
@@ -11,9 +11,11 @@
 #include "SourceCode.h"
 #include "TestTU.h"
 #include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Format/Format.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/raw_os_ostream.h"
+#include "llvm/Testing/Support/Annotations.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -505,6 +507,53 @@
   CheckRange("f");
 }
 
+TEST(SourceCodeTests, HalfOpenFileRangePathologicalPreprocessor) {
+  const char *Case = R"cpp(
+#define MACRO while(1)
+void test() {
+[[#include "Expand.inc"
+br^eak]];
+}
+  )cpp";
+  Annotations Test(Case);
+  auto TU = TestTU::withCode(Test.code());
+  TU.AdditionalFiles["Expand.inc"] = "MACRO\n";
+  auto AST = TU.build();
+
+  const auto &Func = cast(findDecl(AST, "test"));
+  const auto &Body = cast(Func.getBody());
+  const auto &Loop = cast(*Body->child_begin());
+  llvm::Optional Range = toHalfOpenFileRange(
+  AST.getSourceManager(), AST.getASTContext().getLangOpts(),
+  Loop->getSourceRange());
+  ASSERT_TRUE(Range) << "Failed to get file range";
+  EXPECT_EQ(AST.getSourceManager().getFileOffset(Range->getBegin()),
+Test.llvm::Annotations::range().Begin);
+  EXPECT_EQ(AST.getSourceManager().getFileOffset(Range->getEnd()),
+Test.llvm::Annotations::range().End);
+}
+
+TEST(SourceCodeTests, IncludeHashLoc) {
+  const char *Case = R"cpp(
+$foo^#include "foo.inc"
+#define HEADER "bar.inc"
+  $bar^#  include HEADER
+  )cpp";
+  Annotations Test(Case);
+  auto TU = TestTU::withCode(Test.code());
+  TU.AdditionalFiles["foo.inc"] = "int foo;\n";
+  TU.AdditionalFiles["bar.inc"] = "int bar;\n";
+  auto AST = TU.build();
+  const auto& SM = AST.getSourceManager();
+
+  FileID Foo = SM.getFileID(findDecl(AST, "foo").getLocation());
+  EXPECT_EQ(SM.getFileOffset(includeHashLoc(Foo, SM)),
+Test.llvm::Annotations::point("foo"));
+  FileID Bar = SM.getFileID(findDecl(AST, "bar").getLocation());
+  EXPECT_EQ(SM.getFileOffset(includeHashLoc(Bar, SM)),
+Test.llvm::Annotations::point("foo"));
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -346,6 +346,25 @@
   }
 }
 
+TEST(SelectionTest, PathologicalPreprocessor) {
+  const char *Case = R"cpp(
+#define MACRO while(1)
+void test() {
+#include "Expand.inc"
+br^eak;
+}
+  )cpp";
+  Annotations Test(Case);
+  auto TU = TestTU::withCode(Test.code());
+  TU.AdditionalFiles["Expand.inc"] = "MACRO\n";
+  auto AST = TU.build();
+  EXPECT_THAT(AST.getDiagnostics(), ::testing::IsEmpty());
+  auto T = makeSelectionTree(Case, AST);
+
+  EXPECT_EQ("BreakStmt", T.commonAncestor()->kind());
+  EXPECT_EQ("WhileStmt", T.commonAncestor()->Parent->kind());
+}
+
 TEST(SelectionTest, Implicit) {
   const char* Test = R"cpp(
 struct S { S(const char*); };
Index: clang-tools-extra/clangd/SourceCode.h
===
--- clang-tools-extra/clangd/SourceCode.h
+++ clang-tools-extra/clangd/SourceCode.h
@@ -83,6 +83,11 @@
 /// the main file.
 bool isInsideMainFile(SourceLocation Loc, const SourceManager &SM);
 
+/// Returns the #include location through which IncludedFIle was loaded.
+/// Where SM.getIncludeLoc() returns the location of the *filename*, which may
+/// be in a macro, includeHashLoc() returns the location of the #.
+SourceLocation includeHashLoc(FileID IncludedFile, const SourceManager &SM);
+
 /// Returns true if the token at Loc is spelled in the source code.
 /// This is not the case for:
 ///   * symbols formed via macro concatenation, the spelling location will
Index: clang-tools-extra/clangd/SourceCode.cpp
===
--- clang-tools-extra/clangd/SourceCode.cpp
+++ clang-tools-extra/clangd/SourceCode.cpp
@@ -264,6 +264,29 @@
   return L == R.getEnd() || halfOpenRangeContains(Mgr, R, L);
 }
 
+SourceLocation includeHashLoc(FileID IncludedFile, const SourceManager &SM) {
+  assert(SM.getLocF

[PATCH] D66122: [CodeGen] Emit dynamic initializers for static TLS vars in outlined scopes

2019-08-22 Thread Princeton Ferro via Phabricator via cfe-commits

Prince781 marked an inline comment as done.
Prince781 added a comment.

In D66122#1639947 , @efriedma wrote:

> But given that, I think we should submit a core issue, and hold off on 
> merging this until we hear back from the committee.


I agree here. There does appear to be some previous discussion on this matter, 
but the spec itself still doesn't contain any language addressing this issue. I 
will submit a core issue.




Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:317
+  deps.insert(V);
+  auto V_Refs = enumerateVarInitDependencies(V);
+  deps.insert(V_Refs.begin(), V_Refs.end());

efriedma wrote:
> Do you need to recurse here?  It looks like the caller should handle that.
Oops, I think you might be right.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66122



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

[PATCH] D66590: [clangd] Fix toHalfOpenFileRange where start/end endpoints are in different files due to #include

2019-08-22 Thread Sam McCall via Phabricator via cfe-commits

sammccall marked 4 inline comments as done.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/SourceCode.cpp:318
-// Check if two locations have the same file id.
-static bool inSameFile(SourceLocation Loc1, SourceLocation Loc2,
-   const SourceManager &SM) {

I dropped this function because it's just SM.isSpelledInSameFile



Comment at: clang-tools-extra/clangd/SourceCode.cpp:338
+  : R2.getBegin();
+  SourceLocation End =
+  SM.isBeforeInTranslationUnit(getLocForTokenEnd(R1.getEnd(), SM, 
LangOpts),

this is an unrelated bug fix: E1 < E2, std::min() etc don't do anything 
sensible for SourceLocation



Comment at: clang-tools-extra/clangd/SourceCode.cpp:358
Begin = Begin.isFileID()
-   ? SourceLocation()
+   ? includeHashLoc(SM.getFileID(Begin), SM)
: SM.getImmediateExpansionRange(Begin).getBegin()) {

This is half of the real fix: once we've hit the top of the macro tree, we 
should walk up the `#include` stack in case we find a common ancestor there.



Comment at: clang-tools-extra/clangd/SourceCode.cpp:443
+  SourceRange Result =
+  rangeInCommonFile(unionTokenRange(R1, R2, SM, LangOpts), SM, LangOpts);
   unsigned TokLen = getTokenLengthAtLoc(Result.getEnd(), SM, LangOpts);

this is one part of the main fix: the start and endpoint may be in different 
real files in the presence of #include


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66590



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-22 Thread James Y Knight via Phabricator via cfe-commits

jyknight added a comment.

That GCC and Clang differ in handling of Atomics is a really unfortunate, 
longstanding issue.

See https://bugs.llvm.org/show_bug.cgi?id=26462

For RISCV, perhaps it's not yet too late to have the RISCV psABI actually 
specify a single ABI for C11 _Atomic which all compilers can implement, rather 
than having compilers do whatever they want to, separately...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57450



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

[PATCH] D66591: [RISCV] Correct Logic around ilp32e macros

2019-08-22 Thread Sam Elliott via Phabricator via cfe-commits

lenary created this revision.
lenary added reviewers: luismarques, asb.
Herald added subscribers: cfe-commits, pzheng, s.egerton, Jim, benna, psnobl, 
jocewei, PkmX, rkruppe, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, MaskRay, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, 
apazos, simoncook, johnrusso, rbar.
Herald added a project: clang.

GCC seperates the `__riscv_float_abi_*` macros and the
`__riscv_abi_rve` macro. If the chosen abi is ilp32e, `gcc -march=rv32i
-mabi=ilp32i -E -dM` shows that both `__riscv_float_abi_soft` and
`__riscv_abi_rve` are set.

This patch corrects the compiler logic around these defines.

At the moment, this patch will not change clang's behaviour, because we do not
accept the `ilp32e` abi yet.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66591

Files:
  clang/lib/Basic/Targets/RISCV.cpp


Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -96,11 +96,12 @@
 Builder.defineMacro("__riscv_float_abi_single");
   else if (ABIName == "ilp32d" || ABIName == "lp64d")
 Builder.defineMacro("__riscv_float_abi_double");
-  else if (ABIName == "ilp32e")
-Builder.defineMacro("__riscv_abi_rve");
   else
 Builder.defineMacro("__riscv_float_abi_soft");
 
+  if (ABIName == "ilp32e")
+Builder.defineMacro("__riscv_abi_rve");
+
   if (HasM) {
 Builder.defineMacro("__riscv_mul");
 Builder.defineMacro("__riscv_div");


Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -96,11 +96,12 @@
 Builder.defineMacro("__riscv_float_abi_single");
   else if (ABIName == "ilp32d" || ABIName == "lp64d")
 Builder.defineMacro("__riscv_float_abi_double");
-  else if (ABIName == "ilp32e")
-Builder.defineMacro("__riscv_abi_rve");
   else
 Builder.defineMacro("__riscv_float_abi_soft");
 
+  if (ABIName == "ilp32e")
+Builder.defineMacro("__riscv_abi_rve");
+
   if (HasM) {
 Builder.defineMacro("__riscv_mul");
 Builder.defineMacro("__riscv_div");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66592: [clangd] Send suppported codeActionKinds to the client.

2019-08-22 Thread Haojian Wu via Phabricator via cfe-commits

hokein created this revision.
hokein added a reviewer: ilya-biryukov.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

This would make client know which codeActionKinds that clangd may
return.

VSCode will add a new entry "Refactor..." (which shows all
refactoring-kind code actions) in the right-click menu.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66592

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp


Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -464,6 +464,16 @@
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per 
LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action liveral
+  // support (via textDocument.codeAction.codeActionLiteralSupport).
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},


Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -464,6 +464,16 @@
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action liveral
+  // support (via textDocument.codeAction.codeActionLiteralSupport).
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66593: [analyzer] CastValueChecker: Fix some assertions

2019-08-22 Thread Csaba Dabis via Phabricator via cfe-commits

Charusso created this revision.
Charusso added a reviewer: NoQ.
Charusso added a project: clang.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun.

-


Repository:
  rC Clang

https://reviews.llvm.org/D66593

Files:
  clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/DynamicType.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp

Index: clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -1048,7 +1048,7 @@
   return getSubRegion(E, getStackLocalsRegion(SFC));
 }
 
-/// Checks whether \p BaseClass is a valid virtual or direct non-virtual base
+/*/// Checks whether \p BaseClass is a valid virtual or direct non-virtual base
 /// class of the type of \p Super.
 static bool isValidBaseClass(const CXXRecordDecl *BaseClass,
  const TypedValueRegion *Super,
@@ -1068,15 +1068,16 @@
   }
 
   return false;
-}
+}*/
 
 const CXXBaseObjectRegion *
 MemRegionManager::getCXXBaseObjectRegion(const CXXRecordDecl *RD,
  const SubRegion *Super,
  bool IsVirtual) {
   if (isa(Super)) {
-assert(isValidBaseClass(RD, dyn_cast(Super), IsVirtual));
-(void)&isValidBaseClass;
+// FIXME: Make this assertion great again.
+/*assert(isValidBaseClass(RD, dyn_cast(Super), IsVirtual));
+(void)&isValidBaseClass;*/
 
 if (IsVirtual) {
   // Virtual base regions should not be layered, since the layout rules
Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -325,13 +325,15 @@
   return State;
 }
 Result = InitWithAdjustments;
-  } else {
+  }
+  // FIXME: Make this assertion great again.
+  /* else {
 // We need to create a region no matter what. For sanity, make sure we don't
 // try to stuff a Loc into a non-pointer temporary region.
 assert(!InitValWithAdjustments.getAs() ||
Loc::isLocType(Result->getType()) ||
Result->getType()->isMemberPointerType());
-  }
+  }*/
 
   ProgramStateManager &StateMgr = State->getStateManager();
   MemRegionManager &MRMgr = StateMgr.getRegionManager();
Index: clang/lib/StaticAnalyzer/Core/DynamicType.cpp
===
--- clang/lib/StaticAnalyzer/Core/DynamicType.cpp
+++ clang/lib/StaticAnalyzer/Core/DynamicType.cpp
@@ -115,9 +115,11 @@
 template 
 ProgramStateRef removeDead(ProgramStateRef State, const MapTy &Map,
SymbolReaper &SR) {
-  for (const auto &Elem : Map)
-if (!SR.isLiveRegion(Elem.first))
-  State = State->remove(Elem.first);
+  for (const auto &Elem : Map) {
+const MemRegion *MR = Elem.first;
+if (MR && !SR.isLiveRegion(MR))
+  State = State->remove(MR);
+  }
 
   return State;
 }
Index: clang/lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- clang/lib/StaticAnalyzer/Core/CallEvent.cpp
+++ clang/lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -740,8 +740,14 @@
 return {};
 
   // Is the type a C++ class? (This is mostly a defensive check.)
-  QualType RegionType = DynType.getType()->getPointeeType();
-  assert(!RegionType.isNull() && "DynamicTypeInfo should always be a pointer.");
+  QualType RegionType = DynType.getType();
+  if (RegionType->isPointerType())
+RegionType = RegionType->getPointeeType();
+  else
+RegionType = RegionType.getNonReferenceType();
+
+  assert(!RegionType.isNull() &&
+ "DynamicTypeInfo should always be a pointer or a reference.");
 
   const CXXRecordDecl *RD = RegionType->getAsCXXRecordDecl();
   if (!RD || !RD->hasDefinition())
Index: clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
@@ -98,8 +98,7 @@
 
   if (Ty->isPointerType())
 Ty = Ty->getPointeeType();
-
-  if (Ty->isReferenceType())
+  else if (Ty->isReferenceType())
 Ty = Ty.getNonReferenceType();
 
   return Ty.getUnqualifiedType();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66593: [analyzer] CastValueChecker: Fix some assertions

2019-08-22 Thread Csaba Dabis via Phabricator via cfe-commits

Charusso marked an inline comment as done.
Charusso added a comment.

I am not sure how would I fix them, so I just commented them out.




Comment at: clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp:102
+  else if (Ty->isReferenceType())
 Ty = Ty.getNonReferenceType();
 

May it is more explicit.


Repository:
  rC Clang

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

https://reviews.llvm.org/D66593



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

[PATCH] D66397: [Diagnostics] Improve -Wxor-used-as-pow

2019-08-22 Thread Nico Weber via Phabricator via cfe-commits

thakis added a comment.

In D66397#1640685 , @xbolva00 wrote:

> >> I think adding parens and casts are fairly well-understood to suppress 
> >> warnings.
>
> It should work here as well. #define ALPHA_OFFSET (3). Did anobody from 
> Chromium try it?
>
> >> They have varying levels of C++ proficiency
>
> I consider things like hex decimals or parens to silence as a quite basic 
> knowledge.


parens for sure, but I'm not aware of any other warning that behaves 
differently for ordinary and hex literals. What else is there?


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

https://reviews.llvm.org/D66397



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

[PATCH] D66592: [clangd] Send suppported codeActionKinds to the client.

2019-08-22 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:467
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action liveral

NIT: a typo, s/codeActionProvide/codeActionProvider



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:468
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action liveral
+  // support (via textDocument.codeAction.codeActionLiteralSupport).

s/action liveral/action literal



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:469
+  // CodeActionOptions is only valid if the client supports action liveral
+  // support (via textDocument.codeAction.codeActionLiteralSupport).
+  llvm::json::Value CodeActionProvider = true;

NIT: remove 'support', remove parentheses?

Otherwise we have clients **supports** action literal **support**


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66592



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

[PATCH] D66397: [Diagnostics] Improve -Wxor-used-as-pow

2019-08-22 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

>>   other warning that behaves differently for ordinary and hex literals

Such literals should indicate that the user knows what he/she is doing (bit 
tricks, ..). I agree that there should be a additional docs (as we mentioned it 
and kindly pinged @hans) and not force the user to looking at Clang's code to 
see what are preconditions to warn.

I dont know really how to make both sides happy in terms of "macro" issue :(


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

https://reviews.llvm.org/D66397



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

[PATCH] D66219: [clangd] Added a colorizer to the vscode extension.

2019-08-22 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom updated this revision to Diff 216621.
jvikstrom marked 6 inline comments as done.
jvikstrom added a comment.

Rewrote the Highlighter class as we can override the highlighting method for 
the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66219

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
  
clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts
@@ -1,5 +1,6 @@
 import * as assert from 'assert';
 import * as path from 'path';
+import * as vscode from 'vscode';
 
 import * as SM from '../src/semantic-highlighting';
 
@@ -57,4 +58,71 @@
 assert.deepEqual(tm.getBestThemeRule('variable.other.parameter.cpp').scope,
  'variable.other.parameter');
   });
+  test('Colorizer groups decorations correctly', async () => {
+// Helper for creating a vscode Range.
+const createRange = (line: number, startCharacter: number,
+ length: number) =>
+new vscode.Range(new vscode.Position(line, startCharacter),
+ new vscode.Position(line, startCharacter + length));
+const scopeTable = [
+  [ 'variable' ], [ 'entity.type.function' ],
+  [ 'entity.type.function.method' ]
+];
+const rules = [
+  {scope : 'variable', foreground : '1'},
+  {scope : 'entity.type', foreground : '2'},
+];
+class MockHighlighter extends SM.Highlighter {
+  applicationUriHistory: string[] = [];
+  applyHighlights(fileUri: string) {
+this.applicationUriHistory.push(fileUri);
+  }
+  getDecorationRanges(fileUri: string) {
+return super.getDecorationRanges(fileUri);
+  }
+  getVisibleTextEditorUris() { return [ 'a', 'b' ]; }
+}
+const highlighter = new MockHighlighter(scopeTable);
+const tm = new SM.ThemeRuleMatcher(rules);
+// Recolorizes when initialized.
+highlighter.highlight('a', []);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a' ]);
+highlighter.initialize(tm);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a', 'a' ]);
+// Groups decorations into the scopes used.
+let line = [
+  {character : 1, length : 2, scopeIndex : 1},
+  {character : 5, length : 2, scopeIndex : 1},
+  {character : 10, length : 2, scopeIndex : 2}
+];
+highlighter.highlight(
+'a', [ {line : 1, tokens : line}, {line : 2, tokens : line} ]);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a', 'a', 'a' ]);
+assert.deepEqual(highlighter.getDecorationRanges('a'), [
+  [],
+  [
+createRange(1, 1, 2), createRange(1, 5, 2), createRange(2, 1, 2),
+createRange(2, 5, 2)
+  ],
+  [ createRange(1, 10, 2), createRange(2, 10, 2) ],
+]);
+// Keeps state separate between files.
+highlighter.highlight('b', [
+  {line : 1, tokens : [ {character : 1, length : 1, scopeIndex : 0} ]}
+]);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a', 'a', 'a', 'b' ]);
+assert.deepEqual(highlighter.getDecorationRanges('b'),
+ [ [ createRange(1, 1, 1) ], [], [] ]);
+// Does full colorizations.
+highlighter.highlight('a', [
+  {line : 1, tokens : [ {character : 2, length : 1, scopeIndex : 0} ]}
+]);
+assert.deepEqual(highlighter.applicationUriHistory,
+ [ 'a', 'a', 'a', 'b', 'a' ]);
+assert.deepEqual(highlighter.getDecorationRanges('a'), [
+  [ createRange(1, 2, 1) ],
+  [ createRange(2, 1, 2), createRange(2, 5, 2) ],
+  [ createRange(2, 10, 2) ],
+]);
+  });
 });
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
@@ -34,6 +34,13 @@
   // The TextMate scope index to the clangd scope lookup table.
   scopeIndex: number;
 }
+// A line of decoded highlightings from the data clangd sent.
+interface SemanticHighlightingLine {
+  // The zero-based line position in the text document.
+  line: number;
+  // All SemanticHighlightingTokens on the line.
+  tokens: SemanticHighlightingToken[];
+}
 
 // Language server push notification providing the semantic highlighting
 // information for a text document.
@@ -49,6 +56,8 @@
   scopeLookupTable: string[][];
   // The rules for the current theme.
   themeRuleMa

[PATCH] D66219: [clangd] Added a colorizer to the vscode extension.

2019-08-22 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom added a comment.

I had completely forgotten we could just override the applyHighlightings method 
in the tests, everything is much simpler now.

Basically this entire CL was rewritten just now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66219



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

[PATCH] D66219: [clangd] Added a colorizer to the vscode extension.

2019-08-22 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom updated this revision to Diff 216624.
jvikstrom added a comment.

Added missing protected and comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66219

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
  
clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/semantic-highlighting.test.ts
@@ -1,5 +1,6 @@
 import * as assert from 'assert';
 import * as path from 'path';
+import * as vscode from 'vscode';
 
 import * as SM from '../src/semantic-highlighting';
 
@@ -57,4 +58,71 @@
 assert.deepEqual(tm.getBestThemeRule('variable.other.parameter.cpp').scope,
  'variable.other.parameter');
   });
+  test('Colorizer groups decorations correctly', async () => {
+// Helper for creating a vscode Range.
+const createRange = (line: number, startCharacter: number,
+ length: number) =>
+new vscode.Range(new vscode.Position(line, startCharacter),
+ new vscode.Position(line, startCharacter + length));
+const scopeTable = [
+  [ 'variable' ], [ 'entity.type.function' ],
+  [ 'entity.type.function.method' ]
+];
+const rules = [
+  {scope : 'variable', foreground : '1'},
+  {scope : 'entity.type', foreground : '2'},
+];
+class MockHighlighter extends SM.Highlighter {
+  applicationUriHistory: string[] = [];
+  applyHighlights(fileUri: string) {
+this.applicationUriHistory.push(fileUri);
+  }
+  getDecorationRanges(fileUri: string) {
+return super.getDecorationRanges(fileUri);
+  }
+  getVisibleTextEditorUris() { return [ 'a', 'b' ]; }
+}
+const highlighter = new MockHighlighter(scopeTable);
+const tm = new SM.ThemeRuleMatcher(rules);
+// Recolorizes when initialized.
+highlighter.highlight('a', []);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a' ]);
+highlighter.initialize(tm);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a', 'a' ]);
+// Groups decorations into the scopes used.
+let line = [
+  {character : 1, length : 2, scopeIndex : 1},
+  {character : 5, length : 2, scopeIndex : 1},
+  {character : 10, length : 2, scopeIndex : 2}
+];
+highlighter.highlight(
+'a', [ {line : 1, tokens : line}, {line : 2, tokens : line} ]);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a', 'a', 'a' ]);
+assert.deepEqual(highlighter.getDecorationRanges('a'), [
+  [],
+  [
+createRange(1, 1, 2), createRange(1, 5, 2), createRange(2, 1, 2),
+createRange(2, 5, 2)
+  ],
+  [ createRange(1, 10, 2), createRange(2, 10, 2) ],
+]);
+// Keeps state separate between files.
+highlighter.highlight('b', [
+  {line : 1, tokens : [ {character : 1, length : 1, scopeIndex : 0} ]}
+]);
+assert.deepEqual(highlighter.applicationUriHistory, [ 'a', 'a', 'a', 'b' ]);
+assert.deepEqual(highlighter.getDecorationRanges('b'),
+ [ [ createRange(1, 1, 1) ], [], [] ]);
+// Does full colorizations.
+highlighter.highlight('a', [
+  {line : 1, tokens : [ {character : 2, length : 1, scopeIndex : 0} ]}
+]);
+assert.deepEqual(highlighter.applicationUriHistory,
+ [ 'a', 'a', 'a', 'b', 'a' ]);
+assert.deepEqual(highlighter.getDecorationRanges('a'), [
+  [ createRange(1, 2, 1) ],
+  [ createRange(2, 1, 2), createRange(2, 5, 2) ],
+  [ createRange(2, 10, 2) ],
+]);
+  });
 });
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts
@@ -34,6 +34,13 @@
   // The TextMate scope index to the clangd scope lookup table.
   scopeIndex: number;
 }
+// A line of decoded highlightings from the data clangd sent.
+interface SemanticHighlightingLine {
+  // The zero-based line position in the text document.
+  line: number;
+  // All SemanticHighlightingTokens on the line.
+  tokens: SemanticHighlightingToken[];
+}
 
 // Language server push notification providing the semantic highlighting
 // information for a text document.
@@ -49,6 +56,8 @@
   scopeLookupTable: string[][];
   // The rules for the current theme.
   themeRuleMatcher: ThemeRuleMatcher;
+  // The object that applies the highlightings clangd sends.
+  highli

[PATCH] D66592: [clangd] Send suppported codeActionKinds to the client.

2019-08-22 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 216625.
hokein marked 3 inline comments as done.
hokein added a comment.

Fix the comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66592

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp


Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -464,6 +464,16 @@
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per 
LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action literal
+  // via textDocument.codeAction.codeActionLiteralSupport.
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},


Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -464,6 +464,16 @@
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action literal
+  // via textDocument.codeAction.codeActionLiteralSupport.
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r369656 - [clangd] Send suppported codeActionKinds to the client.

2019-08-22 Thread Haojian Wu via cfe-commits

Author: hokein
Date: Thu Aug 22 07:53:45 2019
New Revision: 369656

URL: http://llvm.org/viewvc/llvm-project?rev=369656&view=rev
Log:
[clangd] Send suppported codeActionKinds to the client.

Summary:
This would make client know which codeActionKinds that clangd may
return.

VSCode will add a new entry "Refactor..." (which shows all
refactoring-kind code actions) in the right-click menu.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=369656&r1=369655&r2=369656&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Thu Aug 22 07:53:45 2019
@@ -464,6 +464,16 @@ void ClangdLSPServer::onInitialize(const
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per 
LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action literal
+  // via textDocument.codeAction.codeActionLiteralSupport.
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@ void ClangdLSPServer::onInitialize(const
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},


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

[PATCH] D66592: [clangd] Send suppported codeActionKinds to the client.

2019-08-22 Thread Haojian Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL369656: [clangd] Send suppported codeActionKinds to the 
client. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66592?vs=216625&id=216626#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66592

Files:
  clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp


Index: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
@@ -464,6 +464,16 @@
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per 
LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action literal
+  // via textDocument.codeAction.codeActionLiteralSupport.
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},


Index: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
@@ -464,6 +464,16 @@
   if (!Params.capabilities.RenamePrepareSupport) // Only boolean allowed per LSP
 RenameProvider = true;
 
+  // Per LSP, codeActionProvide can be either boolean or CodeActionOptions.
+  // CodeActionOptions is only valid if the client supports action literal
+  // via textDocument.codeAction.codeActionLiteralSupport.
+  llvm::json::Value CodeActionProvider = true;
+  if (Params.capabilities.CodeActionStructure)
+CodeActionProvider = llvm::json::Object{
+{"codeActionKinds",
+ {CodeAction::QUICKFIX_KIND, CodeAction::REFACTOR_KIND,
+  CodeAction::INFO_KIND}}};
+
   llvm::json::Object Result{
   {{"capabilities",
 llvm::json::Object{
@@ -475,7 +485,7 @@
  {"firstTriggerCharacter", "\n"},
  {"moreTriggerCharacter", {}},
  }},
-{"codeActionProvider", true},
+{"codeActionProvider", std::move(CodeActionProvider)},
 {"completionProvider",
  llvm::json::Object{
  {"resolveProvider", false},
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66122: [CodeGen] Emit dynamic initializers for static TLS vars in outlined scopes

2019-08-22 Thread Princeton Ferro via Phabricator via cfe-commits

Prince781 added a comment.

The more I think about this, the more I have doubts about whether this should 
be supported. For example, what happens in cases like this?:

  #include 
  #include 
  
  struct Object {
  int i;
  Object() : i(3) {}
  Object(int v) : i(3 + v) {}
  };
  
  int main(void) {
  int w = 4;
  static thread_local Object o(w);
  
  std::cout << "[main] o.i = " << o.i << std::endl;
  std::thread([] {
  std::cout << "[new thread] o.i = " << o.i << std::endl;
  }).join();
  }

Should `w` be captured or not? Furthermore, if o referenced another block-scope 
thread-local that had an initializer referencing another local variable, that 
would have to be captured too. So I now think this should be an error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66122



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-22 Thread Sam Elliott via Phabricator via cfe-commits

lenary added a comment.

@jyknight I hear where you're coming from. I'll see what I can do about the 
psABI document.

In that ticket, it's mentioned that the Darwin ABI explicitly says that 
non-power-of-two atomic types should be padded and realigned, but I cannot find 
any documentation explaining this. That would be useful, given presumably GCC 
does have to pad/align on Darwin.

Then the only outstanding question relates to zero-sized atomics, which GCC 
does not pad, but I think Clang has to pad to get the semantics correct, based 
on this comment: 
https://github.com/llvm/llvm-project/blob/master/clang/lib/AST/ASTContext.cpp#L2176


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57450



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

[PATCH] D53476: [clang-cl] Allowed -fopenmp work and link openmp library from per-runtime library directory

2019-08-22 Thread Peiyuan Song via Phabricator via cfe-commits

SquallATF added a comment.

In D53476#1641049 , @hans wrote:

> It looks like it was never committed.
>
> Peiyuan, what's the status here?

This patch need rebase, I see recent have a commit rG7994e1d 
 alias 
`/openmp` option to `-fopenmp` may be that is better. but that commit not 
support `-fopenmp=` option. So can't choose Intel's OpenMP runtime.

Repository:
  rC Clang

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

https://reviews.llvm.org/D53476

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

Re: r369641 - [OpenCL] Fix declaration of enqueue_marker

2019-08-22 Thread Anastasia Stulova via cfe-commits

Hi Hans,


Can this still be merged into the release branch please.


Thanks in advance,

Anastasia



From: cfe-commits  on behalf of Yaxun Liu 
via cfe-commits 
Sent: 22 August 2019 12:18
To: cfe-commits@lists.llvm.org 
Subject: r369641 - [OpenCL] Fix declaration of enqueue_marker

Author: yaxunl
Date: Thu Aug 22 04:18:59 2019
New Revision: 369641

URL: http://llvm.org/viewvc/llvm-project?rev=369641&view=rev
Log:
[OpenCL] Fix declaration of enqueue_marker

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

Modified:
cfe/trunk/lib/Headers/opencl-c.h

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=369641&r1=369640&r2=369641&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Thu Aug 22 04:18:59 2019
@@ -15350,7 +15350,7 @@ ndrange_t __ovld ndrange_3D(const size_t
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3]);
 ndrange_t __ovld ndrange_3D(const size_t[3], const size_t[3], const size_t[3]);

-int __ovld enqueue_marker(queue_t, uint, const __private clk_event_t*, 
__private clk_event_t*);
+int __ovld enqueue_marker(queue_t, uint, const clk_event_t*, clk_event_t*);

 void __ovld retain_event(clk_event_t);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66598: [Clang][Bundler] Fix for a hang when unbundling fat binary

2019-08-22 Thread Sergey Dmitriev via Phabricator via cfe-commits

sdmitriev created this revision.
sdmitriev added a reviewer: ABataev.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

clang-offload-bundler tool may hang under certain conditions when it extracts a 
subset of all available device bundles from the fat binary that is handled by 
the BinaryFileHandler. This patch fixes this problem.


Repository:
  rC Clang

https://reviews.llvm.org/D66598

Files:
  clang/test/Driver/clang-offload-bundler.c
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -231,6 +231,7 @@
 
   /// Iterator for the bundle information that is being read.
   StringMap::iterator CurBundleInfo;
+  StringMap::iterator NextBundleInfo;
 
 public:
   BinaryFileHandler() : FileHandler() {}
@@ -300,13 +301,14 @@
   BundlesInfo[Triple] = BundleInfo(Size, Offset);
 }
 // Set the iterator to where we will start to read.
-CurBundleInfo = BundlesInfo.begin();
+CurBundleInfo = BundlesInfo.end();
+NextBundleInfo = BundlesInfo.begin();
   }
 
   StringRef ReadBundleStart(MemoryBuffer &Input) final {
-if (CurBundleInfo == BundlesInfo.end())
+if (NextBundleInfo == BundlesInfo.end())
   return StringRef();
-
+CurBundleInfo = NextBundleInfo++;
 return CurBundleInfo->first();
   }
 
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -221,6 +221,11 @@
 // RUN: diff %t.empty %t.res.tgt1
 // RUN: diff %t.empty %t.res.tgt2
 
+// Check that we do not have to unbundle all available bundles from the fat 
binary.
+// RUN: clang-offload-bundler -type=ast 
-targets=host-%itanium_abi_triple,openmp-x86_64-pc-linux-gnu 
-outputs=%t.res.ast,%t.res.tgt2 -inputs=%t.bundle3.unordered.ast -unbundle
+// RUN: diff %t.ast %t.res.ast
+// RUN: diff %t.tgt2 %t.res.tgt2
+
 //
 // Check object bundle/unbundle. The content should be bundled into an ELF
 // section (we are using a PowerPC little-endian host which uses ELF). We


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -231,6 +231,7 @@
 
   /// Iterator for the bundle information that is being read.
   StringMap::iterator CurBundleInfo;
+  StringMap::iterator NextBundleInfo;
 
 public:
   BinaryFileHandler() : FileHandler() {}
@@ -300,13 +301,14 @@
   BundlesInfo[Triple] = BundleInfo(Size, Offset);
 }
 // Set the iterator to where we will start to read.
-CurBundleInfo = BundlesInfo.begin();
+CurBundleInfo = BundlesInfo.end();
+NextBundleInfo = BundlesInfo.begin();
   }
 
   StringRef ReadBundleStart(MemoryBuffer &Input) final {
-if (CurBundleInfo == BundlesInfo.end())
+if (NextBundleInfo == BundlesInfo.end())
   return StringRef();
-
+CurBundleInfo = NextBundleInfo++;
 return CurBundleInfo->first();
   }
 
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -221,6 +221,11 @@
 // RUN: diff %t.empty %t.res.tgt1
 // RUN: diff %t.empty %t.res.tgt2
 
+// Check that we do not have to unbundle all available bundles from the fat binary.
+// RUN: clang-offload-bundler -type=ast -targets=host-%itanium_abi_triple,openmp-x86_64-pc-linux-gnu -outputs=%t.res.ast,%t.res.tgt2 -inputs=%t.bundle3.unordered.ast -unbundle
+// RUN: diff %t.ast %t.res.ast
+// RUN: diff %t.tgt2 %t.res.tgt2
+
 //
 // Check object bundle/unbundle. The content should be bundled into an ELF
 // section (we are using a PowerPC little-endian host which uses ELF). We
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66516: [clangd] Added highlighting to types dependant on templates.

2019-08-22 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom marked an inline comment as done.
jvikstrom added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:177
   return;
+if (TP->isPointerType() || TP->isLValueReferenceType())
+  // When highlighting dependant template types the type can be a pointer 
or

ilya-biryukov wrote:
> jvikstrom wrote:
> > ilya-biryukov wrote:
> > > `RecursiveASTVisitor` also traverses the pointer and reference types, why 
> > > does it not reach the inner `TemplateTypeParmType` in the cases you 
> > > describe?
> > The D in `using D = ...` `typedef ... D` does not have a TypeLoc (at least 
> > not one that is visited). Therefore we use the VisitTypedefNameDecl (line 
> > 121) to get the location of `D` to be able to highlight it. And we just 
> > send the typeLocs typeptr to addType (which is a Pointer for `using D = 
> > T*;`)...
> > 
> > But maybe we should get the underlying type before we call addType with 
> > TypePtr? Just a while loop on line 123 basically (can we have multiple 
> > PointerTypes nested in each other actually?)
> > 
> > Even if we keep it in addType the comment is actually wrong, because it 
> > obviously works when for the actual "type occurrences" for `D` (so will fix 
> > that no matter what). This recursion will just make us add more duplicate 
> > tokens...
> Could we investigate why `RecursiveASTVisitor` does not visit the `TypeLoc` 
> of a corresponding decl?
> Here's the code from `RecursiveASTVisitor.h` that should do the trick:
> ```
> DEF_TRAVERSE_DECL(TypeAliasDecl, {
>   TRY_TO(TraverseTypeLoc(D->getTypeSourceInfo()->getTypeLoc()));
>   // We shouldn't traverse D->getTypeForDecl(); it's a result of
>   // declaring the type alias, not something that was written in the
>   // source.
> })
> ```
> 
> If it doesn't, we are probably holding it wrong.
There just doesn't seem to be a TypeLoc for the typedef'ed Decl.  We can get 
the `T*` TypeLoc (with `D->getTypeSourceInfo()->getTypeLoc()`). But there isn't 
one for `D`. Even the `D->getTypeForDecl` returns null.

And I have no idea where I'd even start debugging that. Or if it's even a bug



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66516



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

[PATCH] D66516: [clangd] Added highlighting to types dependant on templates.

2019-08-22 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:177
   return;
+if (TP->isPointerType() || TP->isLValueReferenceType())
+  // When highlighting dependant template types the type can be a pointer 
or

jvikstrom wrote:
> ilya-biryukov wrote:
> > jvikstrom wrote:
> > > ilya-biryukov wrote:
> > > > `RecursiveASTVisitor` also traverses the pointer and reference types, 
> > > > why does it not reach the inner `TemplateTypeParmType` in the cases you 
> > > > describe?
> > > The D in `using D = ...` `typedef ... D` does not have a TypeLoc (at 
> > > least not one that is visited). Therefore we use the VisitTypedefNameDecl 
> > > (line 121) to get the location of `D` to be able to highlight it. And we 
> > > just send the typeLocs typeptr to addType (which is a Pointer for `using 
> > > D = T*;`)...
> > > 
> > > But maybe we should get the underlying type before we call addType with 
> > > TypePtr? Just a while loop on line 123 basically (can we have multiple 
> > > PointerTypes nested in each other actually?)
> > > 
> > > Even if we keep it in addType the comment is actually wrong, because it 
> > > obviously works when for the actual "type occurrences" for `D` (so will 
> > > fix that no matter what). This recursion will just make us add more 
> > > duplicate tokens...
> > Could we investigate why `RecursiveASTVisitor` does not visit the `TypeLoc` 
> > of a corresponding decl?
> > Here's the code from `RecursiveASTVisitor.h` that should do the trick:
> > ```
> > DEF_TRAVERSE_DECL(TypeAliasDecl, {
> >   TRY_TO(TraverseTypeLoc(D->getTypeSourceInfo()->getTypeLoc()));
> >   // We shouldn't traverse D->getTypeForDecl(); it's a result of
> >   // declaring the type alias, not something that was written in the
> >   // source.
> > })
> > ```
> > 
> > If it doesn't, we are probably holding it wrong.
> There just doesn't seem to be a TypeLoc for the typedef'ed Decl.  We can get 
> the `T*` TypeLoc (with `D->getTypeSourceInfo()->getTypeLoc()`). But there 
> isn't one for `D`. Even the `D->getTypeForDecl` returns null.
> 
> And I have no idea where I'd even start debugging that. Or if it's even a bug
> 
I may have misinterpreted the patch. Are we trying to add highlightings for the 
names of using aliases here? E.g. for the following range:
```
template 
struct Foo {
  using [[D]] = T**;
};
```

Why isn't this handled in `VisitNamedDecl`?
We don't seem to call this function for `TypedefNameDecl` at all and it 
actually weird. Is this because we attempt to highlight typedefs as their 
underlying types?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66516



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-22 Thread James Y Knight via Phabricator via cfe-commits

jyknight added a comment.

In D57450#1641190 , @lenary wrote:

> @jyknight I hear where you're coming from. I'll see what I can do about the 
> psABI document.
>
> In that ticket, it's mentioned that the Darwin ABI explicitly says that 
> non-power-of-two atomic types should be padded and realigned, but I cannot 
> find any documentation explaining this. That would be useful, given 
> presumably GCC does have to pad/align on Darwin.

AFAIK, there is no such documentation, at least publicly. Possibly Apple has 
some internally, but I suspect it more likely just some in-person conversation 
or something.

GCC is not really supported on Darwin, so I suspect it just gets it wrong.

> Then the only outstanding question relates to zero-sized atomics, which GCC 
> does not pad, but I think Clang has to pad to get the semantics correct, 
> based on this comment: 
> https://github.com/llvm/llvm-project/blob/master/clang/lib/AST/ASTContext.cpp#L2176

The semantics in GCC are that you can create such an object, but any attempt to 
load or store it will result in a compile-time error. E.g., "error: argument 1 
of ‘__atomic_load’ must be a pointer to a nonzero size object". So I don't 
think there's really an issue there.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57450

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

[PATCH] D66538: [AST] AST structural equivalence to work internally with pairs.

2019-08-22 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

> It looks like that the original code is correct in the decision of structural 
> equivalence of the original pair. If we have an (A,B) and (A,C) to compare, B 
> and C are in different decl chain, then (A,B) or (A,C) will be non-equivalent 
> (unless B and C are equivalent, but what to do in this case?). The problem 
> was that the code assumed that in this case always A and B (or A and C) are 
> non-equivalent. If NonEquivalentDecls is not filled in this case (or not used 
> at all) the problem does not exist.

I think we must not update the NonEquivalentDecls cache at that level, because 
as we've seen (during the discussion of https://reviews.llvm.org/D62131) it may 
store the wrong pairs.
However, it is still okay to cache the inequivalent decls in one level upper, 
right after the `Finish` returns.
See this diff 
https://github.com/martong/clang/compare/NonEqDecls_cache_in_an_upper_level~...martong:NonEqDecls_cache_in_an_upper_level?expand=1
Right now I started a build on our CI to see if it causes any slowdown.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66538



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

[clang-tools-extra] r369666 - Fixed Missing Expected error handling

2019-08-22 Thread Shaurya Gupta via cfe-commits

Author: sureyeaah
Date: Thu Aug 22 09:42:42 2019
New Revision: 369666

URL: http://llvm.org/viewvc/llvm-project?rev=369666&view=rev
Log:
Fixed Missing Expected error handling

Modified:
clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp

Modified: clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp?rev=369666&r1=369665&r2=369666&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp Thu Aug 22 
09:42:42 2019
@@ -89,8 +89,10 @@ std::string TweakTest::apply(llvm::Strin
   Tweak::Selection S(AST, Selection.first, Selection.second);
 
   auto T = prepareTweak(TweakID, S);
-  if (!T)
+  if (!T) {
+llvm::toString(T.takeError());
 return "unavailable";
+  }
   llvm::Expected Result = (*T)->apply(S);
   if (!Result)
 return "fail: " + llvm::toString(Result.takeError());


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

r369668 - [OPENMP]Generalization of handling of declare target attribute.

2019-08-22 Thread Alexey Bataev via cfe-commits

Author: abataev
Date: Thu Aug 22 09:48:26 2019
New Revision: 369668

URL: http://llvm.org/viewvc/llvm-project?rev=369668&view=rev
Log:
[OPENMP]Generalization of handling of declare target attribute.

Used OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration instead of
direct checking of the OMPDeclareTargetDeclAttr attribute.

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=369668&r1=369667&r2=369668&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Thu Aug 22 09:48:26 2019
@@ -6799,7 +6799,7 @@ NamedDecl *Sema::ActOnVariableDeclarator
 if (EmitTLSUnsupportedError &&
 ((getLangOpts().CUDA && DeclAttrsMatchCUDAMode(getLangOpts(), NewVD)) 
||
  (getLangOpts().OpenMPIsDevice &&
-  NewVD->hasAttr(
+  OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(NewVD
   Diag(D.getDeclSpec().getThreadStorageClassSpecLoc(),
diag::err_thread_unsupported);
 // CUDA B.2.5: "__shared__ and __constant__ variables have implied static

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=369668&r1=369667&r2=369668&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Thu Aug 22 09:48:26 2019
@@ -15418,7 +15418,7 @@ static void checkDeclInTargetContext(Sou
 static bool checkValueDeclInTarget(SourceLocation SL, SourceRange SR,
Sema &SemaRef, DSAStackTy *Stack,
ValueDecl *VD) {
-  return VD->hasAttr() ||
+  return OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(VD) ||
  checkTypeMappable(SL, SR, SemaRef, Stack, VD->getType(),
/*FullCheck=*/false);
 }


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

Re: r261008 - Add a nullPointerConstant() AST matcher to handle variations of null pointer constants in one matcher.

2019-08-22 Thread Richard Smith via cfe-commits

(Sorry for the very late review!)

On Tue, 16 Feb 2016 at 13:06, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: aaronballman
> Date: Tue Feb 16 15:02:23 2016
> New Revision: 261008
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261008&view=rev
> Log:
> Add a nullPointerConstant() AST matcher to handle variations of null
> pointer constants in one matcher.
>
> Modified:
> cfe/trunk/docs/LibASTMatchersReference.html
> cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
> cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
>
> Modified: cfe/trunk/docs/LibASTMatchersReference.html
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=261008&r1=261007&r2=261008&view=diff
>
> ==
> --- cfe/trunk/docs/LibASTMatchersReference.html (original)
> +++ cfe/trunk/docs/LibASTMatchersReference.html Tue Feb 16 15:02:23 2016
> @@ -2176,6 +2176,23 @@ fieldDecl(isPublic())
>  
>
>
> +MatcherExpr> class="name" onclick="toggle('nullPointerConstant0')"> name="nullPointerConstant0Anchor">nullPointerConstant
> +Matches
> expressions that resolve to a null pointer constant, such as
> +GNU's __null, C++11's nullptr, or C's NULL macro.
> +
> +Given:
> +  void *v1 = NULL;
> +  void *v2 = nullptr;
> +  void *v3 = __null; GNU extension
> +  char *cp = (char *)0;
> +  int *ip = 0;
> +  int i = 0;
> +expr(nullPointerConstant())
> +  matches the initializer for v1, v2, v3, cp, and ip. Does not match the
> +  initializer for i.
> +
> +
> +
>  MatcherFloatingLiteral> class="name" onclick="toggle('equals1')"> name="equals1Anchor">equalsValueT  Value
>  Matches literals that
> are equal to the given value.
>
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261008&r1=261007&r2=261008&view=diff
>
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Feb 16 15:02:23
> 2016
> @@ -4816,6 +4816,27 @@ const internal::VariadicDynCastAllOfMatc
>Stmt,
>CUDAKernelCallExpr> cudaKernelCallExpr;
>
> +
> +/// \brief Matches expressions that resolve to a null pointer constant,
> such as
> +/// GNU's __null, C++11's nullptr, or C's NULL macro.
> +///
> +/// Given:
> +/// \code
> +///   void *v1 = NULL;
> +///   void *v2 = nullptr;
> +///   void *v3 = __null; // GNU extension
> +///   char *cp = (char *)0;
> +///   int *ip = 0;
> +///   int i = 0;
> +/// \endcode
> +/// expr(nullPointerConstant())
> +///   matches the initializer for v1, v2, v3, cp, and ip. Does not match
> the
> +///   initializer for i.
> +AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
> +  return anyOf(
> +  gnuNullExpr(), cxxNullPtrLiteralExpr(),
> +  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
>

Is there a reason this logic was reinvented rather than using
Expr::isNullPointerConstant()? This is not correct in C or in Clang's
interpretation of DRs against C++98.


> +}
>  } // end namespace ast_matchers
>  } // end namespace clang
>
>
> Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=261008&r1=261007&r2=261008&view=diff
>
> ==
> --- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
> +++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Tue Feb 16 15:02:23 2016
> @@ -326,6 +326,7 @@ RegistryMaps::RegistryMaps() {
>REGISTER_MATCHER(namesType);
>REGISTER_MATCHER(nestedNameSpecifier);
>REGISTER_MATCHER(nestedNameSpecifierLoc);
> +  REGISTER_MATCHER(nullPointerConstant);
>REGISTER_MATCHER(nullStmt);
>REGISTER_MATCHER(numSelectorArgs);
>REGISTER_MATCHER(ofClass);
>
> Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=261008&r1=261007&r2=261008&view=diff
>
> ==
> --- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
> +++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Tue Feb 16
> 15:02:23 2016
> @@ -5348,5 +5348,15 @@ TEST(ObjCMessageExprMatcher, SimpleExprs
>)));
>  }
>
> +TEST(NullPointerConstants, Basic) {
> +  EXPECT_TRUE(matches("#define NULL ((void *)0)\n"
> +  "void *v1 = NULL;", expr(nullPointerConstant(;
> +  EXPECT_TRUE(matches("void *v2 = nullptr;",
> expr(nullPointerConstant(;

[PATCH] D66302: [SVE][Inline-Asm] Support for SVE asm operands

2019-08-22 Thread Kerry McLaughlin via Phabricator via cfe-commits

kmclaughlin updated this revision to Diff 216655.
kmclaughlin added a comment.

- Removed a confusing comment from AArch64AsmPrinter.cpp


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

https://reviews.llvm.org/D66302

Files:
  docs/LangRef.rst
  lib/Target/AArch64/AArch64AsmPrinter.cpp
  lib/Target/AArch64/AArch64ISelLowering.cpp
  lib/Target/AArch64/AArch64InstrInfo.cpp
  lib/Target/AArch64/AArch64SVEInstrInfo.td
  test/CodeGen/AArch64/aarch64-sve-asm-negative.ll
  test/CodeGen/AArch64/aarch64-sve-asm.ll
  test/CodeGen/AArch64/arm64-inline-asm.ll

Index: test/CodeGen/AArch64/arm64-inline-asm.ll
===
--- test/CodeGen/AArch64/arm64-inline-asm.ll
+++ test/CodeGen/AArch64/arm64-inline-asm.ll
@@ -138,6 +138,8 @@
   %a = alloca [2 x float], align 4
   %arraydecay = getelementptr inbounds [2 x float], [2 x float]* %a, i32 0, i32 0
   %0 = load <2 x float>, <2 x float>* %data, align 8
+  call void asm sideeffect "ldr ${1:z}, [$0]\0A", "r,w"(float* %arraydecay, <2 x float> %0) nounwind
+  ; CHECK: ldr {{z[0-9]+}}, [{{x[0-9]+}}]
   call void asm sideeffect "ldr ${1:q}, [$0]\0A", "r,w"(float* %arraydecay, <2 x float> %0) nounwind
   ; CHECK: ldr {{q[0-9]+}}, [{{x[0-9]+}}]
   call void asm sideeffect "ldr ${1:d}, [$0]\0A", "r,w"(float* %arraydecay, <2 x float> %0) nounwind
Index: test/CodeGen/AArch64/aarch64-sve-asm.ll
===
--- /dev/null
+++ test/CodeGen/AArch64/aarch64-sve-asm.ll
@@ -0,0 +1,44 @@
+; RUN: llc < %s -mtriple aarch64-none-linux-gnu -mattr=+sve -stop-after=finalize-isel | FileCheck %s --check-prefix=CHECK
+
+target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-none-linux-gnu"
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_3b = COPY [[ARG1]]
+define  @test_svadd_i8( %Zn,  %Zm) {
+  %1 = tail call  asm "add $0.b, $1.b, $2.b", "=w,w,y"( %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_4b = COPY [[ARG1]]
+define  @test_svsub_i64( %Zn,  %Zm) {
+  %1 = tail call  asm "sub $0.d, $1.d, $2.d", "=w,w,x"( %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_3b = COPY [[ARG1]]
+define  @test_svfmul_f16( %Zn,  %Zm) {
+  %1 = tail call  asm "fmul $0.h, $1.h, $2.h", "=w,w,y"( %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr_4b = COPY [[ARG1]]
+define  @test_svfmul_f( %Zn,  %Zm) {
+  %1 = tail call  asm "fmul $0.s, $1.s, $2.s", "=w,w,x"( %Zn,  %Zm)
+  ret  %1
+}
Index: test/CodeGen/AArch64/aarch64-sve-asm-negative.ll
===
--- /dev/null
+++ test/CodeGen/AArch64/aarch64-sve-asm-negative.ll
@@ -0,0 +1,12 @@
+; RUN: not llc -mtriple aarch64-none-linux-gnu -mattr=+neon -o %t.s -filetype=asm %s 2>&1 | FileCheck %s
+
+; The 'y' constraint only applies to SVE vector registers (Z0-Z7)
+; The test below ensures that we get an appropriate error should the
+; constraint be used with a Neon register.
+
+; Function Attrs: nounwind readnone
+; CHECK: error: couldn't allocate input reg for constraint 'y'
+define <4 x i32> @test_neon(<4 x i32> %in1, <4 x i32> %in2) {
+  %1 = tail call <4 x i32> asm "add $0.4s, $1.4s, $2.4s", "=w,w,y"(<4 x i32> %in1, <4 x i32> %in2)
+  ret <4 x i32> %1
+}
Index: lib/Target/AArch64/AArch64SVEInstrInfo.td
===
--- lib/Target/AArch64/AArch64SVEInstrInfo.td
+++ lib/Target/AArch64/AArch64SVEInstrInfo.td
@@ -1020,6 +1020,56 @@
   (FCMGT_PPzZZ_S PPR32:$Zd, PPR3bAny:$Pg, ZPR32:$Zn, ZPR32:$Zm), 0>;
   def : InstAlias<"fcmlt $Zd, $Pg/z, $Zm, $Zn",
   (FCMGT_PPzZZ_D PPR64:$Zd, PPR3bAny:$Pg, ZPR64:$Zn, ZPR64:$Zm), 0>;
+
+  def : Pat<(nxv16i8 (bitconvert (nxv8i16 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv4i32 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv2i64 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv8f16 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv4f32 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+  def : Pat<(nxv16i8 (bitconvert (nxv2f64 ZPR:$src))), (nxv16i8 ZPR:$src)>;
+
+  def : Pat<(nxv8i16 (bitconvert (nxv16i8 ZPR:$src))), (nxv8i16 ZPR:$src)>;
+  def : Pat<(nxv8i16 (bitconvert (nxv4i32 ZPR:$src))), (nxv8i16 ZPR:$sr

Re: r261008 - Add a nullPointerConstant() AST matcher to handle variations of null pointer constants in one matcher.

2019-08-22 Thread Aaron Ballman via cfe-commits

On Thu, Aug 22, 2019 at 12:58 PM Richard Smith  wrote:
>
> (Sorry for the very late review!)
>
> On Tue, 16 Feb 2016 at 13:06, Aaron Ballman via cfe-commits 
>  wrote:
>>
>> Author: aaronballman
>> Date: Tue Feb 16 15:02:23 2016
>> New Revision: 261008
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=261008&view=rev
>> Log:
>> Add a nullPointerConstant() AST matcher to handle variations of null pointer 
>> constants in one matcher.
>>
>> Modified:
>> cfe/trunk/docs/LibASTMatchersReference.html
>> cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
>> cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
>> cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
>>
>> Modified: cfe/trunk/docs/LibASTMatchersReference.html
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=261008&r1=261007&r2=261008&view=diff
>> ==
>> --- cfe/trunk/docs/LibASTMatchersReference.html (original)
>> +++ cfe/trunk/docs/LibASTMatchersReference.html Tue Feb 16 15:02:23 2016
>> @@ -2176,6 +2176,23 @@ fieldDecl(isPublic())
>>  
>>
>>
>> +Matcher<> href="http://clang.llvm.org/doxygen/classclang_1_1Expr.html";>Expr>>  class="name" onclick="toggle('nullPointerConstant0')">> name="nullPointerConstant0Anchor">nullPointerConstant
>> +Matches 
>> expressions that resolve to a null pointer constant, such as
>> +GNU's __null, C++11's nullptr, or C's NULL macro.
>> +
>> +Given:
>> +  void *v1 = NULL;
>> +  void *v2 = nullptr;
>> +  void *v3 = __null; GNU extension
>> +  char *cp = (char *)0;
>> +  int *ip = 0;
>> +  int i = 0;
>> +expr(nullPointerConstant())
>> +  matches the initializer for v1, v2, v3, cp, and ip. Does not match the
>> +  initializer for i.
>> +
>> +
>> +
>>  Matcher<> href="http://clang.llvm.org/doxygen/classclang_1_1FloatingLiteral.html";>FloatingLiteral>>  class="name" onclick="toggle('equals1')">> name="equals1Anchor">equalsValueT  Value
>>  Matches literals that are 
>> equal to the given value.
>>
>>
>> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261008&r1=261007&r2=261008&view=diff
>> ==
>> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
>> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Feb 16 15:02:23 
>> 2016
>> @@ -4816,6 +4816,27 @@ const internal::VariadicDynCastAllOfMatc
>>Stmt,
>>CUDAKernelCallExpr> cudaKernelCallExpr;
>>
>> +
>> +/// \brief Matches expressions that resolve to a null pointer constant, 
>> such as
>> +/// GNU's __null, C++11's nullptr, or C's NULL macro.
>> +///
>> +/// Given:
>> +/// \code
>> +///   void *v1 = NULL;
>> +///   void *v2 = nullptr;
>> +///   void *v3 = __null; // GNU extension
>> +///   char *cp = (char *)0;
>> +///   int *ip = 0;
>> +///   int i = 0;
>> +/// \endcode
>> +/// expr(nullPointerConstant())
>> +///   matches the initializer for v1, v2, v3, cp, and ip. Does not match the
>> +///   initializer for i.
>> +AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
>> +  return anyOf(
>> +  gnuNullExpr(), cxxNullPtrLiteralExpr(),
>> +  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
>
>
> Is there a reason this logic was reinvented rather than using 
> Expr::isNullPointerConstant()? This is not correct in C or in Clang's 
> interpretation of DRs against C++98.

No reason that I can recall, I'll make the switch. Thank you for the feedback!

~Aaron

>
>>
>> +}
>>  } // end namespace ast_matchers
>>  } // end namespace clang
>>
>>
>> Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=261008&r1=261007&r2=261008&view=diff
>> ==
>> --- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
>> +++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Tue Feb 16 15:02:23 2016
>> @@ -326,6 +326,7 @@ RegistryMaps::RegistryMaps() {
>>REGISTER_MATCHER(namesType);
>>REGISTER_MATCHER(nestedNameSpecifier);
>>REGISTER_MATCHER(nestedNameSpecifierLoc);
>> +  REGISTER_MATCHER(nullPointerConstant);
>>REGISTER_MATCHER(nullStmt);
>>REGISTER_MATCHER(numSelectorArgs);
>>REGISTER_MATCHER(ofClass);
>>
>> Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=261008&r1=261007&r2=261008&view=diff
>> ==
>> --- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
>> +++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Tue Feb 16 15:02:23 
>> 2016
>> @@ -5348,5 +5348,15 @@ TEST(ObjCMessageExprMatcher, SimpleExprs
>>

[PATCH] D66555: [driver] add a new option `-gen-cdb-fragment-path` to emit a fragment of a compilation database for each compilation

2019-08-22 Thread Alex Lorenz via Phabricator via cfe-commits

arphaman added a comment.

In D66555#1640603 , @tschuett wrote:

> How does it relate to the -MJ option?


Ah, I wasn't aware that such option existed. I should use it instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66555



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

[PATCH] D66446: [clang][IFS] Adding new Interface Stubs format.

2019-08-22 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.

Please add a test case for read/write, otherwise LGTM.




Comment at: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp:383
+auto VD = cast(E.first)->getType();
+OS << "Object, Size: "
+   << context.getTypeSizeInChars(VD).getQuantity();

Why is this comma separated rather than a separate value?



Comment at: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp:392
+  if (Symbol.Binding == llvm::ELF::STB_WEAK)
+OS << ", Weak: true";
+  OS << " }\n";

Why comma separated rather than new KV pair?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66446



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

[PATCH] D66601: [Clang][Bundler] Do not require host triple for extracting device bundles

2019-08-22 Thread Sergey Dmitriev via Phabricator via cfe-commits

sdmitriev created this revision.
sdmitriev added a reviewer: ABataev.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
sdmitriev added a reviewer: hfinkel.

Bundler currently requires host triple to be provided no matter if you are 
performing bundling or unbundling, but for unbundling operation such 
requirement is too restrictive. You may for example want to examine device part 
of the object for a particular offload target, but you have to extract host 
part as well even though you do not need it. Host triple isn't really needed 
for unbundling, so this patch removes that requirement.


Repository:
  rC Clang

https://reviews.llvm.org/D66601

Files:
  clang/test/Driver/clang-offload-bundler.c
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -833,7 +833,6 @@
 
   // Read all the bundles that are in the work list. If we find no bundles we
   // assume the file is meant for the host target.
-  bool FoundHostBundle = false;
   while (!Worklist.empty()) {
 StringRef CurTriple = FH.get()->ReadBundleStart(Input);
 
@@ -859,10 +858,6 @@
 FH.get()->ReadBundle(OutputFile, Input);
 FH.get()->ReadBundleEnd(Input);
 Worklist.erase(Output);
-
-// Record if we found the host bundle.
-if (hasHostKind(CurTriple))
-  FoundHostBundle = true;
   }
 
   // If no bundles were found, assume the input file is the host bundle and
@@ -884,12 +879,6 @@
 return false;
   }
 
-  // If we found elements, we emit an error if none of those were for the host.
-  if (!FoundHostBundle) {
-errs() << "error: Can't find bundle for the host target\n";
-return true;
-  }
-
   // If we still have any elements in the worklist, create empty files for 
them.
   for (auto &E : Worklist) {
 std::error_code EC;
@@ -988,7 +977,9 @@
 ++Index;
   }
 
-  if (HostTargetNum != 1) {
+  // Host triple is not really needed for unbundling operation, so do not
+  // treat missing host triple as error if we do unbundling.
+  if ((Unbundle && HostTargetNum > 1) || (!Unbundle && HostTargetNum != 1)) {
 Error = true;
 errs() << "error: expecting exactly one host target but got "
<< HostTargetNum << ".\n";
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -183,6 +183,10 @@
 // RUN: diff %t.empty %t.res.tgt1
 // RUN: diff %t.empty %t.res.tgt2
 
+// Check that we can extract target parts without providing host triple.
+// RUN: clang-offload-bundler -type=s 
-targets=openmp-powerpc64le-ibm-linux-gnu -outputs=%t.res.tgt1 
-inputs=%t.bundle3.s -unbundle
+// RUN: diff %t.tgt1 %t.res.tgt1
+
 //
 // Check binary bundle/unbundle. The content that we have before bundling must 
be the same we have after unbundling.
 //
@@ -221,6 +225,10 @@
 // RUN: diff %t.empty %t.res.tgt1
 // RUN: diff %t.empty %t.res.tgt2
 
+// Check that we can extract target parts without providing host triple.
+// RUN: clang-offload-bundler -type=ast 
-targets=openmp-powerpc64le-ibm-linux-gnu -outputs=%t.res.tgt1 
-inputs=%t.bundle3.unordered.ast -unbundle
+// RUN: diff %t.tgt1 %t.res.tgt1
+
 //
 // Check object bundle/unbundle. The content should be bundled into an ELF
 // section (we are using a PowerPC little-endian host which uses ELF). We
@@ -256,6 +264,10 @@
 // RUN: diff %t.empty %t.res.tgt1
 // RUN: diff %t.empty %t.res.tgt2
 
+// Check that we can extract target parts without providing host triple.
+// RUN: clang-offload-bundler -type=o 
-targets=openmp-powerpc64le-ibm-linux-gnu -outputs=%t.res.tgt1 
-inputs=%t.bundle3.o -unbundle
+// RUN: diff %t.tgt1 %t.res.tgt1
+
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void) {


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -833,7 +833,6 @@
 
   // Read all the bundles that are in the work list. If we find no bundles we
   // assume the file is meant for the host target.
-  bool FoundHostBundle = false;
   while (!Worklist.empty()) {
 StringRef CurTriple = FH.get()->ReadBundleStart(Input);
 
@@ -859,10 +858,6 @@
 FH.get()->ReadBundle(OutputFile, Input);
 FH.get()->ReadBundleEnd(Input);
 Worklist.erase(Output);
-
-// Record if we found the host bundle.
-if (hasHostKind(CurTriple))
-  FoundHostBundle = true;
   }
 
   // If no bundles were found, assume the input file is the host bundle and
@@ -884,12 +879,6 @@
 return

[PATCH] D66573: [clang][ifs] Dropping older experimental interface stub formats.

2019-08-22 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.

Please add a diagnostic to indicate that the provided value is invalid for the 
argument (or at at least extend the existing the tests to ensure that the old 
values are diagnosed in the driver rather hitting the assert in the frontend.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66573



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

[PATCH] D66446: [clang][IFS] Adding new Interface Stubs format.

2019-08-22 Thread Puyan Lotfi via Phabricator via cfe-commits

plotfi marked 4 inline comments as done.
plotfi added inline comments.



Comment at: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp:383
+auto VD = cast(E.first)->getType();
+OS << "Object, Size: "
+   << context.getTypeSizeInChars(VD).getQuantity();

compnerd wrote:
> Why is this comma separated rather than a separate value?
Vestiges of TBE elfabi inspiration. It can change in experimental-ifs-v2 / 1.1 
or something.



Comment at: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp:392
+  if (Symbol.Binding == llvm::ELF::STB_WEAK)
+OS << ", Weak: true";
+  OS << " }\n";

compnerd wrote:
> Why comma separated rather than new KV pair?
Vestiges of TBE elfabi inspiration. It can change in experimental-ifs-v2 / 1.1 
or something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66446



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

[clang-tools-extra] r369674 - Retire llvm::less/equal in favor of C++14 std::less<>/equal_to<>.

2019-08-22 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Thu Aug 22 10:31:59 2019
New Revision: 369674

URL: http://llvm.org/viewvc/llvm-project?rev=369674&view=rev
Log:
Retire llvm::less/equal in favor of C++14 std::less<>/equal_to<>.

Modified:
clang-tools-extra/trunk/clang-doc/Representation.h

Modified: clang-tools-extra/trunk/clang-doc/Representation.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-doc/Representation.h?rev=369674&r1=369673&r2=369674&view=diff
==
--- clang-tools-extra/trunk/clang-doc/Representation.h (original)
+++ clang-tools-extra/trunk/clang-doc/Representation.h Thu Aug 22 10:31:59 2019
@@ -61,7 +61,7 @@ struct CommentInfo {
   return false;
 
 return std::equal(Children.begin(), Children.end(), Other.Children.begin(),
-  llvm::deref{});
+  llvm::deref>{});
   }
 
   // This operator is used to sort a vector of CommentInfos.
@@ -82,7 +82,7 @@ struct CommentInfo {
 if (FirstCI == SecondCI) {
   return std::lexicographical_compare(
   Children.begin(), Children.end(), Other.Children.begin(),
-  Other.Children.end(), llvm::deref());
+  Other.Children.end(), llvm::deref>());
 }
 
 return false;


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

r369675 - Retire llvm::less_ptr. llvm::deref is much more flexible.

2019-08-22 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Thu Aug 22 10:32:16 2019
New Revision: 369675

URL: http://llvm.org/viewvc/llvm-project?rev=369675&view=rev
Log:
Retire llvm::less_ptr. llvm::deref is much more flexible.

Modified:
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/utils/TableGen/NeonEmitter.cpp

Modified: cfe/trunk/lib/Serialization/ASTWriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriter.cpp?rev=369675&r1=369674&r2=369675&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriter.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriter.cpp Thu Aug 22 10:32:16 2019
@@ -2506,7 +2506,7 @@ void ASTWriter::WritePreprocessor(const
   MacroIdentifiers.push_back(Id.second);
   // Sort the set of macro definitions that need to be serialized by the
   // name of the macro, to provide a stable ordering.
-  llvm::sort(MacroIdentifiers, llvm::less_ptr());
+  llvm::sort(MacroIdentifiers, llvm::deref>());
 
   // Emit the macro directives as a list and associate the offset with the
   // identifier they belong to.
@@ -3748,7 +3748,7 @@ void ASTWriter::WriteIdentifierTable(Pre
   IIs.push_back(ID.second);
 // Sort the identifiers lexicographically before getting them references so
 // that their order is stable.
-llvm::sort(IIs, llvm::less_ptr());
+llvm::sort(IIs, llvm::deref>());
 for (const IdentifierInfo *II : IIs)
   if (Trait.isInterestingNonMacroIdentifier(II))
 getIdentifierRef(II);
@@ -4924,7 +4924,7 @@ ASTFileSignature ASTWriter::WriteASTCore
 IIs.push_back(II);
 }
 // Sort the identifiers to visit based on their name.
-llvm::sort(IIs, llvm::less_ptr());
+llvm::sort(IIs, llvm::deref>());
 for (const IdentifierInfo *II : IIs) {
   for (IdentifierResolver::iterator D = SemaRef.IdResolver.begin(II),
  DEnd = SemaRef.IdResolver.end();

Modified: cfe/trunk/utils/TableGen/NeonEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/NeonEmitter.cpp?rev=369675&r1=369674&r2=369675&view=diff
==
--- cfe/trunk/utils/TableGen/NeonEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/NeonEmitter.cpp Thu Aug 22 10:32:16 2019
@@ -2456,7 +2456,7 @@ void NeonEmitter::run(raw_ostream &OS) {
   for (auto *I : Defs)
 I->indexBody();
 
-  llvm::stable_sort(Defs, llvm::less_ptr());
+  llvm::stable_sort(Defs, llvm::deref>());
 
   // Only emit a def when its requirements have been met.
   // FIXME: This loop could be made faster, but it's fast enough for now.
@@ -2563,7 +2563,7 @@ void NeonEmitter::runFP16(raw_ostream &O
   for (auto *I : Defs)
 I->indexBody();
 
-  llvm::stable_sort(Defs, llvm::less_ptr());
+  llvm::stable_sort(Defs, llvm::deref>());
 
   // Only emit a def when its requirements have been met.
   // FIXME: This loop could be made faster, but it's fast enough for now.


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

Re: r369591 - [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-22 Thread Richard Smith via cfe-commits

Hi Matthias,

This introduces false positives into -Wreturn-stack-address for an example
such as:

#include 

std::vector::iterator downcast_to(std::vector::iterator value) {
  return *&value;
}

This breaks an internal build bot for us, so I'm going to revert this for
now (though I expect this isn't the cause of the problem, but is rather
exposing a problem elsewhere).

If we can make the gsl::Pointer diagnostics false-positive-free, that's
great, but otherwise we should use a different warning flag for the
warnings that involve these annotations and use -Wreturn-stack-address for
only the zero-false-positive cases that it historically diagnosed.

Thanks, and sorry for the trouble.

On Wed, 21 Aug 2019 at 15:07, Matthias Gehre via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: mgehre
> Date: Wed Aug 21 15:08:59 2019
> New Revision: 369591
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369591&view=rev
> Log:
> [LifetimeAnalysis] Support more STL idioms (template forward declaration
> and DependentNameType)
>
> Summary:
> This fixes inference of gsl::Pointer on std::set::iterator with libstdc++
> (the typedef for iterator
> on the template is a DependentNameType - we can only put the gsl::Pointer
> attribute
> on the underlaying record after instantiation)
>
> inference of gsl::Pointer on std::vector::iterator with libc++ (the class
> was forward-declared,
> we added the gsl::Pointer on the canonical decl (the forward decl), and
> later when the
> template was instantiated, there was no attribute on the definition so it
> was not instantiated).
>
> and a duplicate gsl::Pointer on some class with libstdc++ (we first added
> an attribute to
> a incomplete instantiation, and then another was copied from the template
> definition
> when the instantiation was completed).
>
> We now add the attributes to all redeclarations to fix thos issues and
> make their usage easier.
>
> Reviewers: gribozavr
>
> Subscribers: Szelethus, xazax.hun, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D66179
>
> Added:
> cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaAttr.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
> cfe/trunk/unittests/Sema/CMakeLists.txt
>
> Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaAttr.cpp Wed Aug 21 15:08:59 2019
> @@ -88,13 +88,11 @@ void Sema::AddMsStructLayoutForRecord(Re
>  template 
>  static void addGslOwnerPointerAttributeIfNotExisting(ASTContext &Context,
>   CXXRecordDecl
> *Record) {
> -  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -  if (Canonical->hasAttr() ||
> Canonical->hasAttr())
> +  if (Record->hasAttr() || Record->hasAttr())
>  return;
>
> -  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
> -   /*DerefType*/ nullptr,
> -   /*Spelling=*/0));
> +  for (Decl *Redecl : Record->redecls())
> +Redecl->addAttr(Attribute::CreateImplicit(Context,
> /*DerefType=*/nullptr));
>  }
>
>  void Sema::inferGslPointerAttribute(NamedDecl *ND,
> @@ -189,8 +187,7 @@ void Sema::inferGslOwnerPointerAttribute
>
>// Handle classes that directly appear in std namespace.
>if (Record->isInStdNamespace()) {
> -CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -if (Canonical->hasAttr() ||
> Canonical->hasAttr())
> +if (Record->hasAttr() || Record->hasAttr())
>return;
>
>  if (StdOwners.count(Record->getName()))
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Aug 21 15:08:59 2019
> @@ -4592,9 +4592,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -D->addAttr(::new (S.Context)
> -   OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> - AL.getAttributeSpellingListIndex()));
> +for (Decl *Redecl : D->redecls()) {
> +  Redecl->addAttr(::new (S.Context)
> +  OwnerAttr(AL.getRange(), S.Context,
> DerefTypeLoc,
> +AL.getAttributeSpellingListIndex()));
> +}
>} else {
>

[clang-tools-extra] r369676 - [Clangd] Tweaktesting replace toString with consumeError

2019-08-22 Thread Shaurya Gupta via cfe-commits

Author: sureyeaah
Date: Thu Aug 22 10:36:31 2019
New Revision: 369676

URL: http://llvm.org/viewvc/llvm-project?rev=369676&view=rev
Log:
[Clangd] Tweaktesting replace toString with consumeError

Modified:
clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp

Modified: clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp?rev=369676&r1=369675&r2=369676&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp Thu Aug 22 
10:36:31 2019
@@ -90,7 +90,7 @@ std::string TweakTest::apply(llvm::Strin
 
   auto T = prepareTweak(TweakID, S);
   if (!T) {
-llvm::toString(T.takeError());
+llvm::consumeError(T.takeError());
 return "unavailable";
   }
   llvm::Expected Result = (*T)->apply(S);


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

[PATCH] D66437: Sema: Create a no-op implicit cast for lvalue function conversions.

2019-08-22 Thread Peter Collingbourne via Phabricator via cfe-commits

pcc added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66437



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

r369677 - Revert "[LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)"

2019-08-22 Thread Richard Smith via cfe-commits

Author: rsmith
Date: Thu Aug 22 10:48:11 2019
New Revision: 369677

URL: http://llvm.org/viewvc/llvm-project?rev=369677&view=rev
Log:
Revert "[LifetimeAnalysis] Support more STL idioms (template forward 
declaration and DependentNameType)"

This reverts commit r369591, because it causes the formerly-reliable
-Wreturn-stack-address warning to start issuing false positives.
Testcase provided on the commit thread.

Removed:
cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
Modified:
cfe/trunk/lib/Sema/SemaAttr.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
cfe/trunk/unittests/Sema/CMakeLists.txt

Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=369677&r1=369676&r2=369677&view=diff
==
--- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaAttr.cpp Thu Aug 22 10:48:11 2019
@@ -88,11 +88,13 @@ void Sema::AddMsStructLayoutForRecord(Re
 template 
 static void addGslOwnerPointerAttributeIfNotExisting(ASTContext &Context,
  CXXRecordDecl *Record) {
-  if (Record->hasAttr() || Record->hasAttr())
+  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
+  if (Canonical->hasAttr() || Canonical->hasAttr())
 return;
 
-  for (Decl *Redecl : Record->redecls())
-Redecl->addAttr(Attribute::CreateImplicit(Context, /*DerefType=*/nullptr));
+  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
+   /*DerefType*/ nullptr,
+   /*Spelling=*/0));
 }
 
 void Sema::inferGslPointerAttribute(NamedDecl *ND,
@@ -187,7 +189,8 @@ void Sema::inferGslOwnerPointerAttribute
 
   // Handle classes that directly appear in std namespace.
   if (Record->isInStdNamespace()) {
-if (Record->hasAttr() || Record->hasAttr())
+CXXRecordDecl *Canonical = Record->getCanonicalDecl();
+if (Canonical->hasAttr() || Canonical->hasAttr())
   return;
 
 if (StdOwners.count(Record->getName()))

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=369677&r1=369676&r2=369677&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Aug 22 10:48:11 2019
@@ -4592,11 +4592,9 @@ static void handleLifetimeCategoryAttr(S
   }
   return;
 }
-for (Decl *Redecl : D->redecls()) {
-  Redecl->addAttr(::new (S.Context)
-  OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
-AL.getAttributeSpellingListIndex()));
-}
+D->addAttr(::new (S.Context)
+   OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
+ AL.getAttributeSpellingListIndex()));
   } else {
 if (checkAttrMutualExclusion(S, D, AL))
   return;
@@ -4611,11 +4609,9 @@ static void handleLifetimeCategoryAttr(S
   }
   return;
 }
-for (Decl *Redecl : D->redecls()) {
-  Redecl->addAttr(::new (S.Context)
-  PointerAttr(AL.getRange(), S.Context, DerefTypeLoc,
-  AL.getAttributeSpellingListIndex()));
-}
+D->addAttr(::new (S.Context)
+   PointerAttr(AL.getRange(), S.Context, DerefTypeLoc,
+   AL.getAttributeSpellingListIndex()));
   }
 }
 

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=369677&r1=369676&r2=369677&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Thu Aug 22 10:48:11 2019
@@ -6561,7 +6561,7 @@ static void visitLocalsRetainedByReferen
 
 template  static bool isRecordWithAttr(QualType Type) {
   if (auto *RD = Type->getAsCXXRecordDecl())
-return RD->hasAttr();
+return RD->getCanonicalDecl()->hasAttr();
   return false;
 }
 
@@ -6672,7 +6672,7 @@ static void handleGslAnnotatedTypes(Indi
 
   if (auto *CCE = dyn_cast(Call)) {
 const auto *Ctor = CCE->getConstructor();
-const CXXRecordDecl *RD = Ctor->getParent();
+const CXXRecordDecl *RD = Ctor->getParent()->getCanonicalDecl();
 if (CCE->getNumArgs() > 0 && RD->hasAttr())
   VisitPointerArg(Ctor->getParamDecl(0), CCE->getArgs()[0]);
   }

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=369677&r1=369676&r2=369677&view=diff
===

Re: r369591 - [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-22 Thread Richard Smith via cfe-commits

Reverted in r369677.

On Thu, 22 Aug 2019 at 10:34, Richard Smith  wrote:

> Hi Matthias,
>
> This introduces false positives into -Wreturn-stack-address for an example
> such as:
>
> #include 
>
> std::vector::iterator downcast_to(std::vector::iterator value) {
>   return *&value;
> }
>
> This breaks an internal build bot for us, so I'm going to revert this for
> now (though I expect this isn't the cause of the problem, but is rather
> exposing a problem elsewhere).
>
> If we can make the gsl::Pointer diagnostics false-positive-free, that's
> great, but otherwise we should use a different warning flag for the
> warnings that involve these annotations and use -Wreturn-stack-address for
> only the zero-false-positive cases that it historically diagnosed.
>
> Thanks, and sorry for the trouble.
>
> On Wed, 21 Aug 2019 at 15:07, Matthias Gehre via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: mgehre
>> Date: Wed Aug 21 15:08:59 2019
>> New Revision: 369591
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=369591&view=rev
>> Log:
>> [LifetimeAnalysis] Support more STL idioms (template forward declaration
>> and DependentNameType)
>>
>> Summary:
>> This fixes inference of gsl::Pointer on std::set::iterator with libstdc++
>> (the typedef for iterator
>> on the template is a DependentNameType - we can only put the gsl::Pointer
>> attribute
>> on the underlaying record after instantiation)
>>
>> inference of gsl::Pointer on std::vector::iterator with libc++ (the class
>> was forward-declared,
>> we added the gsl::Pointer on the canonical decl (the forward decl), and
>> later when the
>> template was instantiated, there was no attribute on the definition so it
>> was not instantiated).
>>
>> and a duplicate gsl::Pointer on some class with libstdc++ (we first added
>> an attribute to
>> a incomplete instantiation, and then another was copied from the template
>> definition
>> when the instantiation was completed).
>>
>> We now add the attributes to all redeclarations to fix thos issues and
>> make their usage easier.
>>
>> Reviewers: gribozavr
>>
>> Subscribers: Szelethus, xazax.hun, cfe-commits
>>
>> Tags: #clang
>>
>> Differential Revision: https://reviews.llvm.org/D66179
>>
>> Added:
>> cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
>> Modified:
>> cfe/trunk/lib/Sema/SemaAttr.cpp
>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> cfe/trunk/lib/Sema/SemaInit.cpp
>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
>> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
>> cfe/trunk/unittests/Sema/CMakeLists.txt
>>
>> Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaAttr.cpp Wed Aug 21 15:08:59 2019
>> @@ -88,13 +88,11 @@ void Sema::AddMsStructLayoutForRecord(Re
>>  template 
>>  static void addGslOwnerPointerAttributeIfNotExisting(ASTContext &Context,
>>   CXXRecordDecl
>> *Record) {
>> -  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
>> -  if (Canonical->hasAttr() ||
>> Canonical->hasAttr())
>> +  if (Record->hasAttr() || Record->hasAttr())
>>  return;
>>
>> -  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
>> -   /*DerefType*/ nullptr,
>> -   /*Spelling=*/0));
>> +  for (Decl *Redecl : Record->redecls())
>> +Redecl->addAttr(Attribute::CreateImplicit(Context,
>> /*DerefType=*/nullptr));
>>  }
>>
>>  void Sema::inferGslPointerAttribute(NamedDecl *ND,
>> @@ -189,8 +187,7 @@ void Sema::inferGslOwnerPointerAttribute
>>
>>// Handle classes that directly appear in std namespace.
>>if (Record->isInStdNamespace()) {
>> -CXXRecordDecl *Canonical = Record->getCanonicalDecl();
>> -if (Canonical->hasAttr() ||
>> Canonical->hasAttr())
>> +if (Record->hasAttr() || Record->hasAttr())
>>return;
>>
>>  if (StdOwners.count(Record->getName()))
>>
>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Aug 21 15:08:59 2019
>> @@ -4592,9 +4592,11 @@ static void handleLifetimeCategoryAttr(S
>>}
>>return;
>>  }
>> -D->addAttr(::new (S.Context)
>> -   OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
>> - AL.getAttributeSpellingListIndex()));
>> +for (Decl *Redecl : D->redecls()) {
>> +

[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

2019-08-22 Thread Shaurya Gupta via Phabricator via cfe-commits

SureYeaah updated this revision to Diff 216669.
SureYeaah marked 33 inline comments as done.
SureYeaah added a comment.
Herald added a subscriber: mgrang.

Addressed Review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65526

Files:
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -599,6 +599,106 @@
 R"cpp(const char * x = "test")cpp");
 }
 
+TWEAK_TEST(ExtractFunction);
+TEST_F(ExtractFunctionTest, FunctionTest) {
+  Header = R"cpp(
+#define F(BODY) void FFF() { BODY }
+  )cpp";
+  Context = Function;
+
+  // Root statements should have common parent.
+  EXPECT_EQ(apply("for(;;) [[1+2; 1+2;]]"), "unavailable");
+  // Expressions aren't extracted.
+  EXPECT_EQ(apply("int x = 0; [[x++;]]"), "unavailable");
+  // We don't support extraction from lambdas.
+  EXPECT_EQ(apply("auto lam = [](){ [[int x;]] }; "), "unavailable");
+  // FIXME: Add tests for macros after selectionTree works properly for macros.
+  // FIXME: This should be extractable
+  EXPECT_EQ(apply("F ([[int x = 0;]])"), "unavailable");
+
+  // Ensure that end of Zone and Beginning of PostZone being adjacent doesn't
+  // lead to break being included in the extraction zone.
+  EXPECT_THAT(apply("for(;;) { [[{}]]break; }"), HasSubstr("extracted"));
+  // FIXME: This should be unavailable since partially selected but
+  // selectionTree doesn't always work correctly for VarDecls.
+  EXPECT_THAT(apply("int [[x = 0]];"), HasSubstr("extracted"));
+  // FIXME: ExtractFunction should be unavailable inside loop construct
+  // initalizer/condition.
+  EXPECT_THAT(apply(" for([[int i = 0;]];);"), HasSubstr("extracted"));
+  // Don't extract because needs hoisting.
+  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), StartsWith("fail"));
+  // Don't extract return
+  EXPECT_THAT(apply(" if(true) [[return;]] "), StartsWith("fail"));
+  // Don't extract break and continue.
+  // FIXME: We should be able to extract this since it's non broken.
+  EXPECT_THAT(apply(" [[for(;;) break;]] "), StartsWith("fail"));
+  EXPECT_THAT(apply(" for(;;) [[continue;]] "), StartsWith("fail"));
+}
+
+TEST_F(ExtractFunctionTest, FileTest) {
+  // Check all parameters are in order
+  std::string ParameterCheckInput = R"cpp(
+struct FOO {
+  int x;
+};
+void f(int a) {
+  int b; int *ptr = &a; FOO foo;
+  [[a += foo.x + b;
+  *ptr++;]]
+})cpp";
+  std::string ParameterCheckOutput = R"cpp(
+struct FOO {
+  int x;
+};
+void extracted(int &a, int &b, int * &ptr, struct FOO &foo) {
+a += foo.x + b;
+  *ptr++;
+}
+void f(int a) {
+  int b; int *ptr = &a; FOO foo;
+  extracted(a, b, ptr, foo);
+})cpp";
+  EXPECT_EQ(apply(ParameterCheckInput), ParameterCheckOutput);
+
+  // Check const qualifier
+  std::string ConstCheckInput = R"cpp(
+void f(const int c) {
+  [[while(c) {}]]
+})cpp";
+  std::string ConstCheckOutput = R"cpp(
+void extracted(const int &c) {
+while(c) {}
+}
+void f(const int c) {
+  extracted(c);
+})cpp";
+  EXPECT_EQ(apply(ConstCheckInput), ConstCheckOutput);
+
+  // Don't extract when we need to make a function as a parameter.
+  EXPECT_THAT(apply("void f() { [[int a; f();]] }"), StartsWith("fail"));
+
+  // We don't extract from methods for now since they may involve multi-file
+  // edits
+  std::string MethodFailInput = R"cpp(
+class T {
+  void f() {
+[[int x;]]
+  }
+};
+  )cpp";
+  EXPECT_EQ(apply(MethodFailInput), "unavailable");
+
+  // We don't extract from templated functions for now as templates are hard
+  // to deal with.
+  std::string TemplateFailInput = R"cpp(
+template
+void f() {
+  [[int x;]]
+}
+  )cpp";
+  EXPECT_EQ(apply(TemplateFailInput), "unavailable");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
@@ -0,0 +1,571 @@
+//===--- ExtractFunction.cpp -*- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+#include "ClangdUnit.h"
+#include "Logger.h"
+#include "Selection.h"
+#include "SourceCode.h"
+#include "refactor/Tweak.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclTemplate.h"
+#include "clang/AST/RecursiveASTVisitor

[PATCH] D66606: IR. Change strip* family of functions to not look through aliases.

2019-08-22 Thread Peter Collingbourne via Phabricator via cfe-commits

pcc created this revision.
pcc added a reviewer: rnk.
Herald added subscribers: cfe-commits, aheejin, hiraditya, jgravelle-google, 
sbc100, dschuff, srhines.
Herald added projects: clang, LLVM.

I noticed another instance of the issue where references to aliases were
being replaced with aliasees, this time in InstCombine. In the instance that
I saw it turned out to be only a QoI issue (a symbol ended up being missing
from the symbol table due to the last reference to the alias being removed,
preventing HWASAN from symbolizing a global reference), but it could easily
have manifested as incorrect behaviour.

Since this is the third such issue encountered (previously: D65118 
, D65314 )
it seems to be time to address this common error/QoI issue once and for all
and make the strip* family of functions not look through aliases.

Includes a test for the specific issue that I saw, but no doubt there are
other similar bugs fixed here.

As with D65118  this has been tested to make 
sure that the optimization isn't
load bearing. I built Clang, Chromium for Linux, Android and Windows as well
as the test-suite and there were no size regressions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66606

Files:
  clang/lib/CodeGen/CGExpr.cpp
  llvm/include/llvm/IR/Value.h
  llvm/lib/Analysis/ConstantFolding.cpp
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/Analysis/StackSafetyAnalysis.cpp
  llvm/lib/CodeGen/Analysis.cpp
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/IR/Constants.cpp
  llvm/lib/IR/Module.cpp
  llvm/lib/IR/Value.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerGlobalDtors.cpp
  llvm/lib/Transforms/IPO/ConstantMerge.cpp
  llvm/lib/Transforms/IPO/GlobalOpt.cpp
  llvm/test/Transforms/InstCombine/bitcast-alias-function.ll
  llvm/test/Transforms/InstCombine/bitcast-function.ll
  llvm/test/Transforms/InstCombine/gep-alias.ll
  llvm/test/Transforms/InstCombine/pr39177.ll

Index: llvm/test/Transforms/InstCombine/pr39177.ll
===
--- llvm/test/Transforms/InstCombine/pr39177.ll
+++ llvm/test/Transforms/InstCombine/pr39177.ll
@@ -30,7 +30,7 @@
 ; CHECK-LABEL: @foo(
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[TMP0:%.*]] = load %struct._IO_FILE*, %struct._IO_FILE** @stderr, align 8
-; CHECK-NEXT:[[TMP1:%.*]] = call i64 @__fwrite_alias(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i64 0, i64 0), i64 7, i64 1, %struct._IO_FILE* [[TMP0]])
+; CHECK-NEXT:[[TMP1:%.*]] = call i64 @fwrite(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i64 0, i64 0), i64 7, i64 1, %struct._IO_FILE* [[TMP0]])
 ; CHECK-NEXT:ret void
 ;
 entry:
Index: llvm/test/Transforms/InstCombine/gep-alias.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/gep-alias.ll
@@ -0,0 +1,15 @@
+; RUN: opt -S -instcombine -o - %s | FileCheck %s
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-unknown-linux-android1"
+
+@x.hwasan = private global { [3 x i32], [4 x i8] } { [3 x i32] [i32 42, i32 57, i32 10], [4 x i8] c"\00\00\00\87" }, align 16
+@x = alias [3 x i32], inttoptr (i64 add (i64 ptrtoint ({ [3 x i32], [4 x i8] }* @x.hwasan to i64), i64 -8718968878589280256) to [3 x i32]*)
+
+define i32 @f(i64 %i) {
+entry:
+  ; CHECK: getelementptr inbounds [3 x i32], [3 x i32]* @x
+  %arrayidx = getelementptr inbounds [3 x i32], [3 x i32]* @x, i64 0, i64 %i
+  %0 = load i32, i32* %arrayidx
+  ret i32 %0
+}
Index: llvm/test/Transforms/InstCombine/bitcast-function.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/bitcast-function.ll
@@ -0,0 +1,206 @@
+; RUN: opt -S -instcombine -o - %s | FileCheck %s
+target datalayout = "e-p:32:32:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v16:16:16-v24:32:32-v32:32:32-v64:64:64-v128:128:128-a0:0:64"
+
+define internal <2 x i32> @func_v2i32(<2 x i32> %v) noinline nounwind {
+entry:
+  ret <2 x i32> %v
+}
+
+define internal <2 x float> @func_v2f32(<2 x float> %v) noinline nounwind {
+entry:
+  ret <2 x float> %v
+}
+
+define internal <4 x float> @func_v4f32(<4 x float> %v) noinline nounwind {
+entry:
+  ret <4 x float> %v
+}
+
+define internal i32 @func_i32(i32 %v) noinline nounwind {
+entry:
+  ret i32 %v
+}
+
+define internal i64 @func_i64(i64 %v) noinline nounwind {
+entry:
+  ret i64 %v
+}
+
+define internal <2 x i64> @func_v2i64(<2 x i64> %v) noinline nounwind {
+entry:
+  ret <2 x i64> %v
+}
+
+define internal <2 x i32*> @func_v2i32p(<2 x i32*> %v) noinline nounwind {
+entry:
+  ret <2 x i32*> %v
+}
+
+; Valid cases, only bitcast for argument / return type and call underlying function
+
+; Test cast between scalars with same bit sizes
+; Sizes match, should only bitcast
+define void @bitcast_

[PATCH] D66492: [Clang][CodeGen] set alias linkage on QualType

2019-08-22 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.

I am not an expert on the alias attribute, but from what I can tell (with much 
thanks to @erichkeane for also helping to verify), this matches the GCC 
behavior. LGTM, but can you add a test for the function behavior as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66492



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

[clang-tools-extra] r369679 - [clangd] Fold string copy into lambda capture. NFC.

2019-08-22 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Thu Aug 22 11:09:46 2019
New Revision: 369679

URL: http://llvm.org/viewvc/llvm-project?rev=369679&view=rev
Log:
[clangd] Fold string copy into lambda capture. NFC.

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=369679&r1=369678&r2=369679&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Thu Aug 22 11:09:46 2019
@@ -582,11 +582,10 @@ void ClangdServer::onFileEvent(const Did
 void ClangdServer::workspaceSymbols(
 llvm::StringRef Query, int Limit,
 Callback> CB) {
-  std::string QueryCopy = Query;
   WorkScheduler.run(
   "getWorkspaceSymbols",
-  [QueryCopy, Limit, CB = std::move(CB), this]() mutable {
-CB(clangd::getWorkspaceSymbols(QueryCopy, Limit, Index,
+  [Query = Query.str(), Limit, CB = std::move(CB), this]() mutable {
+CB(clangd::getWorkspaceSymbols(Query, Limit, Index,
WorkspaceRoot.getValueOr("")));
   });
 }


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

r369680 - Introduce FileEntryRef and use it when handling includes to report correct dependencies

2019-08-22 Thread Alex Lorenz via cfe-commits

Author: arphaman
Date: Thu Aug 22 11:15:50 2019
New Revision: 369680

URL: http://llvm.org/viewvc/llvm-project?rev=369680&view=rev
Log:
Introduce FileEntryRef and use it when handling includes to report correct 
dependencies
when the FileManager is reused across invocations

This commit introduces a parallel API to FileManager's getFile: 
getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In 
the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of 
the file,
not the filename that was used to access it.

The new API is adopted only in the HeaderSearch and Preprocessor for include 
file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's 
FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, 
which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the 
FileManager is reused across multiple Preprocessor invocations.

Note that this patch does not fix all dependency collector issues, as the same 
problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will 
be fixed in follow-up commits.

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

Added:
cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp
Modified:
cfe/trunk/include/clang/Basic/FileManager.h
cfe/trunk/include/clang/Basic/SourceManager.h
cfe/trunk/include/clang/Lex/DirectoryLookup.h
cfe/trunk/include/clang/Lex/HeaderMap.h
cfe/trunk/include/clang/Lex/HeaderSearch.h
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/lib/Basic/FileManager.cpp
cfe/trunk/lib/Basic/SourceManager.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Frontend/DependencyFile.cpp
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp
cfe/trunk/lib/Lex/HeaderMap.cpp
cfe/trunk/lib/Lex/HeaderSearch.cpp
cfe/trunk/lib/Lex/PPDirectives.cpp
cfe/trunk/lib/Lex/PPMacroExpansion.cpp
cfe/trunk/lib/Lex/Pragma.cpp
cfe/trunk/lib/Lex/Preprocessor.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/VFS/external-names.c
cfe/trunk/unittests/Tooling/CMakeLists.txt

Modified: cfe/trunk/include/clang/Basic/FileManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=369680&r1=369679&r2=369680&view=diff
==
--- cfe/trunk/include/clang/Basic/FileManager.h (original)
+++ cfe/trunk/include/clang/Basic/FileManager.h Thu Aug 22 11:15:50 2019
@@ -106,6 +106,32 @@ public:
   bool isOpenForTests() const { return File != nullptr; }
 };
 
+/// A reference to a \c FileEntry that includes the name of the file as it was
+/// accessed by the FileManager's client.
+class FileEntryRef {
+public:
+  FileEntryRef(StringRef Name, const FileEntry &Entry)
+  : Name(Name), Entry(Entry) {}
+
+  const StringRef getName() const { return Name; }
+
+  const FileEntry &getFileEntry() const { return Entry; }
+
+  off_t getSize() const { return Entry.getSize(); }
+
+  unsigned getUID() const { return Entry.getUID(); }
+
+  const llvm::sys::fs::UniqueID &getUniqueID() const {
+return Entry.getUniqueID();
+  }
+
+  time_t getModificationTime() const { return Entry.getModificationTime(); }
+
+private:
+  StringRef Name;
+  const FileEntry &Entry;
+};
+
 /// Implements support for file system lookup, file system caching,
 /// and directory search management.
 ///
@@ -143,13 +169,25 @@ class FileManager : public RefCountedBas
   llvm::StringMap, llvm::BumpPtrAllocator>
   SeenDirEntries;
 
+  /// A reference to the file entry that is associated with a particular
+  /// filename, or a reference to another filename that should be looked up
+  /// instead of the accessed filename.
+  ///
+  /// The reference to another filename is specifically useful for Redirecting
+  /// VFSs that use external names. In that case, the \c FileEntryRef returned
+  /// by the \c FileManager will have the external name, and not the name that
+  /// was used to lookup the file.
+  using SeenFileEntryOrRedirect =
+  llvm::PointerUnion;
+
   /// A cache that maps paths to file entries (either real or
   /// virtual) we have looked up, or an error that occurred when we looked up
   /// the file.
   ///
   /// \see SeenDirEntries
-  llvm::StringMap, llvm::BumpPtrAllocator>
-  SeenFileEntries;
+  llvm::StringMap,
+  llvm::BumpPtrAllocator>
+  SeenFileEntries;
 
   /// The canonical names of directories.
   llvm::DenseMap CanonicalDirNames;
@@ -200,6 +238,9 @@ public:
   /// Removes the FileSystemStatCache object from the m

[PATCH] D65907: Introduce FileEntryRef and use it when handling includes to report correct dependencies when the FileManager is reused across invocations

2019-08-22 Thread Alex Lorenz via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL369680: Introduce FileEntryRef and use it when handling 
includes to report correct… (authored by arphaman, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65907?vs=215719&id=216676#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65907

Files:
  cfe/trunk/include/clang/Basic/FileManager.h
  cfe/trunk/include/clang/Basic/SourceManager.h
  cfe/trunk/include/clang/Lex/DirectoryLookup.h
  cfe/trunk/include/clang/Lex/HeaderMap.h
  cfe/trunk/include/clang/Lex/HeaderSearch.h
  cfe/trunk/include/clang/Lex/Preprocessor.h
  cfe/trunk/lib/Basic/FileManager.cpp
  cfe/trunk/lib/Basic/SourceManager.cpp
  cfe/trunk/lib/Frontend/CompilerInstance.cpp
  cfe/trunk/lib/Frontend/DependencyFile.cpp
  cfe/trunk/lib/Frontend/FrontendActions.cpp
  cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
  cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp
  cfe/trunk/lib/Lex/HeaderMap.cpp
  cfe/trunk/lib/Lex/HeaderSearch.cpp
  cfe/trunk/lib/Lex/PPDirectives.cpp
  cfe/trunk/lib/Lex/PPMacroExpansion.cpp
  cfe/trunk/lib/Lex/Pragma.cpp
  cfe/trunk/lib/Lex/Preprocessor.cpp
  cfe/trunk/lib/Serialization/ASTReader.cpp
  cfe/trunk/lib/Serialization/ASTWriter.cpp
  cfe/trunk/test/VFS/external-names.c
  cfe/trunk/unittests/Tooling/CMakeLists.txt
  cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp

Index: cfe/trunk/lib/Lex/Preprocessor.cpp
===
--- cfe/trunk/lib/Lex/Preprocessor.cpp
+++ cfe/trunk/lib/Lex/Preprocessor.cpp
@@ -563,7 +563,7 @@
 // Lookup and save the FileID for the through header. If it isn't found
 // in the search path, it's a fatal error.
 const DirectoryLookup *CurDir;
-const FileEntry *File = LookupFile(
+Optional File = LookupFile(
 SourceLocation(), PPOpts->PCHThroughHeader,
 /*isAngled=*/false, /*FromDir=*/nullptr, /*FromFile=*/nullptr, CurDir,
 /*SearchPath=*/nullptr, /*RelativePath=*/nullptr,
@@ -575,7 +575,7 @@
   return;
 }
 setPCHThroughHeaderFileID(
-SourceMgr.createFileID(File, SourceLocation(), SrcMgr::C_User));
+SourceMgr.createFileID(*File, SourceLocation(), SrcMgr::C_User));
   }
 
   // Skip tokens from the Predefines and if needed the main file.
Index: cfe/trunk/lib/Lex/HeaderMap.cpp
===
--- cfe/trunk/lib/Lex/HeaderMap.cpp
+++ cfe/trunk/lib/Lex/HeaderMap.cpp
@@ -196,17 +196,17 @@
 
 /// LookupFile - Check to see if the specified relative filename is located in
 /// this HeaderMap.  If so, open it and return its FileEntry.
-const FileEntry *HeaderMap::LookupFile(
-StringRef Filename, FileManager &FM) const {
+Optional HeaderMap::LookupFile(StringRef Filename,
+ FileManager &FM) const {
 
   SmallString<1024> Path;
   StringRef Dest = HeaderMapImpl::lookupFilename(Filename, Path);
   if (Dest.empty())
-return nullptr;
+return None;
 
-  if (auto File = FM.getFile(Dest))
+  if (auto File = FM.getFileRef(Dest))
 return *File;
-  return nullptr;
+  return None;
 }
 
 StringRef HeaderMapImpl::lookupFilename(StringRef Filename,
Index: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
===
--- cfe/trunk/lib/Lex/PPMacroExpansion.cpp
+++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp
@@ -1210,19 +1210,21 @@
 
   // Search include directories.
   const DirectoryLookup *CurDir;
-  const FileEntry *File =
+  Optional File =
   PP.LookupFile(FilenameLoc, Filename, isAngled, LookupFrom, LookupFromFile,
 CurDir, nullptr, nullptr, nullptr, nullptr, nullptr);
 
   if (PPCallbacks *Callbacks = PP.getPPCallbacks()) {
 SrcMgr::CharacteristicKind FileType = SrcMgr::C_User;
 if (File)
-  FileType = PP.getHeaderSearchInfo().getFileDirFlavor(File);
-Callbacks->HasInclude(FilenameLoc, Filename, isAngled, File, FileType);
+  FileType =
+  PP.getHeaderSearchInfo().getFileDirFlavor(&File->getFileEntry());
+Callbacks->HasInclude(FilenameLoc, Filename, isAngled,
+  File ? &File->getFileEntry() : nullptr, FileType);
   }
 
   // Get the result value.  A result of true means the file exists.
-  return File != nullptr;
+  return File.hasValue();
 }
 
 /// EvaluateHasInclude - Process a '__has_include("path")' expression.
Index: cfe/trunk/lib/Lex/HeaderSearch.cpp
===
--- cfe/trunk/lib/Lex/HeaderSearch.cpp
+++ cfe/trunk/lib/Lex/HeaderSearch.cpp
@@ -304,14 +304,13 @@
   return getHeaderMap()->getFileName();
 }
 
-const FileEntry *HeaderSearch::getFileAndSuggestModule(
+Optional HeaderSearch::getFileAndSuggestModule(
 StringRef FileName, SourceLoca

r369683 - Implement nullPointerConstant() using a better API.

2019-08-22 Thread Aaron Ballman via cfe-commits

Author: aaronballman
Date: Thu Aug 22 11:26:44 2019
New Revision: 369683

URL: http://llvm.org/viewvc/llvm-project?rev=369683&view=rev
Log:
Implement nullPointerConstant() using a better API.

Instead of manually attempting to identify whether something is a null pointer 
constant, use Expr::isNullPointerConstant().

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=369683&r1=369682&r2=369683&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Thu Aug 22 11:26:44 2019
@@ -6445,10 +6445,9 @@ extern const internal::VariadicDynCastAl
 /// expr(nullPointerConstant())
 ///   matches the initializer for v1, v2, v3, cp, and ip. Does not match the
 ///   initializer for i.
-AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
-  return anyOf(
-  gnuNullExpr(), cxxNullPtrLiteralExpr(),
-  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
+AST_MATCHER(Expr, nullPointerConstant) {
+  return Node.isNullPointerConstant(Finder->getASTContext(),
+Expr::NPC_ValueDependentIsNull);
 }
 
 /// Matches declaration of the function the statement belongs to


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

Re: r261008 - Add a nullPointerConstant() AST matcher to handle variations of null pointer constants in one matcher.

2019-08-22 Thread Aaron Ballman via cfe-commits

On Thu, Aug 22, 2019 at 1:13 PM Aaron Ballman  wrote:
>
> On Thu, Aug 22, 2019 at 12:58 PM Richard Smith  wrote:
> >
> > (Sorry for the very late review!)
> >
> > On Tue, 16 Feb 2016 at 13:06, Aaron Ballman via cfe-commits 
> >  wrote:
> >>
> >> Author: aaronballman
> >> Date: Tue Feb 16 15:02:23 2016
> >> New Revision: 261008
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=261008&view=rev
> >> Log:
> >> Add a nullPointerConstant() AST matcher to handle variations of null 
> >> pointer constants in one matcher.
> >>
> >> Modified:
> >> cfe/trunk/docs/LibASTMatchersReference.html
> >> cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> >> cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
> >> cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
> >>
> >> Modified: cfe/trunk/docs/LibASTMatchersReference.html
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=261008&r1=261007&r2=261008&view=diff
> >> ==
> >> --- cfe/trunk/docs/LibASTMatchersReference.html (original)
> >> +++ cfe/trunk/docs/LibASTMatchersReference.html Tue Feb 16 15:02:23 2016
> >> @@ -2176,6 +2176,23 @@ fieldDecl(isPublic())
> >>  
> >>
> >>
> >> +Matcher< >> href="http://clang.llvm.org/doxygen/classclang_1_1Expr.html";>Expr> >>  class="name" onclick="toggle('nullPointerConstant0')"> >> name="nullPointerConstant0Anchor">nullPointerConstant
> >> +Matches 
> >> expressions that resolve to a null pointer constant, such as
> >> +GNU's __null, C++11's nullptr, or C's NULL macro.
> >> +
> >> +Given:
> >> +  void *v1 = NULL;
> >> +  void *v2 = nullptr;
> >> +  void *v3 = __null; GNU extension
> >> +  char *cp = (char *)0;
> >> +  int *ip = 0;
> >> +  int i = 0;
> >> +expr(nullPointerConstant())
> >> +  matches the initializer for v1, v2, v3, cp, and ip. Does not match the
> >> +  initializer for i.
> >> +
> >> +
> >> +
> >>  Matcher< >> href="http://clang.llvm.org/doxygen/classclang_1_1FloatingLiteral.html";>FloatingLiteral> >>  class="name" onclick="toggle('equals1')"> >> name="equals1Anchor">equalsValueT  Value
> >>  Matches literals that 
> >> are equal to the given value.
> >>
> >>
> >> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261008&r1=261007&r2=261008&view=diff
> >> ==
> >> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
> >> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Feb 16 15:02:23 
> >> 2016
> >> @@ -4816,6 +4816,27 @@ const internal::VariadicDynCastAllOfMatc
> >>Stmt,
> >>CUDAKernelCallExpr> cudaKernelCallExpr;
> >>
> >> +
> >> +/// \brief Matches expressions that resolve to a null pointer constant, 
> >> such as
> >> +/// GNU's __null, C++11's nullptr, or C's NULL macro.
> >> +///
> >> +/// Given:
> >> +/// \code
> >> +///   void *v1 = NULL;
> >> +///   void *v2 = nullptr;
> >> +///   void *v3 = __null; // GNU extension
> >> +///   char *cp = (char *)0;
> >> +///   int *ip = 0;
> >> +///   int i = 0;
> >> +/// \endcode
> >> +/// expr(nullPointerConstant())
> >> +///   matches the initializer for v1, v2, v3, cp, and ip. Does not match 
> >> the
> >> +///   initializer for i.
> >> +AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
> >> +  return anyOf(
> >> +  gnuNullExpr(), cxxNullPtrLiteralExpr(),
> >> +  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
> >
> >
> > Is there a reason this logic was reinvented rather than using 
> > Expr::isNullPointerConstant()? This is not correct in C or in Clang's 
> > interpretation of DRs against C++98.
>
> No reason that I can recall, I'll make the switch. Thank you for the feedback!

I've corrected this in r369683, thank you!

~Aaron

>
> ~Aaron
>
> >
> >>
> >> +}
> >>  } // end namespace ast_matchers
> >>  } // end namespace clang
> >>
> >>
> >> Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=261008&r1=261007&r2=261008&view=diff
> >> ==
> >> --- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
> >> +++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Tue Feb 16 15:02:23 2016
> >> @@ -326,6 +326,7 @@ RegistryMaps::RegistryMaps() {
> >>REGISTER_MATCHER(namesType);
> >>REGISTER_MATCHER(nestedNameSpecifier);
> >>REGISTER_MATCHER(nestedNameSpecifierLoc);
> >> +  REGISTER_MATCHER(nullPointerConstant);
> >>REGISTER_MATCHER(nullStmt);
> >>REGISTER_MATCHER(numSelectorArgs);
> >>REGISTER_MATCHER(ofClass);
> >>
> >> Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.c

[PATCH] D62739: AMDGPU: Always emit amdgpu-flat-work-group-size

2019-08-22 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added a comment.

ping


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

https://reviews.llvm.org/D62739



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

r369686 - Fix the nullPointerConstant() test to get bots back to green.

2019-08-22 Thread Aaron Ballman via cfe-commits

Author: aaronballman
Date: Thu Aug 22 11:56:18 2019
New Revision: 369686

URL: http://llvm.org/viewvc/llvm-project?rev=369686&view=rev
Log:
Fix the nullPointerConstant() test to get bots back to green.

Modified:
cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp?rev=369686&r1=369685&r2=369686&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp Thu Aug 22 
11:56:18 2019
@@ -2392,7 +2392,7 @@ TEST(NullPointerConstants, Basic) {
   EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
   EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
   EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
-  EXPECT_TRUE(notMatches("int i = 0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("int i = 0;", expr(nullPointerConstant(;
 }
 
 TEST(HasExternalFormalLinkage, Basic) {


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

r369687 - Improve the documentation for OpenCL vector types.

2019-08-22 Thread Aaron Ballman via cfe-commits

Author: aaronballman
Date: Thu Aug 22 11:57:46 2019
New Revision: 369687

URL: http://llvm.org/viewvc/llvm-project?rev=369687&view=rev
Log:
Improve the documentation for OpenCL vector types.

This fixes some minor grammatical issues I noticed when reading the docs, and 
changes the recommended feature testing approach to use __has_attribute instead 
of __has_extension.

Modified:
cfe/trunk/docs/LanguageExtensions.rst

Modified: cfe/trunk/docs/LanguageExtensions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=369687&r1=369686&r2=369687&view=diff
==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Thu Aug 22 11:57:46 2019
@@ -389,8 +389,8 @@ Vectors and Extended Vectors
 
 Supports the GCC, OpenCL, AltiVec and NEON vector extensions.
 
-OpenCL vector types are created using ``ext_vector_type`` attribute.  It
-support for ``V.xyzw`` syntax and other tidbits as seen in OpenCL.  An example
+OpenCL vector types are created using the ``ext_vector_type`` attribute.  It
+supports the ``V.xyzw`` syntax and other tidbits as seen in OpenCL.  An example
 is:
 
 .. code-block:: c++
@@ -405,7 +405,7 @@ is:
 return c;
   }
 
-Query for this feature with ``__has_extension(attribute_ext_vector_type)``.
+Query for this feature with ``__has_attribute(ext_vector_type)``.
 
 Giving ``-maltivec`` option to clang enables support for AltiVec vector syntax
 and functions.  For example:


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

r369688 - Disable the ScanDepsReuseFilemanager test on Windows

2019-08-22 Thread Alex Lorenz via cfe-commits

Author: arphaman
Date: Thu Aug 22 12:00:08 2019
New Revision: 369688

URL: http://llvm.org/viewvc/llvm-project?rev=369688&view=rev
Log:
Disable the ScanDepsReuseFilemanager test on Windows

Right now it fails.
I'm going to investigate it and fix it in follow-up commits.

Modified:
cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp

Modified: cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp?rev=369688&r1=369687&r2=369688&view=diff
==
--- cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/DependencyScannerTest.cpp Thu Aug 22 12:00:08 
2019
@@ -26,6 +26,8 @@
 namespace clang {
 namespace tooling {
 
+#ifndef _WIN32
+
 namespace {
 
 /// Prints out all of the gathered dependencies into a string.
@@ -114,5 +116,7 @@ TEST(DependencyScanner, ScanDepsReuseFil
   EXPECT_EQ(Files.getNumUniqueRealFiles(), 2u);
 }
 
+#endif
+
 } // end namespace tooling
 } // end namespace clang


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

[PATCH] D66122: [CodeGen] Emit dynamic initializers for static TLS vars in outlined scopes

2019-08-22 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added a comment.

Oh, I somehow forgot that was legal. :(  That breaks this whole approach (well, 
maybe the lambda could capture "w", but that seems way too complicated).  So 
we're left with a few possibilities:

1. an error
2. undefined behavior (probably we would want to warn in this case)
3. capturing the address of the thread_local variable


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66122



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

[PATCH] D62739: AMDGPU: Always emit amdgpu-flat-work-group-size

2019-08-22 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits

rampitec added inline comments.



Comment at: lib/CodeGen/TargetInfo.cpp:7885
+// By default, restrict the maximum size to 256.
+F->addFnAttr("amdgpu-flat-work-group-size", "128,256");
   }

arsenm wrote:
> yaxunl wrote:
> > arsenm wrote:
> > > b-sumner wrote:
> > > > Theoretically, shouldn't the minimum be 1?
> > > That's what I thought, but the backend is defaulting to 2 * wave size now
> > I don't get it. This attribute indicates the possible workgroup size range 
> > this kernel may be run with, right? It only depends on how user execute the 
> > kernel. How is it related to backend defaults?
> The backend currently assumes 128,256 by default as the bounds. I want to 
> make this a frontend decision, and make the backend assumption the most 
> conservative default
I would agree that minimum should be 1. Backend's choice is also unclear, but 
emitting a false attribute is a separate issue.


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

https://reviews.llvm.org/D62739



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

[PATCH] D66606: IR. Change strip* family of functions to not look through aliases.

2019-08-22 Thread Reid Kleckner via Phabricator via cfe-commits

rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm

GlobalOpt already replaces replaceable aliases, and if it doesn't do it enough, 
we can adjust the pass pipeline to fix the phase ordering problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66606



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

[clang-tools-extra] r369695 - Fight a bit against global initializers. NFC.

2019-08-22 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Thu Aug 22 12:43:27 2019
New Revision: 369695

URL: http://llvm.org/viewvc/llvm-project?rev=369695&view=rev
Log:
Fight a bit against global initializers. NFC.

Modified:
clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp
clang-tools-extra/trunk/clangd/index/Ref.cpp

Modified: clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp?rev=369695&r1=369694&r2=369695&view=diff
==
--- clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp Thu Aug 22 
12:43:27 2019
@@ -88,12 +88,12 @@ collectIWYUHeaderMaps(CanonicalIncludes
 
 void addSystemHeadersMapping(CanonicalIncludes *Includes,
  const LangOptions &Language) {
-  static const std::vector> SymbolMap = {
+  static constexpr std::pair SymbolMap[] = {
 #define SYMBOL(Name, NameSpace, Header) { #NameSpace#Name, #Header },
   #include "StdSymbolMap.inc"
 #undef SYMBOL
   };
-  static const std::vector> CSymbolMap = 
{
+  static constexpr std::pair CSymbolMap[] = {
 #define SYMBOL(Name, NameSpace, Header) { #Name, #Header },
   #include "CSymbolMap.inc"
 #undef SYMBOL
@@ -107,661 +107,660 @@ void addSystemHeadersMapping(CanonicalIn
   }
   // FIXME: remove the std header mapping once we support ambiguous symbols, 
now
   // it serves as a fallback to disambiguate:
-  //   - symbols with mulitiple headers (e.g. std::move)
-  static const std::vector>
-  SystemHeaderMap = {
-  {"include/__stddef_max_align_t.h", ""},
-  {"include/__wmmintrin_aes.h", ""},
-  {"include/__wmmintrin_pclmul.h", ""},
-  {"include/adxintrin.h", ""},
-  {"include/ammintrin.h", ""},
-  {"include/avx2intrin.h", ""},
-  {"include/avx512bwintrin.h", ""},
-  {"include/avx512cdintrin.h", ""},
-  {"include/avx512dqintrin.h", ""},
-  {"include/avx512erintrin.h", ""},
-  {"include/avx512fintrin.h", ""},
-  {"include/avx512ifmaintrin.h", ""},
-  {"include/avx512ifmavlintrin.h", ""},
-  {"include/avx512pfintrin.h", ""},
-  {"include/avx512vbmiintrin.h", ""},
-  {"include/avx512vbmivlintrin.h", ""},
-  {"include/avx512vlbwintrin.h", ""},
-  {"include/avx512vlcdintrin.h", ""},
-  {"include/avx512vldqintrin.h", ""},
-  {"include/avx512vlintrin.h", ""},
-  {"include/avxintrin.h", ""},
-  {"include/bmi2intrin.h", ""},
-  {"include/bmiintrin.h", ""},
-  {"include/emmintrin.h", ""},
-  {"include/f16cintrin.h", ""},
-  {"include/float.h", ""},
-  {"include/fma4intrin.h", ""},
-  {"include/fmaintrin.h", ""},
-  {"include/fxsrintrin.h", ""},
-  {"include/ia32intrin.h", ""},
-  {"include/immintrin.h", ""},
-  {"include/inttypes.h", ""},
-  {"include/limits.h", ""},
-  {"include/lzcntintrin.h", ""},
-  {"include/mm3dnow.h", ""},
-  {"include/mm_malloc.h", ""},
-  {"include/mmintrin.h", ""},
-  {"include/mwaitxintrin.h", ""},
-  {"include/pkuintrin.h", ""},
-  {"include/pmmintrin.h", ""},
-  {"include/popcntintrin.h", ""},
-  {"include/prfchwintrin.h", ""},
-  {"include/rdseedintrin.h", ""},
-  {"include/rtmintrin.h", ""},
-  {"include/shaintrin.h", ""},
-  {"include/smmintrin.h", ""},
-  {"include/stdalign.h", ""},
-  {"include/stdarg.h", ""},
-  {"include/stdbool.h", ""},
-  {"include/stddef.h", ""},
-  {"include/stdint.h", ""},
-  {"include/tbmintrin.h", ""},
-  {"include/tmmintrin.h", ""},
-  {"include/wmmintrin.h", ""},
-  {"include/x86intrin.h", ""},
-  {"include/xmmintrin.h", ""},
-  {"include/xopintrin.h", ""},
-  {"include/xsavecintrin.h", ""},
-  {"include/xsaveintrin.h", ""},
-  {"include/xsaveoptintrin.h", ""},
-  {"include/xsavesintrin.h", ""},
-  {"include/xtestintrin.h", ""},
-  {"include/_G_config.h", ""},
-  {"include/assert.h", ""},
-  {"algorithm", ""},
-  {"valarray", ""},
-  {"array", ""},
-  {"atomic", ""},
-  {"backward/auto_ptr.h", ""},
-  {"backward/binders.h", ""},
-  {"bits/algorithmfwd.h", ""},
-  {"bits/alloc_traits.h", ""},
-  {"bits/allocated_ptr.h", ""},
-  {"bits/allocator.h", ""},
-  {"bits/atomic_base.h", ""},
-  {"bits/atomic_lockfree_defines.h", ""},
-  {"bits/atomic_futex.h", ""},
-  {"bits/basic_ios.h", ""},
-  {"bits/basic_ios.tcc", ""},
-  {"bits/basic_string.h", ""},
-  {"bits/basic_string.tcc", ""},
-  {"

r369697 - IR. Change strip* family of functions to not look through aliases.

2019-08-22 Thread Peter Collingbourne via cfe-commits

Author: pcc
Date: Thu Aug 22 12:56:14 2019
New Revision: 369697

URL: http://llvm.org/viewvc/llvm-project?rev=369697&view=rev
Log:
IR. Change strip* family of functions to not look through aliases.

I noticed another instance of the issue where references to aliases were
being replaced with aliasees, this time in InstCombine. In the instance that
I saw it turned out to be only a QoI issue (a symbol ended up being missing
from the symbol table due to the last reference to the alias being removed,
preventing HWASAN from symbolizing a global reference), but it could easily
have manifested as incorrect behaviour.

Since this is the third such issue encountered (previously: D65118, D65314)
it seems to be time to address this common error/QoI issue once and for all
and make the strip* family of functions not look through aliases.

Includes a test for the specific issue that I saw, but no doubt there are
other similar bugs fixed here.

As with D65118 this has been tested to make sure that the optimization isn't
load bearing. I built Clang, Chromium for Linux, Android and Windows as well
as the test-suite and there were no size regressions.

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

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=369697&r1=369696&r2=369697&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Thu Aug 22 12:56:14 2019
@@ -677,8 +677,7 @@ void CodeGenFunction::EmitTypeCheck(Type
   // Quickly determine whether we have a pointer to an alloca. It's possible
   // to skip null checks, and some alignment checks, for these pointers. This
   // can reduce compile-time significantly.
-  auto PtrToAlloca =
-  dyn_cast(Ptr->stripPointerCastsNoFollowAliases());
+  auto PtrToAlloca = dyn_cast(Ptr->stripPointerCasts());
 
   llvm::Value *True = llvm::ConstantInt::getTrue(getLLVMContext());
   llvm::Value *IsNonNull = nullptr;


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

[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

2019-08-22 Thread Melanie Blower via Phabricator via cfe-commits

mibintc added a comment.

ping, looking for a code review, especially from front end folks.  thank you!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731



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

[PATCH] D66606: IR. Change strip* family of functions to not look through aliases.

2019-08-22 Thread Peter Collingbourne via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL369697: IR. Change strip* family of functions to not look 
through aliases. (authored by pcc, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D66606?vs=216671&id=216694#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66606

Files:
  cfe/trunk/lib/CodeGen/CGExpr.cpp
  llvm/trunk/include/llvm/IR/Value.h
  llvm/trunk/lib/Analysis/ConstantFolding.cpp
  llvm/trunk/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/trunk/lib/Analysis/StackSafetyAnalysis.cpp
  llvm/trunk/lib/CodeGen/Analysis.cpp
  llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/trunk/lib/IR/Constants.cpp
  llvm/trunk/lib/IR/Module.cpp
  llvm/trunk/lib/IR/Value.cpp
  llvm/trunk/lib/IR/Verifier.cpp
  llvm/trunk/lib/Target/WebAssembly/WebAssemblyLowerGlobalDtors.cpp
  llvm/trunk/lib/Transforms/IPO/ConstantMerge.cpp
  llvm/trunk/lib/Transforms/IPO/GlobalOpt.cpp
  llvm/trunk/test/Transforms/InstCombine/bitcast-alias-function.ll
  llvm/trunk/test/Transforms/InstCombine/bitcast-function.ll
  llvm/trunk/test/Transforms/InstCombine/gep-alias.ll
  llvm/trunk/test/Transforms/InstCombine/pr39177.ll

Index: llvm/trunk/include/llvm/IR/Value.h
===
--- llvm/trunk/include/llvm/IR/Value.h
+++ llvm/trunk/include/llvm/IR/Value.h
@@ -513,17 +513,17 @@
   /// swifterror attribute.
   bool isSwiftError() const;
 
-  /// Strip off pointer casts, all-zero GEPs, address space casts, and aliases.
+  /// Strip off pointer casts, all-zero GEPs and address space casts.
   ///
   /// Returns the original uncasted value.  If this is called on a non-pointer
   /// value, it returns 'this'.
   const Value *stripPointerCasts() const;
   Value *stripPointerCasts() {
 return const_cast(
- static_cast(this)->stripPointerCasts());
+static_cast(this)->stripPointerCasts());
   }
 
-  /// Strip off pointer casts, all-zero GEPs, address space casts, and aliases
+  /// Strip off pointer casts, all-zero GEPs and address space casts
   /// but ensures the representation of the result stays the same.
   ///
   /// Returns the original uncasted value with the same representation. If this
@@ -534,26 +534,15 @@
->stripPointerCastsSameRepresentation());
   }
 
-  /// Strip off pointer casts, all-zero GEPs, aliases and invariant group
-  /// info.
+  /// Strip off pointer casts, all-zero GEPs and invariant group info.
   ///
   /// Returns the original uncasted value.  If this is called on a non-pointer
   /// value, it returns 'this'. This function should be used only in
   /// Alias analysis.
   const Value *stripPointerCastsAndInvariantGroups() const;
   Value *stripPointerCastsAndInvariantGroups() {
-return const_cast(
-static_cast(this)->stripPointerCastsAndInvariantGroups());
-  }
-
-  /// Strip off pointer casts and all-zero GEPs.
-  ///
-  /// Returns the original uncasted value.  If this is called on a non-pointer
-  /// value, it returns 'this'.
-  const Value *stripPointerCastsNoFollowAliases() const;
-  Value *stripPointerCastsNoFollowAliases() {
-return const_cast(
-  static_cast(this)->stripPointerCastsNoFollowAliases());
+return const_cast(static_cast(this)
+   ->stripPointerCastsAndInvariantGroups());
   }
 
   /// Strip off pointer casts and all-constant inbounds GEPs.
Index: llvm/trunk/test/Transforms/InstCombine/gep-alias.ll
===
--- llvm/trunk/test/Transforms/InstCombine/gep-alias.ll
+++ llvm/trunk/test/Transforms/InstCombine/gep-alias.ll
@@ -0,0 +1,15 @@
+; RUN: opt -S -instcombine -o - %s | FileCheck %s
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-unknown-linux-android1"
+
+@x.hwasan = private global { [3 x i32], [4 x i8] } { [3 x i32] [i32 42, i32 57, i32 10], [4 x i8] c"\00\00\00\87" }, align 16
+@x = alias [3 x i32], inttoptr (i64 add (i64 ptrtoint ({ [3 x i32], [4 x i8] }* @x.hwasan to i64), i64 -8718968878589280256) to [3 x i32]*)
+
+define i32 @f(i64 %i) {
+entry:
+  ; CHECK: getelementptr inbounds [3 x i32], [3 x i32]* @x
+  %arrayidx = getelementptr inbounds [3 x i32], [3 x i32]* @x, i64 0, i64 %i
+  %0 = load i32, i32* %arrayidx
+  ret i32 %0
+}
Index: llvm/trunk/test/Transforms/InstCombine/pr39177.ll
===
--- llvm/trunk/test/Transforms/InstCombine/pr39177.ll
+++ llvm/trunk/test/Transforms/InstCombine/pr39177.ll
@@ -30,7 +30,7 @@
 ; CHECK-LABEL: @foo(
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[TMP0:%.*]] = load %struct._IO_FILE*, %struct._IO_FILE** @stderr, align 8
-; CHECK-NEXT:[[TMP1:%.*]] = call i64 @__fwrite_alias(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i64 0, i64 0), i64 7, i64 1,

Re: r369591 - [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-22 Thread Matthias Gehre via cfe-commits

Hi Diana,
hi Richard,

thank you for the feedback!

Diana,
I remember that some gcc version had issues with raw string literals inside
macros. I'll fix that to use normal
string literals instead.

Richard,
We are definitely want the gsl::Pointer-based warnings that are enabled by
default to be free of any false-positives.
As you expected, this is showing a problem we have in another part of our
analysis, and we will fix it before landing
this PR again.

Both, sorry for the breakage!

Am Do., 22. Aug. 2019 um 19:47 Uhr schrieb Richard Smith <
rich...@metafoo.co.uk>:

> Reverted in r369677.
>
> On Thu, 22 Aug 2019 at 10:34, Richard Smith  wrote:
>
>> Hi Matthias,
>>
>> This introduces false positives into -Wreturn-stack-address for an
>> example such as:
>>
>> #include 
>>
>> std::vector::iterator downcast_to(std::vector::iterator value) {
>>   return *&value;
>> }
>>
>> This breaks an internal build bot for us, so I'm going to revert this for
>> now (though I expect this isn't the cause of the problem, but is rather
>> exposing a problem elsewhere).
>>
>> If we can make the gsl::Pointer diagnostics false-positive-free, that's
>> great, but otherwise we should use a different warning flag for the
>> warnings that involve these annotations and use -Wreturn-stack-address for
>> only the zero-false-positive cases that it historically diagnosed.
>>
>> Thanks, and sorry for the trouble.
>>
>> On Wed, 21 Aug 2019 at 15:07, Matthias Gehre via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: mgehre
>>> Date: Wed Aug 21 15:08:59 2019
>>> New Revision: 369591
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=369591&view=rev
>>> Log:
>>> [LifetimeAnalysis] Support more STL idioms (template forward declaration
>>> and DependentNameType)
>>>
>>> Summary:
>>> This fixes inference of gsl::Pointer on std::set::iterator with
>>> libstdc++ (the typedef for iterator
>>> on the template is a DependentNameType - we can only put the
>>> gsl::Pointer attribute
>>> on the underlaying record after instantiation)
>>>
>>> inference of gsl::Pointer on std::vector::iterator with libc++ (the
>>> class was forward-declared,
>>> we added the gsl::Pointer on the canonical decl (the forward decl), and
>>> later when the
>>> template was instantiated, there was no attribute on the definition so
>>> it was not instantiated).
>>>
>>> and a duplicate gsl::Pointer on some class with libstdc++ (we first
>>> added an attribute to
>>> a incomplete instantiation, and then another was copied from the
>>> template definition
>>> when the instantiation was completed).
>>>
>>> We now add the attributes to all redeclarations to fix thos issues and
>>> make their usage easier.
>>>
>>> Reviewers: gribozavr
>>>
>>> Subscribers: Szelethus, xazax.hun, cfe-commits
>>>
>>> Tags: #clang
>>>
>>> Differential Revision: https://reviews.llvm.org/D66179
>>>
>>> Added:
>>> cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
>>> Modified:
>>> cfe/trunk/lib/Sema/SemaAttr.cpp
>>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>> cfe/trunk/lib/Sema/SemaInit.cpp
>>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>>> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
>>> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
>>> cfe/trunk/unittests/Sema/CMakeLists.txt
>>>
>>> Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=369591&r1=369590&r2=369591&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaAttr.cpp Wed Aug 21 15:08:59 2019
>>> @@ -88,13 +88,11 @@ void Sema::AddMsStructLayoutForRecord(Re
>>>  template 
>>>  static void addGslOwnerPointerAttributeIfNotExisting(ASTContext
>>> &Context,
>>>   CXXRecordDecl
>>> *Record) {
>>> -  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
>>> -  if (Canonical->hasAttr() ||
>>> Canonical->hasAttr())
>>> +  if (Record->hasAttr() || Record->hasAttr())
>>>  return;
>>>
>>> -  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
>>> -   /*DerefType*/ nullptr,
>>> -   /*Spelling=*/0));
>>> +  for (Decl *Redecl : Record->redecls())
>>> +Redecl->addAttr(Attribute::CreateImplicit(Context,
>>> /*DerefType=*/nullptr));
>>>  }
>>>
>>>  void Sema::inferGslPointerAttribute(NamedDecl *ND,
>>> @@ -189,8 +187,7 @@ void Sema::inferGslOwnerPointerAttribute
>>>
>>>// Handle classes that directly appear in std namespace.
>>>if (Record->isInStdNamespace()) {
>>> -CXXRecordDecl *Canonical = Record->getCanonicalDecl();
>>> -if (Canonical->hasAttr() ||
>>> Canonical->hasAttr())
>>> +if (Record->hasAttr() || Record->hasAttr())
>>>return;
>>>
>>>  if (StdOwners.count(Record->getName()))
>>>
>>> Modified: cfe/tr

[PATCH] D66361: Improve behavior in the case of stack exhaustion.

2019-08-22 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from an accidental newline change.




Comment at: include/clang/Basic/DiagnosticSemaKinds.td:15
 let CategoryName = "Semantic Issue" in {
-
 def note_previous_decl : Note<"%0 declared here">;

Spurious removal?



Comment at: lib/Sema/SemaExpr.cpp:15070-15079
+  // Trivial default constructors and destructors are never actually used.
+  // FIXME: What about other special members?
+  if (Func->isTrivial() && !Func->hasAttr() &&
+  OdrUse == OdrUseContext::Used) {
+if (auto *Constructor = dyn_cast(Func))
+  if (Constructor->isDefaultConstructor())
+OdrUse = OdrUseContext::FormallyOdrUsed;

rsmith wrote:
> aaron.ballman wrote:
> > This seems unrelated to the patch?
> I agree it seems that way, but it is related:
> 
> The block of code below that got turned into a lambda contains early exits 
> via `return` for the cases that get downgraded to `FormallyOdrUsed` here. We 
> used to bail out of the whole function and not mark these trivial special 
> member functions as "used" (in the code after the `NeedDefinition && 
> !Func->getBody()` condition), which seems somewhat reasonable since we don't 
> actually need definitions of them; other parts of Clang (specifically the 
> static analyzer) have developed a reliance on that behavior.
> 
> So this is preserving the existing behavior and (hopefully) making it more 
> obvious what that behavior is, rather than getting that behavior by an early 
> exit from the "need a definition?" portion of this function leaking into the 
> semantics of the "mark used" portion.
> 
> I can split this out and make this change first if you like.
> I can split this out and make this change first if you like.

No need, I appreciate the explanation!


Repository:
  rC Clang

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

https://reviews.llvm.org/D66361



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

[PATCH] D66179: [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-22 Thread Matthias Gehre via Phabricator via cfe-commits

mgehre marked 2 inline comments as done.
mgehre added inline comments.



Comment at: cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp:9
+
+#include "../ASTMatchers/ASTMatchersTest.h"
+#include "clang/ASTMatchers/ASTMatchers.h"

thakis wrote:
> mgehre wrote:
> > thakis wrote:
> > > This weird relative include path is a hint that this isn't the intended 
> > > use :)
> > True. But ...
> > I thought about copying the `matches` function from STMatchersTest.h, but 
> > together with all callees, that's many lines of code.
> > Alternatively, I could implement my own AST walking and property checking, 
> > but then the test would be much less readable.
> > As yet another alternative, I though about moving the 
> > `GslOwnerPointerInference.cpp` test itself to `unittests/ASTMatchers`,
> > but that would also be strange because it actually tests Sema functionality.
> > 
> > What would be your suggestion? (It's good that we discuss this now because 
> > I'm planning to extend this unit test further).
> Do you need the full matches() function? With the current test, it's not even 
> clear to me what exactly it tests since it looks very integration-testy and 
> not very unit-testy. Maybe if you make the test narrower, you don't that much 
> scaffolding? (Integration-type tests are supposed to be lit tests, and unit 
> tests are supposed to test small details that are difficult to test via lit.)
The purpose of the test is to verify that the ClassTemplateSpecialization gets 
the Owner attribute, independent of which of the redeclarations of the template 
had the attribute attached.
The second thing that I want to test here in the future is that the inference 
for std:: types leads to correct Owner/Pointer attributes on the 
`ClassTemplateSpecialization`.,
i.e. a type named `std::vector` should have OwnerAttr on each of its 
`ClassTemplateSpecialization`.

We currently do this in a lit test here 
https://reviews.llvm.org/differential/changeset/?ref=1574879 via checking the 
AST dump, but that is really hard to debug in cases of failures,
and not entirely clear that it checks exactly what we want. (E.g. we can check 
that a `ClassTemplateSpecializationDecl` line is followed by a `PointerAttr` 
line, but we don't actually know if that attribute hierarchically belongs to 
that decl or a another one).

So @gribozavr suggested to me to instead break this integration tests into 
smaller chunks using the ASTMatchers, which at least solves that problem.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66179



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

[PATCH] D66397: [Diagnostics] Improve -Wxor-used-as-pow

2019-08-22 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D66397#1639818 , @rsmith wrote:

> The `ALPHA_OFFSET` code seems to be unnecessarily "clever" to me. I think the 
> warning can be suppressed by reversing the operands:
>
> `ALPHA_OFFSET ^ 2`
>
> But if I were maintaining that code I would get rid of the xor hack entirely 
> and use
>
>   #define CHANNEL_OFFSET(i) (i)
>
>
> or
>
>   #define CHANNEL_OFFSET(i) (3-(i))
>


+1

In D66397#1641121 , @thakis wrote:

> In D66397#1640685 , @xbolva00 wrote:
>
> > >> I think adding parens and casts are fairly well-understood to suppress 
> > >> warnings.
> >
> > It should work here as well. #define ALPHA_OFFSET (3). Did anobody from 
> > Chromium try it?
> >
> > >> They have varying levels of C++ proficiency
> >
> > I consider things like hex decimals or parens to silence as a quite basic 
> > knowledge.
>
>
> parens for sure, but I'm not aware of any other warning that behaves 
> differently for ordinary and hex literals. What else is there?


I thought we did in Clang proper, but now I am second-guessing because I cannot 
find any with a quick search. Regardless, I think the "how do we silence this 
diagnostic" is getting a bit out of hand. We seem to now silence it when 
there's a hex, oct, or binary literal, a digit separator, or the `xor` token. I 
think we do not want to list all of those options in a diagnostic message.

> I looked through D63423  and didn't find an 
> evaluation of false / true positive rates when lhs and rhs are just literals 
> vs when they're identifiers / macros. Glancing through 
> https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E&search=Search , I 
> couldn't find a single true positive where lhs or rhs weren't a bare literal 
> (but I didn't look super carefully). Did I just miss that in D63423 
> ? What was the motivation for firing on more 
> than bare literals?

This is an interesting question to me that may help inform how we want to 
proceed.


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

https://reviews.llvm.org/D66397



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

[PATCH] D66179: [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-22 Thread Matthias Gehre via Phabricator via cfe-commits

mgehre marked an inline comment as done.
mgehre added a comment.

Yes, for  libc++ we could add the annotations to its source code, and 
eventually this would be the cleaner solution.
Currently, that is neither sufficient (because one could use libstdc++, MSVC or 
an older libc++ version) nor necessary (the inference we need for libstdc++ / 
MSVC also works for libc++),
so it's currently low on our priority list.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66179



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

1 2 >

1 - 100 of 194 matches

Mail list logo