[PATCH] D79477: [clang-tidy] Add --use-color command line option and UseColor option to control colors in diagnostics

2020-05-07 Thread hyd-dev via Phabricator via cfe-commits
hyd-dev updated this revision to Diff 262817.
hyd-dev marked an inline comment as done.
hyd-dev added a comment.

Say the `--use-color` command line option overrides the `UseColor` option in 
`.clang-tidy` file in its help text.


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

https://reviews.llvm.org/D79477

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.h
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
  clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
@@ -76,6 +76,7 @@
   User: user1
   ExtraArgs: ['arg1', 'arg2']
   ExtraArgsBefore: ['arg-before1', 'arg-before2']
+  UseColor: false
   )");
   ASSERT_TRUE(!!Options1);
   llvm::ErrorOr Options2 = parseConfiguration(R"(
@@ -85,6 +86,7 @@
   User: user2
   ExtraArgs: ['arg3', 'arg4']
   ExtraArgsBefore: ['arg-before3', 'arg-before4']
+  UseColor: true
   )");
   ASSERT_TRUE(!!Options2);
   ClangTidyOptions Options = Options1->mergeWith(*Options2, 0);
@@ -98,6 +100,8 @@
   EXPECT_EQ("arg-before1,arg-before2,arg-before3,arg-before4",
 llvm::join(Options.ExtraArgsBefore->begin(),
Options.ExtraArgsBefore->end(), ","));
+  ASSERT_TRUE(Options.UseColor.hasValue());
+  EXPECT_TRUE(*Options.UseColor);
 }
 
 class TestCheck : public ClangTidyCheck {
Index: clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
@@ -0,0 +1,28 @@
+// RUN: clang-tidy -dump-config | FileCheck %s
+// RUN: clang-tidy -dump-config -use-color | FileCheck -check-prefix=CHECK-CONFIG-COLOR %s
+// RUN: clang-tidy -dump-config -use-color=false | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
+// RUN: clang-tidy -config='UseColor: true' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-COLOR %s
+// RUN: clang-tidy -config='UseColor: false' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
+// RUN: clang-tidy -help | FileCheck -check-prefix=CHECK-OPT-PRESENT %s
+
+// REQUIRES: ansi-escape-sequences
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color=false %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
+// RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color %s | FileCheck -check-prefix=CHECK-COLOR %s
+
+// CHECK-NOT: UseColor
+// CHECK-CONFIG-NO-COLOR: UseColor: false
+// CHECK-CONFIG-COLOR: UseColor: true
+// CHECK-OPT-PRESENT: --use-color
+
+class Base {
+public:
+  virtual ~Base() = 0;
+};
+
+class Delivered : public Base {
+public:
+  virtual ~Delivered() = default;
+  // CHECK-NO-COLOR: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-COLOR: {{.\[0;1;35m}}warning: {{.\[0m}}{{.\[1m}}prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+};
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -229,6 +229,15 @@
cl::value_desc("filename"),
cl::cat(ClangTidyCategory));
 
+static cl::opt UseColor("use-color", cl::desc(R"(
+Use colors in diagnostics. If not set, colors
+will be used if the terminal connected to
+standard output supports colors.
+This option overrides the 'UseColor' option in
+.clang-tidy file, if any.
+)"),
+  cl::init(false), cl::cat(ClangTidyCategory));
+
 namespace clang {
 namespace tidy {
 
@@ -291,6 +300,8 @@
 OverrideOptions.SystemHeaders = SystemHeaders;
   if (FormatStyle.getNumOccurrences() > 0)
 OverrideOptions.FormatStyle = FormatStyle;
+  if (UseColor.getNumOccurrences() > 0)
+OverrideOptions.UseColor = UseColor;
 
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
Index: clang-tools-extra/clang-tidy/ClangTidyOptions.h
===
--- clang-tools-extra/clang-tidy/ClangTidyOptions.h
+++ clang-tools-extra/clang-tidy/ClangTidyOptions.h
@@ -126,6 +126,9 @@
   /// apply this config file on top of the parent one. If false or missing,
   /// only this configuration file will be used.
   llvm::Optional 

[PATCH] D79477: [clang-tidy] Add --use-color command line option and UseColor option to control colors in diagnostics

2020-05-07 Thread hyd-dev via Phabricator via cfe-commits
hyd-dev added inline comments.



Comment at: clang-tools-extra/clang-tidy/ClangTidyOptions.cpp:99
 IO.mapOptional("InheritParentConfig", Options.InheritParentConfig);
+IO.mapOptional("UseColor", Options.UseColor);
   }

njames93 wrote:
> I'm not entirely sure this option belongs in the config file. However if it 
> will get read in here, maybe update the help string for the command line 
> option to say it overrides the `UseColor` option from the `.clang-tidy` 
> configuration file.
> I'm not entirely sure this option belongs in the config file.
It will be useful in the config file if the user invokes clang-tidy via another 
tool that does not allow the user to set clang-tidy's command line options.
> However if it will get read in here, maybe update the help string for the 
> command line option to say it overrides the `UseColor` option from the 
> `.clang-tidy` configuration file.
I've updated it.


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

https://reviews.llvm.org/D79477



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


[PATCH] D79072: [Analyzer][VLASizeChecker] Check VLA size in typedef and sizeof.

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

This change is relatively small and the refactoring like part (introduction of 
`checkVLA` if I think correct?) is connected to its use. The other change is 
add of a new function (callback). This is probably small enough to go into one 
change and we can see why the new function `checkVLA` is needed. So my vote is 
to not split this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79072



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


[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

2020-05-07 Thread Scott Constable via Phabricator via cfe-commits
sconstab added inline comments.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:295
+std::function)> AnalyzeDefUseChain =
+[&](NodeAddr Def) {
+  if (Transmitters.find(Def.Id) != Transmitters.end())

mattdr wrote:
> fwiw, this code would be easier to understand if we didn't shadow `Def` with 
> another variable named `Def`.
Changed the outer def to `SourceDef`, which also seems to make the code after 
the lambda a lot clearer.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:321-322
+  for (auto UseID : Uses) {
+if (!UsesVisited.insert(UseID).second)
+  continue; // Already visited this use of the current def
+

mattdr wrote:
> "current def" is a bit ambiguous here. I _believe_ it means `AnalyzeDef`'s 
> `Def` argument? At least, that's the interpretation that makes the comment 
> make sense since `UsesVisited` is in `AnalyzeDef`'s scope.
I am now trying to be clearer by using capital-d "Def" to refer specifically to 
the def that is being analyzed, and lower-case-d "def" to refer to any other 
defs. Do you think this is better? Good enough?



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:331
+// We naively assume that an instruction propagates any loaded
+// Uses to all Defs, unless the instruction is a call.
+if (UseMI.isCall())

mattdr wrote:
> Copying a comment from a previous iteration:
> 
> > Why is it okay to assume that a call doesn't propagate its uses to defs? Is 
> > it because we can assume the CFI transform is already inserting an LFENCE? 
> > Whatever the reason, let's state it explicitly here
> 
Added clarification to the comment.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:341
+  if (UseMI.mayLoad())
+continue; // Found a transmitting load, stop traversing defs
+}

mattdr wrote:
> The comment doesn't match the loop, which is traversing over `Uses`. More 
> importantly, though: why are we allowed to stop traversing through `Uses` 
> here? This `Def` won't be analyzed again, so this is our only chance to 
> enumerate all transmitters to make sure we have all the necessary source -> 
> sink edges in the gadget graph.
@mattdr I think that the code is correct, and I added more to the comment in an 
attempt to clarify. Let me know if you still think that this is an issue.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:366-369
+  llvm::sort(DefTransmitters);
+  DefTransmitters.erase(
+  std::unique(DefTransmitters.begin(), DefTransmitters.end()),
+  DefTransmitters.end());

mattdr wrote:
> Should `Transmitters` map to an `llvm::SmallSet`?
In my testing, `std::vector` seems a bit faster than `llvm::SmallSet`. I also 
suspect that `llvm::SmallSet` may waste more space because many defs will have 
no transmitters.


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

https://reviews.llvm.org/D75936



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


[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

2020-05-07 Thread Scott Constable via Phabricator via cfe-commits
sconstab updated this revision to Diff 262816.
sconstab marked 9 inline comments as done.
sconstab added a comment.

Addressed comments by @mattdr.

Several comments in the code have been updated, but the code has not changed.


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

https://reviews.llvm.org/D75936

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Arch/X86.cpp
  clang/test/Driver/x86-target-features.c
  llvm/lib/Target/X86/CMakeLists.txt
  llvm/lib/Target/X86/ImmutableGraph.h
  llvm/lib/Target/X86/X86.h
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp
  llvm/lib/Target/X86/X86Subtarget.h
  llvm/lib/Target/X86/X86TargetMachine.cpp
  llvm/test/CodeGen/X86/O0-pipeline.ll
  llvm/test/CodeGen/X86/O3-pipeline.ll
  llvm/test/CodeGen/X86/lvi-hardening-gadget-graph.ll

Index: llvm/test/CodeGen/X86/lvi-hardening-gadget-graph.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/lvi-hardening-gadget-graph.ll
@@ -0,0 +1,129 @@
+; RUN: llc -verify-machineinstrs -mtriple=x86_64-unknown -x86-lvi-load-dot-verify -o %t < %s | FileCheck %s
+
+; Function Attrs: noinline nounwind optnone uwtable
+define dso_local i32 @test(i32* %untrusted_user_ptr, i32* %secret, i32 %secret_size) #0 {
+entry:
+  %untrusted_user_ptr.addr = alloca i32*, align 8
+  %secret.addr = alloca i32*, align 8
+  %secret_size.addr = alloca i32, align 4
+  %ret_val = alloca i32, align 4
+  %i = alloca i32, align 4
+  store i32* %untrusted_user_ptr, i32** %untrusted_user_ptr.addr, align 8
+  store i32* %secret, i32** %secret.addr, align 8
+  store i32 %secret_size, i32* %secret_size.addr, align 4
+  store i32 0, i32* %ret_val, align 4
+  call void @llvm.x86.sse2.lfence()
+  store i32 0, i32* %i, align 4
+  br label %for.cond
+
+for.cond: ; preds = %for.inc, %entry
+  %0 = load i32, i32* %i, align 4
+  %1 = load i32, i32* %secret_size.addr, align 4
+  %cmp = icmp slt i32 %0, %1
+  br i1 %cmp, label %for.body, label %for.end
+
+for.body: ; preds = %for.cond
+  %2 = load i32, i32* %i, align 4
+  %rem = srem i32 %2, 2
+  %cmp1 = icmp eq i32 %rem, 0
+  br i1 %cmp1, label %if.then, label %if.else
+
+if.then:  ; preds = %for.body
+  %3 = load i32*, i32** %secret.addr, align 8
+  %4 = load i32, i32* %ret_val, align 4
+  %idxprom = sext i32 %4 to i64
+  %arrayidx = getelementptr inbounds i32, i32* %3, i64 %idxprom
+  %5 = load i32, i32* %arrayidx, align 4
+  %6 = load i32*, i32** %untrusted_user_ptr.addr, align 8
+  store i32 %5, i32* %6, align 4
+  br label %if.end
+
+if.else:  ; preds = %for.body
+  %7 = load i32*, i32** %secret.addr, align 8
+  %8 = load i32, i32* %ret_val, align 4
+  %idxprom2 = sext i32 %8 to i64
+  %arrayidx3 = getelementptr inbounds i32, i32* %7, i64 %idxprom2
+  store i32 42, i32* %arrayidx3, align 4
+  br label %if.end
+
+if.end:   ; preds = %if.else, %if.then
+  %9 = load i32*, i32** %untrusted_user_ptr.addr, align 8
+  %10 = load i32, i32* %9, align 4
+  store i32 %10, i32* %ret_val, align 4
+  br label %for.inc
+
+for.inc:  ; preds = %if.end
+  %11 = load i32, i32* %i, align 4
+  %inc = add nsw i32 %11, 1
+  store i32 %inc, i32* %i, align 4
+  br label %for.cond
+
+for.end:  ; preds = %for.cond
+  %12 = load i32, i32* %ret_val, align 4
+  ret i32 %12
+}
+
+; CHECK:  digraph "Speculative gadgets for \"test\" function" {
+; CHECK-NEXT: label="Speculative gadgets for \"test\" function";
+; CHECK:  Node0x{{[0-9a-f]+}} [shape=record,color = green,label="{LFENCE\n}"];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[label = 0];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} [shape=record,label="{renamable $eax = MOV32rm %stack.4.i, 1, $noreg, 0, $noreg :: (dereferenceable load 4 from %ir.i)\n}"];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[color = red, style = "dashed"];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[label = 1];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} [shape=record,label="{JCC_1 %bb.6, 13, implicit killed $eflags\n}"];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[label = 1];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[label = 1];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} [shape=record,label="{CMP32rm killed renamable $eax, %stack.2.secret_size.addr, 1, $noreg, 0, $noreg, implicit-def $eflags :: (dereferenceable load 4 from %ir.secret_size.addr)\n}"];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[color = red, style = "dashed"];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} -> Node0x{{[0-9a-f]+}}[label = 1];
+; CHECK-NEXT: Node0x{{[0-9a-f]+}} [shape=record,label="{renamable $eax = MOV32rm %stack.4.i, 1, $noreg, 0, $noreg :: (dereferenceable load 4 from %ir.i)

[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

In D79344#2026349 , @tra wrote:

> Here's a slightly smaller variant which may be a good clue for tracking down 
> the root cause. This one fails with:
>
>   var.cc:6:14: error: no matching function for call to 'copysign'
> double g = copysign(0, g);
>^~~~
>   var.cc:5:56: note: candidate template ignored: substitution failure [with e 
> = int, f = double]: reference to __host__ variable 'b' in __device__ function
>   __attribute__((device)) typename c::b, double>::d copysign(e, f) {
>~ ^
>   1 error generated when compiling for sm_60.
>
>
> I suspect that it's handling of non-type template parameter that may be 
> breaking things in both cases.
>
>   template  struct a { static const bool b = true; };
>   template  struct c;
>   template  struct c { typedef h d; };
>   template 
>   __attribute__((device)) typename c::b, double>::d copysign(e, f) {
> double g = copysign(0, g);
>   }
>


My bad. We need a similar logic in the call check to skip the template not 
instantiated yet, i.e.

  diff --git a/clang/lib/Sema/SemaCUDA.cpp b/clang/lib/Sema/SemaCUDA.cpp
  index 583e588e4bd..467136f4579 100644
  --- a/clang/lib/Sema/SemaCUDA.cpp
  +++ b/clang/lib/Sema/SemaCUDA.cpp
  @@ -910,6 +910,10 @@ bool Sema::CheckCUDAAccess(SourceLocation Loc, 
FunctionDecl *Caller,
 assert(getLangOpts().CUDA && "Should only be called during CUDA 
compilation");
 assert(VD && isNonLocalVariable(VD) && "Variable must be a non-local 
one.");
   
  +  auto &ExprEvalCtx = ExprEvalContexts.back();
  +  if (ExprEvalCtx.isUnevaluated() || ExprEvalCtx.isConstantEvaluated())
  +return true;
  +
 // FIXME: Is bailing out early correct here?  Should we instead assume that
 // the caller is a global initializer?
 if (!Caller)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D79548: Fix false positive with warning -Wnon-c-typedef-for-linkage

2020-05-07 Thread Richard Trieu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4ae537c2220f: Fix false positive with 
-Wnon-c-typedef-for-linkage (authored by rtrieu).

Changed prior to commit:
  https://reviews.llvm.org/D79548?vs=262536&id=262808#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79548

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/anonymous-struct.cpp


Index: clang/test/SemaCXX/anonymous-struct.cpp
===
--- clang/test/SemaCXX/anonymous-struct.cpp
+++ clang/test/SemaCXX/anonymous-struct.cpp
@@ -133,3 +133,23 @@
 int arr[&f ? 1 : 2];
   } C; // expected-note {{by this typedef}}
 }
+
+namespace ImplicitDecls {
+struct Destructor {
+  ~Destructor() {}
+};
+typedef struct {
+} Empty;
+
+typedef struct {
+  Destructor x;
+} A;
+
+typedef struct {
+  Empty E;
+} B;
+
+typedef struct {
+  const Empty E;
+} C;
+} // namespace ImplicitDecls
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -4425,8 +4425,11 @@
 isa(D))
   continue;
 auto *MemberRD = dyn_cast(D);
-if (!MemberRD)
+if (!MemberRD) {
+  if (D->isImplicit())
+continue;
   return {NonCLikeKind::OtherMember, D->getSourceRange()};
+}
 
 //  -- contain a lambda-expression,
 if (MemberRD->isLambda())


Index: clang/test/SemaCXX/anonymous-struct.cpp
===
--- clang/test/SemaCXX/anonymous-struct.cpp
+++ clang/test/SemaCXX/anonymous-struct.cpp
@@ -133,3 +133,23 @@
 int arr[&f ? 1 : 2];
   } C; // expected-note {{by this typedef}}
 }
+
+namespace ImplicitDecls {
+struct Destructor {
+  ~Destructor() {}
+};
+typedef struct {
+} Empty;
+
+typedef struct {
+  Destructor x;
+} A;
+
+typedef struct {
+  Empty E;
+} B;
+
+typedef struct {
+  const Empty E;
+} C;
+} // namespace ImplicitDecls
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -4425,8 +4425,11 @@
 isa(D))
   continue;
 auto *MemberRD = dyn_cast(D);
-if (!MemberRD)
+if (!MemberRD) {
+  if (D->isImplicit())
+continue;
   return {NonCLikeKind::OtherMember, D->getSourceRange()};
+}
 
 //  -- contain a lambda-expression,
 if (MemberRD->isLambda())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 4ae537c - Fix false positive with -Wnon-c-typedef-for-linkage

2020-05-07 Thread via cfe-commits

Author: Weverything
Date: 2020-05-07T19:20:08-07:00
New Revision: 4ae537c2220f5064fdc914348dabe70eb10eef85

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

LOG: Fix false positive with -Wnon-c-typedef-for-linkage

Implicit methods for structs can confuse the warning, so exclude checking
the Decl's that are implicit. Implicit Decl's for lambdas still need to
be checked, so skipping all implicit Decl's won't work.

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

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/SemaCXX/anonymous-struct.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 46e541917510..5d3314b4f244 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -4425,8 +4425,11 @@ static NonCLikeKind 
getNonCLikeKindForAnonymousStruct(const CXXRecordDecl *RD) {
 isa(D))
   continue;
 auto *MemberRD = dyn_cast(D);
-if (!MemberRD)
+if (!MemberRD) {
+  if (D->isImplicit())
+continue;
   return {NonCLikeKind::OtherMember, D->getSourceRange()};
+}
 
 //  -- contain a lambda-expression,
 if (MemberRD->isLambda())

diff  --git a/clang/test/SemaCXX/anonymous-struct.cpp 
b/clang/test/SemaCXX/anonymous-struct.cpp
index 017c867c95db..10f6711dd340 100644
--- a/clang/test/SemaCXX/anonymous-struct.cpp
+++ b/clang/test/SemaCXX/anonymous-struct.cpp
@@ -133,3 +133,23 @@ namespace ValidButUnsupported {
 int arr[&f ? 1 : 2];
   } C; // expected-note {{by this typedef}}
 }
+
+namespace ImplicitDecls {
+struct Destructor {
+  ~Destructor() {}
+};
+typedef struct {
+} Empty;
+
+typedef struct {
+  Destructor x;
+} A;
+
+typedef struct {
+  Empty E;
+} B;
+
+typedef struct {
+  const Empty E;
+} C;
+} // namespace ImplicitDecls



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


[PATCH] D73307: Unique Names for Functions with Internal Linkage

2020-05-07 Thread Sriraman Tallam via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe8147ad82226: Uniuqe Names for Internal Linkage Symbols. 
(authored by tmsriram).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73307

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/unique-internal-linkage-names.cpp
  clang/test/Driver/funique-internal-linkage-names.c

Index: clang/test/Driver/funique-internal-linkage-names.c
===
--- /dev/null
+++ clang/test/Driver/funique-internal-linkage-names.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### -funique-internal-linkage-names %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -funique-internal-linkage-names -fno-unique-internal-linkage-names %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// CHECK-OPT: "-funique-internal-linkage-names"
+// CHECK-NOOPT-NOT: "-funique-internal-linkage-names"
Index: clang/test/CodeGen/unique-internal-linkage-names.cpp
===
--- /dev/null
+++ clang/test/CodeGen/unique-internal-linkage-names.cpp
@@ -0,0 +1,61 @@
+// This test checks if internal linkage symbols get unique names with
+// -funique-internal-linkage-names option.
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -o - < %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -fexperimental-new-pass-manager -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
+
+static int glob;
+static int foo() {
+  return 0;
+}
+
+int (*bar())() {
+  return foo;
+}
+
+int getGlob() {
+  return glob;
+}
+
+// Function local static variable and anonymous namespace namespace variable.
+namespace {
+int anon_m;
+int getM() {
+  return anon_m;
+}
+} // namespace
+
+int retAnonM() {
+  static int fGlob;
+  return getM() + fGlob;
+}
+
+// Multiversioning symbols
+__attribute__((target("default"))) static int mver() {
+  return 0;
+}
+
+__attribute__((target("sse4.2"))) static int mver() {
+  return 1;
+}
+
+int mver_call() {
+  return mver();
+}
+
+// PLAIN: @_ZL4glob = internal global
+// PLAIN: @_ZZ8retAnonMvE5fGlob = internal global
+// PLAIN: @_ZN12_GLOBAL__N_16anon_mE = internal global
+// PLAIN: define internal i32 @_ZL3foov()
+// PLAIN: define internal i32 @_ZN12_GLOBAL__N_14getMEv
+// PLAIN: define weak_odr i32 ()* @_ZL4mverv.resolver()
+// PLAIN: define internal i32 @_ZL4mverv()
+// PLAIN: define internal i32 @_ZL4mverv.sse4.2()
+// UNIQUE: @_ZL4glob.{{[0-9a-f]+}} = internal global
+// UNIQUE: @_ZZ8retAnonMvE5fGlob.{{[0-9a-f]+}} = internal global
+// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.{{[0-9a-f]+}} = internal global
+// UNIQUE: define internal i32 @_ZL3foov.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.{{[0-9a-f]+}}
+// UNIQUE: define weak_odr i32 ()* @_ZL4mverv.resolver()
+// UNIQUE: define internal i32 @_ZL4mverv.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.{{[0-9a-f]+}}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -957,6 +957,8 @@
   Opts.DataSections = Args.hasArg(OPT_fdata_sections);
   Opts.StackSizeSection = Args.hasArg(OPT_fstack_size_section);
   Opts.UniqueSectionNames = !Args.hasArg(OPT_fno_unique_section_names);
+  Opts.UniqueInternalLinkageNames =
+  Args.hasArg(OPT_funique_internal_linkage_names);
 
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4253,6 +4253,8 @@
 options::OPT_fno_function_sections,
 options::OPT_fdata_sections,
 options::OPT_fno_data_sections,
+options::OPT_funique_internal_linkage_names,
+options::OPT_fno_unique_internal_linkage_names,
 options::OPT_funique_section_names,
 options::OPT_fno_unique_section_names,
 options::OPT_mrestrict_it,
@@ -4872,6 +4874,10 @@
 options::OPT_fno_unique_section_names, true))
 CmdArgs.push_back("-fno-unique-section-names");
 
+  if (Args.hasFlag(options::OPT_funique_internal_linkage_names,
+   options::OPT_fno_unique_internal_linkage_names, false))
+CmdArgs.push_back("-funique-internal-linkage-names");
+
   Args.AddLastArg(C

[PATCH] D66983: [WebAssembly] Add wasm-specific vector shuffle builtin and intrinsic

2020-05-07 Thread Thomas Lively via Phabricator via cfe-commits
tlively added a comment.

Ok, this is ready for review for real this time. The WebAssembly SIMD 
contributors have decided that this is an appropriate direction to go in, and 
we are leaving the door open for future improvements.




Comment at: llvm/include/llvm/IR/IntrinsicsWebAssembly.td:117
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+[IntrNoMem, IntrSpeculatable]>;

aheejin wrote:
> i32 is bigger than `ImmLaneIdx32`. Should we model this into something 
> smaller, like i8? What happens if we specify an index grater than 31? (I 
> think this question also applies to other intrinsics and builtins. I don't 
> think it matters a lot given than all integers are larger than lane types 
> though.)
It turns out that it would have been an ISel failure. I fixed this to replace 
an out-of-bounds indices with 0.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1251
+return DAG.getNode(WebAssemblyISD::SHUFFLE, DL, Op.getValueType(), Ops);
+  }
   }

aheejin wrote:
> This looks rather straightforward... Can't we do this in TableGen?
No, I don't know of a simple way to handle undef lanes in TableGen. I could 
look into using custom patterns and transform nodes, but in the end this code 
is probably simpler the way it is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66983



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


[PATCH] D66983: [WebAssembly] Add wasm-specific vector shuffle builtin and intrinsic

2020-05-07 Thread Thomas Lively via Phabricator via cfe-commits
tlively updated this revision to Diff 262798.
tlively marked an inline comment as done.
tlively added a comment.

- Rebase, update intrinsics header, and address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66983

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/wasm_simd128.h
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll

Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -141,6 +141,36 @@
   ret <16 x i8> %a
 }
 
+; CHECK-LABEL: shuffle_v16i8:
+; NO-SIMD128-NOT: v8x16
+; SIMD128-NEXT: .functype shuffle_v16i8 (v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: v8x16.shuffle $push[[R:[0-9]+]]=, $0, $1,
+; SIMD128-SAME: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <16 x i8> @llvm.wasm.shuffle(
+  <16 x i8>, <16 x i8>, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32,
+  i32, i32, i32, i32, i32)
+define <16 x i8> @shuffle_v16i8(<16 x i8> %x, <16 x i8> %y) {
+  %res = call <16 x i8> @llvm.wasm.shuffle(<16 x i8> %x, <16 x i8> %y,
+  i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7,
+  i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 35)
+  ret <16 x i8> %res
+}
+
+; CHECK-LABEL: shuffle_undef_v16i8:
+; NO-SIMD128-NOT: v8x16
+; SIMD128-NEXT: .functype shuffle_undef_v16i8 (v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: v8x16.shuffle $push[[R:[0-9]+]]=, $0, $1,
+; SIMD128-SAME: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+define <16 x i8> @shuffle_undef_v16i8(<16 x i8> %x, <16 x i8> %y) {
+  %res = call <16 x i8> @llvm.wasm.shuffle(<16 x i8> %x, <16 x i8> %y,
+  i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
+  i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
+  i32 undef, i32 undef, i32 undef, i32 2)
+  ret <16 x i8> %res
+}
+
 ; ==
 ; 8 x i16
 ; ==
Index: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
@@ -1353,6 +1353,24 @@
Op.getOperand(3)  // thrown value
});
   }
+
+  case Intrinsic::wasm_shuffle: {
+// Drop in-chain and replace undefs, but otherwise pass through unchanged
+SDValue Ops[18];
+size_t OpIdx = 0;
+Ops[OpIdx++] = Op.getOperand(1);
+Ops[OpIdx++] = Op.getOperand(2);
+while (OpIdx < 18) {
+  const SDValue &MaskIdx = Op.getOperand(OpIdx + 1);
+  if (MaskIdx.isUndef() ||
+  cast(MaskIdx.getNode())->getZExtValue() >= 32) {
+Ops[OpIdx++] = DAG.getConstant(0, DL, MVT::i32);
+  } else {
+Ops[OpIdx++] = MaskIdx;
+  }
+}
+return DAG.getNode(WebAssemblyISD::SHUFFLE, DL, Op.getValueType(), Ops);
+  }
   }
 }
 
Index: llvm/include/llvm/IR/IntrinsicsWebAssembly.td
===
--- llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -104,6 +104,13 @@
   Intrinsic<[llvm_v16i8_ty],
 [llvm_v16i8_ty, llvm_v16i8_ty],
 [IntrNoMem, IntrSpeculatable]>;
+def int_wasm_shuffle :
+  Intrinsic<[llvm_v16i8_ty],
+[llvm_v16i8_ty, llvm_v16i8_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+[IntrNoMem, IntrSpeculatable]>;
 def int_wasm_sub_saturate_signed :
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>],
@@ -116,7 +123,6 @@
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>],
 [IntrNoMem, IntrSpeculatable]>;
-
 def int_wasm_bitselect :
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],
@@ -170,7 +176,6 @@
 [llvm_anyvector_ty],
 [IntrNoMem, IntrSpeculatable]>;
 
-
 //===--===//
 // Bulk memory intrinsics
 //===--===//
Index: clang/test/CodeGen/builtins-wasm.c

[PATCH] D79588: [llvm][Support] Use std::atomic for llvm::call_once

2020-05-07 Thread Brad Smith via Phabricator via cfe-commits
brad added a comment.

OpenBSD 6.7 is just wrapping up and will be released in a few days. We have 
switched to Clang for our PowerPC system compiler and thus libc++. It should be 
Ok to remove OpenBSD from that bit of code.

The original issue as far as I remember is that because we don't have TLS 
support it was exposing another code path that could sometimes have deadlocks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79588



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


[clang] e8147ad - Uniuqe Names for Internal Linkage Symbols.

2020-05-07 Thread Sriraman Tallam via cfe-commits

Author: Sriraman Tallam
Date: 2020-05-07T18:18:37-07:00
New Revision: e8147ad8222602d16728c370d5fac086260d058c

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

LOG: Uniuqe Names for Internal Linkage Symbols.

This is a standalone patch and this would help Propeller do a better job of code
layout as it can accurately attribute the profiles to the right internal linkage
function.

This also helps SampledFDO/AutoFDO correctly associate sampled profiles to the
right internal function. Currently, if there is more than one internal symbol
foo, their profiles are aggregated by SampledFDO.

This patch adds a new clang option, -funique-internal-funcnames, to generate
unique names for functions with internal linkage. This patch appends the md5
hash of the module name to the function symbol as a best effort to generate a
unique name for symbols with internal linkage.

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

Added: 
clang/test/CodeGen/unique-internal-linkage-names.cpp
clang/test/Driver/funique-internal-linkage-names.c

Modified: 
clang/docs/UsersManual.rst
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 97ba2aad575e..ae479e0a58ae 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1677,6 +1677,27 @@ are listed below.
on ELF targets when using the integrated assembler. This flag currently
only has an effect on ELF targets.
 
+**-f[no]-unique-internal-linkage-names**
+
+   Controls whether Clang emits a unique (best-effort) symbol name for internal
+   linkage symbols.  When this option is set, compiler hashes the main source
+   file path from the command line and appends it to all internal symbols. If a
+   program contains multiple objects compiled with the same command-line source
+   file path, the symbols are not guaranteed to be unique.  This option is
+   particularly useful in attributing profile information to the correct
+   function when multiple functions with the same private linkage name exist
+   in the binary.
+
+   It should be noted that this option cannot guarantee uniqueness and the
+   following is an example where it is not unique when two modules contain
+   symbols with the same private linkage name:
+
+   .. code-block:: console
+
+ $ cd $P/foo && clang -c -funique-internal-linkage-names name_conflict.c
+ $ cd $P/bar && clang -c -funique-internal-linkage-names name_conflict.c
+ $ cd $P && clang foo/name_conflict.o && bar/name_conflict.o
+
 Profile Guided Optimization
 ---
 

diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index bc7108edece9..5c7fbf43ce46 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -161,6 +161,7 @@ CODEGENOPT(ReciprocalMath, 1, 0) ///< Allow FP 
divisions to be reassociated.
 CODEGENOPT(NoTrappingMath, 1, 0) ///< Set when -fno-trapping-math is 
enabled.
 CODEGENOPT(NoNaNsFPMath  , 1, 0) ///< Assume FP arguments, results not NaN.
 CODEGENOPT(CorrectlyRoundedDivSqrt, 1, 0) ///< 
-cl-fp32-correctly-rounded-divide-sqrt
+CODEGENOPT(UniqueInternalLinkageNames, 1, 0) ///< Internal Linkage symbols get 
unique names.
 
 /// When false, this attempts to generate code as if the result of an
 /// overflowing conversion matches the overflowing behavior of a target's 
native

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 66b98b1e46fa..ef8ccb5b90e2 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2001,6 +2001,12 @@ def funique_section_names : Flag <["-"], 
"funique-section-names">,
 def fno_unique_section_names : Flag <["-"], "fno-unique-section-names">,
   Group, Flags<[CC1Option]>;
 
+def funique_internal_linkage_names : Flag <["-"], 
"funique-internal-linkage-names">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Uniqueify Internal Linkage Symbol Names by appending the MD5 hash 
of the module path">;
+def fno_unique_internal_linkage_names : Flag <["-"], 
"fno-unique-internal-linkage-names">,
+  Group;
+
 def fstrict_return : Flag<["-"], "fstrict-return">, Group,
   HelpText<"Always treat control flow paths that fall off the end of a "
"non-void function as unreachable">;

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index a125c96fd00e..ba61a93a4d1a 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp

[PATCH] D73307: Unique Names for Functions with Internal Linkage

2020-05-07 Thread Sriraman Tallam via Phabricator via cfe-commits
tmsriram updated this revision to Diff 262797.
tmsriram added a comment.

Update patch with changes to BackendUtil.cpp (forgot this file).


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

https://reviews.llvm.org/D73307

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/unique-internal-linkage-names.cpp
  clang/test/Driver/funique-internal-linkage-names.c

Index: clang/test/Driver/funique-internal-linkage-names.c
===
--- /dev/null
+++ clang/test/Driver/funique-internal-linkage-names.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### -funique-internal-linkage-names %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -funique-internal-linkage-names -fno-unique-internal-linkage-names %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// CHECK-OPT: "-funique-internal-linkage-names"
+// CHECK-NOOPT-NOT: "-funique-internal-linkage-names"
Index: clang/test/CodeGen/unique-internal-linkage-names.cpp
===
--- /dev/null
+++ clang/test/CodeGen/unique-internal-linkage-names.cpp
@@ -0,0 +1,61 @@
+// This test checks if internal linkage symbols get unique names with
+// -funique-internal-linkage-names option.
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -o - < %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -fexperimental-new-pass-manager -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
+
+static int glob;
+static int foo() {
+  return 0;
+}
+
+int (*bar())() {
+  return foo;
+}
+
+int getGlob() {
+  return glob;
+}
+
+// Function local static variable and anonymous namespace namespace variable.
+namespace {
+int anon_m;
+int getM() {
+  return anon_m;
+}
+} // namespace
+
+int retAnonM() {
+  static int fGlob;
+  return getM() + fGlob;
+}
+
+// Multiversioning symbols
+__attribute__((target("default"))) static int mver() {
+  return 0;
+}
+
+__attribute__((target("sse4.2"))) static int mver() {
+  return 1;
+}
+
+int mver_call() {
+  return mver();
+}
+
+// PLAIN: @_ZL4glob = internal global
+// PLAIN: @_ZZ8retAnonMvE5fGlob = internal global
+// PLAIN: @_ZN12_GLOBAL__N_16anon_mE = internal global
+// PLAIN: define internal i32 @_ZL3foov()
+// PLAIN: define internal i32 @_ZN12_GLOBAL__N_14getMEv
+// PLAIN: define weak_odr i32 ()* @_ZL4mverv.resolver()
+// PLAIN: define internal i32 @_ZL4mverv()
+// PLAIN: define internal i32 @_ZL4mverv.sse4.2()
+// UNIQUE: @_ZL4glob.{{[0-9a-f]+}} = internal global
+// UNIQUE: @_ZZ8retAnonMvE5fGlob.{{[0-9a-f]+}} = internal global
+// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.{{[0-9a-f]+}} = internal global
+// UNIQUE: define internal i32 @_ZL3foov.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.{{[0-9a-f]+}}
+// UNIQUE: define weak_odr i32 ()* @_ZL4mverv.resolver()
+// UNIQUE: define internal i32 @_ZL4mverv.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.{{[0-9a-f]+}}
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -77,6 +77,7 @@
 #include "llvm/Transforms/Utils/EntryExitInstrumenter.h"
 #include "llvm/Transforms/Utils/NameAnonGlobals.h"
 #include "llvm/Transforms/Utils/SymbolRewriter.h"
+#include "llvm/Transforms/Utils/UniqueInternalLinkageNames.h"
 #include 
 using namespace clang;
 using namespace llvm;
@@ -719,6 +720,12 @@
   if (!CodeGenOpts.RewriteMapFiles.empty())
 addSymbolRewriterPass(CodeGenOpts, &MPM);
 
+  // Add UniqueInternalLinkageNames Pass which renames internal linkage symbols
+  // with unique names.
+  if (CodeGenOpts.UniqueInternalLinkageNames) {
+MPM.add(createUniqueInternalLinkageNamesPass());
+  }
+
   if (Optional Options = getGCOVOptions(CodeGenOpts)) {
 MPM.add(createGCOVProfilerPass(*Options));
 if (CodeGenOpts.getDebugInfo() == codegenoptions::NoDebugInfo)
@@ -1203,6 +1210,12 @@
   if (LangOpts.Sanitize.has(SanitizerKind::LocalBounds))
 MPM.addPass(createModuleToFunctionPassAdaptor(BoundsCheckingPass()));
 
+  // Add UniqueInternalLinkageNames Pass which renames internal linkage
+  // symbols with unique names.
+  if (CodeGenOpts.UniqueInternalLinkageNames) {
+MPM.addPass(UniqueInternalLinkageNamesPass());
+  }
+
   // Lastly, add semantically necessary passes for LTO.
   if (IsLTO || IsThinLTO) {
 MPM.addPass(CanonicalizeAliasesPass());
@@ -1292,6 +1305,12 @@
   MPM.addPass(InstrProfiling(*Options, false));
 });
 
+  /

[PATCH] D76083: [clang-tidy] Expand the list of functions in bugprone-unused-return-value

2020-05-07 Thread Joe Ranieri via Phabricator via cfe-commits
jranieri-grammatech added a comment.

Ping? It sounds like the consensus is to commit this as-is and, if there's a 
negative fallout for users of clang-tidy, either split out the functions or 
pare the list down later?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76083



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


[PATCH] D66983: [WebAssembly] Add wasm-specific vector shuffle builtin and intrinsic

2020-05-07 Thread Thomas Lively via Phabricator via cfe-commits
tlively updated this revision to Diff 262795.
tlively marked an inline comment as done.
tlively edited the summary of this revision.
tlively added a comment.

- Rebase and update intrinsics header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66983

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/wasm_simd128.h
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll

Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -141,6 +141,36 @@
   ret <16 x i8> %a
 }
 
+; CHECK-LABEL: shuffle_v16i8:
+; NO-SIMD128-NOT: v8x16
+; SIMD128-NEXT: .functype shuffle_v16i8 (v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: v8x16.shuffle $push[[R:[0-9]+]]=, $0, $1,
+; SIMD128-SAME: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <16 x i8> @llvm.wasm.shuffle(
+  <16 x i8>, <16 x i8>, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32,
+  i32, i32, i32, i32, i32)
+define <16 x i8> @shuffle_v16i8(<16 x i8> %x, <16 x i8> %y) {
+  %res = call <16 x i8> @llvm.wasm.shuffle(<16 x i8> %x, <16 x i8> %y,
+  i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7,
+  i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15)
+  ret <16 x i8> %res
+}
+
+; CHECK-LABEL: shuffle_undef_v16i8:
+; NO-SIMD128-NOT: v8x16
+; SIMD128-NEXT: .functype shuffle_undef_v16i8 (v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: v8x16.shuffle $push[[R:[0-9]+]]=, $0, $1,
+; SIMD128-SAME: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+define <16 x i8> @shuffle_undef_v16i8(<16 x i8> %x, <16 x i8> %y) {
+  %res = call <16 x i8> @llvm.wasm.shuffle(<16 x i8> %x, <16 x i8> %y,
+  i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
+  i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
+  i32 undef, i32 undef, i32 undef, i32 2)
+  ret <16 x i8> %res
+}
+
 ; ==
 ; 8 x i16
 ; ==
Index: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
@@ -1353,6 +1353,20 @@
Op.getOperand(3)  // thrown value
});
   }
+
+  case Intrinsic::wasm_shuffle: {
+// Drop in-chain and replace undefs, but otherwise pass through unchanged
+SDValue Ops[18];
+size_t OpIdx = 0;
+Ops[OpIdx++] = Op.getOperand(1);
+Ops[OpIdx++] = Op.getOperand(2);
+while (OpIdx < 18) {
+  const SDValue &MaskIdx = Op.getOperand(OpIdx + 1);
+  Ops[OpIdx++] =
+  MaskIdx.isUndef() ? DAG.getConstant(0, DL, MVT::i32) : MaskIdx;
+}
+return DAG.getNode(WebAssemblyISD::SHUFFLE, DL, Op.getValueType(), Ops);
+  }
   }
 }
 
Index: llvm/include/llvm/IR/IntrinsicsWebAssembly.td
===
--- llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -104,6 +104,13 @@
   Intrinsic<[llvm_v16i8_ty],
 [llvm_v16i8_ty, llvm_v16i8_ty],
 [IntrNoMem, IntrSpeculatable]>;
+def int_wasm_shuffle :
+  Intrinsic<[llvm_v16i8_ty],
+[llvm_v16i8_ty, llvm_v16i8_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty,
+ llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+[IntrNoMem, IntrSpeculatable]>;
 def int_wasm_sub_saturate_signed :
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>],
@@ -116,7 +123,6 @@
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>],
 [IntrNoMem, IntrSpeculatable]>;
-
 def int_wasm_bitselect :
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],
@@ -170,7 +176,6 @@
 [llvm_anyvector_ty],
 [IntrNoMem, IntrSpeculatable]>;
 
-
 //===--===//
 // Bulk memory intrinsics
 //===--===//
Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c

[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

Here's a slightly smaller variant which may be a good clue for tracking down 
the root cause. This one fails with:

  var.cc:6:14: error: no matching function for call to 'copysign'
double g = copysign(0, g);
   ^~~~
  var.cc:5:56: note: candidate template ignored: substitution failure [with e = 
int, f = double]: reference to __host__ variable 'b' in __device__ function
  __attribute__((device)) typename c::b, double>::d copysign(e, f) {
   ~ ^
  1 error generated when compiling for sm_60.

I suspect that it's handling of non-type template parameter that may be 
breaking things in both cases.

  template  struct a { static const bool b = true; };
  template  struct c;
  template  struct c { typedef h d; };
  template 
  __attribute__((device)) typename c::b, double>::d copysign(e, f) {
double g = copysign(0, g);
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D73307: Unique Names for Functions with Internal Linkage

2020-05-07 Thread Sriraman Tallam via Phabricator via cfe-commits
tmsriram updated this revision to Diff 262791.
tmsriram added a comment.

Rebase.


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

https://reviews.llvm.org/D73307

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/unique-internal-linkage-names.cpp
  clang/test/Driver/funique-internal-linkage-names.c

Index: clang/test/Driver/funique-internal-linkage-names.c
===
--- /dev/null
+++ clang/test/Driver/funique-internal-linkage-names.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### -funique-internal-linkage-names %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -funique-internal-linkage-names -fno-unique-internal-linkage-names %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// CHECK-OPT: "-funique-internal-linkage-names"
+// CHECK-NOOPT-NOT: "-funique-internal-linkage-names"
Index: clang/test/CodeGen/unique-internal-linkage-names.cpp
===
--- /dev/null
+++ clang/test/CodeGen/unique-internal-linkage-names.cpp
@@ -0,0 +1,61 @@
+// This test checks if internal linkage symbols get unique names with
+// -funique-internal-linkage-names option.
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -o - < %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
+// RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -fexperimental-new-pass-manager -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
+
+static int glob;
+static int foo() {
+  return 0;
+}
+
+int (*bar())() {
+  return foo;
+}
+
+int getGlob() {
+  return glob;
+}
+
+// Function local static variable and anonymous namespace namespace variable.
+namespace {
+int anon_m;
+int getM() {
+  return anon_m;
+}
+} // namespace
+
+int retAnonM() {
+  static int fGlob;
+  return getM() + fGlob;
+}
+
+// Multiversioning symbols
+__attribute__((target("default"))) static int mver() {
+  return 0;
+}
+
+__attribute__((target("sse4.2"))) static int mver() {
+  return 1;
+}
+
+int mver_call() {
+  return mver();
+}
+
+// PLAIN: @_ZL4glob = internal global
+// PLAIN: @_ZZ8retAnonMvE5fGlob = internal global
+// PLAIN: @_ZN12_GLOBAL__N_16anon_mE = internal global
+// PLAIN: define internal i32 @_ZL3foov()
+// PLAIN: define internal i32 @_ZN12_GLOBAL__N_14getMEv
+// PLAIN: define weak_odr i32 ()* @_ZL4mverv.resolver()
+// PLAIN: define internal i32 @_ZL4mverv()
+// PLAIN: define internal i32 @_ZL4mverv.sse4.2()
+// UNIQUE: @_ZL4glob.{{[0-9a-f]+}} = internal global
+// UNIQUE: @_ZZ8retAnonMvE5fGlob.{{[0-9a-f]+}} = internal global
+// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.{{[0-9a-f]+}} = internal global
+// UNIQUE: define internal i32 @_ZL3foov.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.{{[0-9a-f]+}}
+// UNIQUE: define weak_odr i32 ()* @_ZL4mverv.resolver()
+// UNIQUE: define internal i32 @_ZL4mverv.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.{{[0-9a-f]+}}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -957,6 +957,8 @@
   Opts.DataSections = Args.hasArg(OPT_fdata_sections);
   Opts.StackSizeSection = Args.hasArg(OPT_fstack_size_section);
   Opts.UniqueSectionNames = !Args.hasArg(OPT_fno_unique_section_names);
+  Opts.UniqueInternalLinkageNames =
+  Args.hasArg(OPT_funique_internal_linkage_names);
 
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1677,6 +1677,27 @@
on ELF targets when using the integrated assembler. This flag currently
only has an effect on ELF targets.
 
+**-f[no]-unique-internal-linkage-names**
+
+   Controls whether Clang emits a unique (best-effort) symbol name for internal
+   linkage symbols.  When this option is set, compiler hashes the main source
+   file path from the command line and appends it to all internal symbols. If a
+   program contains multiple objects compiled with the same command-line source
+   file path, the symbols are not guaranteed to be unique.  This option is
+   particularly useful in attributing profile information to the correct
+   function when multiple functions with the same private linkage name exist
+   in the binary.
+
+   It should be noted that this option cannot guarantee uniqueness and the
+   following is an example where it is not unique when two modules contain
+   symbols with the same private linkage name:
+
+   .. code-block:: console

[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D79344#2026180 , @tra wrote:

> The problem is reproducible in upstream clang. Let's see if I can reduce it 
> to something simpler.


Reduced it down to this -- compiles with clang w/o the patch, but fails with it.

  __attribute__((device)) double copysign(double, double);
  __attribute__((device)) double copysign(float, double);
  template  struct a { static const bool b = true; };
  template  struct c;
  template  struct c { typedef f g; };
  template 
  __attribute__((device)) typename c::b, double>::g copysign(d, h) {
double e = copysign(0, e);
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-07 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D79343#2025211 , @ldionne wrote:

> Regarding the formatting changes, I personally think we should clang-format 
> all of libc++, libc++abi and libunwind in one go. Then we'd be done with 
> these small issues that add up. And we can even add the revision to 
> `.git-blame-ignore-revs`.


(FWIW, that's what I think we should do with `llvm/` and `clang/` too...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79343



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


[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

In D79344#2026180 , @tra wrote:

> The problem is reproducible in upstream clang. Let's see if I can reduce it 
> to something simpler.


I remembered found similar errors when the math part is refactored out into the 
current but, later, it seems fixed. Not sure, it's relevant or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262779.
MyDeveloperDay added a comment.

Refactor the analyse function to reduce the function size


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

https://reviews.llvm.org/D69764

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/CMakeLists.txt
  clang/lib/Format/EastWestConstFixer.cpp
  clang/lib/Format/EastWestConstFixer.h
  clang/lib/Format/Format.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13097,6 +13097,11 @@
   CHECK_PARSE("ContinuationIndentWidth: 11", ContinuationIndentWidth, 11u);
   CHECK_PARSE("CommentPragmas: '// abc$'", CommentPragmas, "// abc$");
 
+  Style.ConstStyle = FormatStyle::CS_Left;
+  CHECK_PARSE("ConstStyle: Leave", ConstStyle, FormatStyle::CS_Leave);
+  CHECK_PARSE("ConstStyle: Right", ConstStyle, FormatStyle::CS_Right);
+  CHECK_PARSE("ConstStyle: Left", ConstStyle, FormatStyle::CS_Left);
+
   Style.PointerAlignment = FormatStyle::PAS_Middle;
   CHECK_PARSE("PointerAlignment: Left", PointerAlignment,
   FormatStyle::PAS_Left);
@@ -15849,6 +15854,194 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, EastWestConst) {
+  FormatStyle Style = getLLVMStyle();
+
+  // keep the const style unaltered
+  verifyFormat("const int a;", Style);
+  verifyFormat("const int *a;", Style);
+  verifyFormat("const int &a;", Style);
+  verifyFormat("const int &&a;", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const &b;", Style);
+  verifyFormat("int const &&b;", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("const Foo a;", Style);
+  verifyFormat("const Foo *a;", Style);
+  verifyFormat("const Foo &a;", Style);
+  verifyFormat("const Foo &&a;", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const &b;", Style);
+  verifyFormat("Foo const &&b;", Style);
+  verifyFormat("Foo const *b const;", Style);
+
+  verifyFormat("LLVM_NODISCARD const int &Foo();", Style);
+  verifyFormat("LLVM_NODISCARD int const &Foo();", Style);
+
+  verifyFormat("volatile const int *restrict;", Style);
+  verifyFormat("const volatile int *restrict;", Style);
+  verifyFormat("const int volatile *restrict;", Style);
+
+  Style.ConstStyle = FormatStyle::CS_Right;
+
+  verifyFormat("int const a;", Style);
+  verifyFormat("int const *a;", Style);
+  verifyFormat("int const &a;", Style);
+  verifyFormat("int const &&a;", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const &b;", Style);
+  verifyFormat("int const &&b;", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("Foo const a;", Style);
+  verifyFormat("Foo const *a;", Style);
+  verifyFormat("Foo const &a;", Style);
+  verifyFormat("Foo const &&a;", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const &b;", Style);
+  verifyFormat("Foo const &&b;", Style);
+  verifyFormat("Foo const *b const;", Style);
+  verifyFormat("Foo *const b;", Style);
+  verifyFormat("Foo const *const b;", Style);
+  verifyFormat("auto const v = get_value();", Style);
+  verifyFormat("long long const &a;", Style);
+  verifyFormat("unsigned char const *a;", Style);
+  verifyFormat("int main(int const argc, char const *const *const argv)",
+   Style);
+
+  verifyFormat("LLVM_NODISCARD int const &Foo();", Style);
+  verifyFormat("SourceRange getSourceRange() const override LLVM_READONLY",
+   Style);
+  verifyFormat("void foo() const override;", Style);
+  verifyFormat("void foo() const override LLVM_READONLY;", Style);
+  verifyFormat("void foo() const final;", Style);
+  verifyFormat("void foo() const final LLVM_READONLY;", Style);
+  verifyFormat("void foo() const LLVM_READONLY;", Style);
+
+  verifyFormat(
+  "template  explicit Action(Action const &action);",
+  Style);
+  verifyFormat(
+  "template  explicit Action(Action const &action);",
+  "template  explicit Action(const Action& action);",
+  Style);
+  verifyFormat(
+  "template  explicit Action(Action const &action);",
+  "template \nexplicit Action(const Action& action);",
+  Style);
+
+  verifyFormat("int const a;", "const int a;", Style);
+  verifyFormat("int const *a;", "const int *a;", Style);
+  verifyFormat("int const &a;", "const int &a;", Style);
+  verifyFormat("foo(int const &a)", "foo(const int &a)", Style);
+  verifyFormat("unsigned char *a;", "unsigned char *

[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262772.
MyDeveloperDay added a comment.

remove macros from the unit tests


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

https://reviews.llvm.org/D69764

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/CMakeLists.txt
  clang/lib/Format/EastWestConstFixer.cpp
  clang/lib/Format/EastWestConstFixer.h
  clang/lib/Format/Format.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13097,6 +13097,11 @@
   CHECK_PARSE("ContinuationIndentWidth: 11", ContinuationIndentWidth, 11u);
   CHECK_PARSE("CommentPragmas: '// abc$'", CommentPragmas, "// abc$");
 
+  Style.ConstStyle = FormatStyle::CS_Left;
+  CHECK_PARSE("ConstStyle: Leave", ConstStyle, FormatStyle::CS_Leave);
+  CHECK_PARSE("ConstStyle: Right", ConstStyle, FormatStyle::CS_Right);
+  CHECK_PARSE("ConstStyle: Left", ConstStyle, FormatStyle::CS_Left);
+
   Style.PointerAlignment = FormatStyle::PAS_Middle;
   CHECK_PARSE("PointerAlignment: Left", PointerAlignment,
   FormatStyle::PAS_Left);
@@ -15849,6 +15854,194 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, EastWestConst) {
+  FormatStyle Style = getLLVMStyle();
+
+  // keep the const style unaltered
+  verifyFormat("const int a;", Style);
+  verifyFormat("const int *a;", Style);
+  verifyFormat("const int &a;", Style);
+  verifyFormat("const int &&a;", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const &b;", Style);
+  verifyFormat("int const &&b;", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("const Foo a;", Style);
+  verifyFormat("const Foo *a;", Style);
+  verifyFormat("const Foo &a;", Style);
+  verifyFormat("const Foo &&a;", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const &b;", Style);
+  verifyFormat("Foo const &&b;", Style);
+  verifyFormat("Foo const *b const;", Style);
+
+  verifyFormat("LLVM_NODISCARD const int &Foo();", Style);
+  verifyFormat("LLVM_NODISCARD int const &Foo();", Style);
+
+  verifyFormat("volatile const int *restrict;", Style);
+  verifyFormat("const volatile int *restrict;", Style);
+  verifyFormat("const int volatile *restrict;", Style);
+
+  Style.ConstStyle = FormatStyle::CS_Right;
+
+  verifyFormat("int const a;", Style);
+  verifyFormat("int const *a;", Style);
+  verifyFormat("int const &a;", Style);
+  verifyFormat("int const &&a;", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const &b;", Style);
+  verifyFormat("int const &&b;", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("Foo const a;", Style);
+  verifyFormat("Foo const *a;", Style);
+  verifyFormat("Foo const &a;", Style);
+  verifyFormat("Foo const &&a;", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const &b;", Style);
+  verifyFormat("Foo const &&b;", Style);
+  verifyFormat("Foo const *b const;", Style);
+  verifyFormat("Foo *const b;", Style);
+  verifyFormat("Foo const *const b;", Style);
+  verifyFormat("auto const v = get_value();", Style);
+  verifyFormat("long long const &a;", Style);
+  verifyFormat("unsigned char const *a;", Style);
+  verifyFormat("int main(int const argc, char const *const *const argv)",
+   Style);
+
+  verifyFormat("LLVM_NODISCARD int const &Foo();", Style);
+  verifyFormat("SourceRange getSourceRange() const override LLVM_READONLY",
+   Style);
+  verifyFormat("void foo() const override;", Style);
+  verifyFormat("void foo() const override LLVM_READONLY;", Style);
+  verifyFormat("void foo() const final;", Style);
+  verifyFormat("void foo() const final LLVM_READONLY;", Style);
+  verifyFormat("void foo() const LLVM_READONLY;", Style);
+
+  verifyFormat(
+  "template  explicit Action(Action const &action);",
+  Style);
+  verifyFormat(
+  "template  explicit Action(Action const &action);",
+  "template  explicit Action(const Action& action);",
+  Style);
+  verifyFormat(
+  "template  explicit Action(Action const &action);",
+  "template \nexplicit Action(const Action& action);",
+  Style);
+
+  verifyFormat("int const a;", "const int a;", Style);
+  verifyFormat("int const *a;", "const int *a;", Style);
+  verifyFormat("int const &a;", "const int &a;", Style);
+  verifyFormat("foo(int const &a)", "foo(const int &a)", Style);
+  verifyFormat("unsigned char *a;", "unsigned char *a;", Style);
+  verifyFo

[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

The problem is reproducible in upstream clang. Let's see if I can reduce it to 
something simpler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262768.
MyDeveloperDay added a comment.

I'm returning to this revision which I'd left to think about, this update is 
really just a rebase and also to remove the dual configuation.

For now I will still with just Left/Right const to avoid confusion.

I'm going to start to review address some of the other review comments next.


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

https://reviews.llvm.org/D69764

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/CMakeLists.txt
  clang/lib/Format/EastWestConstFixer.cpp
  clang/lib/Format/EastWestConstFixer.h
  clang/lib/Format/Format.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -27,6 +27,10 @@
 
 FormatStyle getGoogleStyle() { return getGoogleStyle(FormatStyle::LK_Cpp); }
 
+#define VERIFYFORMAT(expect, style) verifyFormat(expect, style, __LINE__)
+#define VERIFYFORMAT2(expect, actual, style)   \
+  verifyFormat(expect, actual, style, __LINE__)
+
 class FormatTest : public ::testing::Test {
 protected:
   enum StatusCheck { SC_ExpectComplete, SC_ExpectIncomplete, SC_DoNotCheck };
@@ -66,10 +70,12 @@
   }
 
   void verifyFormat(llvm::StringRef Expected, llvm::StringRef Code,
-const FormatStyle &Style = getLLVMStyle()) {
+const FormatStyle &Style = getLLVMStyle(),
+int line = __LINE__) {
 EXPECT_EQ(Expected.str(), format(Expected, Style))
-<< "Expected code is not stable";
-EXPECT_EQ(Expected.str(), format(Code, Style));
+<< "Expected code is not stable at " << __FILE__ << ":" << line;
+EXPECT_EQ(Expected.str(), format(Code, Style))
+<< " at " << __FILE__ << ":" << line;
 if (Style.Language == FormatStyle::LK_Cpp) {
   // Objective-C++ is a superset of C++, so everything checked for C++
   // needs to be checked for Objective-C++ as well.
@@ -80,8 +86,9 @@
   }
 
   void verifyFormat(llvm::StringRef Code,
-const FormatStyle &Style = getLLVMStyle()) {
-verifyFormat(Code, test::messUp(Code), Style);
+const FormatStyle &Style = getLLVMStyle(),
+int line = __LINE__) {
+verifyFormat(Code, test::messUp(Code), Style, line);
   }
 
   void verifyIncompleteFormat(llvm::StringRef Code,
@@ -13097,6 +13104,11 @@
   CHECK_PARSE("ContinuationIndentWidth: 11", ContinuationIndentWidth, 11u);
   CHECK_PARSE("CommentPragmas: '// abc$'", CommentPragmas, "// abc$");
 
+  Style.ConstStyle = FormatStyle::CS_Left;
+  CHECK_PARSE("ConstStyle: Leave", ConstStyle, FormatStyle::CS_Leave);
+  CHECK_PARSE("ConstStyle: Right", ConstStyle, FormatStyle::CS_Right);
+  CHECK_PARSE("ConstStyle: Left", ConstStyle, FormatStyle::CS_Left);
+
   Style.PointerAlignment = FormatStyle::PAS_Middle;
   CHECK_PARSE("PointerAlignment: Left", PointerAlignment,
   FormatStyle::PAS_Left);
@@ -15849,6 +15861,194 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, EastWestConst) {
+  FormatStyle Style = getLLVMStyle();
+
+  // keep the const style unaltered
+  VERIFYFORMAT("const int a;", Style);
+  VERIFYFORMAT("const int *a;", Style);
+  VERIFYFORMAT("const int &a;", Style);
+  VERIFYFORMAT("const int &&a;", Style);
+  VERIFYFORMAT("int const b;", Style);
+  VERIFYFORMAT("int const *b;", Style);
+  VERIFYFORMAT("int const &b;", Style);
+  VERIFYFORMAT("int const &&b;", Style);
+  VERIFYFORMAT("int const *b const;", Style);
+  VERIFYFORMAT("int *const c;", Style);
+
+  VERIFYFORMAT("const Foo a;", Style);
+  VERIFYFORMAT("const Foo *a;", Style);
+  VERIFYFORMAT("const Foo &a;", Style);
+  VERIFYFORMAT("const Foo &&a;", Style);
+  VERIFYFORMAT("Foo const b;", Style);
+  VERIFYFORMAT("Foo const *b;", Style);
+  VERIFYFORMAT("Foo const &b;", Style);
+  VERIFYFORMAT("Foo const &&b;", Style);
+  VERIFYFORMAT("Foo const *b const;", Style);
+
+  VERIFYFORMAT("LLVM_NODISCARD const int &Foo();", Style);
+  VERIFYFORMAT("LLVM_NODISCARD int const &Foo();", Style);
+
+  VERIFYFORMAT("volatile const int *restrict;", Style);
+  VERIFYFORMAT("const volatile int *restrict;", Style);
+  VERIFYFORMAT("const int volatile *restrict;", Style);
+
+  Style.ConstStyle = FormatStyle::CS_Right;
+
+  VERIFYFORMAT("int const a;", Style);
+  VERIFYFORMAT("int const *a;", Style);
+  VERIFYFORMAT("int const &a;", Style);
+  VERIFYFORMAT("int const &&a;", Style);
+  VERIFYFORMAT("int const b;", Style);
+  VERIFYFORMAT("int const *b;", Style);
+  VERIFYFORMAT("int const &b;", Style);
+  VERIFYFORMAT("int const &&b;", Style);
+  VERIFYFORMAT("int const *b const;", Style);
+  VERIFYFORMAT("int *const c;", Style);

[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D79344#2026126 , @hliao wrote:

> In D79344#2026025 , @tra wrote:
>
> > We're calling `copysign( int, double)`. The standard library provides 
> > `copysign(double, double)`, CUDA provides only `copysign(float, double)`.  
> > As far as C++ is concerned, both require one type conversion. I guess 
> > previously we would give `__device__` one provided by CUDA a higher 
> > preference, considering that the callee is a device function. Now both seem 
> > to have equal weight. I'm not sure how/why,
>
>
> @yaxunl, that may be related to the change of overload resolution. Back to 
> this change, that error should not be related to the non-local variable 
> checks.


The tree I've tested had Sam's changes reverted 
(bf6a26b066382e0f41bf023c781d84061c542307 
), so it 
appears to be triggered by this patch. Let me try reproducing it in the 
upstream HEAD.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D79588: [llvm][Support] Use std::atomic for llvm::call_once

2020-05-07 Thread JF Bastien via Phabricator via cfe-commits
jfb added a subscriber: brad.
jfb added a comment.

is this code still relevant?

  #if defined(_MSC_VER)
  // MSVC's call_once implementation worked since VS 2015, which is the minimum
  // supported version as of this writing.
  #define LLVM_THREADING_USE_STD_CALL_ONCE 1
  #elif defined(LLVM_ON_UNIX) &&
 \
  (defined(_LIBCPP_VERSION) ||  
 \
   !(defined(__NetBSD__) || defined(__OpenBSD__) || 
 \
 (defined(__ppc__) || defined(__PPC__
  // std::call_once from libc++ is used on all Unix platforms. Other
  // implementations like libstdc++ are known to have problems on NetBSD,
  // OpenBSD and PowerPC.
  #define LLVM_THREADING_USE_STD_CALL_ONCE 1
  #elif defined(LLVM_ON_UNIX) &&
 \
  ((defined(__ppc__) || defined(__PPC__)) && defined(__LITTLE_ENDIAN__))
  #define LLVM_THREADING_USE_STD_CALL_ONCE 1
  #else
  #define LLVM_THREADING_USE_STD_CALL_ONCE 0
  #endif

Seems like something that's probably aged out? Check with @brad since it's from 
2016 in b4f6ebf80695. What's the actual problem?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79588



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


[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

In D79344#2026025 , @tra wrote:

> We're calling `copysign( int, double)`. The standard library provides 
> `copysign(double, double)`, CUDA provides only `copysign(float, double)`.  As 
> far as C++ is concerned, both require one type conversion. I guess previously 
> we would give `__device__` one provided by CUDA a higher preference, 
> considering that the callee is a device function. Now both seem to have equal 
> weight. I'm not sure how/why,


@yaxunl, that may be related to the change of overload resolution. Back to this 
change, that error should not be related to the non-local variable checks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D79477: [clang-tidy] Add --use-color command line option and UseColor option to control colors in diagnostics

2020-05-07 Thread Nathan James via Phabricator via cfe-commits
njames93 added inline comments.



Comment at: clang-tools-extra/clang-tidy/ClangTidyOptions.cpp:99
 IO.mapOptional("InheritParentConfig", Options.InheritParentConfig);
+IO.mapOptional("UseColor", Options.UseColor);
   }

I'm not entirely sure this option belongs in the config file. However if it 
will get read in here, maybe update the help string for the command line option 
to say it overrides the `UseColor` option from the `.clang-tidy` configuration 
file.


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

https://reviews.llvm.org/D79477



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


[PATCH] D79588: [llvm][Support] Use std::atomic for llvm::call_once

2020-05-07 Thread Eli Friedman via Phabricator via cfe-commits
efriedma requested changes to this revision.
efriedma added a comment.
This revision now requires changes to proceed.

This code is basically untested; I'd rather not touch it until we eventually 
kill it off.  (See the definition of LLVM_THREADING_USE_STD_CALL_ONCE.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79588



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


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

2020-05-07 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2143
+return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,
+ DimExpr, Info, Deduced);
+} else if (const ConstantMatrixType *ConstantMatrixArg =

fhahn wrote:
> rjmccall wrote:
> > fhahn wrote:
> > > rjmccall wrote:
> > > > fhahn wrote:
> > > > > rjmccall wrote:
> > > > > > I'm curious why this extra check is necessary vs. just calling 
> > > > > > `DeduceNonTypeTemplateArgument` with `DimExpr` unconditionally.
> > > > > The code can indeed be quite simplified if we can get a row/column 
> > > > > expression for ConstantMatrixType as well. 
> > > > > 
> > > > > I've refactored the code to also keep the original row/column 
> > > > > expression in ConstantMatrixType. The new code here is much more 
> > > > > compact as the cost of increasing the size of ConstantMatrixType. I 
> > > > > am not sure if the bigger size is a concern, but I would expect that 
> > > > > it would not matter much in practice. 
> > > > > 
> > > > > If it is not a concern, I would further refactor the code and move 
> > > > > the expressions to MatrixType (which would further simplify the 
> > > > > lambdas here). The main difference between ConstantMatrixType and 
> > > > > DependentSizedMatrixType would be that ConstantMatrixTpye would also 
> > > > > store the dimensions as integers (for easier/faster access). What do 
> > > > > you think?
> > > > > 
> > > > > Alternatively we could potentially construct a new ConstantExpr from 
> > > > > the integer dimensions in the lambda. Or keep the more clunky 
> > > > > accessor lambdas.
> > > > Eh, I'm torn about storing the expressions in `ConstantMatrixType`.  
> > > > It's probably true that we wouldn't have a ton of these types and so 
> > > > the overall overhead might be negligible.  However, I think that if we 
> > > > choose to represent things this way, we probably ought to make 
> > > > "pristine" new `IntegerLiteral` expressions instead of remembering the 
> > > > original expressions, because we don't want weird syntactic quirks of 
> > > > the first matrix type we see to become embedded in the type forever.  
> > > > We also run the risk of actually propagating those expressions around 
> > > > and getting bad diagnostics that point unexpectedly back at the first 
> > > > place that wrote a matrix type (or at the null location of a pristine 
> > > > literal) because of uniquing.  So I think it might be better to just 
> > > > continue to define away those problems by not storing expressions.
> > > Sounds good to me. Should I update the code here to use the separate 
> > > lambdas again or would you prefer creating temporary expressions for the 
> > > integer case?
> > I think I would prefer lambdas (or member pointers).
> Done, I've removed them again. The code with member pointers seems relatively 
> nice, given the circumstances IMO
Thanks, this looks great.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262764.
MyDeveloperDay added a comment.

Address review comments and ensure existence of closing `]`


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

https://reviews.llvm.org/D79354

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7647,6 +7647,10 @@
   verifyFormat("void f() [[deprecated(\"so sorry\")]];");
   verifyFormat("aa\n"
"[[unused]] aaa(int i);");
+  verifyFormat("[[nodiscard]] bool f() { return false; }");
+  verifyFormat("class [[nodiscard]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[deprecated(\"so sorry\")]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[gnu::unused]] f {\npublic:\n  f() {}\n}");
 
   // Make sure we do not mistake attributes for array subscripts.
   verifyFormat("int a() {}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2399,9 +2399,10 @@
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier.
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, TT_AttributeSquare) ||
  ((Style.Language == FormatStyle::LK_Java ||
Style.Language == FormatStyle::LK_JavaScript) &&
   FormatTok->isOneOf(tok::period, tok::comma))) {
@@ -2421,8 +2422,16 @@
 FormatTok->TokenText != FormatTok->TokenText.upper();
 nextToken();
 // We can have macros or attributes in between 'class' and the class name.
-if (!IsNonMacroIdentifier && FormatTok->Tok.is(tok::l_paren))
-  parseParens();
+if (!IsNonMacroIdentifier) {
+  if (FormatTok->Tok.is(tok::l_paren)) {
+parseParens();
+  } else if (FormatTok->is(TT_AttributeSquare)) {
+parseSquare();
+// Consume the closing TT_AttributeSquare.
+if (FormatTok->Next && FormatTok->is(TT_AttributeSquare))
+  nextToken();
+  }
+}
   }
 
   // Note that parsing away template declarations here leads to incorrectly


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7647,6 +7647,10 @@
   verifyFormat("void f() [[deprecated(\"so sorry\")]];");
   verifyFormat("aa\n"
"[[unused]] aaa(int i);");
+  verifyFormat("[[nodiscard]] bool f() { return false; }");
+  verifyFormat("class [[nodiscard]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[deprecated(\"so sorry\")]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[gnu::unused]] f {\npublic:\n  f() {}\n}");
 
   // Make sure we do not mistake attributes for array subscripts.
   verifyFormat("int a() {}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2399,9 +2399,10 @@
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier.
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, TT_AttributeSquare) ||
  ((Style.Language == FormatStyle::LK_Java ||
Style.Language == FormatStyle::LK_JavaScript) &&
   FormatTok->isOneOf(tok::period, tok::comma))) {
@@ -2421,8 +2422,16 @@
 FormatTok->TokenText != FormatTok->TokenText.upper();
 nextToken();
 // We can have macros or attributes in between 'class' and the class name.
-if (!IsNonMacroIdentifier && FormatTok->Tok.is(tok::l_paren))
-  parseParens();
+if (!IsNonMacroIdentifier) {
+  if (FormatTok->Tok.is(tok::l_paren)) {
+parseParens();
+  } else if (FormatTok->is(TT_AttributeSquare)) {
+parseSquare();
+// Consume the closing TT_AttributeSquare.
+if (FormatTok->Next && FormatTok->is(TT_AttributeSquare))
+  nextToken();
+  }
+}
   }
 
   // Note that parsing away template declarations here leads to incorrectly
__

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2431
+// Consume the closing TT_AttributeSquare.
+nextToken();
+  }

krasimir wrote:
> slight concern: check if the next token is `TT_AttributeSquare` and only 
> consume it in that case. Other languages that are using `TT_AttributeSquare` 
> may have a different syntax for their attributes than `[[attribute]]`, e.g. 
> recently added [[ 
> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/
>  | C# `[attributes]` ]].
I agree, in fact I had the same concern myself, I kind of assumed because we'd 
of seen

`[[  `]`  then it would be obvious that the next would be `]`

But on  reflection I think it could potentially be other things too


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

https://reviews.llvm.org/D79354



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


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

2020-05-07 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2143
+return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,
+ DimExpr, Info, Deduced);
+} else if (const ConstantMatrixType *ConstantMatrixArg =

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > fhahn wrote:
> > > > rjmccall wrote:
> > > > > I'm curious why this extra check is necessary vs. just calling 
> > > > > `DeduceNonTypeTemplateArgument` with `DimExpr` unconditionally.
> > > > The code can indeed be quite simplified if we can get a row/column 
> > > > expression for ConstantMatrixType as well. 
> > > > 
> > > > I've refactored the code to also keep the original row/column 
> > > > expression in ConstantMatrixType. The new code here is much more 
> > > > compact as the cost of increasing the size of ConstantMatrixType. I am 
> > > > not sure if the bigger size is a concern, but I would expect that it 
> > > > would not matter much in practice. 
> > > > 
> > > > If it is not a concern, I would further refactor the code and move the 
> > > > expressions to MatrixType (which would further simplify the lambdas 
> > > > here). The main difference between ConstantMatrixType and 
> > > > DependentSizedMatrixType would be that ConstantMatrixTpye would also 
> > > > store the dimensions as integers (for easier/faster access). What do 
> > > > you think?
> > > > 
> > > > Alternatively we could potentially construct a new ConstantExpr from 
> > > > the integer dimensions in the lambda. Or keep the more clunky accessor 
> > > > lambdas.
> > > Eh, I'm torn about storing the expressions in `ConstantMatrixType`.  It's 
> > > probably true that we wouldn't have a ton of these types and so the 
> > > overall overhead might be negligible.  However, I think that if we choose 
> > > to represent things this way, we probably ought to make "pristine" new 
> > > `IntegerLiteral` expressions instead of remembering the original 
> > > expressions, because we don't want weird syntactic quirks of the first 
> > > matrix type we see to become embedded in the type forever.  We also run 
> > > the risk of actually propagating those expressions around and getting bad 
> > > diagnostics that point unexpectedly back at the first place that wrote a 
> > > matrix type (or at the null location of a pristine literal) because of 
> > > uniquing.  So I think it might be better to just continue to define away 
> > > those problems by not storing expressions.
> > Sounds good to me. Should I update the code here to use the separate 
> > lambdas again or would you prefer creating temporary expressions for the 
> > integer case?
> I think I would prefer lambdas (or member pointers).
Done, I've removed them again. The code with member pointers seems relatively 
nice, given the circumstances IMO


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a4ddbd69db2: [clang-format] [PR45639] clang-format splits 
up the brackets of C++17 attribute… (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79401

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7672,6 +7672,19 @@
MultiLineFunctions);
 }
 
+TEST_F(FormatTest, AttributePenaltyBreaking) {
+  FormatStyle Style = getLLVMStyle();
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJKLMN(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJK(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGH([[maybe_unused]] const "
+   "shared_ptr &C d) {\n}",
+   Style);
+}
+
 TEST_F(FormatTest, UnderstandsEllipsis) {
   verifyFormat("int printf(const char *fmt, ...);");
   verifyFormat("template  void Foo(Ts... ts) { Foo(ts...); }");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3888,7 +3888,7 @@
 
   if (Right.is(tok::kw___attribute) ||
   (Right.is(tok::l_square) && Right.is(TT_AttributeSquare)))
-return true;
+return !Left.is(TT_AttributeSquare);
 
   if (Left.is(tok::identifier) && Right.is(tok::string_literal))
 return true;


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7672,6 +7672,19 @@
MultiLineFunctions);
 }
 
+TEST_F(FormatTest, AttributePenaltyBreaking) {
+  FormatStyle Style = getLLVMStyle();
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJKLMN(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJK(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGH([[maybe_unused]] const "
+   "shared_ptr &C d) {\n}",
+   Style);
+}
+
 TEST_F(FormatTest, UnderstandsEllipsis) {
   verifyFormat("int printf(const char *fmt, ...);");
   verifyFormat("template  void Foo(Ts... ts) { Foo(ts...); }");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3888,7 +3888,7 @@
 
   if (Right.is(tok::kw___attribute) ||
   (Right.is(tok::l_square) && Right.is(TT_AttributeSquare)))
-return true;
+return !Left.is(TT_AttributeSquare);
 
   if (Left.is(tok::identifier) && Right.is(tok::string_literal))
 return true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D62368: Add vendor identity check for Hygon Dhyana processor in Scudo

2020-05-07 Thread Kostya Kortchinsky via Phabricator via cfe-commits
cryptoad added a comment.

A couple of style issues to address.




Comment at: compiler-rt/lib/scudo/scudo_utils.cpp:66
+
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */

s/the gcc/gcc/



Comment at: compiler-rt/lib/scudo/scudo_utils.cpp:67
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */
+#define signature_HYGON_ebx 0x6f677948

Please use C++-style comments 
(https://llvm.org/docs/CodingStandards.html#comment-formatting)



Comment at: compiler-rt/lib/scudo/standalone/checksum.cpp:34
 
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */

s/the gcc/gcc



Comment at: compiler-rt/lib/scudo/standalone/checksum.cpp:35
+#ifndef signature_HYGON_ebx // They are not defined in the gcc.
+/* HYGON:   "HygonGenuine" */
+#define signature_HYGON_ebx 0x6f677948

Please use C++-style comments 
(https://llvm.org/docs/CodingStandards.html#comment-formatting)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62368



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


[PATCH] D79599: Add a flag that controls if clang-tidy and clang-include-fixer are built into libclang.

2020-05-07 Thread Nico Weber via Phabricator via cfe-commits
thakis created this revision.
thakis added a reviewer: bkramer.
Herald added subscribers: llvm-commits, mgorny.
Herald added a project: LLVM.

Based on the discussion on D55415 , also make 
the flag default to false.
Having libclang depend on clang-tools-extra means check-clang builds all
of clang-tools-extra, which besides being a layering violation takes
quite some time, since clang-tools-extra has many files that are slow
to compile.

Longer term, we likely will want to remove this flag completely. If
people need this functionality, maybe there could be a
libclang-tools-extra that's libclang + clang-tidy and
clang-includes-fixer linked in.


https://reviews.llvm.org/D79599

Files:
  clang/tools/libclang/CMakeLists.txt
  llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn


Index: llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
+++ llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
@@ -9,6 +9,11 @@
 #   in the CMake build), so libclang is always a static library on linux
 # - the GN build doesn't have LIBCLANG_BUILD_STATIC
 
+declare_args() {
+  # Whether to include code from clang-tools-extra in libclang.
+  libclang_include_clang_tools_extra = false
+}
+
 libclang_target_type = "shared_library"
 if (host_os != "win" && host_os != "mac") {
   # ELF targets need -fPIC to build shared libs but they aren't on by default.
@@ -41,9 +46,7 @@
 
   # FIXME: Once the GN build has a way to select which bits to build,
   # only include this dependency if clang-tools-extra is part of the build.
-  # FIXME: libclang depending on anything in clang-tools-extra seems like
-  # a layering violation.
-  if (true) {
+  if (libclang_include_clang_tools_extra) {
 defines += [ "CLANG_TOOL_EXTRA_BUILD" ]
 deps += [
   "//clang-tools-extra/clang-include-fixer/plugin",
Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -50,13 +50,20 @@
   list(APPEND LIBS clangARCMigrate)
 endif ()
 
-if (TARGET clangTidyPlugin)
-  add_definitions(-DCLANG_TOOL_EXTRA_BUILD)
-  list(APPEND LIBS clangTidyPlugin)
-  list(APPEND LIBS clangIncludeFixerPlugin)
-  if(LLVM_ENABLE_MODULES)
-list(APPEND LLVM_COMPILE_FLAGS 
"-fmodules-ignore-macro=CLANG_TOOL_EXTRA_BUILD")
-  endif()
+option(LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA
+  "Include code from clang-tools-extra in libclang." OFF)
+
+if (LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA)
+  if (TARGET clangTidyPlugin)
+add_definitions(-DCLANG_TOOL_EXTRA_BUILD)
+list(APPEND LIBS clangTidyPlugin)
+list(APPEND LIBS clangIncludeFixerPlugin)
+if(LLVM_ENABLE_MODULES)
+  list(APPEND LLVM_COMPILE_FLAGS 
"-fmodules-ignore-macro=CLANG_TOOL_EXTRA_BUILD")
+endif()
+  else ()
+message(FATAL_ERROR "LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA needs 
clang-tools-extra in LLVM_BUILD_PROJECTS")
+  endif ()
 endif ()
 
 find_library(DL_LIBRARY_PATH dl)


Index: llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
+++ llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
@@ -9,6 +9,11 @@
 #   in the CMake build), so libclang is always a static library on linux
 # - the GN build doesn't have LIBCLANG_BUILD_STATIC
 
+declare_args() {
+  # Whether to include code from clang-tools-extra in libclang.
+  libclang_include_clang_tools_extra = false
+}
+
 libclang_target_type = "shared_library"
 if (host_os != "win" && host_os != "mac") {
   # ELF targets need -fPIC to build shared libs but they aren't on by default.
@@ -41,9 +46,7 @@
 
   # FIXME: Once the GN build has a way to select which bits to build,
   # only include this dependency if clang-tools-extra is part of the build.
-  # FIXME: libclang depending on anything in clang-tools-extra seems like
-  # a layering violation.
-  if (true) {
+  if (libclang_include_clang_tools_extra) {
 defines += [ "CLANG_TOOL_EXTRA_BUILD" ]
 deps += [
   "//clang-tools-extra/clang-include-fixer/plugin",
Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -50,13 +50,20 @@
   list(APPEND LIBS clangARCMigrate)
 endif ()
 
-if (TARGET clangTidyPlugin)
-  add_definitions(-DCLANG_TOOL_EXTRA_BUILD)
-  list(APPEND LIBS clangTidyPlugin)
-  list(APPEND LIBS clangIncludeFixerPlugin)
-  if(LLVM_ENABLE_MODULES)
-list(APPEND LLVM_COMPILE_FLAGS "-fmodules-ignore-macro=CLANG_TOOL_EXTRA_BUILD")
-  endif()
+option(LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA
+  "Include code from clang-tools-extra in libclang." OFF)
+
+if (LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA)
+  if (TARGET clangTidyPlugin)
+add_definitions(-DCL

[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

We're calling `copysign( int, double)`. The standard library provides 
`copysign(double, double)`, CUDA provides only `copysign(float, double)`.  As 
far as C++ is concerned, both require one type conversion. I guess previously 
we would give `__device__` one provided by CUDA a higher preference, 
considering that the callee is a device function. Now both seem to have equal 
weight. I'm not sure how/why,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

2020-05-07 Thread Matthew Riley via Phabricator via cfe-commits
mattdr added a comment.

Calling special attention to the comment at line 341, since I think it affects 
the correctness of the pass.




Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:287
+  // The `Transmitters` map memoizes transmitters found for each def. If a def
+  // has not yet been analyzed, then its list of transmitters will be empty.
+  DenseMap> Transmitters;

This comment doesn't seem to match how the map is used -- it looks like the 
loop assumes a def has been analyzed iff it is present in the map. This matches 
my expectation that, if a def is present and maps to an empty list, it would 
meant the def **had** been analyzed and found not to transmit.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:295
+std::function)> AnalyzeDefUseChain =
+[&](NodeAddr Def) {
+  if (Transmitters.find(Def.Id) != Transmitters.end())

fwiw, this code would be easier to understand if we didn't shadow `Def` with 
another variable named `Def`.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:321-322
+  for (auto UseID : Uses) {
+if (!UsesVisited.insert(UseID).second)
+  continue; // Already visited this use of the current def
+

"current def" is a bit ambiguous here. I _believe_ it means `AnalyzeDef`'s 
`Def` argument? At least, that's the interpretation that makes the comment make 
sense since `UsesVisited` is in `AnalyzeDef`'s scope.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:331
+// We naively assume that an instruction propagates any loaded
+// Uses to all Defs, unless the instruction is a call.
+if (UseMI.isCall())

Copying a comment from a previous iteration:

> Why is it okay to assume that a call doesn't propagate its uses to defs? Is 
> it because we can assume the CFI transform is already inserting an LFENCE? 
> Whatever the reason, let's state it explicitly here




Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:341
+  if (UseMI.mayLoad())
+continue; // Found a transmitting load, stop traversing defs
+}

The comment doesn't match the loop, which is traversing over `Uses`. More 
importantly, though: why are we allowed to stop traversing through `Uses` here? 
This `Def` won't be analyzed again, so this is our only chance to enumerate all 
transmitters to make sure we have all the necessary source -> sink edges in the 
gadget graph.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:364-365
+
+  // Remove duplicate transmitters
+  auto &DefTransmitters = Transmitters[Def.Id];
+  llvm::sort(DefTransmitters);

This is also the place we populate `Transmitters` (with a default-constructed 
vector) for the current def if we haven't otherwise found any transmits. That's 
good, and necessary for `Transmitters` to remember we've analyzed the current 
def. But we should leave a comment about this subtle load-bearing side-effect.



Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:366-369
+  llvm::sort(DefTransmitters);
+  DefTransmitters.erase(
+  std::unique(DefTransmitters.begin(), DefTransmitters.end()),
+  DefTransmitters.end());

Should `Transmitters` map to an `llvm::SmallSet`?


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

https://reviews.llvm.org/D75936



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


[PATCH] D72893: [NewPassManager] Add assertions when getting statefull cached analysis.

2020-05-07 Thread Alina Sbirlea via Phabricator via cfe-commits
asbirlea added a comment.

Weekly re-ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72893



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


[PATCH] D78655: [HIP] Add -fhip-lambda-host-device

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D78655#2020651 , @tra wrote:

> Ack. Let's give it a try. I'll test this on our code and see what falls out. 
> Stay tuned.


The patch seems to cause no issues. I've ran it with local changes that enable 
it unconditionally for CUDA. I'm OK with making this the default behavior.


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

https://reviews.llvm.org/D78655



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


[PATCH] D79344: [cuda] Start diagnosing variables with bad target.

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D79344#2018915 , @tra wrote:

> If you can wait, I can try patching this change into our clang tree and then 
> see if it breaks anything obvious. If nothing falls apart, I'll be fine with 
> the patch as is.


The patch appears to break compilation of CUDA headers:

  In file included from :1:
  In file included from 
llvm_unstable/toolchain/lib/clang/google3-trunk/include/__clang_cuda_runtime_wrapper.h:406:
  
llvm_unstable/toolchain/lib/clang/google3-trunk/include/__clang_cuda_complex_builtins.h:30:13:
 error: call to 'copysign' is ambiguous
__a = std::copysign(std::isinf(__a) ? 1 : 0, __a);
  ^
  
llvm_unstable/toolchain/lib/clang/google3-trunk/include/__clang_cuda_math.h:76:19:
 note: candidate function
  __DEVICE__ double copysign(double __a, double __b) {
^
  third_party/gpus/cuda_10_1/include/crt/math_functions.hpp:861:32: note: 
candidate function
  __MATH_FUNCTIONS_DECL__ double copysign(float a, double b)
 ^
  1 error generated when compiling for sm_60.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79344



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


[clang] 5a4ddbd - [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

2020-05-07 Thread via cfe-commits

Author: mydeveloperday
Date: 2020-05-07T22:00:04+01:00
New Revision: 5a4ddbd69db2b0e09398214510501d0e59a0c30b

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

LOG: [clang-format] [PR45639] clang-format splits up the brackets of C++17 
attribute [[ ]] when used with the first parameter

Summary:
https://bugs.llvm.org/show_bug.cgi?id=45639

clang-format incorrectly splits the `[[` in a long argument list

```
void SomeLongClassName::ALongMethodNameInThatClass([[maybe_unused]] const 
shared_ptr& argumentNameForThat
LongType) {

}
```

becomes

```
void SomeLongClassName::ALongMethodNameInThatClass([
[maybe_unused]] const shared_ptr 
&argumentNameForThatLongType) {

}
```

leaving one `[` on the previous line

For a function with just 1 very long argument, clang-format chooses to split 
between the `[[`,

This revision prevents the slip between the two `[` and the second `[`

Reviewed By: krasimir

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 408f68e35418..216ae984c67a 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -3888,7 +3888,7 @@ bool TokenAnnotator::canBreakBefore(const AnnotatedLine 
&Line,
 
   if (Right.is(tok::kw___attribute) ||
   (Right.is(tok::l_square) && Right.is(TT_AttributeSquare)))
-return true;
+return !Left.is(TT_AttributeSquare);
 
   if (Left.is(tok::identifier) && Right.is(tok::string_literal))
 return true;

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 86eeb2705595..9a654d66250c 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -7672,6 +7672,19 @@ TEST_F(FormatTest, UnderstandsSquareAttributes) {
MultiLineFunctions);
 }
 
+TEST_F(FormatTest, AttributePenaltyBreaking) {
+  FormatStyle Style = getLLVMStyle();
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJKLMN(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJK(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGH([[maybe_unused]] const "
+   "shared_ptr &C d) {\n}",
+   Style);
+}
+
 TEST_F(FormatTest, UnderstandsEllipsis) {
   verifyFormat("int printf(const char *fmt, ...);");
   verifyFormat("template  void Foo(Ts... ts) { Foo(ts...); }");



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


[PATCH] D79522: Allow -fsanitize-minimal-runtime with memtag sanitizer.

2020-05-07 Thread Evgenii Stepanov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb4aa71e1bd9a: Allow -fsanitize-minimal-runtime with memtag 
sanitizer. (authored by eugenis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79522

Files:
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/fsanitize.c


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -781,6 +781,10 @@
 // CHECK-UBSAN-MINIMAL: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
 // CHECK-UBSAN-MINIMAL: "-fsanitize-minimal-runtime"
 
+// RUN: %clang -target aarch64-linux-android -march=armv8-a+memtag 
-fsanitize=memtag -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MEMTAG-MINIMAL
+// CHECK-MEMTAG-MINIMAL: "-fsanitize=memtag"
+// CHECK-MEMTAG-MINIMAL: "-fsanitize-minimal-runtime"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize=function -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-UBSAN-FUNCTION-MINIMAL
 // CHECK-UBSAN-FUNCTION-MINIMAL: error: invalid argument '-fsanitize=function' 
not allowed with '-fsanitize-minimal-runtime'
 
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -68,7 +68,8 @@
 SanitizerKind::CFIMFCall | SanitizerKind::CFIDerivedCast |
 SanitizerKind::CFIUnrelatedCast;
 static const SanitizerMask CompatibleWithMinimalRuntime =
-TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack;
+TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack |
+SanitizerKind::MemTag;
 
 enum CoverageFeature {
   CoverageFunc = 1 << 0,


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -781,6 +781,10 @@
 // CHECK-UBSAN-MINIMAL: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
 // CHECK-UBSAN-MINIMAL: "-fsanitize-minimal-runtime"
 
+// RUN: %clang -target aarch64-linux-android -march=armv8-a+memtag -fsanitize=memtag -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MEMTAG-MINIMAL
+// CHECK-MEMTAG-MINIMAL: "-fsanitize=memtag"
+// CHECK-MEMTAG-MINIMAL: "-fsanitize-minimal-runtime"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize=function -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-FUNCTION-MINIMAL
 // CHECK-UBSAN-FUNCTION-MINIMAL: error: invalid argument '-fsanitize=function' not allowed with '-fsanitize-minimal-runtime'
 
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -68,7 +68,8 @@
 SanitizerKind::CFIMFCall | SanitizerKind::CFIDerivedCast |
 SanitizerKind::CFIUnrelatedCast;
 static const SanitizerMask CompatibleWithMinimalRuntime =
-TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack;
+TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack |
+SanitizerKind::MemTag;
 
 enum CoverageFeature {
   CoverageFunc = 1 << 0,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79595: Fix bugs when an included file name is typo corrected.

2020-05-07 Thread Nico Weber via Phabricator via cfe-commits
thakis created this revision.
thakis added a reviewer: hans.

D52774  fixed a bug with typo correction of 
includes, but didn't add
a test.

D65907  then broke recovery of typo correction 
of includes again,
because it extracted the code that writes to Filename to a separate
function that took the parameter not by reference.

Fix that, and also don't repeat the slash normalization computation
and fix both lookup and regular file name after recovery.


https://reviews.llvm.org/D79595

Files:
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Lexer/case-insensitive-include-pr31836.sh
  clang/test/Lexer/case-insensitive-include-win.c

Index: clang/test/Lexer/case-insensitive-include-win.c
===
--- clang/test/Lexer/case-insensitive-include-win.c
+++ clang/test/Lexer/case-insensitive-include-win.c
@@ -5,6 +5,6 @@
 // REQUIRES: system-windows
 // RUN: mkdir -p %t.dir
 // RUN: touch %t.dir/foo.h
-// RUN: not %clang_cl /FI\\?\%t.dir\FOO.h /WX -Xclang -verify -fsyntax-only %s 2>&1 | FileCheck %s
+// RUN: not %clang_cl /FI\\?\%t.dir\FOO.h /WX -fsyntax-only %s 2>&1 | FileCheck %s
 
 // CHECK: non-portable path to file '"\\?\
Index: clang/test/Lexer/case-insensitive-include-pr31836.sh
===
--- clang/test/Lexer/case-insensitive-include-pr31836.sh
+++ clang/test/Lexer/case-insensitive-include-pr31836.sh
@@ -2,7 +2,8 @@
 
 // RUN: mkdir -p %t
 // RUN: touch %t/case-insensitive-include-pr31836.h
-// RUN: echo "#include \"%t/Case-Insensitive-Include-Pr31836.h\"" | %clang_cc1 -E - 2>&1 | FileCheck %s
+// RUN: echo "#include \"?%t/Case-Insensitive-Include-Pr31836.h\"" | not %clang_cc1 -E - 2>&1 | FileCheck %s
 
+// CHECK: error: {{.*}}file not found, did you mean
 // CHECK: warning: non-portable path to file
 // CHECK-SAME: /case-insensitive-include-pr31836.h
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -1716,11 +1716,11 @@
 }
 
 Optional Preprocessor::LookupHeaderIncludeOrImport(
-const DirectoryLookup *&CurDir, StringRef Filename,
+const DirectoryLookup *&CurDir, StringRef& Filename,
 SourceLocation FilenameLoc, CharSourceRange FilenameRange,
 const Token &FilenameTok, bool &IsFrameworkFound, bool IsImportDecl,
 bool &IsMapped, const DirectoryLookup *LookupFrom,
-const FileEntry *LookupFromFile, StringRef LookupFilename,
+const FileEntry *LookupFromFile, StringRef& LookupFilename,
 SmallVectorImpl &RelativePath, SmallVectorImpl &SearchPath,
 ModuleMap::KnownHeader &SuggestedModule, bool isAngled) {
   Optional File = LookupFile(
@@ -1789,21 +1789,10 @@
   return Filename;
 };
 StringRef TypoCorrectionName = CorrectTypoFilename(Filename);
-
-#ifndef _WIN32
-// Normalize slashes when compiling with -fms-extensions on non-Windows.
-// This is unnecessary on Windows since the filesystem there handles
-// backslashes.
-SmallString<128> NormalizedTypoCorrectionPath;
-if (LangOpts.MicrosoftExt) {
-  NormalizedTypoCorrectionPath = TypoCorrectionName;
-  llvm::sys::path::native(NormalizedTypoCorrectionPath);
-  TypoCorrectionName = NormalizedTypoCorrectionPath;
-}
-#endif
+StringRef TypoCorrectionLookupName = CorrectTypoFilename(LookupFilename);
 
 Optional File = LookupFile(
-FilenameLoc, TypoCorrectionName, isAngled, LookupFrom, LookupFromFile,
+FilenameLoc, TypoCorrectionLookupName, isAngled, LookupFrom, LookupFromFile,
 CurDir, Callbacks ? &SearchPath : nullptr,
 Callbacks ? &RelativePath : nullptr, &SuggestedModule, &IsMapped,
 /*IsFrameworkFound=*/nullptr);
@@ -1818,6 +1807,7 @@
   // We found the file, so set the Filename to the name after typo
   // correction.
   Filename = TypoCorrectionName;
+  LookupFilename = TypoCorrectionLookupName;
   return File;
 }
   }
@@ -2074,8 +2064,6 @@
   if (Callbacks && !IsImportDecl) {
 // Notify the callback object that we've seen an inclusion directive.
 // FIXME: Use a different callback for a pp-import?
-// FIXME: Passes wrong filename if LookupHeaderIncludeOrImport() did
-// typo correction.
 Callbacks->InclusionDirective(
 HashLoc, IncludeTok, LookupFilename, isAngled, FilenameRange,
 File ? &File->getFileEntry() : nullptr, SearchPath, RelativePath,
@@ -2102,7 +2090,6 @@
   !IsMapped && !File->getFileEntry().tryGetRealPathName().empty();
 
   if (CheckIncludePathPortability) {
-// FIXME: Looks at the wrong filename if we did typo correction.
 StringRef Name = LookupFilename;
 StringRef NameWithoriginalSlashes = Filename;
 #if defined(_WIN32)
Index: clang/include/clang/Lex/Preprocessor.h
=

[clang] f9eaa69 - Ensure aux-target specific builtins get validated.

2020-05-07 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2020-05-07T13:22:10-07:00
New Revision: f9eaa6934e4fdd92e09ddff89b6805a8b583e53e

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

LOG: Ensure aux-target specific builtins get validated.

I discovered that when using an aux-target builtin, it was recognized as
a builtin but never checked. This patch checks for an aux-target builtin
and instead validates it against the correct target.

It does this by extracting the checking code for Target-specific
builtins into its own function, then calls with either targetInfo or
AuxTargetInfo.

Added: 
clang/test/Sema/check-aux-builtins.c

Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 4d6e94df0b4d..66294c34a608 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -12003,6 +12003,10 @@ class Sema final {
 
   ExprResult CheckBuiltinFunctionCall(FunctionDecl *FDecl,
   unsigned BuiltinID, CallExpr *TheCall);
+
+  bool CheckTSBuiltinFunctionCall(llvm::Triple::ArchType Arch,
+  unsigned BuiltinID, CallExpr *TheCall);
+
   void checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD, CallExpr 
*TheCall);
 
   bool CheckARMBuiltinExclusiveCall(unsigned BuiltinID, CallExpr *TheCall,

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 478a534ab71c..b4cb76d0b1ad 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -1379,6 +1379,46 @@ CheckBuiltinTargetSupport(Sema &S, unsigned BuiltinID, 
CallExpr *TheCall,
 static void CheckNonNullArgument(Sema &S, const Expr *ArgExpr,
  SourceLocation CallSiteLoc);
 
+bool Sema::CheckTSBuiltinFunctionCall(llvm::Triple::ArchType Arch,
+  unsigned BuiltinID, CallExpr *TheCall) {
+  switch (Arch) {
+  default:
+// Some builtins don't require additional checking, so just consider these
+// acceptable.
+return false;
+  case llvm::Triple::arm:
+  case llvm::Triple::armeb:
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return CheckARMBuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::aarch64:
+  case llvm::Triple::aarch64_32:
+  case llvm::Triple::aarch64_be:
+return CheckAArch64BuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::bpfeb:
+  case llvm::Triple::bpfel:
+return CheckBPFBuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::hexagon:
+return CheckHexagonBuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::mips:
+  case llvm::Triple::mipsel:
+  case llvm::Triple::mips64:
+  case llvm::Triple::mips64el:
+return CheckMipsBuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::systemz:
+return CheckSystemZBuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::x86:
+  case llvm::Triple::x86_64:
+return CheckX86BuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::ppc:
+  case llvm::Triple::ppc64:
+  case llvm::Triple::ppc64le:
+return CheckPPCBuiltinFunctionCall(BuiltinID, TheCall);
+  case llvm::Triple::amdgcn:
+return CheckAMDGCNBuiltinFunctionCall(BuiltinID, TheCall);
+  }
+}
+
 ExprResult
 Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, unsigned BuiltinID,
CallExpr *TheCall) {
@@ -1875,57 +1915,19 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
   // Since the target specific builtins for each arch overlap, only check those
   // of the arch we are compiling for.
   if (Context.BuiltinInfo.isTSBuiltin(BuiltinID)) {
-switch (Context.getTargetInfo().getTriple().getArch()) {
-  case llvm::Triple::arm:
-  case llvm::Triple::armeb:
-  case llvm::Triple::thumb:
-  case llvm::Triple::thumbeb:
-if (CheckARMBuiltinFunctionCall(BuiltinID, TheCall))
-  return ExprError();
-break;
-  case llvm::Triple::aarch64:
-  case llvm::Triple::aarch64_32:
-  case llvm::Triple::aarch64_be:
-if (CheckAArch64BuiltinFunctionCall(BuiltinID, TheCall))
-  return ExprError();
-break;
-  case llvm::Triple::bpfeb:
-  case llvm::Triple::bpfel:
-if (CheckBPFBuiltinFunctionCall(BuiltinID, TheCall))
-  return ExprError();
-break;
-  case llvm::Triple::hexagon:
-if (CheckHexagonBuiltinFunctionCall(BuiltinID, TheCall))
-  return ExprError();
-break;
-  case llvm::Triple::mips:
-  case llvm::Triple::mipsel:
-  case llvm::Triple::mips64:
-  case llvm::Triple::mips64el:
-if (CheckMipsBuiltinFunctionCall(BuiltinID, The

[clang] b4aa71e - Allow -fsanitize-minimal-runtime with memtag sanitizer.

2020-05-07 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2020-05-07T13:07:46-07:00
New Revision: b4aa71e1bd9aaee377e0ea22cf60a5857e570733

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

LOG: Allow -fsanitize-minimal-runtime with memtag sanitizer.

Summary:
MemTag does not have any runtime at the moment, it's strictly code
instrumentation.

Reviewers: pcc

Subscribers: cryptoad, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Driver/SanitizerArgs.cpp
clang/test/Driver/fsanitize.c

Removed: 




diff  --git a/clang/lib/Driver/SanitizerArgs.cpp 
b/clang/lib/Driver/SanitizerArgs.cpp
index c7760f086284..bc186fa5a598 100644
--- a/clang/lib/Driver/SanitizerArgs.cpp
+++ b/clang/lib/Driver/SanitizerArgs.cpp
@@ -68,7 +68,8 @@ static const SanitizerMask CFIClasses =
 SanitizerKind::CFIMFCall | SanitizerKind::CFIDerivedCast |
 SanitizerKind::CFIUnrelatedCast;
 static const SanitizerMask CompatibleWithMinimalRuntime =
-TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack;
+TrappingSupported | SanitizerKind::Scudo | SanitizerKind::ShadowCallStack |
+SanitizerKind::MemTag;
 
 enum CoverageFeature {
   CoverageFunc = 1 << 0,

diff  --git a/clang/test/Driver/fsanitize.c b/clang/test/Driver/fsanitize.c
index e7094ef93afc..55a5e7a2e2eb 100644
--- a/clang/test/Driver/fsanitize.c
+++ b/clang/test/Driver/fsanitize.c
@@ -781,6 +781,10 @@
 // CHECK-UBSAN-MINIMAL: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
 // CHECK-UBSAN-MINIMAL: "-fsanitize-minimal-runtime"
 
+// RUN: %clang -target aarch64-linux-android -march=armv8-a+memtag 
-fsanitize=memtag -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MEMTAG-MINIMAL
+// CHECK-MEMTAG-MINIMAL: "-fsanitize=memtag"
+// CHECK-MEMTAG-MINIMAL: "-fsanitize-minimal-runtime"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize=function -fsanitize-minimal-runtime %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-UBSAN-FUNCTION-MINIMAL
 // CHECK-UBSAN-FUNCTION-MINIMAL: error: invalid argument '-fsanitize=function' 
not allowed with '-fsanitize-minimal-runtime'
 



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


[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-07 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

Thank you! Looks good with a couple of nits.




Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2402
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,

nit: add a fullstop



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2431
+// Consume the closing TT_AttributeSquare.
+nextToken();
+  }

slight concern: check if the next token is `TT_AttributeSquare` and only 
consume it in that case. Other languages that are using `TT_AttributeSquare` 
may have a different syntax for their attributes than `[[attribute]]`, e.g. 
recently added [[ 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/
 | C# `[attributes]` ]].


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

https://reviews.llvm.org/D79354



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


[PATCH] D79531: Make -Wnonportable-include-path ignore drive case on Windows.

2020-05-07 Thread Nico Weber via Phabricator via cfe-commits
thakis closed this revision.
thakis marked an inline comment as done.
thakis added a comment.

Landed in d03838343f2199580 
. Found 
another bug elsewhere while looking at this, will make a patch for that now.




Comment at: clang/lib/Lex/PPDirectives.cpp:2123
+isLowercase(Name[0]) != isLowercase(RealPathName[0])) {
+  assert(Components.size() >= 3 && "should have drive, backslash, name");
+  FixedDriveRealPath = (Name.substr(0, 1) + RealPathName.substr(1)).str();

thakis wrote:
> hans wrote:
> > Could it be different for e.g. network drives? I guess maybe they'd still 
> > have at least 3 components, but perhaps no drive letter
> Oh, good call, ` /FI\\?\%cd%\test.h` produces a path that's is_absolute() but 
> that returns
> 
> ```
> \\?
> \
> c:
> \
> src
> llvm-project
> test.h
> ```
> 
> as path components (one per line). Looking at how to handle that now. If 
> anyone happens to know, please shout :)
This now strips the common UNC path at the start and restores it at the end if 
it was there, and there's a test for this.


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

https://reviews.llvm.org/D79531



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


[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

2020-05-07 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

Thank you!


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

https://reviews.llvm.org/D79401



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


[clang] d038383 - Make -Wnonportable-include-path ignore drive case on Windows.

2020-05-07 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-05-07T15:54:09-04:00
New Revision: d03838343f2199580a1942eb353901add38af909

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

LOG: Make -Wnonportable-include-path ignore drive case on Windows.

See PR45812 for motivation.

No explicit test since I couldn't figure out how to get the
current disk drive in lower case into a form in lit where I could
mkdir it and cd to it. But the change does have test coverage in
that I can remove the case normalization in lit, and tests failed
on several bots (and for me locally if in a pwd with a lower-case
drive) without that normalization prior to this change.

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

Added: 
clang/test/Lexer/case-insensitive-include-win.c

Modified: 
clang/lib/Lex/PPDirectives.cpp
llvm/cmake/modules/AddLLVM.cmake

Removed: 




diff  --git a/clang/lib/Lex/PPDirectives.cpp b/clang/lib/Lex/PPDirectives.cpp
index 8b1d1fb320e7..84c13b286e68 100644
--- a/clang/lib/Lex/PPDirectives.cpp
+++ b/clang/lib/Lex/PPDirectives.cpp
@@ -2074,6 +2074,8 @@ Preprocessor::ImportAction 
Preprocessor::HandleHeaderIncludeOrImport(
   if (Callbacks && !IsImportDecl) {
 // Notify the callback object that we've seen an inclusion directive.
 // FIXME: Use a 
diff erent callback for a pp-import?
+// FIXME: Passes wrong filename if LookupHeaderIncludeOrImport() did
+// typo correction.
 Callbacks->InclusionDirective(
 HashLoc, IncludeTok, LookupFilename, isAngled, FilenameRange,
 File ? &File->getFileEntry() : nullptr, SearchPath, RelativePath,
@@ -2100,10 +2102,41 @@ Preprocessor::ImportAction 
Preprocessor::HandleHeaderIncludeOrImport(
   !IsMapped && !File->getFileEntry().tryGetRealPathName().empty();
 
   if (CheckIncludePathPortability) {
+// FIXME: Looks at the wrong filename if we did typo correction.
 StringRef Name = LookupFilename;
+StringRef NameWithoriginalSlashes = Filename;
+#if defined(_WIN32)
+// Skip UNC prefix if present. (tryGetRealPathName() always
+// returns a path with the prefix skipped.)
+bool NameWasUNC = Name.consume_front("?\\");
+NameWithoriginalSlashes.consume_front("?\\");
+#endif
 StringRef RealPathName = File->getFileEntry().tryGetRealPathName();
 SmallVector Components(llvm::sys::path::begin(Name),
   llvm::sys::path::end(Name));
+#if defined(_WIN32)
+// -Wnonportable-include-path is designed to diagnose includes using
+// case even on systems with a case-insensitive file system.
+// On Windows, RealPathName always starts with an upper-case drive
+// letter for absolute paths, but Name might start with either
+// case depending on if `cd c:\foo` or `cd C:\foo` was used in the shell.
+// ("foo" will always have on-disk case, no matter which case was
+// used in the cd command). To not emit this warning solely for
+// the drive letter, whose case is dependent on if `cd` is used
+// with upper- or lower-case drive letters, always consider the
+// given drive letter case as correct for the purpose of this warning.
+SmallString<128> FixedDriveRealPath;
+if (llvm::sys::path::is_absolute(Name) &&
+llvm::sys::path::is_absolute(RealPathName) &&
+toLowercase(Name[0]) == toLowercase(RealPathName[0]) &&
+isLowercase(Name[0]) != isLowercase(RealPathName[0])) {
+  assert(Components.size() >= 3 && "should have drive, backslash, name");
+  assert(Components[0].size() == 2 && "should start with drive");
+  assert(Components[0][1] == ':' && "should have colon");
+  FixedDriveRealPath = (Name.substr(0, 1) + RealPathName.substr(1)).str();
+  RealPathName = FixedDriveRealPath;
+}
+#endif
 
 if (trySimplifyPath(Components, RealPathName)) {
   SmallString<128> Path;
@@ -2132,15 +2165,23 @@ Preprocessor::ImportAction 
Preprocessor::HandleHeaderIncludeOrImport(
   continue;
 
 // Append the separator(s) the user used, or the close quote
-if (Path.size() > Filename.size()) {
+if (Path.size() > NameWithoriginalSlashes.size()) {
   Path.push_back(isAngled ? '>' : '"');
   continue;
 }
-assert(IsSep(Filename[Path.size()-1]));
+assert(IsSep(NameWithoriginalSlashes[Path.size()-1]));
 do
-  Path.push_back(Filename[Path.size()-1]);
-while (Path.size() <= Filename.size() && 
IsSep(Filename[Path.size()-1]));
+  Path.push_back(NameWithoriginalSlashes[Path.size()-1]);
+while (Path.size() <= NameWithoriginalSlashes.size() &&
+   IsSep(NameWithoriginalSlashes[Path.size()-1]));
   }
+
+#if defined(_WIN32)
+  // Restore UNC prefix if it was there.
+  if (Na

[clang] ed86058 - Add static assert to ID Table to make sure aux targets work right.

2020-05-07 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2020-05-07T12:49:46-07:00
New Revision: ed86058b53f971ed93cc79c8b4fc76da37ca0664

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

LOG: Add static assert to ID Table to make sure aux targets work right.

I discovered that the limit on possible builtins managed by this
ObjCOrBuiltin variable is too low when combining large targets, since
aux-targets are appended to the targets list. A runtime assert exists
for this, however this patch creates a static-assert as well.

The logic for said static-assert is to make sure we have the room for
the aux-target and target to both be the largest list, which makes sure
we have room for all possible combinations.

I also incremented the number of bits by 1, since I discovered this
currently broken.  The current bit-count was 36, so this doesn't
increase any size.

Added: 


Modified: 
clang/include/clang/Basic/IdentifierTable.h
clang/include/clang/Basic/TargetBuiltins.h
clang/lib/Basic/IdentifierTable.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/IdentifierTable.h 
b/clang/include/clang/Basic/IdentifierTable.h
index f23e7276b030..31849bbdd545 100644
--- a/clang/include/clang/Basic/IdentifierTable.h
+++ b/clang/include/clang/Basic/IdentifierTable.h
@@ -48,6 +48,8 @@ using IdentifierLocPair = std::pair;
 /// of a pointer to one of these classes.
 enum { IdentifierInfoAlignment = 8 };
 
+static constexpr int ObjCOrBuiltinIDBits = 14;
+
 /// One of these records is kept for each identifier that
 /// is lexed.  This contains information about whether the token was 
\#define'd,
 /// is a language keyword, or if it is a front-end token of some sort (e.g. a
@@ -63,7 +65,7 @@ class alignas(IdentifierInfoAlignment) IdentifierInfo {
   // ObjC keyword ('protocol' in '@protocol') or builtin (__builtin_inf).
   // First NUM_OBJC_KEYWORDS values are for Objective-C,
   // the remaining values are for builtins.
-  unsigned ObjCOrBuiltinID : 13;
+  unsigned ObjCOrBuiltinID : ObjCOrBuiltinIDBits;
 
   // True if there is a #define for this.
   unsigned HasMacro : 1;

diff  --git a/clang/include/clang/Basic/TargetBuiltins.h 
b/clang/include/clang/Basic/TargetBuiltins.h
index bf07a8950f28..db10077895ee 100644
--- a/clang/include/clang/Basic/TargetBuiltins.h
+++ b/clang/include/clang/Basic/TargetBuiltins.h
@@ -15,6 +15,7 @@
 #ifndef LLVM_CLANG_BASIC_TARGETBUILTINS_H
 #define LLVM_CLANG_BASIC_TARGETBUILTINS_H
 
+#include 
 #include 
 #include "clang/Basic/Builtins.h"
 #include "llvm/Support/MathExtras.h"
@@ -308,6 +309,14 @@ namespace clang {
 };
   }
 
+  static constexpr uint64_t LargestBuiltinID = std::max(
+  {NEON::FirstTSBuiltin, ARM::LastTSBuiltin, SVE::FirstTSBuiltin,
+   AArch64::LastTSBuiltin, BPF::LastTSBuiltin, PPC::LastTSBuiltin,
+   NVPTX::LastTSBuiltin, AMDGPU::LastTSBuiltin, X86::LastTSBuiltin,
+   Hexagon::LastTSBuiltin, Mips::LastTSBuiltin, XCore::LastTSBuiltin,
+   Le64::LastTSBuiltin, SystemZ::LastTSBuiltin,
+   WebAssembly::LastTSBuiltin});
+
 } // end namespace clang.
 
 #endif

diff  --git a/clang/lib/Basic/IdentifierTable.cpp 
b/clang/lib/Basic/IdentifierTable.cpp
index d7ef159743b0..36b26d9b7c68 100644
--- a/clang/lib/Basic/IdentifierTable.cpp
+++ b/clang/lib/Basic/IdentifierTable.cpp
@@ -16,6 +16,7 @@
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/OperatorKinds.h"
 #include "clang/Basic/Specifiers.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TokenKinds.h"
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/FoldingSet.h"
@@ -32,6 +33,12 @@
 
 using namespace clang;
 
+// A check to make sure the ObjCOrBuiltinID has sufficient room to store the
+// largest possible target/aux-target combination. If we exceed this, we likely
+// need to just change the ObjCOrBuiltinIDBits value in IdentifierTable.h.
+static_assert(2 * LargestBuiltinID < (2 << (ObjCOrBuiltinIDBits - 1)),
+  "Insufficient ObjCOrBuiltinID Bits");
+
 
//===--===//
 // IdentifierTable Implementation
 
//===--===//



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


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

2020-05-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2143
+return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,
+ DimExpr, Info, Deduced);
+} else if (const ConstantMatrixType *ConstantMatrixArg =

fhahn wrote:
> rjmccall wrote:
> > fhahn wrote:
> > > rjmccall wrote:
> > > > I'm curious why this extra check is necessary vs. just calling 
> > > > `DeduceNonTypeTemplateArgument` with `DimExpr` unconditionally.
> > > The code can indeed be quite simplified if we can get a row/column 
> > > expression for ConstantMatrixType as well. 
> > > 
> > > I've refactored the code to also keep the original row/column expression 
> > > in ConstantMatrixType. The new code here is much more compact as the cost 
> > > of increasing the size of ConstantMatrixType. I am not sure if the bigger 
> > > size is a concern, but I would expect that it would not matter much in 
> > > practice. 
> > > 
> > > If it is not a concern, I would further refactor the code and move the 
> > > expressions to MatrixType (which would further simplify the lambdas 
> > > here). The main difference between ConstantMatrixType and 
> > > DependentSizedMatrixType would be that ConstantMatrixTpye would also 
> > > store the dimensions as integers (for easier/faster access). What do you 
> > > think?
> > > 
> > > Alternatively we could potentially construct a new ConstantExpr from the 
> > > integer dimensions in the lambda. Or keep the more clunky accessor 
> > > lambdas.
> > Eh, I'm torn about storing the expressions in `ConstantMatrixType`.  It's 
> > probably true that we wouldn't have a ton of these types and so the overall 
> > overhead might be negligible.  However, I think that if we choose to 
> > represent things this way, we probably ought to make "pristine" new 
> > `IntegerLiteral` expressions instead of remembering the original 
> > expressions, because we don't want weird syntactic quirks of the first 
> > matrix type we see to become embedded in the type forever.  We also run the 
> > risk of actually propagating those expressions around and getting bad 
> > diagnostics that point unexpectedly back at the first place that wrote a 
> > matrix type (or at the null location of a pristine literal) because of 
> > uniquing.  So I think it might be better to just continue to define away 
> > those problems by not storing expressions.
> Sounds good to me. Should I update the code here to use the separate lambdas 
> again or would you prefer creating temporary expressions for the integer case?
I think I would prefer lambdas (or member pointers).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D77491: [Sema] Fix incompatible builtin redeclarations in non-global scope

2020-05-07 Thread John McCall via Phabricator via cfe-commits
rjmccall requested changes to this revision.
rjmccall added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Sema/SemaDecl.cpp:3759
   unsigned BuiltinID;
-  if (Old->isImplicit() && (BuiltinID = Old->getBuiltinID())) {
+  bool RevertedBuiltin{Old->getIdentifier()->hasRevertedBuiltin()};
+  if (Old->isImplicit() &&

The old code didn't check this eagerly.  The `Old->isImplicit()` check is 
unlikely to fire; please make sure that we don't do any extra work unless it 
does.



Comment at: clang/lib/Sema/SemaDecl.cpp:3765
+// Also warn if it's a redeclaration of a builtin redeclaration. We know if
+// it is if the previous declaration is a reverted builtin.
+if (RevertedBuiltin ||

`hasRevertedBuiltin()` is global state for the identifier, so this check isn't 
specifically checking anything about the previous declaration, it's checking 
whether the identifier was ever used for a builtin.  Now, the implicit-ness of 
the previous declaration *is* declaration-specific, and there are very few ways 
that we end up with an implicit function declaration.  It's quite possible that 
implicit + identifier-is-or-was-a-builtin is sufficient to say that it's an 
implicit builtin declaration today.  However, I do worry about the fact that 
this change is losing the is-predefined-library-function part of the existing 
check, and I think we should continue to check that somehow.  If that means 
changing how we revert builtin-ness, e.g. by continuing to store the old 
builtinID but just recording that it's been reverted, that seems reasonable.

That said, I think there's a larger problem, which is that you're ignoring half 
of the point of the comment you've deleted:

> // Doing this for local extern declarations is problematic.  If
> // the builtin declaration remains visible, a second invalid
> // local declaration will produce a hard error; if it doesn't
> // remain visible, a single bogus local redeclaration (which is
> // actually only a warning) could break all the downstream code.

The problem with reverting the builtin-ness of the identifier after seeing a 
bad local declaration is that, after we leave the scope of that function, the 
global function doesn't go back to being a builtin, which can break the 
behavior of all the rest of the code.

If we want to handle this kind of bogus local declaration correctly, I think we 
need to stop relying primarily on the builtin-ness of the identifier — which is 
global state and therefore inherently problematic — and instead start recording 
whether a specific declaration has builtin semantics.  The most obvious way to 
do that is to record an implicit `BuiltinAttr` when implicitly declaring a 
builtin, inherit that attribute only on compatible redeclarations, and then 
make builtin queries look for that attribute instead of checking the identifier.

Richard, do you agree?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491



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


[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262725.
MyDeveloperDay added a comment.

Simplify to ensure we don't break in between the two `TT_AttributeSquares`


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

https://reviews.llvm.org/D79401

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7672,6 +7672,19 @@
MultiLineFunctions);
 }
 
+TEST_F(FormatTest, AttributePenaltyBreaking) {
+  FormatStyle Style = getLLVMStyle();
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJKLMN(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJK(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGH([[maybe_unused]] const "
+   "shared_ptr &C d) {\n}",
+   Style);
+}
+
 TEST_F(FormatTest, UnderstandsEllipsis) {
   verifyFormat("int printf(const char *fmt, ...);");
   verifyFormat("template  void Foo(Ts... ts) { Foo(ts...); }");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3888,7 +3888,7 @@
 
   if (Right.is(tok::kw___attribute) ||
   (Right.is(tok::l_square) && Right.is(TT_AttributeSquare)))
-return true;
+return !Left.is(TT_AttributeSquare);
 
   if (Left.is(tok::identifier) && Right.is(tok::string_literal))
 return true;


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7672,6 +7672,19 @@
MultiLineFunctions);
 }
 
+TEST_F(FormatTest, AttributePenaltyBreaking) {
+  FormatStyle Style = getLLVMStyle();
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJKLMN(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGHIJK(\n"
+   "[[maybe_unused]] const shared_ptr &C d) {}",
+   Style);
+  verifyFormat("void ABCDEFGH::ABCDEFGH([[maybe_unused]] const "
+   "shared_ptr &C d) {\n}",
+   Style);
+}
+
 TEST_F(FormatTest, UnderstandsEllipsis) {
   verifyFormat("int printf(const char *fmt, ...);");
   verifyFormat("template  void Foo(Ts... ts) { Foo(ts...); }");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3888,7 +3888,7 @@
 
   if (Right.is(tok::kw___attribute) ||
   (Right.is(tok::l_square) && Right.is(TT_AttributeSquare)))
-return true;
+return !Left.is(TT_AttributeSquare);
 
   if (Left.is(tok::identifier) && Right.is(tok::string_literal))
 return true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79293: [clang-format] [PR45218] Fix an issue where < and > and >> in a for loop gets incorrectly interpreted at a TemplateOpener/Closer

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262727.
MyDeveloperDay added a comment.

Handle addition calse

  if (w>, 1>::t) return true;


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

https://reviews.llvm.org/D79293

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7076,6 +7076,22 @@
   verifyFormat("static_assert(is_convertible::value, \"AAA\");");
   verifyFormat("Constructor(A... a) : a_(X{std::forward(a)}...) {}");
   verifyFormat("< < < < < < < < < < < < < < < < < < < < < < < < < < < < < <");
+
+  verifyFormat("some_templated_type");
+}
+
+TEST_F(FormatTest, UnderstandsShiftOperators) {
+  verifyFormat("if (i < x >> 1)");
+  verifyFormat("while (i < x >> 1)");
+  verifyFormat("for (unsigned i = 0; i < i; ++i, v = v >> 1)");
+  verifyFormat("for (unsigned i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat(
+  "for (std::vector::iterator i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat("Foo.call>()");
+  verifyFormat("if (Foo.call>() == 0)");
+  verifyFormat("for (std::vector>::iterator i = 0; i < x >> 1; "
+   "++i, v = v >> 1)");
+  verifyFormat("if (w>, 1>::t)");
 }
 
 TEST_F(FormatTest, BitshiftOperatorWidth) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -119,7 +119,16 @@
 (Style.Language == FormatStyle::LK_Proto && Left->Previous &&
  Left->Previous->isOneOf(TT_SelectorName, TT_DictLiteral)))
   CurrentToken->Type = TT_DictLiteral;
-else
+// In if/for/while  (i < x >> 1) ensure we don't see the <> as
+// TemplateOpener/Closer
+else if (CurrentToken->Next && CurrentToken->Next->is(tok::greater) &&
+ CurrentToken->Next->Next &&
+ !CurrentToken->Next->Next->isOneOf(
+ tok::l_paren, tok::coloncolon, tok::comma) &&
+ Line.First->isOneOf(tok::kw_if, tok::kw_for, tok::kw_while)) {
+  Left->Type = TT_BinaryOperator;
+  return false;
+} else
   CurrentToken->Type = TT_TemplateCloser;
 next();
 return true;
@@ -1522,8 +1531,8 @@
 if (Style.Language == FormatStyle::LK_JavaScript) {
   if (Current.is(tok::exclaim)) {
 if (Current.Previous &&
-(Keywords.IsJavaScriptIdentifier(
- *Current.Previous, /* AcceptIdentifierName= */ true) ||
+(Keywords.IsJavaScriptIdentifier(*Current.Previous,
+ /*AcceptIdentifierName=*/true) ||
  Current.Previous->isOneOf(
  tok::kw_namespace, tok::r_paren, tok::r_square, tok::r_brace,
  Keywords.kw_type, Keywords.kw_get, Keywords.kw_set) ||
@@ -2178,7 +2187,7 @@
   FormatToken *Current;
 };
 
-} // end anonymous namespace
+} // namespace
 
 void TokenAnnotator::setCommentLineLevels(
 SmallVectorImpl &Lines) {


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7076,6 +7076,22 @@
   verifyFormat("static_assert(is_convertible::value, \"AAA\");");
   verifyFormat("Constructor(A... a) : a_(X{std::forward(a)}...) {}");
   verifyFormat("< < < < < < < < < < < < < < < < < < < < < < < < < < < < < <");
+
+  verifyFormat("some_templated_type");
+}
+
+TEST_F(FormatTest, UnderstandsShiftOperators) {
+  verifyFormat("if (i < x >> 1)");
+  verifyFormat("while (i < x >> 1)");
+  verifyFormat("for (unsigned i = 0; i < i; ++i, v = v >> 1)");
+  verifyFormat("for (unsigned i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat(
+  "for (std::vector::iterator i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat("Foo.call>()");
+  verifyFormat("if (Foo.call>() == 0)");
+  verifyFormat("for (std::vector>::iterator i = 0; i < x >> 1; "
+   "++i, v = v >> 1)");
+  verifyFormat("if (w>, 1>::t)");
 }
 
 TEST_F(FormatTest, BitshiftOperatorWidth) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -119,7 +119,16 @@
 (Style.Language == FormatStyle::LK_Proto && Left->Previous &&
  Left->Previous->isOneOf(TT_SelectorName, TT_DictLiteral)))
   CurrentToken->Type = TT_DictLiteral;
-else
+// In if/for/while  (i < x >> 1) ensure we don't see the <> as
+// TemplateOpener/Closer
+else if (CurrentToken->Next && CurrentToken->Next->is(tok::greater) &&
+ CurrentToken->Next->Next &&
+   

[PATCH] D79325: [clang-format] [PR42164] Add Option to Break before While

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked 2 inline comments as done.
MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2170
 parseBlock(/*MustBeDeclaration=*/false);
-if (Style.BraceWrapping.IndentBraces)
+if (Style.BraceWrapping.IndentBraces || Style.BraceWrapping.BeforeWhile)
   addUnwrappedLine();

krasimir wrote:
> Why not remove `Style.BraceWrapping.IndentBraces`? 
> - should be a no-op for GNU style, 
> - other styles don't IndentBraces, 
> - we can add a sentence in the release notes that previously IndentBraces 
> implied the new "BeforeWhile" option, and now you just have to set it if 
> you're using a custom GNU-like style.
`IndentBraces` is used elsewhere inside parseLabel() and 
CompoundStatementIndenter, I think I'd be uncomfortable about removing it.

There are 1000's of references to it in GitHub.

https://github.com/search?l=YAML&q=%22IndentBraces%3A+true%22&type=Code

https://github.com/search?q=%22IndentBraces%3A+false%22&type=Code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79325



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


[PATCH] D79526: [CUDA][HIP] Workaround for resolving host device function against wrong-sided function

2020-05-07 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

I've tested the patch on our sources and it still breaks tensorflow 
compilation, though in a different way:

  In file included from 
third_party/tensorflow/core/kernels/slice_op_gpu.cu.cc:22:
  In file included from 
./third_party/tensorflow/core/framework/register_types.h:20:
  In file included from 
./third_party/tensorflow/core/framework/numeric_types.h:28:
  In file included from ./third_party/tensorflow/core/platform/types.h:22:
  In file included from ./third_party/tensorflow/core/platform/tstring.h:24:
  In file included from ./third_party/tensorflow/core/platform/cord.h:23:
  In file included from ./third_party/tensorflow/core/platform/google/cord.h:19:
  In file included from ./third_party/absl/strings/cord.h:89:
  ./third_party/absl/strings/internal/cord_internal.h:34:16: error: no matching 
constructor for initialization of 'std::atomic' (aka 'atomic')
Refcount() : count_{1} {}
 ^ ~~~
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1778:8:
 note: candidate constructor (the implicit copy constructor) not viable: no 
known conversion from 'int' to 'const std::__u::atomic' for 1st argument
  struct atomic
 ^
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1784:5:
 note: candidate constructor not viable: requires 0 arguments, but 1 was 
provided
  atomic() _NOEXCEPT _LIBCPP_DEFAULT
  ^
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1807:52:
 error: call to deleted constructor of 
'__atomic_base'
  _LIBCPP_CONSTEXPR atomic(_Tp* __d) _NOEXCEPT : __base(__d) {}
 ^  ~~~
  ./third_party/absl/base/internal/thread_identity.h:162:66: note: in 
instantiation of member function 
'std::__u::atomic::atomic' requested here
  std::atomic bound_schedulable{nullptr};
   ^
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1675:5:
 note: '__atomic_base' has been explicitly marked deleted here
  __atomic_base(const __atomic_base&) = delete;
  ^
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1786:51:
 error: call to implicitly-deleted copy constructor of '__atomic_base'
  _LIBCPP_CONSTEXPR atomic(_Tp __d) _NOEXCEPT : __base(__d) {}
^  ~~~
  ./third_party/absl/synchronization/mutex.h:927:25: note: in instantiation of 
member function 'std::__u::atomic::atomic' requested here
  inline Mutex::Mutex() : mu_(0) {
  ^
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1698:7:
 note: copy constructor of '__atomic_base' is implicitly deleted 
because base class '__atomic_base' has a deleted copy constructor
  : public __atomic_base<_Tp, false>
^
  
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1675:5:
 note: '__atomic_base' has been explicitly marked deleted here
  __atomic_base(const __atomic_base&) = delete;
  ^


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

https://reviews.llvm.org/D79526



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


[PATCH] D79320: [clang-format [PR45791] BeforeLambdaBody is confused by comment inside lambda

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5b8ffb414200: [clang-format] [PR45791] BeforeLambdaBody is 
confused by comment inside lambda (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79320

Files:
  clang/lib/Format/ContinuationIndenter.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14587,6 +14587,30 @@
LLVMWithBeforeLambdaBody);
 }
 
+TEST_F(FormatTest, LambdaWithLineComments) {
+  FormatStyle LLVMWithBeforeLambdaBody = getLLVMStyle();
+  LLVMWithBeforeLambdaBody.BreakBeforeBraces = FormatStyle::BS_Custom;
+  LLVMWithBeforeLambdaBody.BraceWrapping.BeforeLambdaBody = true;
+  LLVMWithBeforeLambdaBody.AllowShortLambdasOnASingleLine =
+  FormatStyle::ShortLambdaStyle::SLS_All;
+
+  verifyFormat("auto k = []() { return; }", LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() // comment\n"
+   "{ return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() /* comment */ { return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() /* comment */ /* comment */ { return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() // X\n"
+   "{ return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat(
+  "auto k = []() // \n"
+  "{ return; }",
+  LLVMWithBeforeLambdaBody);
+}
+
 TEST_F(FormatTest, EmptyLinesInLambdas) {
   verifyFormat("auto lambda = []() {\n"
"  x(); //\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -330,7 +330,7 @@
   const FormatToken &Current = *State.NextToken;
   const FormatToken &Previous = *Current.Previous;
   if (Style.BraceWrapping.BeforeLambdaBody && Current.CanBreakBefore &&
-  Current.is(TT_LambdaLBrace)) {
+  Current.is(TT_LambdaLBrace) && Previous.isNot(TT_LineComment)) {
 auto LambdaBodyLength = getLengthToMatchingParen(Current, State.Stack);
 return (LambdaBodyLength > getColumnLimit(State));
   }


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14587,6 +14587,30 @@
LLVMWithBeforeLambdaBody);
 }
 
+TEST_F(FormatTest, LambdaWithLineComments) {
+  FormatStyle LLVMWithBeforeLambdaBody = getLLVMStyle();
+  LLVMWithBeforeLambdaBody.BreakBeforeBraces = FormatStyle::BS_Custom;
+  LLVMWithBeforeLambdaBody.BraceWrapping.BeforeLambdaBody = true;
+  LLVMWithBeforeLambdaBody.AllowShortLambdasOnASingleLine =
+  FormatStyle::ShortLambdaStyle::SLS_All;
+
+  verifyFormat("auto k = []() { return; }", LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() // comment\n"
+   "{ return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() /* comment */ { return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() /* comment */ /* comment */ { return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() // X\n"
+   "{ return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat(
+  "auto k = []() // \n"
+  "{ return; }",
+  LLVMWithBeforeLambdaBody);
+}
+
 TEST_F(FormatTest, EmptyLinesInLambdas) {
   verifyFormat("auto lambda = []() {\n"
"  x(); //\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -330,7 +330,7 @@
   const FormatToken &Current = *State.NextToken;
   const FormatToken &Previous = *Current.Previous;
   if (Style.BraceWrapping.BeforeLambdaBody && Current.CanBreakBefore &&
-  Current.is(TT_LambdaLBrace)) {
+  Current.is(TT_LambdaLBrace) && Previous.isNot(TT_LineComment)) {
 auto LambdaBodyLength = getLengthToMatchingParen(Current, State.Stack);
 return (LambdaBodyLength > getColumnLimit(State));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79326: [clang-format] ensure dump_format_style.py works with Python3 correctly

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3125aa99593d: [clang-format] ensure dump_format_style.py 
works with Python3 correctly (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79326

Files:
  clang/docs/tools/dump_format_style.py


Index: clang/docs/tools/dump_format_style.py
===
--- clang/docs/tools/dump_format_style.py
+++ clang/docs/tools/dump_format_style.py
@@ -225,4 +225,4 @@
 contents = substitute(contents, 'FORMAT_STYLE_OPTIONS', options_text)
 
 with open(DOC_FILE, 'wb') as output:
-  output.write(contents)
+  output.write(contents.encode())


Index: clang/docs/tools/dump_format_style.py
===
--- clang/docs/tools/dump_format_style.py
+++ clang/docs/tools/dump_format_style.py
@@ -225,4 +225,4 @@
 contents = substitute(contents, 'FORMAT_STYLE_OPTIONS', options_text)
 
 with open(DOC_FILE, 'wb') as output:
-  output.write(contents)
+  output.write(contents.encode())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-07 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

Let's separate out HasPA from SVEFeatures now while we are at it, probably it's 
more work to do this as a follow up, and after that this looks good to me.

Bonus points for adding some llvm-mca tests, see the 
`llvm-project/llvm/test/tools/llvm-mca/` directory for some inspiration how 
this latencies can be checked, but that seems like something for follow-up.




Comment at: llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td:1992
+def : InstRW<[THX3T110Write_11Cyc_LS01_I1], (instregex "^LDRAA", "^LDRAB")>;
+// disable these instructions for the time being
+// pending further decisions

just remove them then instead of commenting them out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129



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


[PATCH] D79372: [clang-format] [PR45126] Help text is missing all available formats

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG305a4abfd3a1: [clang-format] [PR45126] Help text is missing 
all available formats (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79372

Files:
  clang/lib/Format/Format.cpp
  clang/tools/clang-format/clang-format-diff.py


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -56,8 +56,8 @@
   parser.add_argument('-v', '--verbose', action='store_true',
   help='be more verbose, ineffective without -i')
   parser.add_argument('-style',
-  help='formatting style to apply (LLVM, Google, Chromium, 
'
-  'Mozilla, WebKit)')
+  help='formatting style to apply (LLVM, GNU, Google, 
Chromium, '
+  'Microsoft, Mozilla, WebKit)')
   parser.add_argument('-binary', default='clang-format',
   help='location of binary to use for clang-format')
   args = parser.parse_args()
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -2644,7 +2644,7 @@
 
 const char *StyleOptionHelpDescription =
 "Coding style, currently supports:\n"
-"  LLVM, Google, Chromium, Mozilla, WebKit.\n"
+"  LLVM, GNU, Google, Chromium, Microsoft, Mozilla, WebKit.\n"
 "Use -style=file to load style configuration from\n"
 ".clang-format file located in one of the parent\n"
 "directories of the source file (or current\n"


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -56,8 +56,8 @@
   parser.add_argument('-v', '--verbose', action='store_true',
   help='be more verbose, ineffective without -i')
   parser.add_argument('-style',
-  help='formatting style to apply (LLVM, Google, Chromium, '
-  'Mozilla, WebKit)')
+  help='formatting style to apply (LLVM, GNU, Google, Chromium, '
+  'Microsoft, Mozilla, WebKit)')
   parser.add_argument('-binary', default='clang-format',
   help='location of binary to use for clang-format')
   args = parser.parse_args()
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -2644,7 +2644,7 @@
 
 const char *StyleOptionHelpDescription =
 "Coding style, currently supports:\n"
-"  LLVM, Google, Chromium, Mozilla, WebKit.\n"
+"  LLVM, GNU, Google, Chromium, Microsoft, Mozilla, WebKit.\n"
 "Use -style=file to load style configuration from\n"
 ".clang-format file located in one of the parent\n"
 "directories of the source file (or current\n"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2020-05-07 Thread Florian Hahn via Phabricator via cfe-commits
fhahn marked an inline comment as done.
fhahn added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2143
+return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,
+ DimExpr, Info, Deduced);
+} else if (const ConstantMatrixType *ConstantMatrixArg =

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > I'm curious why this extra check is necessary vs. just calling 
> > > `DeduceNonTypeTemplateArgument` with `DimExpr` unconditionally.
> > The code can indeed be quite simplified if we can get a row/column 
> > expression for ConstantMatrixType as well. 
> > 
> > I've refactored the code to also keep the original row/column expression in 
> > ConstantMatrixType. The new code here is much more compact as the cost of 
> > increasing the size of ConstantMatrixType. I am not sure if the bigger size 
> > is a concern, but I would expect that it would not matter much in practice. 
> > 
> > If it is not a concern, I would further refactor the code and move the 
> > expressions to MatrixType (which would further simplify the lambdas here). 
> > The main difference between ConstantMatrixType and DependentSizedMatrixType 
> > would be that ConstantMatrixTpye would also store the dimensions as 
> > integers (for easier/faster access). What do you think?
> > 
> > Alternatively we could potentially construct a new ConstantExpr from the 
> > integer dimensions in the lambda. Or keep the more clunky accessor lambdas.
> Eh, I'm torn about storing the expressions in `ConstantMatrixType`.  It's 
> probably true that we wouldn't have a ton of these types and so the overall 
> overhead might be negligible.  However, I think that if we choose to 
> represent things this way, we probably ought to make "pristine" new 
> `IntegerLiteral` expressions instead of remembering the original expressions, 
> because we don't want weird syntactic quirks of the first matrix type we see 
> to become embedded in the type forever.  We also run the risk of actually 
> propagating those expressions around and getting bad diagnostics that point 
> unexpectedly back at the first place that wrote a matrix type (or at the null 
> location of a pristine literal) because of uniquing.  So I think it might be 
> better to just continue to define away those problems by not storing 
> expressions.
Sounds good to me. Should I update the code here to use the separate lambdas 
again or would you prefer creating temporary expressions for the integer case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D79579: [SveEmitter] Add builtins for svmovlb and svmovlt

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

LGTM


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

https://reviews.llvm.org/D79579



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


[clang] 5b8ffb4 - [clang-format] [PR45791] BeforeLambdaBody is confused by comment inside lambda

2020-05-07 Thread via cfe-commits

Author: mydeveloperday
Date: 2020-05-07T19:53:56+01:00
New Revision: 5b8ffb414200aa65ab26b16415a98a63d81c14ca

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

LOG: [clang-format] [PR45791] BeforeLambdaBody is confused by comment inside 
lambda

Summary:
https://bugs.llvm.org/show_bug.cgi?id=45791

Lambda with line comment is incorrectly formatted

```
auto k = []() // comment
{ return; };


```
auto k = []() // comment { return; };
```

Reviewed By: Wawha

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/lib/Format/ContinuationIndenter.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/ContinuationIndenter.cpp 
b/clang/lib/Format/ContinuationIndenter.cpp
index 5fdb1dbc433c..cf885240a4f2 100644
--- a/clang/lib/Format/ContinuationIndenter.cpp
+++ b/clang/lib/Format/ContinuationIndenter.cpp
@@ -330,7 +330,7 @@ bool ContinuationIndenter::mustBreak(const LineState 
&State) {
   const FormatToken &Current = *State.NextToken;
   const FormatToken &Previous = *Current.Previous;
   if (Style.BraceWrapping.BeforeLambdaBody && Current.CanBreakBefore &&
-  Current.is(TT_LambdaLBrace)) {
+  Current.is(TT_LambdaLBrace) && Previous.isNot(TT_LineComment)) {
 auto LambdaBodyLength = getLengthToMatchingParen(Current, State.Stack);
 return (LambdaBodyLength > getColumnLimit(State));
   }

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index aba209b4252d..86eeb2705595 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -14587,6 +14587,30 @@ TEST_F(FormatTest, FormatsLambdas) {
LLVMWithBeforeLambdaBody);
 }
 
+TEST_F(FormatTest, LambdaWithLineComments) {
+  FormatStyle LLVMWithBeforeLambdaBody = getLLVMStyle();
+  LLVMWithBeforeLambdaBody.BreakBeforeBraces = FormatStyle::BS_Custom;
+  LLVMWithBeforeLambdaBody.BraceWrapping.BeforeLambdaBody = true;
+  LLVMWithBeforeLambdaBody.AllowShortLambdasOnASingleLine =
+  FormatStyle::ShortLambdaStyle::SLS_All;
+
+  verifyFormat("auto k = []() { return; }", LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() // comment\n"
+   "{ return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() /* comment */ { return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() /* comment */ /* comment */ { return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("auto k = []() // X\n"
+   "{ return; }",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat(
+  "auto k = []() // \n"
+  "{ return; }",
+  LLVMWithBeforeLambdaBody);
+}
+
 TEST_F(FormatTest, EmptyLinesInLambdas) {
   verifyFormat("auto lambda = []() {\n"
"  x(); //\n"



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


[clang] 3125aa9 - [clang-format] ensure dump_format_style.py works with Python3 correctly

2020-05-07 Thread via cfe-commits

Author: mydeveloperday
Date: 2020-05-07T19:52:12+01:00
New Revision: 3125aa99593db9fe17c825fd5984b333bb86437f

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

LOG: [clang-format] ensure dump_format_style.py works with Python3 correctly

Summary:
Python2 has been removed from cygwin, this means anyone running the 
dump_format_style.py in a cygwin shell could pick up python3 instead

In Python3 all strings are unicode as the file is opened in binary mode we need 
to encode the contents string or we'll face the following error

```
Traceback (most recent call last):
  File "./dump_format_style.py", line 228, in 
output.write(contents)
TypeError: a bytes-like object is required, not 'str'
```

Reviewed By: krasimir

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/docs/tools/dump_format_style.py

Removed: 




diff  --git a/clang/docs/tools/dump_format_style.py 
b/clang/docs/tools/dump_format_style.py
index acb0dfcaf4a7..61167979b3e6 100755
--- a/clang/docs/tools/dump_format_style.py
+++ b/clang/docs/tools/dump_format_style.py
@@ -225,4 +225,4 @@ class State(object):
 contents = substitute(contents, 'FORMAT_STYLE_OPTIONS', options_text)
 
 with open(DOC_FILE, 'wb') as output:
-  output.write(contents)
+  output.write(contents.encode())



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


[clang] 305a4ab - [clang-format] [PR45126] Help text is missing all available formats

2020-05-07 Thread via cfe-commits

Author: mydeveloperday
Date: 2020-05-07T19:50:21+01:00
New Revision: 305a4abfd3a1e3f4e5c8d98136f88f54b761b011

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

LOG: [clang-format] [PR45126] Help text is missing all available formats

Summary:
https://bugs.llvm.org/show_bug.cgi?id=45126

GNU and Microsoft styles are built in supported styles but are not displayed in 
the help text

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/lib/Format/Format.cpp
clang/tools/clang-format/clang-format-diff.py

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 1fd7d613f9fb..655df7e45ba7 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -2644,7 +2644,7 @@ LangOptions getFormattingLangOpts(const FormatStyle 
&Style) {
 
 const char *StyleOptionHelpDescription =
 "Coding style, currently supports:\n"
-"  LLVM, Google, Chromium, Mozilla, WebKit.\n"
+"  LLVM, GNU, Google, Chromium, Microsoft, Mozilla, WebKit.\n"
 "Use -style=file to load style configuration from\n"
 ".clang-format file located in one of the parent\n"
 "directories of the source file (or current\n"

diff  --git a/clang/tools/clang-format/clang-format-
diff .py b/clang/tools/clang-format/clang-format-
diff .py
index 5977ab056515..c5331202fc1b 100755
--- a/clang/tools/clang-format/clang-format-
diff .py
+++ b/clang/tools/clang-format/clang-format-
diff .py
@@ -56,8 +56,8 @@ def main():
   parser.add_argument('-v', '--verbose', action='store_true',
   help='be more verbose, ineffective without -i')
   parser.add_argument('-style',
-  help='formatting style to apply (LLVM, Google, Chromium, 
'
-  'Mozilla, WebKit)')
+  help='formatting style to apply (LLVM, GNU, Google, 
Chromium, '
+  'Microsoft, Mozilla, WebKit)')
   parser.add_argument('-binary', default='clang-format',
   help='location of binary to use for clang-format')
   args = parser.parse_args()



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


[PATCH] D79584: [SVE] Add a couple of extra sizeless type tests

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79584



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


[PATCH] D79531: Make -Wnonportable-include-path ignore drive case on Windows.

2020-05-07 Thread Nico Weber via Phabricator via cfe-commits
thakis marked an inline comment as done.
thakis added inline comments.



Comment at: clang/lib/Lex/PPDirectives.cpp:2123
+isLowercase(Name[0]) != isLowercase(RealPathName[0])) {
+  assert(Components.size() >= 3 && "should have drive, backslash, name");
+  FixedDriveRealPath = (Name.substr(0, 1) + RealPathName.substr(1)).str();

hans wrote:
> Could it be different for e.g. network drives? I guess maybe they'd still 
> have at least 3 components, but perhaps no drive letter
Oh, good call, ` /FI\\?\%cd%\test.h` produces a path that's is_absolute() but 
that returns

```
\\?
\
c:
\
src
llvm-project
test.h
```

as path components (one per line). Looking at how to handle that now. If anyone 
happens to know, please shout :)


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

https://reviews.llvm.org/D79531



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


[PATCH] D79587: [CodeGen][SVE] Legalisation of extends with scalable types

2020-05-07 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Can you explain why target-independent legalization isn't suitable here?  I'd 
prefer not to have target-specific type legalization for every operation on 
vscale'ed types.  (The target-independent name of AArch64ISD::SUNPKLO is 
ISD::SIGN_EXTEND_VECTOR_INREG.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79587



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


[PATCH] D79276: [FileCheck] Support comment directives

2020-05-07 Thread Joel E. Denny via Phabricator via cfe-commits
jdenny marked 2 inline comments as done.
jdenny added a comment.

Thanks!


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

https://reviews.llvm.org/D79276



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


[PATCH] D79210: Let clang print registered targets for --version

2020-05-07 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D79210#2025547 , @MaskRay wrote:

> @yaxunl The plural form `--print-targets` may make more sense to be 
> consistent with other plural form options (--print-search-dirs, 
> --print-diagnostic-categories, etc)


Agree


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79210



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


[PATCH] D79210: Let clang print registered targets for --version

2020-05-07 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

@yaxunl The plural form `--print-targets` may make more sense to be consistent 
with other plural form options (--print-search-dirs, 
--print-diagnostic-categories, etc)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79210



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


[PATCH] D77697: libc++: adjust modulemap for non-modular C

2020-05-07 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision as: libc++.
ldionne added a comment.

LGTM since other reviewers are fine with it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77697



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


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

2020-05-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2143
+return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,
+ DimExpr, Info, Deduced);
+} else if (const ConstantMatrixType *ConstantMatrixArg =

fhahn wrote:
> rjmccall wrote:
> > I'm curious why this extra check is necessary vs. just calling 
> > `DeduceNonTypeTemplateArgument` with `DimExpr` unconditionally.
> The code can indeed be quite simplified if we can get a row/column expression 
> for ConstantMatrixType as well. 
> 
> I've refactored the code to also keep the original row/column expression in 
> ConstantMatrixType. The new code here is much more compact as the cost of 
> increasing the size of ConstantMatrixType. I am not sure if the bigger size 
> is a concern, but I would expect that it would not matter much in practice. 
> 
> If it is not a concern, I would further refactor the code and move the 
> expressions to MatrixType (which would further simplify the lambdas here). 
> The main difference between ConstantMatrixType and DependentSizedMatrixType 
> would be that ConstantMatrixTpye would also store the dimensions as integers 
> (for easier/faster access). What do you think?
> 
> Alternatively we could potentially construct a new ConstantExpr from the 
> integer dimensions in the lambda. Or keep the more clunky accessor lambdas.
Eh, I'm torn about storing the expressions in `ConstantMatrixType`.  It's 
probably true that we wouldn't have a ton of these types and so the overall 
overhead might be negligible.  However, I think that if we choose to represent 
things this way, we probably ought to make "pristine" new `IntegerLiteral` 
expressions instead of remembering the original expressions, because we don't 
want weird syntactic quirks of the first matrix type we see to become embedded 
in the type forever.  We also run the risk of actually propagating those 
expressions around and getting bad diagnostics that point unexpectedly back at 
the first place that wrote a matrix type (or at the null location of a pristine 
literal) because of uniquing.  So I think it might be better to just continue 
to define away those problems by not storing expressions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281



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


[PATCH] D79276: [FileCheck] Support comment directives

2020-05-07 Thread Thomas Preud'homme via Phabricator via cfe-commits
thopre accepted this revision.
thopre added a comment.

LGTM. Sorry for the late review.




Comment at: llvm/test/FileCheck/comment/after-words.txt:1
+# Comment prefixes are not recognized at ends of words.
+

jdenny wrote:
> jdenny wrote:
> > thopre wrote:
> > > How about characters that cannot be part of an identifier? E.g. would 
> > > "@COM:" be interpreted as a comment? Should we only accept comment prefix 
> > > if it's a space or beginning of line before?
> > Yes, this patch interprets `@COM:` as a comment directive.
> > 
> > My justification is that, to keep things simple for the FileCheck user and 
> > implementation, I tried to keep parsing of comment directives and check 
> > directives as similar as possible.  One intentional difference is that 
> > comment directives are ignored if they have check suffixes, such as `-NOT`.
> `git grep '@RUN'` shows that `@` without a following space might be a comment 
> style we should support. Here's an example match:
> 
> ```
> llvm/test/MC/ARM/ldr-pseudo-cond-darwin.s:@RUN: llvm-mc -triple 
> armv7-base-apple-darwin %s | FileCheck --check-prefix=CHECK-ARM 
> --check-prefix=CHECK %s
> ```
You're right, I forgot CHECK directives have the same problem. This should be 
fixed by the patch that was proposed to force a comment mark or beginning of 
line for a prefix to be recognized as a directive. Patch LGTM then.


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

https://reviews.llvm.org/D79276



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-07 Thread Casey Carter via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8615ce246d1c: [libc++][test] Adjust move_iterator tests to 
allow C++20 (authored by CaseyCarter).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79343

Files:
  
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
  
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp


Index: 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
===
--- 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
+++ 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
@@ -35,6 +35,8 @@
   typedef std::ptrdiff_t difference_type;
   typedef ValueType* pointer;
   typedef Reference reference;
+
+  Reference operator*() const;
 };
 
 template 
Index: 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
===
--- 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
+++ 
libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
@@ -16,10 +16,20 @@
 
 #include 
 #include 
+#include 
 
 #include "test_macros.h"
 #include "test_iterators.h"
 
+#if TEST_STD_VER > 17
+template 
+void test_single_pass(It i, It x) {
+  std::move_iterator r(std::move(i));
+  r++;
+  assert(std::move(r).base() == x);
+}
+#endif
+
 template 
 void
 test(It i, It x)
@@ -33,7 +43,11 @@
 int main(int, char**)
 {
 char s[] = "123";
+#if TEST_STD_VER > 17
+test_single_pass(input_iterator(s), input_iterator(s + 1));
+#else
 test(input_iterator(s), input_iterator(s+1));
+#endif
 test(forward_iterator(s), forward_iterator(s+1));
 test(bidirectional_iterator(s), bidirectional_iterator(s+1));
 test(random_access_iterator(s), random_access_iterator(s+1));


Index: libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
===
--- libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
+++ libcxx/test/std/iterators/predef.iterators/move.iterators/move.iterator/types.pass.cpp
@@ -35,6 +35,8 @@
   typedef std::ptrdiff_t difference_type;
   typedef ValueType* pointer;
   typedef Reference reference;
+
+  Reference operator*() const;
 };
 
 template 
Index: libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
===
--- libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
+++ libcxx/test/std/iterators/predef.iterators/move.iterators/move.iter.ops/move.iter.op.incr/post.pass.cpp
@@ -16,10 +16,20 @@
 
 #include 
 #include 
+#include 
 
 #include "test_macros.h"
 #include "test_iterators.h"
 
+#if TEST_STD_VER > 17
+template 
+void test_single_pass(It i, It x) {
+  std::move_iterator r(std::move(i));
+  r++;
+  assert(std::move(r).base() == x);
+}
+#endif
+
 template 
 void
 test(It i, It x)
@@ -33,7 +43,11 @@
 int main(int, char**)
 {
 char s[] = "123";
+#if TEST_STD_VER > 17
+test_single_pass(input_iterator(s), input_iterator(s + 1));
+#else
 test(input_iterator(s), input_iterator(s+1));
+#endif
 test(forward_iterator(s), forward_iterator(s+1));
 test(bidirectional_iterator(s), bidirectional_iterator(s+1));
 test(random_access_iterator(s), random_access_iterator(s+1));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79276: [FileCheck] Support comment directives

2020-05-07 Thread Joel E. Denny via Phabricator via cfe-commits
jdenny marked an inline comment as done.
jdenny added inline comments.



Comment at: llvm/test/FileCheck/comment/after-words.txt:1
+# Comment prefixes are not recognized at ends of words.
+

jdenny wrote:
> thopre wrote:
> > How about characters that cannot be part of an identifier? E.g. would 
> > "@COM:" be interpreted as a comment? Should we only accept comment prefix 
> > if it's a space or beginning of line before?
> Yes, this patch interprets `@COM:` as a comment directive.
> 
> My justification is that, to keep things simple for the FileCheck user and 
> implementation, I tried to keep parsing of comment directives and check 
> directives as similar as possible.  One intentional difference is that 
> comment directives are ignored if they have check suffixes, such as `-NOT`.
`git grep '@RUN'` shows that `@` without a following space might be a comment 
style we should support. Here's an example match:

```
llvm/test/MC/ARM/ldr-pseudo-cond-darwin.s:@RUN: llvm-mc -triple 
armv7-base-apple-darwin %s | FileCheck --check-prefix=CHECK-ARM 
--check-prefix=CHECK %s
```


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

https://reviews.llvm.org/D79276



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


[PATCH] D79276: [FileCheck] Support comment directives

2020-05-07 Thread Joel E. Denny via Phabricator via cfe-commits
jdenny marked an inline comment as done.
jdenny added inline comments.



Comment at: llvm/test/FileCheck/comment/after-words.txt:1
+# Comment prefixes are not recognized at ends of words.
+

thopre wrote:
> How about characters that cannot be part of an identifier? E.g. would "@COM:" 
> be interpreted as a comment? Should we only accept comment prefix if it's a 
> space or beginning of line before?
Yes, this patch interprets `@COM:` as a comment directive.

My justification is that, to keep things simple for the FileCheck user and 
implementation, I tried to keep parsing of comment directives and check 
directives as similar as possible.  One intentional difference is that comment 
directives are ignored if they have check suffixes, such as `-NOT`.


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

https://reviews.llvm.org/D79276



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


[PATCH] D79587: [CodeGen][SVE] Legalisation of extends with scalable types

2020-05-07 Thread Kerry McLaughlin via Phabricator via cfe-commits
kmclaughlin created this revision.
kmclaughlin added reviewers: sdesmalen, efriedma, david-arm.
Herald added subscribers: psnobl, rkruppe, hiraditya, tschuett.
Herald added a project: LLVM.

This patch adds legalisation of extensions where the operand
of the extend is a legal scalable type but the result is not.

In these cases we can try to use the [S|U]UNPK[HI|LO] operations
to extend each half individually and concatenate the result.

For example:

  zext  %a to 

should emit:

  uunpklo z2.h, z0.b
  uunpkhi z1.h, z0.b

Patch by Richard Sandiford


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79587

Files:
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.h
  llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
  llvm/test/CodeGen/AArch64/sve-arith.ll
  llvm/test/CodeGen/AArch64/sve-ext.ll

Index: llvm/test/CodeGen/AArch64/sve-ext.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/sve-ext.ll
@@ -0,0 +1,127 @@
+; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; SEXT
+;
+
+define  @sext_b_to_h( %a) {
+; CHECK-LABEL: sext_b_to_h:
+; CHECK-DAG: sunpklo z2.h, z0.b
+; CHECK-DAG: sunpkhi z1.h, z0.b
+; CHECK-DAG: mov z0.d, z2.d
+; CHECK-NEXT: ret
+  %ext = sext  %a to 
+  ret  %ext
+}
+
+define  @sext_h_to_s( %a) {
+; CHECK-LABEL: sext_h_to_s:
+; CHECK-DAG: sunpklo z2.s, z0.h
+; CHECK-DAG: sunpkhi z1.s, z0.h
+; CHECK-DAG: mov z0.d, z2.d
+; CHECK-NEXT: ret
+  %ext = sext  %a to 
+  ret  %ext
+}
+
+define  @sext_s_to_d( %a) {
+; CHECK-LABEL: sext_s_to_d:
+; CHECK-DAG: sunpklo z2.d, z0.s
+; CHECK-DAG: sunpkhi z1.d, z0.s
+; CHECK-DAG: mov z0.d, z2.d
+; CHECK-NEXT: ret
+  %ext = sext  %a to 
+  ret  %ext
+}
+
+define  @sext_b_to_s( %a) {
+; CHECK-LABEL: sext_b_to_s:
+; CHECK-DAG: sunpklo [[LO:z[0-9]+]].h, z0.b
+; CHECK-DAG: sunpkhi [[HI:z[0-9]+]].h, z0.b
+; CHECK-DAG: sunpklo [[LOLO:z[0-9]+]].s, [[LO]].h
+; CHECK-DAG: sunpkhi {{z[0-9]+}}.s, [[LO]].h
+; CHECK-DAG: sunpklo {{z[0-9]+}}.s, [[HI]].h
+; CHECK-DAG: sunpkhi {{z[0-9]+}}.s, [[HI]].h
+; CHECK: ret
+  %ext = sext  %a to 
+  ret  %ext
+}
+
+define  @sext_promote_b_to_s( %in) {
+; CHECK-LABEL: @sext_promote
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sxtb z0.s, p0/m, z0.s
+; CHECK-NEXT: ret
+  %out = sext  %in to 
+  ret  %out
+}
+
+define  @sext_promote_h_to_d( %in) {
+; CHECK-LABEL: @sext_promote_h_to_d
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sxth z0.d, p0/m, z0.d
+; CHECK-NEXT: ret
+  %out = sext  %in to 
+  ret  %out
+}
+
+; ZEXT
+
+define  @zext_b_to_h( %a) {
+; CHECK-LABEL: zext_b_to_h:
+; CHECK-DAG: uunpklo z2.h, z0.b
+; CHECK-DAG: uunpkhi z1.h, z0.b
+; CHECK-DAG: mov z0.d, z2.d
+; CHECK-NEXT: ret
+  %ext = zext  %a to 
+  ret  %ext
+}
+
+define  @zext_h_to_s( %a) {
+; CHECK-LABEL: zext_h_to_s:
+; CHECK-DAG: uunpklo z2.s, z0.h
+; CHECK-DAG: uunpkhi z1.s, z0.h
+; CHECK-DAG: mov z0.d, z2.d
+; CHECK-NEXT: ret
+  %ext = zext  %a to 
+  ret  %ext
+}
+
+define  @zext_s_to_d( %a) {
+; CHECK-LABEL: zext_s_to_d:
+; CHECK-DAG: uunpklo z2.d, z0.s
+; CHECK-DAG: uunpkhi z1.d, z0.s
+; CHECK-DAG: mov z0.d, z2.d
+; CHECK-NEXT: ret
+  %ext = zext  %a to 
+  ret  %ext
+}
+
+define  @zext_b_to_s( %a) {
+; CHECK-LABEL: zext_b_to_s:
+; CHECK-DAG: uunpklo [[LO:z[0-9]+]].h, z0.b
+; CHECK-DAG: uunpkhi [[HI:z[0-9]+]].h, z0.b
+; CHECK-DAG: uunpklo z0.s, [[LO]].h
+; CHECK-DAG: uunpkhi z1.s, [[LO]].h
+; CHECK-DAG: uunpklo z2.s, [[HI]].h
+; CHECK-DAG: uunpkhi z3.s, [[HI]].h
+; CHECK: ret
+  %ext = zext  %a to 
+  ret  %ext
+}
+
+define  @zext_promote_b_to_s( %in) {
+; CHECK-LABEL: @zext_promote
+; CHECK-DAG: and z0.s, z0.s, #0xff
+; CHECK-NEXT: ret
+  %out = zext  %in to 
+  ret  %out
+}
+
+define  @zext_promote_h_to_d( %in) {
+; CHECK-LABEL: @zext_promote_h_to_d
+; CHECK-DAG: and z0.d, z0.d, #0x
+; CHECK-NEXT: ret
+  %out = zext  %in to 
+  ret  %out
+}
Index: llvm/test/CodeGen/AArch64/sve-arith.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/sve-arith.ll
@@ -0,0 +1,608 @@
+; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; SDIV
+;
+
+define  @sdiv_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sdiv z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_i64( %a,  %b) {
+; CHECK-LABEL: @sdiv_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_split_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_split_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sdiv z0.s, p0/m, z0.s, z2.s
+; CHECK-DAG: sdiv z1.s, p0/m, z1.s, z3.s
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_promote_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_promote_i32
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sxtw z1.d, p0/m, z1.d
+; CHECK-DAG: sxtw z0.d, p0/m, z0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z1.d
+; CHE

[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-07 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter marked an inline comment as done.
CaseyCarter added a comment.

In D79343#2025211 , @ldionne wrote:

> Regarding the formatting changes, I personally think we should clang-format 
> all of libc++, libc++abi and libunwind in one go. Then we'd be done with 
> these small issues that add up. And we can even add the revision to 
> `.git-blame-ignore-revs`.


I'm the furthest thing from a core libc++ maintainer, but FWIW I agree. I set 
up a `.git-blame-ignore-revs` for the MSVC internal git repo a week or two ago 
with our "clang-format the things" and "change all the line endings" commits 
and it has been a great experience.


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

https://reviews.llvm.org/D79343



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


[PATCH] D79035: [clang][AIX] Implement ABIInfo and TargetCodeGenInfo for AIX

2020-05-07 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4257
+  // 64-bit only registers:
+  // 114: tfhar
+  // 115: tfiar

From what I've seen, the tfhar, tfiar and texasr are used by the Power8 CPU, 
which means that there is potential for them to be used on 64BIT AIX.  I don't 
have access to a Power8 AIX machine to test and confirm this however.  If no 
one else can confirm, maybe it's good to leave a TODO here to check?



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4541
options::OPT_msvr4_struct_return)) {
-if (TC.getArch() != llvm::Triple::ppc) {
+if (TC.getArch() != llvm::Triple::ppc || TC.getTriple().isOSAIX()) {
   D.Diag(diag::err_drv_unsupported_opt_for_target)

-maix-struct-return behaves as expected on AIX (ie. it has no change from 
default behaviour) but I agree, to me it makes disable both if we are not sure 
about one of them.  However, I think it would be good to add a TODO to enable 
this once it's verified on AIX.  



Comment at: clang/test/CodeGen/ppc32-and-aix-struct-return.c:55
+// CHECK-AIX-LABEL: define void @ret0(%struct.Zero* noalias sret {{[^,]*}})
+// CHECK-SVR4-LABEL: define void @ret0()
+Zero ret0(void) { return (Zero){}; }

sorry, is it possible to lineup the `define ..` with the line below, for the 
entire testcase?


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

https://reviews.llvm.org/D79035



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


[PATCH] D79582: [clangd] Fix crash in AddUsing tweak due to non-identifier DeclName

2020-05-07 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

thanks for tracking it down.




Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:214
+if (D->getDecl()->getDeclName().getNameKind() ==
+DeclarationName::Identifier) {
+  QualifierToRemove = D->getQualifierLoc();

nit:  

```
if (const auto* II = D->getDecl()->getIdentifier()) {
...
  Name = II->getName();
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79582



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


[PATCH] D79276: [FileCheck] Support comment directives

2020-05-07 Thread Thomas Preud'homme via Phabricator via cfe-commits
thopre added inline comments.



Comment at: llvm/test/FileCheck/comment/after-words.txt:1
+# Comment prefixes are not recognized at ends of words.
+

How about characters that cannot be part of an identifier? E.g. would "@COM:" 
be interpreted as a comment? Should we only accept comment prefix if it's a 
space or beginning of line before?


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

https://reviews.llvm.org/D79276



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


[PATCH] D79210: Let clang print registered targets for --version

2020-05-07 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79210



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


[clang] e42fee7 - Add a test for "clang --version".

2020-05-07 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-05-07T12:15:01-04:00
New Revision: e42fee75b8107177de5b27cb461172d326cf6141

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

LOG: Add a test for "clang --version".

Added: 
clang/test/Driver/version.c

Modified: 


Removed: 




diff  --git a/clang/test/Driver/version.c b/clang/test/Driver/version.c
new file mode 100644
index ..a9f4f9ff0aa6
--- /dev/null
+++ b/clang/test/Driver/version.c
@@ -0,0 +1,7 @@
+// RUN: %clang --version 2>&1 | FileCheck %s
+
+CHECK: clang version
+
+// Don't add llvm::TargetRegistry::printRegisteredTargetsForVersion()
+// to --version output, see D79210 and D33900.
+CHECK-NOT: Registered Targets:



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


[PATCH] D79584: [SVE] Add a couple of extra sizeless type tests

2020-05-07 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm created this revision.
rsandifo-arm added reviewers: sdesmalen, efriedma, rovka, rjmccall.
Herald added subscribers: cfe-commits, psnobl, rkruppe, tschuett.
Herald added a project: clang.

This patch adds tests for things that happened to be fixed by previous
patches, but that should continue working if we do decide to treat
sizeless types as incomplete types.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79584

Files:
  clang/test/Sema/sizeless-1.c
  clang/test/SemaCXX/sizeless-1.cpp


Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -379,6 +379,8 @@
 extern array_alias *array_alias_int8_ptr; // expected-note {{in 
instantiation of template type alias 'array_alias' requested here}}
 #endif
 
+extern "C" svint8_t c_return_int8();
+
 void cxx_only(int sel) {
   svint8_t local_int8;
   svint16_t local_int16;
Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -290,4 +290,10 @@
   int a3[_Generic(0, svint8_t : 1, svint16_t : 2, default : 3) == 3 ? 1 : -1];
   (void)_Generic(0, svint8_t : 1, svint8_t : 2, default : 3); // 
expected-error {{type 'svint8_t' (aka '__SVInt8_t') in generic association 
compatible with previously specified type 'svint8_t'}} expected-note 
{{compatible type}}
 }
+
+void test_compound_literal(void) {
+  svint8_t local_int8;
+
+  (void)(svint8_t){local_int8};
+}
 #endif


Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -379,6 +379,8 @@
 extern array_alias *array_alias_int8_ptr; // expected-note {{in instantiation of template type alias 'array_alias' requested here}}
 #endif
 
+extern "C" svint8_t c_return_int8();
+
 void cxx_only(int sel) {
   svint8_t local_int8;
   svint16_t local_int16;
Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -290,4 +290,10 @@
   int a3[_Generic(0, svint8_t : 1, svint16_t : 2, default : 3) == 3 ? 1 : -1];
   (void)_Generic(0, svint8_t : 1, svint8_t : 2, default : 3); // expected-error {{type 'svint8_t' (aka '__SVInt8_t') in generic association compatible with previously specified type 'svint8_t'}} expected-note {{compatible type}}
 }
+
+void test_compound_literal(void) {
+  svint8_t local_int8;
+
+  (void)(svint8_t){local_int8};
+}
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79582: [clangd] Fix crash in AddUsing tweak due to non-identifier DeclName

2020-05-07 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz created this revision.
adamcz added a reviewer: hokein.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79582

Files:
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.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
@@ -2444,6 +2444,7 @@
 public:
   struct st {};
   static void mm() {}
+  cc operator|(const cc& x) const { return x; }
 };
 }
 })cpp";
@@ -2463,6 +2464,9 @@
   // test that we don't crash.
   EXPECT_UNAVAILABLE(Header +
  "template using foo = one::tt;");
+  // Test that we don't crash or misbehave on unnamed DeclRefExpr.
+  EXPECT_UNAVAILABLE(Header +
+ "void fun() { one::two::cc() ^| one::two::cc(); }");
 
   // Check that we do not trigger in header files.
   FileName = "test.h";
Index: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
@@ -210,8 +210,11 @@
 return false;
 
   if (auto *D = Node->ASTNode.get()) {
-QualifierToRemove = D->getQualifierLoc();
-Name = D->getDecl()->getName();
+if (D->getDecl()->getDeclName().getNameKind() ==
+DeclarationName::Identifier) {
+  QualifierToRemove = D->getQualifierLoc();
+  Name = D->getDecl()->getName();
+}
   } else if (auto *T = Node->ASTNode.get()) {
 if (auto E = T->getAs()) {
   if (auto *BaseTypeIdentifier =


Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -2444,6 +2444,7 @@
 public:
   struct st {};
   static void mm() {}
+  cc operator|(const cc& x) const { return x; }
 };
 }
 })cpp";
@@ -2463,6 +2464,9 @@
   // test that we don't crash.
   EXPECT_UNAVAILABLE(Header +
  "template using foo = one::tt;");
+  // Test that we don't crash or misbehave on unnamed DeclRefExpr.
+  EXPECT_UNAVAILABLE(Header +
+ "void fun() { one::two::cc() ^| one::two::cc(); }");
 
   // Check that we do not trigger in header files.
   FileName = "test.h";
Index: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
@@ -210,8 +210,11 @@
 return false;
 
   if (auto *D = Node->ASTNode.get()) {
-QualifierToRemove = D->getQualifierLoc();
-Name = D->getDecl()->getName();
+if (D->getDecl()->getDeclName().getNameKind() ==
+DeclarationName::Identifier) {
+  QualifierToRemove = D->getQualifierLoc();
+  Name = D->getDecl()->getName();
+}
   } else if (auto *T = Node->ASTNode.get()) {
 if (auto E = T->getAs()) {
   if (auto *BaseTypeIdentifier =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79274: Fix template class debug info for Visual Studio visualizers

2020-05-07 Thread Adrian McCarthy via Phabricator via cfe-commits
amccarth marked 2 inline comments as done.
amccarth added inline comments.



Comment at: clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp:10
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
+// RUN:   -o - -triple=x86_64-pc-win32 -Wno-new-returns-null 
-fms-compatibility | \
+// RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: 
"\([^"]*\)".*/"\1"/' | \

rnk wrote:
> Why choose fms-compatibility? Does it have a side effect of raising the 
> default standard version?
> Why choose fms-compatibility?

I thought that `-fms-compatibility` was the solution we had discussed.

With ms-compat, we retain the space.  Without ms-compat, clang does what clang 
does (which, currently, is to omit the space).

> Does it have a side effect of raising the default standard version?

That was not my intent.  Removing the `-std=c++98` raises the standard.



Comment at: clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp:12
+// RUN:grep -E 'DISubprogram|DICompositeType' | sed -e 's/.*name: 
"\([^"]*\)".*/"\1"/' | \
+// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=MSCOMPAT
 

rnk wrote:
> Any reason not to reuse `--check-prefix=UNQUAL`? This should be the same as 
> the first RUN line, with a different standard.
This partly overlaps with the thread about ms-compat.  But apart from that, I 
was trying to be explicit about what's being tested, which, in this case, is 
the ms-compat.  The reason the old test got the space is somewhat tangential to 
the qualified/unqualified distinction.

If you wanted to not pin to C++98 and not use ms-compat, then you wouldn't 
expect the space.  Maybe that's something that I should also test.


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

https://reviews.llvm.org/D79274



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


[PATCH] D79343: [libc++][test] Adjust move_iterator tests to allow C++20

2020-05-07 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

Regarding the formatting changes, I personally think we should clang-format all 
of libc++, libc++abi and libunwind in one go. Then we'd be done with these 
small issues that add up. And we can even add the revision to 
`.git-blame-ignore-revs`.


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

https://reviews.llvm.org/D79343



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


[PATCH] D79504: [Clang] Wrong return type of atomic_is_lock_free

2020-05-07 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: dexonsmith.

This change LGTM, libc++ will keep working as-is since we assume the builtins 
return `bool` (I checked).


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

https://reviews.llvm.org/D79504



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


[PATCH] D79423: [analyzer][NFC] StdLibraryFunctionsChecker: Add empty Signatures

2020-05-07 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

In D79423#2025001 , @martong wrote:

> 1. Some function types contain non-builtin types. E.g. `FILE*`. We cannot get 
> this type as easily as we do with builtin types (we can get builtins simply 
> from the ASTContext). In case of such a compound type, we should be digging 
> up the type from the AST, and that can be done by doing a lookup.


I see the problem, but as far as I understand, this is not unique to libC or 
Posix. Any libraries that use non-primitive types (which is most of them) will 
suffer from the very same problem. So I anticipated that this type lookup from 
the ASTContext needs to be implemented regardless of the irrelevant signature 
functionality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79423



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


[PATCH] D78933: [analyzer] RangeConstraintManager optimizations in comparison expressions

2020-05-07 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 262667.
ASDenysPetrov edited the summary of this revision.

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

https://reviews.llvm.org/D78933

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constraint_manager_conditions.cpp

Index: clang/test/Analysis/constraint_manager_conditions.cpp
===
--- /dev/null
+++ clang/test/Analysis/constraint_manager_conditions.cpp
@@ -0,0 +1,213 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+
+void comparison_lt(int x, int y) {
+  if (x < y) {
+clang_analyzer_eval(x < y);  // expected-warning{{TRUE}}
+clang_analyzer_eval(y > x);  // expected-warning{{TRUE}}
+clang_analyzer_eval(x > y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y <= x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x == y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}}
+  } else {
+clang_analyzer_eval(x < y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x == y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+  }
+}
+
+void comparison_gt(int x, int y) {
+  if (x > y) {
+clang_analyzer_eval(x < y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{TRUE}}
+clang_analyzer_eval(y < x);  // expected-warning{{TRUE}}
+clang_analyzer_eval(x <= y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y >= x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x == y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}}
+  } else {
+clang_analyzer_eval(x < y);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x == y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+  }
+}
+
+void comparison_le(int x, int y) {
+  if (x <= y) {
+clang_analyzer_eval(x < y);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x == y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expe

[PATCH] D78933: [analyzer] RangeConstraintManager optimizations in comparison expressions

2020-05-07 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov marked an inline comment as done.
ASDenysPetrov added a comment.

Updated the patch due to comments of @xazax.hun




Comment at: clang/test/Analysis/constraint_manager_conditions.cpp:184
+}
\ No newline at end of file


xazax.hun wrote:
> Nit: please add new line at the end of the file.
I've added a new line and checked twice before creating a patch. But it didn't 
appear.


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

https://reviews.llvm.org/D78933



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


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-07 Thread Wei Zhao via Phabricator via cfe-commits
wxz2020 added a comment.

I will put the "PAUnsupported" predicate later once this got passed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129



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


[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-07 Thread Arthur Eubanks via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG48451ee6a7ee: [MSan] Pass MSan command line options under 
new pass manager (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79445

Files:
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1016,8 +1016,11 @@
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, false})));
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
@@ -1236,12 +1239,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager &MPM) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager &MPM) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level) 
{
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager &FPM,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1016,8 +1016,11 @@
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, false})));
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
@@ -1236,12 +1239,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager &MPM) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager &MPM) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level) {
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager &FPM,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262662.
MyDeveloperDay added a comment.

Change to TT_AttributeSquare


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

https://reviews.llvm.org/D79354

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7636,6 +7636,10 @@
   verifyFormat("void f() [[deprecated(\"so sorry\")]];");
   verifyFormat("aa\n"
"[[unused]] aaa(int i);");
+  verifyFormat("[[nodiscard]] bool f() { return false; }");
+  verifyFormat("class [[nodiscard]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[deprecated(\"so sorry\")]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[gnu::unused]] f {\npublic:\n  f() {}\n}");
 
   // Make sure we do not mistake attributes for array subscripts.
   verifyFormat("int a() {}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2399,9 +2399,10 @@
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, TT_AttributeSquare) ||
  ((Style.Language == FormatStyle::LK_Java ||
Style.Language == FormatStyle::LK_JavaScript) &&
   FormatTok->isOneOf(tok::period, tok::comma))) {
@@ -2421,8 +2422,15 @@
 FormatTok->TokenText != FormatTok->TokenText.upper();
 nextToken();
 // We can have macros or attributes in between 'class' and the class name.
-if (!IsNonMacroIdentifier && FormatTok->Tok.is(tok::l_paren))
-  parseParens();
+if (!IsNonMacroIdentifier) {
+  if (FormatTok->Tok.is(tok::l_paren)) {
+parseParens();
+  } else if (FormatTok->is(TT_AttributeSquare)) {
+parseSquare();
+// Consume the closing TT_AttributeSquare.
+nextToken();
+  }
+}
   }
 
   // Note that parsing away template declarations here leads to incorrectly


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7636,6 +7636,10 @@
   verifyFormat("void f() [[deprecated(\"so sorry\")]];");
   verifyFormat("aa\n"
"[[unused]] aaa(int i);");
+  verifyFormat("[[nodiscard]] bool f() { return false; }");
+  verifyFormat("class [[nodiscard]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[deprecated(\"so sorry\")]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[gnu::unused]] f {\npublic:\n  f() {}\n}");
 
   // Make sure we do not mistake attributes for array subscripts.
   verifyFormat("int a() {}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2399,9 +2399,10 @@
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, TT_AttributeSquare) ||
  ((Style.Language == FormatStyle::LK_Java ||
Style.Language == FormatStyle::LK_JavaScript) &&
   FormatTok->isOneOf(tok::period, tok::comma))) {
@@ -2421,8 +2422,15 @@
 FormatTok->TokenText != FormatTok->TokenText.upper();
 nextToken();
 // We can have macros or attributes in between 'class' and the class name.
-if (!IsNonMacroIdentifier && FormatTok->Tok.is(tok::l_paren))
-  parseParens();
+if (!IsNonMacroIdentifier) {
+  if (FormatTok->Tok.is(tok::l_paren)) {
+parseParens();
+  } else if (FormatTok->is(TT_AttributeSquare)) {
+parseSquare();
+// Consume the closing TT_AttributeSquare.
+nextToken();
+  }
+}
   }
 
   // Note that parsing away template declarations here leads to incorrectly
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-05-07 Thread Wei Zhao via Phabricator via cfe-commits
wxz2020 updated this revision to Diff 262665.
wxz2020 added a comment.

I put every people's feedbacks into the code and upload them here.

I think we can use it as the start point for TX3, and add more when we move on.

Thank you all for great help,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129

Files:
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/test/CodeGen/AArch64/aarch64-combine-fmul-fsub.mir
  llvm/test/CodeGen/AArch64/cpus.ll
  llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
  llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
  llvm/test/CodeGen/AArch64/remat.ll

Index: llvm/test/CodeGen/AArch64/remat.ll
===
--- llvm/test/CodeGen/AArch64/remat.ll
+++ llvm/test/CodeGen/AArch64/remat.ll
@@ -19,6 +19,7 @@
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=thunderx2t99 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=tsv110 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mattr=+custom-cheap-as-move -o - %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=thunderx3t110 -o - %s | FileCheck %s
 
 %X = type { i64, i64, i64 }
 declare void @f(%X*)
Index: llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
===
--- llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
+++ llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
@@ -19,6 +19,7 @@
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderxt83 < %s | FileCheck --check-prefixes=ALIGN3,CHECK %s
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderxt88 < %s | FileCheck --check-prefixes=ALIGN3,CHECK %s
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderx2t99 < %s | FileCheck --check-prefixes=ALIGN3,CHECK %s
+; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderx3t110 < %s | FileCheck --check-prefixes=ALIGN4,CHECK %s
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=exynos-m3 < %s | FileCheck --check-prefixes=ALIGN5,CHECK %s
 
 define void @test() {
Index: llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
===
--- llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
+++ llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
@@ -6,6 +6,7 @@
 ; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=exynos-m3  < %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=kryo   < %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=thunderx2t99 < %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=thunderx3t110 < %s | FileCheck %s
 
 ; Make sure that inst-combine fuses the multiply add in the addressing mode of
 ; the load.
Index: llvm/test/CodeGen/AArch64/cpus.ll
===
--- llvm/test/CodeGen/AArch64/cpus.ll
+++ llvm/test/CodeGen/AArch64/cpus.ll
@@ -24,6 +24,7 @@
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=saphira 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=kryo 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=thunderx2t99 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=thunderx3t110 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=tsv110 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=apple-latest 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=a64fx 2>&1 | FileCheck %s
Index: llvm/test/CodeGen/AArch64/aarch64-combine-fmul-fsub.mir
===
--- llvm/test/CodeGen/AArch64/aarch64-combine-fmul-fsub.mir
+++ llvm/test/CodeGen/AArch64/aarch64-combine-fmul-fsub.mir
@@ -2,6 +2,7 @@
 # RUN: llc -run-pass=machine-combiner -o - -mtriple=aarch64-unknown-linux -mcpu=falkor -enable-unsafe-fp-math %s -machine-combiner-verify-pattern-order=true | FileCheck --check-prefixes=PROFITABLE,ALL %s
 # RUN: llc -run-pass=machine-combiner -o - -mtriple=aarch64-unknown-linux -mcpu=exynos-m3 -enable-unsafe-fp-math -machine-combiner-verify-pattern-order=true %s | FileCheck --check-prefixes=PROFITABLE,ALL %s
 # RUN: llc -run-pass=machine-combiner -o - -mtriple=aarch64-unknown-linux -mcpu=thunderx2t99 -enable-unsafe-fp-math -machine-combiner-verify-pattern-order=true %s | FileCheck --check-prefixes=PROFITABLE,ALL %s
+# RUN: llc -run-pass=machine-combiner -o - -mtriple=aarch64-unknown-linux -mcpu=thunderx3t110 -enable-unsafe-fp-math -machine-combiner-verify-pattern-order=true %s | FileCheck --check-prefixes=PROFITABLE,ALL %s
 #
 name:f1_2s
 registers:
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
=

[PATCH] D79072: [Analyzer][VLASizeChecker] Check VLA size in typedef and sizeof.

2020-05-07 Thread Balázs Kéri via Phabricator via cfe-commits
balazske marked 3 inline comments as done.
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp:577
+  if (isa(*DS->decl_begin())) {
+ExplodedNodeSet DstPre;
+getCheckerManager().runCheckersForPreStmt(DstPre, Pred, DS, *this);

Should we not do something else with the VLA size expressions (not only call 
the checker callbacks) because they should be evaluated, are these handled in 
some other way automatically? (The CFG should contain these expressions already 
so these should be evaluated by the engine, and this place is only to make the 
checkers aware of `typedef` statements.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79072



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


[PATCH] D79072: [Analyzer][VLASizeChecker] Check VLA size in typedef and sizeof.

2020-05-07 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

I'd split this patch into two as well.

1. [NFC] Refactoring parts
2. The actual extra additions about sizeof and typedef.

WDYT?

Other than that looks good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79072



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


  1   2   >