[clang] c42116c - Fix up ms-pch-macro.c test to pass on non-Windows

2020-01-14 Thread Reid Kleckner via cfe-commits

Author: Reid Kleckner
Date: 2020-01-14T22:19:30-08:00
New Revision: c42116cc653ae1618cc49dab367d9f6addd8cfd9

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

LOG: Fix up ms-pch-macro.c test to pass on non-Windows

Added: 


Modified: 
clang/test/PCH/ms-pch-macro.c

Removed: 




diff  --git a/clang/test/PCH/ms-pch-macro.c b/clang/test/PCH/ms-pch-macro.c
index eb45be1b6b73..3a8052eb322e 100644
--- a/clang/test/PCH/ms-pch-macro.c
+++ b/clang/test/PCH/ms-pch-macro.c
@@ -8,16 +8,16 @@
 // RUN: not %clang_cc1 -UFOO -DBAR=int -include-pch %t1.pch %s 
-pch-through-header=%S/variables.h 2> %t.err
 // RUN: FileCheck -check-prefix=CHECK-NOFOO %s < %t.err
 
-// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s
 
 // Enabling MS extensions should allow us to add BAR definitions.
-// RUN: %clang_cc1 -fms-extensions -DFOO %S/variables.h -emit-pch -o %t1.pch
-// RUN: %clang_cc1 -fms-extensions -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+// RUN: %clang_cc1 -DMSEXT -fms-extensions -DFOO %S/variables.h -emit-pch -o 
%t1.pch
+// RUN: %clang_cc1 -DMSEXT -fms-extensions -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s
 
 #include "variables.h"
 
 BAR bar = 17;
-#ifndef _MSC_EXTENSIONS
+#ifndef MSEXT
 // expected-error@-2 {{unknown type name 'BAR'}}
 #endif
 
@@ -29,7 +29,7 @@ BAR bar = 17;
 #  error FOO has the wrong definition
 #endif
 
-#if defined(_MSC_EXTENSIONS) && !defined(BAR)
+#if defined(MSEXT) && !defined(BAR)
 #  error BAR was not defined
 #endif
 



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


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

2020-01-14 Thread Richard Trieu via Phabricator via cfe-commits
rtrieu added a comment.

Heads up in case it affects you refactoring work:
While looking through this code, I found a bug I previously made.  I fixed it 
with a small change, but that lies in the middle of your refactoring during 
FieldDecl handling.  The change is here:

https://reviews.llvm.org/rGa60e8927297005898b10a46300d929ba5cf7833c


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71734



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


[PATCH] D72463: [Driver][X86] Add -malign-branch* and -malign-branch-within-32B-boundaries

2020-01-14 Thread Fangrui Song via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5ca24d09aefa: [Driver][X86] Add -malign-branch* and 
-mbranches-within-32B-boundaries (authored by MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D72463?vs=238120&id=238167#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72463

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/x86-malign-branch.c
  clang/test/Driver/x86-malign-branch.s

Index: clang/test/Driver/x86-malign-branch.s
===
--- /dev/null
+++ clang/test/Driver/x86-malign-branch.s
@@ -0,0 +1,13 @@
+/// Test that -malign-branch* and -mbranches-within-32B-boundaries are handled for assembly files.
+
+// RUN: %clang -target x86_64 -malign-branch-boundary=16 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY
+// BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+
+// RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE
+// TYPE: "-mllvm" "-x86-align-branch=fused+jcc+jmp"
+
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=5 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX
+// PREFIX: "-mllvm" "-x86-align-branch-prefix-size=5"
+
+// RUN: %clang -target x86_64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck %s --check-prefix=32B
+// 32B: "-mllvm" "-x86-branches-within-32B-boundaries"
Index: clang/test/Driver/x86-malign-branch.c
===
--- /dev/null
+++ clang/test/Driver/x86-malign-branch.c
@@ -0,0 +1,39 @@
+/// Test that -malign-branch* and -mbranches-within-32B-boundaries are parsed and converted to -mllvm options.
+
+/// Test -malign-branch-boundary=
+// RUN: %clang -target x86_64 -malign-branch-boundary=16 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY
+// BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+
+// RUN: %clang -target x86_64 -malign-branch-boundary=8 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-ERR
+// RUN: %clang -target x86_64 -malign-branch-boundary=15 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-ERR
+// BOUNDARY-ERR: invalid argument {{.*}} to -malign-branch-boundary=
+
+/// Test -malign-branch=
+// RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE0
+// TYPE0: "-mllvm" "-x86-align-branch=fused+jcc+jmp"
+// RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp,ret,call,indirect %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE1
+// TYPE1: "-mllvm" "-x86-align-branch=fused+jcc+jmp+ret+call+indirect"
+
+// RUN: %clang -target x86_64 -malign-branch=fused,foo,bar %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE-ERR
+// TYPE-ERR: invalid argument 'foo' to -malign-branch=; each element must be one of: fused, jcc, jmp, call, ret, indirect
+// TYPE-ERR: invalid argument 'bar' to -malign-branch=; each element must be one of: fused, jcc, jmp, call, ret, indirect
+
+/// Test -malign-branch-prefix-size=
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=0 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-0
+// PREFIX-0: "-mllvm" "-x86-align-branch-prefix-size=0"
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=5 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-5
+// PREFIX-5: "-mllvm" "-x86-align-branch-prefix-size=5"
+
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=6 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-6
+// PREFIX-6: invalid argument
+
+/// Test -mbranches-within-32B-boundaries
+// RUN: %clang -target x86_64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck %s --check-prefix=32B
+// 32B: "-mllvm" "-x86-branches-within-32B-boundaries"
+
+/// Unsupported on other targets.
+// RUN: %clang -target aarch64 -malign-branch=jmp %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// RUN: %clang -target aarch64 -malign-branch-boundary=7 %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// RUN: %clang -target aarch64 -malign-branch-prefix-size=15 %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// RUN: %clang -target aarch64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// UNUSED: warning: argument unused
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2015,8 +2015,59 @@
 CmdArgs.push_back("-mpacked-stack");
 }
 
+static void addX86AlignBranchArgs(const Driver &D, const ArgList &Args,
+  ArgStringList &CmdArgs) {
+  if (Args.hasArg(options::OPT_mbranches_within_32B_boundaries)) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-x86-branches-

[clang] 5ca24d0 - [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundaries

2020-01-14 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-01-14T21:57:06-08:00
New Revision: 5ca24d09aefaedf8e4148c7fce4b4ab0c4ecc72a

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

LOG: [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundaries

These driver options perform some checking and delegate to MC options 
-x86-align-branch* and -x86-branches-within-32B-boundaries.

Reviewed By: skan

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

Added: 
clang/test/Driver/x86-malign-branch.c
clang/test/Driver/x86-malign-branch.s

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 752ed2d255b7..0fe14e4e05be 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -250,6 +250,9 @@ def err_drv_unsupported_embed_bitcode
 def err_drv_bitcode_unsupported_on_toolchain : Error<
   "-fembed-bitcode is not supported on versions of iOS prior to 6.0">;
 
+def err_drv_invalid_malign_branch_EQ : Error<
+  "invalid argument '%0' to -malign-branch=; each element must be one of: %1">;
+
 def warn_O4_is_O3 : Warning<"-O4 is equivalent to -O3">, InGroup;
 def warn_drv_optimization_value : Warning<"optimization level '%0' is not 
supported; using '%1%2' instead">,
   InGroup;

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 385ddbf5e40d..1218172fd5b6 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2146,6 +2146,10 @@ def mno_iamcu : Flag<["-"], "mno-iamcu">, 
Group, Flags<[DriverOption, C
 def malign_functions_EQ : Joined<["-"], "malign-functions=">, 
Group;
 def malign_loops_EQ : Joined<["-"], "malign-loops=">, 
Group;
 def malign_jumps_EQ : Joined<["-"], "malign-jumps=">, 
Group;
+def malign_branch_EQ : CommaJoined<["-"], "malign-branch=">, Group;
+def malign_branch_boundary_EQ : Joined<["-"], "malign-branch-boundary=">, 
Group;
+def malign_branch_prefix_size_EQ : Joined<["-"], 
"malign-branch-prefix-size=">, Group;
+def mbranches_within_32B_boundaries : Flag<["-"], 
"mbranches-within-32B-boundaries">, Flags<[DriverOption]>, Group;
 def mfancy_math_387 : Flag<["-"], "mfancy-math-387">, 
Group;
 def mlong_calls : Flag<["-"], "mlong-calls">, Group,
   HelpText<"Generate branches with extended addressability, usually via 
indirect jumps.">;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 646627c6d40c..9b3055413e9e 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2015,8 +2015,59 @@ void Clang::AddSystemZTargetArgs(const ArgList &Args,
 CmdArgs.push_back("-mpacked-stack");
 }
 
+static void addX86AlignBranchArgs(const Driver &D, const ArgList &Args,
+  ArgStringList &CmdArgs) {
+  if (Args.hasArg(options::OPT_mbranches_within_32B_boundaries)) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-x86-branches-within-32B-boundaries");
+  }
+  if (const Arg *A = Args.getLastArg(options::OPT_malign_branch_boundary_EQ)) {
+StringRef Value = A->getValue();
+unsigned Boundary;
+if (Value.getAsInteger(10, Boundary) || Boundary < 16 ||
+!llvm::isPowerOf2_64(Boundary)) {
+  D.Diag(diag::err_drv_invalid_argument_to_option)
+  << Value << A->getOption().getName();
+} else {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(
+  Args.MakeArgString("-x86-align-branch-boundary=" + Twine(Boundary)));
+}
+  }
+  if (const Arg *A = Args.getLastArg(options::OPT_malign_branch_EQ)) {
+std::string AlignBranch;
+for (StringRef T : A->getValues()) {
+  if (T != "fused" && T != "jcc" && T != "jmp" && T != "call" &&
+  T != "ret" && T != "indirect")
+D.Diag(diag::err_drv_invalid_malign_branch_EQ)
+<< T << "fused, jcc, jmp, call, ret, indirect";
+  if (!AlignBranch.empty())
+AlignBranch += '+';
+  AlignBranch += T;
+}
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back(Args.MakeArgString("-x86-align-branch=" + AlignBranch));
+  }
+  if (const Arg *A =
+  Args.getLastArg(options::OPT_malign_branch_prefix_size_EQ)) {
+StringRef Value = A->getValue();
+unsigned PrefixSize;
+if (Value.getAsInteger(10, PrefixSize) || PrefixSize > 5) {
+  D.Diag(diag::err_drv_invalid_argument_to_option)
+  << Value << A->getOption().getName();
+} else {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(Args.MakeArgString("-x86-align-branch-prefix-siz

[PATCH] D72227: [Driver][X86] Add -malign-branch* and -malign-branch-within-32B-boundaries

2020-01-14 Thread Kan Shengchen via Phabricator via cfe-commits
skan abandoned this revision.
skan added a comment.

The override principle of driver should keep same with MC (D72738 
). D72463  is 
better, so I prefer to abandon this revision.


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

https://reviews.llvm.org/D72227



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


[PATCH] D72463: [Driver][X86] Add -malign-branch* and -malign-branch-within-32B-boundaries

2020-01-14 Thread Kan Shengchen via Phabricator via cfe-commits
skan accepted this revision.
skan added a comment.
This revision is now accepted and ready to land.

LGTM
The principle of override here is consistent with MC (D72738 
). So I think this patch is better than D72227 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72463



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


[clang] a60e892 - [ODRHash] Fix wrong error message with bitfields and mutable.

2020-01-14 Thread via cfe-commits

Author: Weverything
Date: 2020-01-14T21:12:15-08:00
New Revision: a60e8927297005898b10a46300d929ba5cf7833c

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

LOG: [ODRHash] Fix wrong error message with bitfields and mutable.

Add a check to bitfield mismatches that may have caused Clang to
give an error about the bitfield instead of being mutable.

Added: 


Modified: 
clang/lib/Serialization/ASTReader.cpp
clang/test/Modules/odr_hash.cpp

Removed: 




diff  --git a/clang/lib/Serialization/ASTReader.cpp 
b/clang/lib/Serialization/ASTReader.cpp
index 6c8bc7dc33a9..19e7ebe03a1f 100644
--- a/clang/lib/Serialization/ASTReader.cpp
+++ b/clang/lib/Serialization/ASTReader.cpp
@@ -10094,14 +10094,22 @@ void ASTReader::diagnoseOdrViolations() {
 }
 
 if (IsFirstBitField && IsSecondBitField) {
-  ODRDiagError(FirstField->getLocation(), FirstField->getSourceRange(),
-   FieldDifferentWidthBitField)
-  << FirstII << FirstField->getBitWidth()->getSourceRange();
-  ODRDiagNote(SecondField->getLocation(), 
SecondField->getSourceRange(),
-  FieldDifferentWidthBitField)
-  << SecondII << SecondField->getBitWidth()->getSourceRange();
-  Diagnosed = true;
-  break;
+  unsigned FirstBitWidthHash =
+  ComputeODRHash(FirstField->getBitWidth());
+  unsigned SecondBitWidthHash =
+  ComputeODRHash(SecondField->getBitWidth());
+  if (FirstBitWidthHash != SecondBitWidthHash) {
+ODRDiagError(FirstField->getLocation(),
+ FirstField->getSourceRange(),
+ FieldDifferentWidthBitField)
+<< FirstII << FirstField->getBitWidth()->getSourceRange();
+ODRDiagNote(SecondField->getLocation(),
+SecondField->getSourceRange(),
+FieldDifferentWidthBitField)
+<< SecondII << SecondField->getBitWidth()->getSourceRange();
+Diagnosed = true;
+break;
+  }
 }
 
 const bool IsFirstMutable = FirstField->isMutable();

diff  --git a/clang/test/Modules/odr_hash.cpp b/clang/test/Modules/odr_hash.cpp
index ff7cfb3ae7fd..6d26b3cfb570 100644
--- a/clang/test/Modules/odr_hash.cpp
+++ b/clang/test/Modules/odr_hash.cpp
@@ -310,6 +310,20 @@ S9 s9;
 // expected-note@first.h:* {{but in 'FirstModule' found mutable field 'x'}}
 #endif
 
+#if defined(FIRST)
+struct S9b {
+  mutable int x : 2;
+};
+#elif defined(SECOND)
+struct S9b {
+  int x : 2;
+};
+#else
+S9b s9b;
+// expected-error@second.h:* {{'Field::S9b' has 
diff erent definitions in 
diff erent modules; first 
diff erence is definition in module 'SecondModule' found non-mutable field 'x'}}
+// expected-note@first.h:* {{but in 'FirstModule' found mutable field 'x'}}
+#endif
+
 #if defined(FIRST)
 struct S10 {
   unsigned x = 5;
@@ -372,7 +386,9 @@ S13 s13;
   unsigned c : 1 + 2; \
   s d;\
   double e = 1.0; \
-  long f[5];
+  long f[5];  \
+  mutable int g;  \
+  mutable int h : 5;
 
 #if defined(FIRST) || defined(SECOND)
 typedef short s;



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


[PATCH] D72747: [objc_direct] Allow for direct messages be sent to `self` when it is a Class

2020-01-14 Thread Pierre Habouzit via Phabricator via cfe-commits
MadCoder created this revision.
MadCoder added reviewers: ahatanak, arphaman, dexonsmith, erik.pilkington.
MadCoder added a project: clang.
Herald added a subscriber: cfe-commits.

Sending a message to `self` when it is const and within a class method is safe 
because we know that `self` is the Class itself.

We can only relax this error in ARC.

Radar-Id: rdar://problem/58581965


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72747

Files:
  clang/lib/Sema/SemaExprObjC.cpp
  clang/test/SemaObjC/method-direct-arc.m


Index: clang/test/SemaObjC/method-direct-arc.m
===
--- /dev/null
+++ clang/test/SemaObjC/method-direct-arc.m
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fobjc-arc -fsyntax-only -verify -Wselector-type-mismatch %s
+
+extern Class object_getClass(id);
+
+__attribute__((objc_root_class))
+@interface Root
+- (Class)class;
++ (void)directMethod1 __attribute__((objc_direct)); // expected-note {{direct 
method 'directMethod1' declared here}}
++ (void)directMethod2 __attribute__((objc_direct));
+@end
+
+@implementation Root
+- (Class)class
+{
+  return object_getClass(self);
+}
++ (void)directMethod1 {
+}
++ (void)directMethod2 {
+  [self directMethod1]; // this should not warn
+}
++ (void)regularMethod {
+  [self directMethod1]; // this should not warn
+  [self directMethod2]; // this should not warn
+}
+- (void)regularInstanceMethod {
+  [[self class] directMethod1]; // expected-error {{messaging a Class with a 
method that is possibly direct}}
+}
+@end
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -3012,7 +3012,11 @@
   << Method->getDeclName();
 }
 
-if (ReceiverType->isObjCClassType() && !isImplicit) {
+   // Under ARC, self can't be assigned, and doing a direct call to `self`
+   // when it's a Class is hence safe.  For other cases, we can't trust 
`self`
+   // is what we think it is, so we reject it.
+if (ReceiverType->isObjCClassType() && !isImplicit &&
+(!Receiver->isObjCSelfExpr() || !getLangOpts().ObjCAutoRefCount)) {
   Diag(Receiver->getExprLoc(),
diag::err_messaging_class_with_direct_method);
   Diag(Method->getLocation(), diag::note_direct_method_declared_at)


Index: clang/test/SemaObjC/method-direct-arc.m
===
--- /dev/null
+++ clang/test/SemaObjC/method-direct-arc.m
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fobjc-arc -fsyntax-only -verify -Wselector-type-mismatch %s
+
+extern Class object_getClass(id);
+
+__attribute__((objc_root_class))
+@interface Root
+- (Class)class;
++ (void)directMethod1 __attribute__((objc_direct)); // expected-note {{direct method 'directMethod1' declared here}}
++ (void)directMethod2 __attribute__((objc_direct));
+@end
+
+@implementation Root
+- (Class)class
+{
+  return object_getClass(self);
+}
++ (void)directMethod1 {
+}
++ (void)directMethod2 {
+  [self directMethod1]; // this should not warn
+}
++ (void)regularMethod {
+  [self directMethod1]; // this should not warn
+  [self directMethod2]; // this should not warn
+}
+- (void)regularInstanceMethod {
+  [[self class] directMethod1]; // expected-error {{messaging a Class with a method that is possibly direct}}
+}
+@end
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -3012,7 +3012,11 @@
   << Method->getDeclName();
 }
 
-if (ReceiverType->isObjCClassType() && !isImplicit) {
+	// Under ARC, self can't be assigned, and doing a direct call to `self`
+	// when it's a Class is hence safe.  For other cases, we can't trust `self`
+	// is what we think it is, so we reject it.
+if (ReceiverType->isObjCClassType() && !isImplicit &&
+(!Receiver->isObjCSelfExpr() || !getLangOpts().ObjCAutoRefCount)) {
   Diag(Receiver->getExprLoc(),
diag::err_messaging_class_with_direct_method);
   Diag(Method->getLocation(), diag::note_direct_method_declared_at)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D71682: Relax the rules around objc_alloc and objc_alloc_init optimizations.

2020-01-14 Thread Pierre Habouzit via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd18fbfc09720: Relax the rules around objc_alloc and 
objc_alloc_init optimizations. (authored by MadCoder).

Changed prior to commit:
  https://reviews.llvm.org/D71682?vs=234644&id=238161#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71682

Files:
  clang/lib/CodeGen/CGObjC.cpp
  clang/test/CodeGenObjC/objc-alloc-init.m

Index: clang/test/CodeGenObjC/objc-alloc-init.m
===
--- clang/test/CodeGenObjC/objc-alloc-init.m
+++ clang/test/CodeGenObjC/objc-alloc-init.m
@@ -22,21 +22,30 @@
 }
 
 @interface Y : X
++(Class)class;
 +(void)meth;
 -(void)instanceMeth;
 @end
 
 @implementation Y
++(Class)class {
+  return self;
+}
 +(void)meth {
   [[self alloc] init];
   // OPTIMIZED: call i8* @objc_alloc_init(
   // NOT_OPTIMIZED: call i8* @objc_alloc(
 }
++ (void)meth2 {
+  [[[self class] alloc] init];
+  // OPTIMIZED: call i8* @objc_alloc_init(
+  // NOT_OPTIMIZED: call i8* @objc_alloc(
+}
 -(void)instanceMeth {
   // EITHER-NOT: call i8* @objc_alloc
   // EITHER: call {{.*}} @objc_msgSend
   // EITHER: call {{.*}} @objc_msgSend
-  [[self alloc] init];
+  [[(id)self alloc] init];
 }
 @end
 
Index: clang/lib/CodeGen/CGObjC.cpp
===
--- clang/lib/CodeGen/CGObjC.cpp
+++ clang/lib/CodeGen/CGObjC.cpp
@@ -461,38 +461,39 @@
   Sel.getNameForSlot(0) != "init")
 return None;
 
-  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]' or
-  // we are in an ObjC class method and 'receiver' is '[self alloc]'.
+  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]'
+  // with 'cls' a Class.
   auto *SubOME =
   dyn_cast(OME->getInstanceReceiver()->IgnoreParenCasts());
   if (!SubOME)
 return None;
   Selector SubSel = SubOME->getSelector();
 
-  // Check if we are in an ObjC class method and the receiver expression is
-  // 'self'.
-  const Expr *SelfInClassMethod = nullptr;
-  if (const auto *CurMD = dyn_cast_or_null(CGF.CurFuncDecl))
-if (CurMD->isClassMethod())
-  if ((SelfInClassMethod = SubOME->getInstanceReceiver()))
-if (!SelfInClassMethod->isObjCSelfExpr())
-  SelfInClassMethod = nullptr;
-
-  if ((SubOME->getReceiverKind() != ObjCMessageExpr::Class &&
-   !SelfInClassMethod) || !SubOME->getType()->isObjCObjectPointerType() ||
+  if (!SubOME->getType()->isObjCObjectPointerType() ||
   !SubSel.isUnarySelector() || SubSel.getNameForSlot(0) != "alloc")
 return None;
 
-  llvm::Value *Receiver;
-  if (SelfInClassMethod) {
-Receiver = CGF.EmitScalarExpr(SelfInClassMethod);
-  } else {
+  llvm::Value *Receiver = nullptr;
+  switch (SubOME->getReceiverKind()) {
+  case ObjCMessageExpr::Instance:
+if (!SubOME->getInstanceReceiver()->getType()->isObjCClassType())
+  return None;
+Receiver = CGF.EmitScalarExpr(SubOME->getInstanceReceiver());
+break;
+
+  case ObjCMessageExpr::Class: {
 QualType ReceiverType = SubOME->getClassReceiver();
 const ObjCObjectType *ObjTy = ReceiverType->castAs();
 const ObjCInterfaceDecl *ID = ObjTy->getInterface();
 assert(ID && "null interface should be impossible here");
 Receiver = CGF.CGM.getObjCRuntime().GetClass(CGF, ID);
+break;
+  }
+  case ObjCMessageExpr::SuperInstance:
+  case ObjCMessageExpr::SuperClass:
+return None;
   }
+
   return CGF.EmitObjCAllocInit(Receiver, CGF.ConvertType(OME->getType()));
 }
 
@@ -540,10 +541,7 @@
   switch (E->getReceiverKind()) {
   case ObjCMessageExpr::Instance:
 ReceiverType = E->getInstanceReceiver()->getType();
-if (auto *OMD = dyn_cast_or_null(CurFuncDecl))
-  if (OMD->isClassMethod())
-if (E->getInstanceReceiver()->isObjCSelfExpr())
-  isClassMessage = true;
+isClassMessage = ReceiverType->isObjCClassType();
 if (retainSelf) {
   TryEmitResult ter = tryEmitARCRetainScalarExpr(*this,
E->getInstanceReceiver());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] d18fbfc - Relax the rules around objc_alloc and objc_alloc_init optimizations.

2020-01-14 Thread Pierre Habouzit via cfe-commits

Author: Pierre Habouzit
Date: 2020-01-14T19:48:33-08:00
New Revision: d18fbfc09720009c0dc6a1ddf315402ee0a7751d

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

LOG: Relax the rules around objc_alloc and objc_alloc_init optimizations.

Today the optimization is limited to:
- `[ClassName alloc]`
- `[self alloc]` when within a class method

However it means that when code is written this way:

```
@interface MyObject
- (id)copyWithZone:(NSZone *)zone
{
return [[self.class alloc] _initWith...];
}

@end
```

... then the optimization doesn't kick in and `+[NSObject alloc]` ends
up in IMP caches where it could have been avoided. It turns out that
`+alloc` -> `+[NSObject alloc]` is the most cached SEL/IMP pair in the
entire platform which is rather silly).

There's two theoretical risks allowing this optimization:

1. if the receiver is nil (which it can't be today), but it turns out
   that `objc_alloc()`/`objc_alloc_init()` cope with a nil receiver,

2. if the `Clas` type for the receiver is a lie. However, for such a
   code to work today (and not fail witn an unrecognized selector
   anyway) you'd have to have implemented the `-alloc` **instance
   method**.

   Fortunately, `objc_alloc()` doesn't assume that the receiver is a
   Class, it basically starts with a test that is similar to

   `if (receiver->isa->bits & hasDefaultAWZ) { /* fastpath */ }`.

   This bit is only set on metaclasses by the runtime, so if an instance
   is passed to this function by accident, its isa will fail this test,
   and `objc_alloc()` will gracefully fallback to `objc_msgSend()`.

   The one thing `objc_alloc()` doesn't support is tagged pointer
   instances. None of the tagged pointer classes implement an instance
   method called `'alloc'` (actually there's a single class in the
   entire Apple codebase that has such a method).

Differential Revision: https://reviews.llvm.org/D71682
Radar-Id: rdar://problem/58058316
Reviewed-By: Akira Hatanaka
Signed-off-by: Pierre Habouzit 

Added: 


Modified: 
clang/lib/CodeGen/CGObjC.cpp
clang/test/CodeGenObjC/objc-alloc-init.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index c52aa6bb5496..90fca2836d99 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -461,38 +461,39 @@ tryEmitSpecializedAllocInit(CodeGenFunction &CGF, const 
ObjCMessageExpr *OME) {
   Sel.getNameForSlot(0) != "init")
 return None;
 
-  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]' or
-  // we are in an ObjC class method and 'receiver' is '[self alloc]'.
+  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]'
+  // with 'cls' a Class.
   auto *SubOME =
   
dyn_cast(OME->getInstanceReceiver()->IgnoreParenCasts());
   if (!SubOME)
 return None;
   Selector SubSel = SubOME->getSelector();
 
-  // Check if we are in an ObjC class method and the receiver expression is
-  // 'self'.
-  const Expr *SelfInClassMethod = nullptr;
-  if (const auto *CurMD = dyn_cast_or_null(CGF.CurFuncDecl))
-if (CurMD->isClassMethod())
-  if ((SelfInClassMethod = SubOME->getInstanceReceiver()))
-if (!SelfInClassMethod->isObjCSelfExpr())
-  SelfInClassMethod = nullptr;
-
-  if ((SubOME->getReceiverKind() != ObjCMessageExpr::Class &&
-   !SelfInClassMethod) || !SubOME->getType()->isObjCObjectPointerType() ||
+  if (!SubOME->getType()->isObjCObjectPointerType() ||
   !SubSel.isUnarySelector() || SubSel.getNameForSlot(0) != "alloc")
 return None;
 
-  llvm::Value *Receiver;
-  if (SelfInClassMethod) {
-Receiver = CGF.EmitScalarExpr(SelfInClassMethod);
-  } else {
+  llvm::Value *Receiver = nullptr;
+  switch (SubOME->getReceiverKind()) {
+  case ObjCMessageExpr::Instance:
+if (!SubOME->getInstanceReceiver()->getType()->isObjCClassType())
+  return None;
+Receiver = CGF.EmitScalarExpr(SubOME->getInstanceReceiver());
+break;
+
+  case ObjCMessageExpr::Class: {
 QualType ReceiverType = SubOME->getClassReceiver();
 const ObjCObjectType *ObjTy = ReceiverType->castAs();
 const ObjCInterfaceDecl *ID = ObjTy->getInterface();
 assert(ID && "null interface should be impossible here");
 Receiver = CGF.CGM.getObjCRuntime().GetClass(CGF, ID);
+break;
+  }
+  case ObjCMessageExpr::SuperInstance:
+  case ObjCMessageExpr::SuperClass:
+return None;
   }
+
   return CGF.EmitObjCAllocInit(Receiver, CGF.ConvertType(OME->getType()));
 }
 
@@ -540,10 +541,7 @@ RValue CodeGenFunction::EmitObjCMessageExpr(const 
ObjCMessageExpr *E,
   switch (E->getReceiverKind()) {
   case ObjCMessageExpr::Instance:
 ReceiverType = E->getInstanceReceiver()->getType();
-if (auto *OMD = dyn_cast_or_nu

[PATCH] D72405: Allow /D flags absent during PCH creation under msvc-compat

2020-01-14 Thread Zachary Henkel via Phabricator via cfe-commits
zahen added a comment.

Wild guess is that `2> %t.err` should be removed from the `-verify` lines? That 
change passes in the single env I have access to.  @rnk any idea what might be 
going on?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72405



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


[clang] 1b5404a - PR44540: Prefer an inherited default constructor over an initializer

2020-01-14 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-01-14T19:29:50-08:00
New Revision: 1b5404aff37953ce4c10191d04872ed7c2dc6548

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

LOG: PR44540: Prefer an inherited default constructor over an initializer
list constructor when initializing from {}.

We would previously pick between calling an initializer list constructor
and calling a default constructor unstably in this situation, depending
on whether the inherited default constructor had already been used
elsewhere in the program.

Added: 


Modified: 
clang/lib/AST/DeclCXX.cpp
clang/lib/Sema/SemaInit.cpp
clang/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp

Removed: 




diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index bc75c4e544d2..2ead1e70ea0d 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -738,49 +738,55 @@ void CXXRecordDecl::addedMember(Decl *D) {
 
   // Handle constructors.
   if (const auto *Constructor = dyn_cast(D)) {
-if (!Constructor->isImplicit()) {
-  // Note that we have a user-declared constructor.
-  data().UserDeclaredConstructor = true;
+if (Constructor->isInheritingConstructor()) {
+  // Ignore constructor shadow declarations. They are lazily created and
+  // so shouldn't affect any properties of the class.
+} else {
+  if (!Constructor->isImplicit()) {
+// Note that we have a user-declared constructor.
+data().UserDeclaredConstructor = true;
+
+// C++ [class]p4:
+//   A POD-struct is an aggregate class [...]
+// Since the POD bit is meant to be C++03 POD-ness, clear it even if
+// the type is technically an aggregate in C++0x since it wouldn't be
+// in 03.
+data().PlainOldData = false;
+  }
 
-  // C++ [class]p4:
-  //   A POD-struct is an aggregate class [...]
-  // Since the POD bit is meant to be C++03 POD-ness, clear it even if the
-  // type is technically an aggregate in C++0x since it wouldn't be in 03.
-  data().PlainOldData = false;
-}
+  if (Constructor->isDefaultConstructor()) {
+SMKind |= SMF_DefaultConstructor;
 
-if (Constructor->isDefaultConstructor()) {
-  SMKind |= SMF_DefaultConstructor;
+if (Constructor->isUserProvided())
+  data().UserProvidedDefaultConstructor = true;
+if (Constructor->isConstexpr())
+  data().HasConstexprDefaultConstructor = true;
+if (Constructor->isDefaulted())
+  data().HasDefaultedDefaultConstructor = true;
+  }
 
-  if (Constructor->isUserProvided())
-data().UserProvidedDefaultConstructor = true;
-  if (Constructor->isConstexpr())
-data().HasConstexprDefaultConstructor = true;
-  if (Constructor->isDefaulted())
-data().HasDefaultedDefaultConstructor = true;
-}
+  if (!FunTmpl) {
+unsigned Quals;
+if (Constructor->isCopyConstructor(Quals)) {
+  SMKind |= SMF_CopyConstructor;
 
-if (!FunTmpl) {
-  unsigned Quals;
-  if (Constructor->isCopyConstructor(Quals)) {
-SMKind |= SMF_CopyConstructor;
+  if (Quals & Qualifiers::Const)
+data().HasDeclaredCopyConstructorWithConstParam = true;
+} else if (Constructor->isMoveConstructor())
+  SMKind |= SMF_MoveConstructor;
+  }
 
-if (Quals & Qualifiers::Const)
-  data().HasDeclaredCopyConstructorWithConstParam = true;
-  } else if (Constructor->isMoveConstructor())
-SMKind |= SMF_MoveConstructor;
+  // C++11 [dcl.init.aggr]p1: DR1518
+  //   An aggregate is an array or a class with no user-provided [or]
+  //   explicit [...] constructors
+  // C++20 [dcl.init.aggr]p1:
+  //   An aggregate is an array or a class with no user-declared [...]
+  //   constructors
+  if (getASTContext().getLangOpts().CPlusPlus2a
+  ? !Constructor->isImplicit()
+  : (Constructor->isUserProvided() || Constructor->isExplicit()))
+data().Aggregate = false;
 }
-
-// C++11 [dcl.init.aggr]p1: DR1518
-//   An aggregate is an array or a class with no user-provided [or]
-//   explicit [...] constructors
-// C++20 [dcl.init.aggr]p1:
-//   An aggregate is an array or a class with no user-declared [...]
-//   constructors
-if (getASTContext().getLangOpts().CPlusPlus2a
-? !Constructor->isImplicit()
-: (Constructor->isUserProvided() || Constructor->isExplicit()))
-  data().Aggregate = false;
   }
 
   // Handle constructors, including those inherited from base classes.

diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index 163ad8dc54dc..785637761e71 100644
--- a/clang/lib/Sema/SemaInit

[clang] c6e6988 - Modify test to use -S instead of -c so that it works when an external assembler is used that is not present.

2020-01-14 Thread Douglas Yung via cfe-commits

Author: Douglas Yung
Date: 2020-01-14T18:58:18-08:00
New Revision: c6e69880ae4d9ce4d27bf046292a0a20c3ab3540

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

LOG: Modify test to use -S instead of -c so that it works when an external 
assembler is used that is not present.

Added: 


Modified: 
clang/test/Driver/cc1-spawnprocess.c

Removed: 




diff  --git a/clang/test/Driver/cc1-spawnprocess.c 
b/clang/test/Driver/cc1-spawnprocess.c
index db13d8ce85d9..c5c16ce8513f 100644
--- a/clang/test/Driver/cc1-spawnprocess.c
+++ b/clang/test/Driver/cc1-spawnprocess.c
@@ -1,4 +1,4 @@
-// RUN: env CLANG_SPAWN_CC1= %clang -c %s -o /dev/null
-// RUN: env CLANG_SPAWN_CC1=0 %clang -c %s -o /dev/null
-// RUN: env CLANG_SPAWN_CC1=1 %clang -c %s -o /dev/null
-// RUN: env CLANG_SPAWN_CC1=test not %clang -c %s -o /dev/null
+// RUN: env CLANG_SPAWN_CC1= %clang -S %s -o /dev/null
+// RUN: env CLANG_SPAWN_CC1=0 %clang -S %s -o /dev/null
+// RUN: env CLANG_SPAWN_CC1=1 %clang -S %s -o /dev/null
+// RUN: env CLANG_SPAWN_CC1=test not %clang -S %s -o /dev/null



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


[PATCH] D72746: [clangd] Add a flag for implicit references in the Index

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61855 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon check-circle color=green} clang-format: pass.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72746



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


[PATCH] D72624: [WIP] TargetMachine Hook for Module Metadata

2020-01-14 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

From an LTO perspective, this seems fine for the reasons we discussed here. I 
looked through the patch and have a few comments.




Comment at: clang/lib/CodeGen/BackendUtil.cpp:818
+  if (TM) {
+TM->initializeOptionsWithModuleMetadata(*TheModule);
 TheModule->setDataLayout(TM->createDataLayout());

Also needed in EmitAssemblyWithNewPassManager. Maybe it should be moved into 
CreateTargetMachine which would cover both cases.

I'm not sure if this was already discussed - but is there a reason why this 
can't be done in Target::createTargetMachine()? Is it not possible to ensure it 
is called once we have the Module available and pass that in? That would 
centralize this handling and seems cleaner overall.



Comment at: llvm/include/llvm/Target/TargetMachine.h:157
+  const DataLayout createDataLayout() const {
+OptionsCanBeInitalizedFromModule = false;
+return DL;

Do you want to also ensure that createDataLayout is only called iff 
initializeOptionsWithModuleMetadata was previously called? That would need to 
make this a tri-state, or use 2 bools. Then you could assert here that the 
other routine was already called at this point, which would help avoid missing 
calls (like the one I pointed out above), possibly due to future code drift.



Comment at: llvm/include/llvm/Target/TargetMachine.h:192
+  virtual void
+  setTargetOptionsWithModuleMetadata(const Module &M LLVM_ATTRIBUTE_UNUSED) {}
+

Should this be private so that it can only be called via 
initializeOptionsWithModuleMetadata?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72624



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


[PATCH] D72746: [clangd] Add a flag for implicit references in the Index

2020-01-14 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added a comment.

The patch could be shorter and slightly less confusing if I preserved 1:1 
`RefKind::Implicit` <-> `index::SymbolKind::Implicit` relation, but I thought 
we might want to keep `RefKind` being 1 byte so that we don't waste unnecessary 
memory. Also, since we might want to start using `findExplicitReferences` (or 
something else we come up with) for indexing, it shouldn't be critical. Let me 
know if you think it's unnecessary.

+CC @hokein


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72746



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


[PATCH] D72638: [clangd] Fix rename for explicit destructor calls

2020-01-14 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added a comment.

Changed reviewer to @kadircet because Sam would be out until the end of the 
week.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72638



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


[PATCH] D72405: Allow /D flags absent during PCH creation under msvc-compat

2020-01-14 Thread Matthew Voss via Phabricator via cfe-commits
ormris added a comment.

Hi Zach,

The tests in this patch are failing on this PS4 windows bot. Could you take a 
look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/30273/steps/test-check-all/logs/stdio

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72405



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


[PATCH] D72746: [clangd] Add a flag for implicit references in the Index

2020-01-14 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev created this revision.
kbobyrev added a reviewer: kadircet.
Herald added subscribers: usaxena95, arphaman, jkorous, MaskRay, ilya-biryukov.
Herald added a project: clang.
kbobyrev added a subscriber: hokein.

This patch allows the index does to provide a way to distinguish implicit
references (e.g. coming from macro expansions). The corresponding flag was
added to RefKind and symbols that are referenced without spelling their name
explicitly are now marked implicit. This fixes incorrect behavior when renaming
a symbol that was referenced in macro expansions would try to rename macro
invocations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72746

Files:
  clang-tools-extra/clangd/index/Ref.h
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -837,7 +837,7 @@
   {
   // variables.
   R"cpp(
-  static const int [[VA^R]] = 123;
+static const int [[VA^R]] = 123;
   )cpp",
   R"cpp(
 #include "foo.h"
@@ -868,6 +868,22 @@
 }
   )cpp",
   },
+  {
+  // Implicit references in macro expansions.
+  R"cpp(
+class [[Fo^o]] {};
+#define FooFoo Foo
+#define FOO Foo
+  )cpp",
+  R"cpp(
+#include "foo.h"
+void bar() {
+  [[Foo]] x;
+  FOO y;
+  FooFoo z;
+}
+  )cpp",
+  },
   };
 
   for (const auto& T : Cases) {
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -296,6 +296,8 @@
   bool HasMore = Index.refs(RQuest, [&](const Ref &R) {
 if (AffectedFiles.size() > MaxLimitFiles)
   return;
+if (static_cast(R.Kind & RefKind::Implicit))
+  return;
 if (auto RefFilePath = filePath(R.Location, /*HintFilePath=*/MainFile)) {
   if (*RefFilePath != MainFile)
 AffectedFiles[*RefFilePath].push_back(toRange(R.Location));
Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -180,7 +180,14 @@
 }
 
 RefKind toRefKind(index::SymbolRoleSet Roles) {
-  return static_cast(static_cast(RefKind::All) & Roles);
+  // Because RefKind::Implicit != index::SymbolRole::Implicit because due to the
+  // memory considerations, all flags except "Implicit" should be set
+  // independently.
+  auto Result =
+  static_cast(static_cast(RefKind::NotImplicit) & Roles);
+  if (Roles & static_cast(index::SymbolRole::Implicit))
+Result |= RefKind::Implicit;
+  return Result;
 }
 
 bool shouldIndexRelation(const index::SymbolRelation &R) {
@@ -291,7 +298,17 @@
   // occurrence inside the base-specifier.
   processRelations(*ND, *ID, Relations);
 
-  bool CollectRef = static_cast(Opts.RefFilter) & Roles;
+  // Check if the referenced symbol is spelled exactly the same way the
+  // corresponding NamedDecl is. If it isn't, mark this reference as implicit.
+  // An example of implicit references would be a macro expansion.
+  llvm::SmallString<16> Buffer;
+  const auto Spelling =
+  Lexer::getSpelling(Loc, Buffer, SM, ASTCtx->getLangOpts());
+  DeclarationName Name = ND->getDeclName();
+  if (Name.isIdentifier() && Name.getAsString() != Spelling)
+Roles |= static_cast(index::SymbolRole::Implicit);
+
+  bool CollectRef = static_cast(Opts.RefFilter & toRefKind(Roles));
   bool IsOnlyRef =
   !(Roles & (static_cast(index::SymbolRole::Declaration) |
  static_cast(index::SymbolRole::Definition)));
Index: clang-tools-extra/clangd/index/Ref.h
===
--- clang-tools-extra/clangd/index/Ref.h
+++ clang-tools-extra/clangd/index/Ref.h
@@ -30,7 +30,12 @@
   Declaration = static_cast(index::SymbolRole::Declaration),
   Definition = static_cast(index::SymbolRole::Definition),
   Reference = static_cast(index::SymbolRole::Reference),
-  All = Declaration | Definition | Reference,
+  // This corresponds to index::SymbolRole::Implicit. In order to save memory
+  // and keep RefKind occupying 1 byte, the original value is modified to the
+  // one below.
+  Implicit = 1 << 3,
+  All = Declaration | Definition | Reference | Implicit,
+  NotImplicit = Declaration | Definition | Reference,
 };
 
 inline RefKind operator|(RefKind L, RefKind R) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c

[PATCH] D72114: [MS] Overhaul how clang passes overaligned args on x86_32

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 61871 tests passed, 1 failed 
and 781 were skipped.

  failed: Clang.PCH/ms-pch-macro.c

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72114



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


[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61850 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488



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


[PATCH] D72110: [X86] ABI compat bugfix for MSVC vectorcall

2020-01-14 Thread Reid Kleckner via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8e780252a728: [X86] ABI compat bugfix for MSVC vectorcall 
(authored by rnk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72110

Files:
  clang/include/clang/CodeGen/CGFunctionInfo.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/vectorcall.c

Index: clang/test/CodeGen/vectorcall.c
===
--- clang/test/CodeGen/vectorcall.c
+++ clang/test/CodeGen/vectorcall.c
@@ -116,3 +116,24 @@
 // X32: define dso_local x86_vectorcallcc void @"\01HVAAnywhere@@88"(%struct.HFA2 inreg %p1.coerce, i32 inreg %p2, i32 inreg %p3, float %p4, i32 %p5, i32 %p6, %struct.HFA4* %p7, %struct.HFA2 inreg %p8.coerce, float %p9)
 // X64: define dso_local x86_vectorcallcc void @"\01HVAAnywhere@@112"(%struct.HFA2 inreg %p1.coerce, i32 %p2, i32 %p3, float %p4, i32 %p5, i32 %p6, %struct.HFA4* %p7, %struct.HFA2 inreg %p8.coerce, float %p9) 
 
+#ifndef __x86_64__
+// This covers the three ways XMM values can be passed on 32-bit x86:
+// - directly in XMM register (xmm5)
+// - indirectly by address, address in GPR (ecx)
+// - indirectly by address, address on stack
+void __vectorcall vectorcall_indirect_vec(
+double xmm0, double xmm1, double xmm2, double xmm3, double xmm4,
+v4f32 xmm5, v4f32 ecx, int edx, v4f32 mem) {
+}
+
+// X32: define dso_local x86_vectorcallcc void @"\01vectorcall_indirect_vec@@{{[0-9]+}}"
+// X32-SAME: (double %xmm0,
+// X32-SAME: double %xmm1,
+// X32-SAME: double %xmm2,
+// X32-SAME: double %xmm3,
+// X32-SAME: double %xmm4,
+// X32-SAME: <4 x float> %xmm5,
+// X32-SAME: <4 x float>* inreg %0,
+// X32-SAME: i32 inreg %edx,
+// X32-SAME: <4 x float>* %1)
+#endif
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -22,6 +22,7 @@
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"
+#include "llvm/ADT/SmallBitVector.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
@@ -996,11 +997,13 @@
 
 /// Similar to llvm::CCState, but for Clang.
 struct CCState {
-  CCState(unsigned CC) : CC(CC), FreeRegs(0), FreeSSERegs(0) {}
+  CCState(CGFunctionInfo &FI)
+  : IsPreassigned(FI.arg_size()), CC(FI.getCallingConvention()) {}
 
-  unsigned CC;
-  unsigned FreeRegs;
-  unsigned FreeSSERegs;
+  llvm::SmallBitVector IsPreassigned;
+  unsigned CC = CallingConv::CC_C;
+  unsigned FreeRegs = 0;
+  unsigned FreeSSERegs = 0;
 };
 
 enum {
@@ -1071,8 +1074,7 @@
   void addFieldToArgStruct(SmallVector &FrameFields,
CharUnits &StackOffset, ABIArgInfo &Info,
QualType Type) const;
-  void computeVectorCallArgs(CGFunctionInfo &FI, CCState &State,
- bool &UsedInAlloca) const;
+  void runVectorCallFirstPass(CGFunctionInfo &FI, CCState &State) const;
 
 public:
 
@@ -1640,9 +1642,38 @@
   return true;
 }
 
+void X86_32ABIInfo::runVectorCallFirstPass(CGFunctionInfo &FI, CCState &State) const {
+  // Vectorcall x86 works subtly different than in x64, so the format is
+  // a bit different than the x64 version.  First, all vector types (not HVAs)
+  // are assigned, with the first 6 ending up in the [XYZ]MM0-5 registers.
+  // This differs from the x64 implementation, where the first 6 by INDEX get
+  // registers.
+  // In the second pass over the arguments, HVAs are passed in the remaining
+  // vector registers if possible, or indirectly by address. The address will be
+  // passed in ECX/EDX if available. Any other arguments are passed according to
+  // the usual fastcall rules.
+  MutableArrayRef Args = FI.arguments();
+  for (int I = 0, E = Args.size(); I < E; ++I) {
+const Type *Base = nullptr;
+uint64_t NumElts = 0;
+const QualType &Ty = Args[I].type;
+if ((Ty->isVectorType() || Ty->isBuiltinType()) &&
+isHomogeneousAggregate(Ty, Base, NumElts)) {
+  if (State.FreeSSERegs >= NumElts) {
+State.FreeSSERegs -= NumElts;
+Args[I].info = ABIArgInfo::getDirect();
+State.IsPreassigned.set(I);
+  }
+}
+  }
+}
+
 ABIArgInfo X86_32ABIInfo::classifyArgumentType(QualType Ty,
CCState &State) const {
   // FIXME: Set alignment on indirect arguments.
+  bool IsFastCall = State.CC == llvm::CallingConv::X86_FastCall;
+  bool IsRegCall = State.CC == llvm::CallingConv::X86_RegCall;
+  bool IsVectorCall = State.CC == llvm::CallingConv::X86_VectorCall;
 
   Ty = useFirstFieldIfTransparentUnion(Ty);
 
@@ -1662,11 +1693,16 @@
   // to other targets.
   const Type *Base = nullptr;
   uint64_t NumElts = 0;
-  if (State.CC == llvm::CallingConv::X86_RegCall &&
+  if ((Is

[PATCH] D72114: [MS] Overhaul how clang passes overaligned args on x86_32

2020-01-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk updated this revision to Diff 238152.
rnk marked 2 inline comments as done.
rnk added a comment.

- rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72114

Files:
  clang/include/clang/CodeGen/CGFunctionInfo.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/x86_32-arguments-win32.c
  clang/test/CodeGenCXX/inalloca-overaligned.cpp
  clang/test/CodeGenCXX/inalloca-vector.cpp

Index: clang/test/CodeGenCXX/inalloca-vector.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/inalloca-vector.cpp
@@ -0,0 +1,79 @@
+// RUN: %clang_cc1 -w -triple i686-pc-win32 -emit-llvm -o - %s | FileCheck %s
+
+// PR44395
+// MSVC passes up to three vectors in registers, and the rest indirectly. Check
+// that both are compatible with an inalloca prototype.
+
+struct NonTrivial {
+  NonTrivial();
+  NonTrivial(const NonTrivial &o);
+  unsigned handle;
+};
+
+typedef float __m128 __attribute__((__vector_size__(16), __aligned__(16)));
+__m128 gv128;
+
+// nt, w, and q will be in the inalloca pack.
+void receive_vec_128(NonTrivial nt, __m128 x, __m128 y, __m128 z, __m128 w, __m128 q) {
+  gv128 = x + y + z + w + q;
+}
+// CHECK-LABEL: define dso_local void  @"?receive_vec_128@@YAXUNonTrivial@@T__m128@@@Z"
+// CHECK-SAME: (<4 x float> inreg %x,
+// CHECK-SAME: <4 x float> inreg %y,
+// CHECK-SAME: <4 x float> inreg %z,
+// CHECK-SAME: <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>* inalloca %0)
+
+void pass_vec_128() {
+  __m128 z = {0};
+  receive_vec_128(NonTrivial(), z, z, z, z, z);
+}
+// CHECK-LABEL: define dso_local void @"?pass_vec_128@@YAXXZ"()
+// CHECK: getelementptr inbounds <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>, <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>* %{{[^,]*}}, i32 0, i32 0
+// CHECK: call x86_thiscallcc %struct.NonTrivial* @"??0NonTrivial@@QAE@XZ"(%struct.NonTrivial* %{{.*}})
+
+// Store q, store temp alloca.
+// CHECK: store <4 x float> %{{[^,]*}}, <4 x float>* %{{[^,]*}}, align 16
+// CHECK: getelementptr inbounds <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>, <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>* %{{[^,]*}}, i32 0, i32 1
+// CHECK: store <4 x float>* %{{[^,]*}}, <4 x float>** %{{[^,]*}}, align 4
+
+// Store w, store temp alloca.
+// CHECK: store <4 x float> %{{[^,]*}}, <4 x float>* %{{[^,]*}}, align 16
+// CHECK: getelementptr inbounds <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>, <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>* %{{[^,]*}}, i32 0, i32 2
+// CHECK: store <4 x float>* %{{[^,]*}}, <4 x float>** %{{[^,]*}}, align 4
+
+// CHECK: call void @"?receive_vec_128@@YAXUNonTrivial@@T__m128@@@Z"
+// CHECK-SAME: (<4 x float> inreg %{{[^,]*}},
+// CHECK-SAME: <4 x float> inreg %{{[^,]*}},
+// CHECK-SAME: <4 x float> inreg %{{[^,]*}},
+// CHECK-SAME: <{ %struct.NonTrivial, <4 x float>*, <4 x float>* }>* inalloca %{{[^,]*}})
+
+// w will be passed indirectly by register, and q will be passed indirectly, but
+// the pointer will be in memory.
+void __fastcall fastcall_receive_vec(__m128 x, __m128 y, __m128 z, __m128 w, int edx, __m128 q, NonTrivial nt) {
+  gv128 = x + y + z + w + q;
+}
+// CHECK-LABEL: define dso_local x86_fastcallcc void @"?fastcall_receive_vec@@Y{{[^"]*}}"
+// CHECK-SAME: (<4 x float> inreg %x,
+// CHECK-SAME: <4 x float> inreg %y,
+// CHECK-SAME: <4 x float> inreg %z,
+// CHECK-SAME: <4 x float>* inreg %0,
+// CHECK-SAME: i32 inreg %edx,
+// CHECK-SAME: <{ <4 x float>*, %struct.NonTrivial }>* inalloca %1)
+
+
+void __vectorcall vectorcall_receive_vec(double xmm0, double xmm1, double xmm2,
+ __m128 x, __m128 y, __m128 z,
+ __m128 w, int edx, __m128 q, NonTrivial nt) {
+  gv128 = x + y + z + w + q;
+}
+// FIXME: Enable these checks, clang generates wrong IR.
+// CHECK-LABEL: define dso_local x86_vectorcallcc void @"?vectorcall_receive_vec@@Y{{[^"]*}}"
+// CHECKX-SAME: (double inreg %xmm0,
+// CHECKX-SAME: double inreg %xmm1,
+// CHECKX-SAME: double inreg %xmm2,
+// CHECKX-SAME: <4 x float> inreg %x,
+// CHECKX-SAME: <4 x float> inreg %y,
+// CHECKX-SAME: <4 x float> inreg %z,
+// CHECKX-SAME: <4 x float>* inreg %0,
+// CHECKX-SAME: i32 inreg %edx,
+// CHECKX-SAME: <{ <4 x float>*, %struct.NonTrivial }>* inalloca %1)
Index: clang/test/CodeGenCXX/inalloca-overaligned.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/inalloca-overaligned.cpp
@@ -0,0 +1,52 @@
+// RUN: %clang_cc1 -fms-extensions -w -triple i386-pc-win32 -emit-llvm -o - %s | FileCheck %s
+
+// PR44395
+// MSVC passes overaligned types indirectly since MSVC 2015. Make sure that
+// works with inalloca.
+
+// FIXME: Pass non-trivial *and* overaligned types indirectly. Right now the C++
+// ABI rules say to use inalloca, and they take p

[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 marked 3 inline comments as done.
njames93 added inline comments.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-oop57-cpp.rst:6
+
+  Flags use of the `C` standard library functions 'memset', 'memcpy' and
+  'memcmp' and similar derivatives on non-trivial types.

Eugene.Zelenko wrote:
> Please use double back-ticks to highlight function names.
Thats what i get for c&p


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488



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


[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 238153.
njames93 marked an inline comment as done.
njames93 added a comment.

- double ticks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/NonTrivialTypesLibcMemoryCallsCheck.cpp
  clang-tools-extra/clang-tidy/cert/NonTrivialTypesLibcMemoryCallsCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-oop57-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/cert-oop57-cpp.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-oop57-cpp.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-oop57-cpp.cpp
@@ -0,0 +1,90 @@
+// RUN: %check_clang_tidy %s cert-oop57-cpp %t -- \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: cert-oop57-cpp.MemSetNames, value: mymemset}, \
+// RUN:  {key: cert-oop57-cpp.MemCpyNames, value: mymemcpy}, \
+// RUN:  {key: cert-oop57-cpp.MemCmpNames, value: mymemcmp}]}' \
+// RUN: --
+
+void mymemset(void *, unsigned char, decltype(sizeof(int)));
+void mymemcpy(void *, const void *, decltype(sizeof(int)));
+int mymemcmp(const void *, const void *, decltype(sizeof(int)));
+
+namespace std {
+void memset(void *, unsigned char, decltype(sizeof(int)));
+void memcpy(void *, const void *, decltype(sizeof(int)));
+void memmove(void *, const void *, decltype(sizeof(int)));
+void strcpy(void *, const void *, decltype(sizeof(int)));
+int memcmp(const void *, const void *, decltype(sizeof(int)));
+int strcmp(const void *, const void *, decltype(sizeof(int)));
+} // namespace std
+
+struct Trivial {
+  int I;
+  int J;
+};
+
+struct NonTrivial {
+  int I;
+  int J;
+
+  NonTrivial() : I(0), J(0) {}
+  NonTrivial &operator=(const NonTrivial &Other) {
+I = Other.I;
+J = Other.J;
+return *this;
+  }
+
+  bool operator==(const Trivial &Other) const {
+return I == Other.I && J == Other.J;
+  }
+  bool operator!=(const Trivial &Other) const {
+return !(*this == Other);
+  }
+};
+
+void foo(const Trivial &Other) {
+  Trivial Data;
+  std::memset(&Data, 0, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  std::memset(&Data, 0, sizeof(Trivial));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  std::memcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memcpy' on a non-trivially copyable class is undefined
+  std::memmove(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memmove' on a non-trivially copyable class is undefined
+  std::strcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'strcpy' on a non-trivially copyable class is undefined
+  std::memcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'memcmp'
+  std::strcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'strcmp'
+}
+
+void bar(const NonTrivial &Other) {
+  NonTrivial Data;
+  std::memset(&Data, 0, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  // Check it detects sizeof(Type) as well as sizeof(Instantiation)
+  std::memset(&Data, 0, sizeof(NonTrivial));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  std::memcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memcpy' on a non-trivially copyable class is undefined
+  std::memmove(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memmove' on a non-trivially copyable class is undefined
+  std::strcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'strcpy' on a non-trivially copyable class is undefined
+  std::memcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'memcmp'
+  std::strcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'strcmp'
+}
+
+void baz(const NonTrivial &Other) {
+  NonTrivial Data;
+  mymemset(&Data, 0, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'mymemset' on a non-trivially default constructible class is undefined
+  mymemcpy(&Data, &Other, sizeo

[PATCH] D72114: [MS] Overhaul how clang passes overaligned args on x86_32

2020-01-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/include/clang/CodeGen/CGFunctionInfo.h:91
   bool InAllocaSRet : 1;// isInAlloca()
+  bool InAllocaIndirect : 1;// isInAlloca()
   bool IndirectByVal : 1;   // isIndirect()

rjmccall wrote:
> rnk wrote:
> > rnk wrote:
> > > rjmccall wrote:
> > > > Would it be better to handle `inalloca` differently, maybe as a flag 
> > > > rather than as a top-level kind?  I'm concerned about gradually 
> > > > duplicating a significant amount of the expressivity of other kinds.
> > > In the past, I've drafted a more than one unfinished designs for how we 
> > > could remodel inalloca with tokens so that it can be per-argument instead 
> > > of something that applies to all argument memory. Unfortunately, I never 
> > > found the time to finish or implement one.
> > > 
> > > As I was working on this patch, I was thinking to myself that this could 
> > > be the moment to implement one of those designs, but it would be pretty 
> > > involved. Part of the issue is that, personally, I have very little 
> > > interest in improving x86_32 code quality, so a big redesign wouldn't 
> > > deliver much benefit. The benefits would all be code simplifications and 
> > > maintenance cost reductions, which are nice, but seem to only get me 
> > > through the prototype design stage.
> > > 
> > > I'll go dig up my last doc and try to share it, but for now, I think we 
> > > have to suffer the extra inalloca code in this patch.
> > Here's what I wrote, with some sketches of possible LLVM IR that could 
> > replace inalloca:
> > https://reviews.llvm.org/P8183
> > 
> > The basic idea is that we need a call setup instruction that forms a region 
> > with the call. During CodeGen, we can look forward (potentially across BBs) 
> > to determine how much argument stack memory to allocate, allocate it 
> > (perhaps in pieces as we go along), and then skip the normal call stack 
> > argument adjustment during regular call lowering.
> > 
> > Suggestions for names better than "argmem" are welcome.
> > 
> > The major complication comes from edges that exit the call setup region. 
> > These could be exceptional exits or normal exits with statement expressions 
> > and break, return, or goto. Along these paths we need to adjust SP, or risk 
> > leaking stack memory. Today, with inalloca, I think we leak stack memory.
> > In the past, I've drafted a more than one unfinished designs for how we 
> > could remodel inalloca with tokens so that it can be per-argument instead 
> > of something that applies to all argument memory. Unfortunately, I never 
> > found the time to finish or implement one.
> 
> Sorry!  I think it would be great to rethink `inalloca` to avoid the 
> duplication and so on, but I certainly didn't mean to suggest that we should 
> do that as part of this patch.  (I'll look at your proposal later.)  I was 
> trying to ask if it would make sense to change how `inalloca` arguments are 
> represented by `ABIInfo`, so that we could e.g. build a normal indirect 
> `ABIInfo` and then flag that it also needs to be written into an `inalloca` 
> buffer.
I see. I think implementing that would require a greater refactoring of 
ClangToLLVMArgMapping. We'd need a new place to store the inalloca struct field 
index. That is currently put in a union with some other stuff, which would no 
longer work.



Comment at: clang/test/CodeGen/x86_32-arguments-win32.c:77
+// CHECK-LABEL: define dso_local void @receive_vec_256(<8 x float> inreg %x, 
<8 x float> inreg %y, <8 x float> inreg %z, <8 x float>* %0, <8 x float>* %1)
+// CHECK-LABEL: define dso_local void @receive_vec_512(<16 x float> inreg %x, 
<16 x float> inreg %y, <16 x float> inreg %z, <16 x float>* %0, <16 x float>* 
%1)
+// CHECK-LABEL: define dso_local void @receive_vec_1024(<32 x float>* %0, <32 
x float>* %1, <32 x float>* %2, <32 x float>* %3, <32 x float>* %4)

AntonYudintsev wrote:
> rjmccall wrote:
> > AntonYudintsev wrote:
> > > rjmccall wrote:
> > > > AntonYudintsev wrote:
> > > > > rjmccall wrote:
> > > > > > rnk wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > rnk wrote:
> > > > > > > > > craig.topper wrote:
> > > > > > > > > > What happens in the backend with inreg if 512-bit vectors 
> > > > > > > > > > aren't legal?
> > > > > > > > > LLVM splits the vector up using the largest legal vector 
> > > > > > > > > size. As many pieces as possible are passed in available 
> > > > > > > > > XMM/YMM registers, and the rest are passed in memory. MSVC, 
> > > > > > > > > of course, assumes the user wanted the larger vector size, 
> > > > > > > > > and uses whatever vector instructions it needs to move the 
> > > > > > > > > arguments around.
> > > > > > > > > 
> > > > > > > > > Previously, I advocated for a model where calling an Intel 
> > > > > > > > > intrinsic function had the effect of implicitly marking the 
> > > > > > > > > caller with the target attributes of the intr

[clang] 8e78025 - [X86] ABI compat bugfix for MSVC vectorcall

2020-01-14 Thread Reid Kleckner via cfe-commits

Author: Reid Kleckner
Date: 2020-01-14T17:49:13-08:00
New Revision: 8e780252a7284be45cf1ba224cabd884847e8e92

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

LOG: [X86] ABI compat bugfix for MSVC vectorcall

Summary:
Before this change, X86_32ABIInfo::classifyArgument would be called
twice on vector arguments to vectorcall functions. This function has
side effects to track GPR register usage, and this would lead to
incorrect GPR usage in some cases.  The specific case I noticed is from
running out of XMM registers with mixed FP and vector arguments and no
aggregates of any kind. Consider this prototype:

  void __vectorcall vectorcall_indirect_vec(
  double xmm0, double xmm1, double xmm2, double xmm3, double xmm4,
  __m128 xmm5,
  __m128 ecx,
  int edx,
  __m128 mem);

classifyArgument has no effects when called on a plain FP type, but when
called on a vector type, it modifies FreeRegs to model GPR consumption.
However, this should not happen during the vector call first pass.

I refactored the code to unify vectorcall HVA logic with regcall HVA
logic. The conventions pass HVAs in registers differently (expanded vs.
not expanded), but if they do not fit in registers, they both pass them
indirectly by address.

Reviewers: erichkeane, craig.topper

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/CodeGen/CGFunctionInfo.h
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/vectorcall.c

Removed: 




diff  --git a/clang/include/clang/CodeGen/CGFunctionInfo.h 
b/clang/include/clang/CodeGen/CGFunctionInfo.h
index 65a1061f12a8..2a41ab9eece7 100644
--- a/clang/include/clang/CodeGen/CGFunctionInfo.h
+++ b/clang/include/clang/CodeGen/CGFunctionInfo.h
@@ -563,12 +563,11 @@ class CGFunctionInfo final
   typedef const ArgInfo *const_arg_iterator;
   typedef ArgInfo *arg_iterator;
 
-  typedef llvm::iterator_range arg_range;
-  typedef llvm::iterator_range const_arg_range;
-
-  arg_range arguments() { return arg_range(arg_begin(), arg_end()); }
-  const_arg_range arguments() const {
-return const_arg_range(arg_begin(), arg_end());
+  MutableArrayRef arguments() {
+return MutableArrayRef(arg_begin(), NumArgs);
+  }
+  ArrayRef arguments() const {
+return ArrayRef(arg_begin(), NumArgs);
   }
 
   const_arg_iterator arg_begin() const { return getArgsBuffer() + 1; }

diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index dd6597f154bb..682ef18da73b 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -22,6 +22,7 @@
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"
+#include "llvm/ADT/SmallBitVector.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
@@ -996,11 +997,13 @@ static ABIArgInfo getDirectX86Hva(llvm::Type* T = 
nullptr) {
 
 /// Similar to llvm::CCState, but for Clang.
 struct CCState {
-  CCState(unsigned CC) : CC(CC), FreeRegs(0), FreeSSERegs(0) {}
+  CCState(CGFunctionInfo &FI)
+  : IsPreassigned(FI.arg_size()), CC(FI.getCallingConvention()) {}
 
-  unsigned CC;
-  unsigned FreeRegs;
-  unsigned FreeSSERegs;
+  llvm::SmallBitVector IsPreassigned;
+  unsigned CC = CallingConv::CC_C;
+  unsigned FreeRegs = 0;
+  unsigned FreeSSERegs = 0;
 };
 
 enum {
@@ -1071,8 +1074,7 @@ class X86_32ABIInfo : public SwiftABIInfo {
   void addFieldToArgStruct(SmallVector &FrameFields,
CharUnits &StackOffset, ABIArgInfo &Info,
QualType Type) const;
-  void computeVectorCallArgs(CGFunctionInfo &FI, CCState &State,
- bool &UsedInAlloca) const;
+  void runVectorCallFirstPass(CGFunctionInfo &FI, CCState &State) const;
 
 public:
 
@@ -1640,9 +1642,38 @@ bool X86_32ABIInfo::shouldPrimitiveUseInReg(QualType Ty, 
CCState &State) const {
   return true;
 }
 
+void X86_32ABIInfo::runVectorCallFirstPass(CGFunctionInfo &FI, CCState &State) 
const {
+  // Vectorcall x86 works subtly 
diff erent than in x64, so the format is
+  // a bit 
diff erent than the x64 version.  First, all vector types (not HVAs)
+  // are assigned, with the first 6 ending up in the [XYZ]MM0-5 registers.
+  // This 
diff ers from the x64 implementation, where the first 6 by INDEX get
+  // registers.
+  // In the second pass over the arguments, HVAs are passed in the remaining
+  // vector registers if possible, or indirectly by address. The address will 
be
+  // passed in ECX/EDX if available. Any other arguments are passed according 
to
+  // the usual fastcall rules.
+  MutableArrayRef Args = FI.arguments();
+  for (int I = 

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61859 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72404



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


[PATCH] D72405: Allow /D flags absent during PCH creation under msvc-compat

2020-01-14 Thread Reid Kleckner via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0f9cf42facaf: Allow /D flags absent during PCH creation 
under msvc-compat (authored by zahen, committed by rnk).

Changed prior to commit:
  https://reviews.llvm.org/D72405?vs=238147&id=238149#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72405

Files:
  clang/lib/Lex/PPDirectives.cpp
  clang/test/PCH/ms-pch-macro.c


Index: clang/test/PCH/ms-pch-macro.c
===
--- /dev/null
+++ clang/test/PCH/ms-pch-macro.c
@@ -0,0 +1,39 @@
+// Test -D and -U interaction with a PCH when -fms-extensions is enabled.
+
+// RUN: %clang_cc1 -DFOO %S/variables.h -emit-pch -o %t1.pch
+
+// RUN: not %clang_cc1 -DFOO=blah -DBAR=int -include-pch %t1.pch 
-pch-through-header=%S/variables.h %s 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-FOO %s < %t.err
+
+// RUN: not %clang_cc1 -UFOO -DBAR=int -include-pch %t1.pch %s 
-pch-through-header=%S/variables.h 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-NOFOO %s < %t.err
+
+// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+// Enabling MS extensions should allow us to add BAR definitions.
+// RUN: %clang_cc1 -fms-extensions -DFOO %S/variables.h -emit-pch -o %t1.pch
+// RUN: %clang_cc1 -fms-extensions -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+#include "variables.h"
+
+BAR bar = 17;
+#ifndef _MSC_EXTENSIONS
+// expected-error@-2 {{unknown type name 'BAR'}}
+#endif
+
+#ifndef FOO
+#  error FOO was not defined
+#endif
+
+#if FOO != 1
+#  error FOO has the wrong definition
+#endif
+
+#if defined(_MSC_EXTENSIONS) && !defined(BAR)
+#  error BAR was not defined
+#endif
+
+// CHECK-FOO: definition of macro 'FOO' differs between the precompiled header 
('1') and the command line ('blah')
+// CHECK-NOFOO: macro 'FOO' was defined in the precompiled header but undef'd 
on the command line
+
+// expected-warning@1 {{definition of macro 'BAR' does not match definition in 
precompiled header}}
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2727,7 +2727,9 @@
  /*Syntactic=*/LangOpts.MicrosoftExt))
   Diag(MI->getDefinitionLoc(), diag::warn_pp_macro_def_mismatch_with_pch)
   << MacroNameTok.getIdentifierInfo();
-return;
+// Issue the diagnostic but allow the change if msvc extensions are enabled
+if (!LangOpts.MicrosoftExt)
+  return;
   }
 
   // Finally, if this identifier already had a macro defined for it, verify 
that


Index: clang/test/PCH/ms-pch-macro.c
===
--- /dev/null
+++ clang/test/PCH/ms-pch-macro.c
@@ -0,0 +1,39 @@
+// Test -D and -U interaction with a PCH when -fms-extensions is enabled.
+
+// RUN: %clang_cc1 -DFOO %S/variables.h -emit-pch -o %t1.pch
+
+// RUN: not %clang_cc1 -DFOO=blah -DBAR=int -include-pch %t1.pch -pch-through-header=%S/variables.h %s 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-FOO %s < %t.err
+
+// RUN: not %clang_cc1 -UFOO -DBAR=int -include-pch %t1.pch %s -pch-through-header=%S/variables.h 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-NOFOO %s < %t.err
+
+// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int -pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+// Enabling MS extensions should allow us to add BAR definitions.
+// RUN: %clang_cc1 -fms-extensions -DFOO %S/variables.h -emit-pch -o %t1.pch
+// RUN: %clang_cc1 -fms-extensions -include-pch %t1.pch -DBAR=int -pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+#include "variables.h"
+
+BAR bar = 17;
+#ifndef _MSC_EXTENSIONS
+// expected-error@-2 {{unknown type name 'BAR'}}
+#endif
+
+#ifndef FOO
+#  error FOO was not defined
+#endif
+
+#if FOO != 1
+#  error FOO has the wrong definition
+#endif
+
+#if defined(_MSC_EXTENSIONS) && !defined(BAR)
+#  error BAR was not defined
+#endif
+
+// CHECK-FOO: definition of macro 'FOO' differs between the precompiled header ('1') and the command line ('blah')
+// CHECK-NOFOO: macro 'FOO' was defined in the precompiled header but undef'd on the command line
+
+// expected-warning@1 {{definition of macro 'BAR' does not match definition in precompiled header}}
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2727,7 +2727,9 @@
  /*Syntactic=*/LangOpts.MicrosoftExt))
   Diag(MI->getDefinitionLoc(), diag::warn_pp_macro_def_mismatch_with_pch)
   << MacroNameTok.getIdentifierInfo();
-return;
+// Issue the diagnostic but allow the change if msvc extensions are enabled
+if (!LangOpts.Mic

[clang] 0f9cf42 - Allow /D flags absent during PCH creation under msvc-compat

2020-01-14 Thread Reid Kleckner via cfe-commits

Author: Zachary Henkel
Date: 2020-01-14T17:26:01-08:00
New Revision: 0f9cf42facaf9eff47dc0b9eb7e6ed8803d3bc3b

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

LOG: Allow /D flags absent during PCH creation under msvc-compat

Summary:
Before this patch adding a new /D flag when compiling a source file that 
consumed a PCH with clang-cl would issue a diagnostic and then fail.  With the 
patch, the diagnostic is still issued but the definition is accepted.  This 
matches the msvc behavior.  The fuzzy-pch-msvc.c is a clone of the existing 
fuzzy-pch.c tests with some msvc specific rework.

msvc diagnostic:
  warning C4605: '/DBAR=int' specified on current command line, but was not 
specified when precompiled header was built

Output of the CHECK-BAR test prior to the code change:
  (1,9): warning: definition of macro 'BAR' does not match definition 
in precompiled header [-Wclang-cl-pch]
  #define BAR int
  ^
  D:\repos\llvm\llvm-project\clang\test\PCH\fuzzy-pch-msvc.c(12,1): error: 
unknown type name 'BAR'
  BAR bar = 17;
  ^
  D:\repos\llvm\llvm-project\clang\test\PCH\fuzzy-pch-msvc.c(23,4): error: BAR 
was not defined
  #  error BAR was not defined
 ^
  1 warning and 2 errors generated.

Reviewers: rnk, thakis, hans, zturner

Subscribers: mikerice, aganea, cfe-commits

Tags: #clang

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

Added: 
clang/test/PCH/ms-pch-macro.c

Modified: 
clang/lib/Lex/PPDirectives.cpp

Removed: 




diff  --git a/clang/lib/Lex/PPDirectives.cpp b/clang/lib/Lex/PPDirectives.cpp
index 3b7eaee3c914..e433b2cf1b95 100644
--- a/clang/lib/Lex/PPDirectives.cpp
+++ b/clang/lib/Lex/PPDirectives.cpp
@@ -2727,7 +2727,9 @@ void Preprocessor::HandleDefineDirective(
  /*Syntactic=*/LangOpts.MicrosoftExt))
   Diag(MI->getDefinitionLoc(), diag::warn_pp_macro_def_mismatch_with_pch)
   << MacroNameTok.getIdentifierInfo();
-return;
+// Issue the diagnostic but allow the change if msvc extensions are enabled
+if (!LangOpts.MicrosoftExt)
+  return;
   }
 
   // Finally, if this identifier already had a macro defined for it, verify 
that

diff  --git a/clang/test/PCH/ms-pch-macro.c b/clang/test/PCH/ms-pch-macro.c
new file mode 100644
index ..eb45be1b6b73
--- /dev/null
+++ b/clang/test/PCH/ms-pch-macro.c
@@ -0,0 +1,39 @@
+// Test -D and -U interaction with a PCH when -fms-extensions is enabled.
+
+// RUN: %clang_cc1 -DFOO %S/variables.h -emit-pch -o %t1.pch
+
+// RUN: not %clang_cc1 -DFOO=blah -DBAR=int -include-pch %t1.pch 
-pch-through-header=%S/variables.h %s 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-FOO %s < %t.err
+
+// RUN: not %clang_cc1 -UFOO -DBAR=int -include-pch %t1.pch %s 
-pch-through-header=%S/variables.h 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-NOFOO %s < %t.err
+
+// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+// Enabling MS extensions should allow us to add BAR definitions.
+// RUN: %clang_cc1 -fms-extensions -DFOO %S/variables.h -emit-pch -o %t1.pch
+// RUN: %clang_cc1 -fms-extensions -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+#include "variables.h"
+
+BAR bar = 17;
+#ifndef _MSC_EXTENSIONS
+// expected-error@-2 {{unknown type name 'BAR'}}
+#endif
+
+#ifndef FOO
+#  error FOO was not defined
+#endif
+
+#if FOO != 1
+#  error FOO has the wrong definition
+#endif
+
+#if defined(_MSC_EXTENSIONS) && !defined(BAR)
+#  error BAR was not defined
+#endif
+
+// CHECK-FOO: definition of macro 'FOO' 
diff ers between the precompiled header ('1') and the command line ('blah')
+// CHECK-NOFOO: macro 'FOO' was defined in the precompiled header but undef'd 
on the command line
+
+// expected-warning@1 {{definition of macro 'BAR' does not match definition in 
precompiled header}}



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


[PATCH] D72405: Allow /D flags absent during PCH creation under msvc-compat

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

In D72405#1818237 , @zahen wrote:

> I had no luck converting the CHECK-FOO & CHECK-NOFOO tests to use `-verify` 
> because the errors were reported against "(frontend)"


I converted what I could over to `-verify` and switched to testing clang -cc1.

I think this looks good, I'm going to land it, since that's what I've done for 
you in the past. We have git now, it'll be attributed properly and all that. :)

Let me know if you get commit access in the future to push your own patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72405



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


[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2020-01-14 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/D67678/new/

https://reviews.llvm.org/D67678



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


[PATCH] D72405: Allow /D flags absent during PCH creation under msvc-compat

2020-01-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk updated this revision to Diff 238147.
rnk added a comment.

- use %clang_cc1 as possible in tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72405

Files:
  clang/lib/Lex/PPDirectives.cpp
  clang/test/PCH/ms-pch-macro.c


Index: clang/test/PCH/ms-pch-macro.c
===
--- /dev/null
+++ clang/test/PCH/ms-pch-macro.c
@@ -0,0 +1,39 @@
+// Test -D and -U interaction with a PCH when -fms-extensions is enabled.
+
+// RUN: %clang_cc1 -DFOO %S/variables.h -emit-pch -o %t1.pch
+
+// RUN: not %clang_cc1 -DFOO=blah -DBAR=int -include-pch %t1.pch 
-pch-through-header=%S/variables.h %s 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-FOO %s < %t.err
+
+// RUN: not %clang_cc1 -UFOO -DBAR=int -include-pch %t1.pch %s 
-pch-through-header=%S/variables.h 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-NOFOO %s < %t.err
+
+// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+// Enabling MS extensions should allow us to add BAR definitions.
+// RUN: %clang_cc1 -fms-extensions -DFOO %S/variables.h -emit-pch -o %t1.pch
+// RUN: %clang_cc1 -fms-extensions -include-pch %t1.pch -DBAR=int 
-pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+#include "variables.h"
+
+BAR bar = 17;
+#ifndef _MSC_EXTENSIONS
+// expected-error@-2 {{unknown type name 'BAR'}}
+#endif
+
+#ifndef FOO
+#  error FOO was not defined
+#endif
+
+#if FOO != 1
+#  error FOO has the wrong definition
+#endif
+
+#if !defined(_MSC_EXTENSIONS) && !defined(BAR)
+#  error BAR was not defined
+#endif
+
+// CHECK-FOO: definition of macro 'FOO' differs between the precompiled header 
('1') and the command line ('blah')
+// CHECK-NOFOO: macro 'FOO' was defined in the precompiled header but undef'd 
on the command line
+
+// expected-warning@1 {{definition of macro 'BAR' does not match definition in 
precompiled header}}
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2727,7 +2727,9 @@
  /*Syntactic=*/LangOpts.MicrosoftExt))
   Diag(MI->getDefinitionLoc(), diag::warn_pp_macro_def_mismatch_with_pch)
   << MacroNameTok.getIdentifierInfo();
-return;
+// Issue the diagnostic but allow the change if msvc extensions are enabled
+if (!LangOpts.MicrosoftExt)
+  return;
   }
 
   // Finally, if this identifier already had a macro defined for it, verify 
that


Index: clang/test/PCH/ms-pch-macro.c
===
--- /dev/null
+++ clang/test/PCH/ms-pch-macro.c
@@ -0,0 +1,39 @@
+// Test -D and -U interaction with a PCH when -fms-extensions is enabled.
+
+// RUN: %clang_cc1 -DFOO %S/variables.h -emit-pch -o %t1.pch
+
+// RUN: not %clang_cc1 -DFOO=blah -DBAR=int -include-pch %t1.pch -pch-through-header=%S/variables.h %s 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-FOO %s < %t.err
+
+// RUN: not %clang_cc1 -UFOO -DBAR=int -include-pch %t1.pch %s -pch-through-header=%S/variables.h 2> %t.err
+// RUN: FileCheck -check-prefix=CHECK-NOFOO %s < %t.err
+
+// RUN: %clang_cc1 -include-pch %t1.pch -DBAR=int -pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+// Enabling MS extensions should allow us to add BAR definitions.
+// RUN: %clang_cc1 -fms-extensions -DFOO %S/variables.h -emit-pch -o %t1.pch
+// RUN: %clang_cc1 -fms-extensions -include-pch %t1.pch -DBAR=int -pch-through-header=%S/variables.h -verify %s 2> %t.err
+
+#include "variables.h"
+
+BAR bar = 17;
+#ifndef _MSC_EXTENSIONS
+// expected-error@-2 {{unknown type name 'BAR'}}
+#endif
+
+#ifndef FOO
+#  error FOO was not defined
+#endif
+
+#if FOO != 1
+#  error FOO has the wrong definition
+#endif
+
+#if !defined(_MSC_EXTENSIONS) && !defined(BAR)
+#  error BAR was not defined
+#endif
+
+// CHECK-FOO: definition of macro 'FOO' differs between the precompiled header ('1') and the command line ('blah')
+// CHECK-NOFOO: macro 'FOO' was defined in the precompiled header but undef'd on the command line
+
+// expected-warning@1 {{definition of macro 'BAR' does not match definition in precompiled header}}
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2727,7 +2727,9 @@
  /*Syntactic=*/LangOpts.MicrosoftExt))
   Diag(MI->getDefinitionLoc(), diag::warn_pp_macro_def_mismatch_with_pch)
   << MacroNameTok.getIdentifierInfo();
-return;
+// Issue the diagnostic but allow the change if msvc extensions are enabled
+if (!LangOpts.MicrosoftExt)
+  return;
   }
 
   // Finally, if this identifier already had a macro defined for it, verify that
___
cfe-commits mailing lis

[PATCH] D71387: pass -mabi to LTO linker only in RISC-V targets, enable RISC-V LTO

2020-01-14 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Okay.  Please let me know if you want me to review anything.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71387



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


[PATCH] D72547: [llvm] Make new pass manager's OptimizationLevel a class

2020-01-14 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

Overall I like this approach.




Comment at: llvm/lib/Passes/PassBuilder.cpp:246
 
-static bool isOptimizingForSize(PassBuilder::OptimizationLevel Level) {
-  switch (Level) {
-  case PassBuilder::O0:
-  case PassBuilder::O1:
-  case PassBuilder::O2:
-  case PassBuilder::O3:
-return false;
-
-  case PassBuilder::Os:
-  case PassBuilder::Oz:
-return true;
-  }
-  llvm_unreachable("Invalid optimization level!");
-}
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::O0 = {0,
+   0};

Nit, it would be good to document the constant parameters, e.g. 
{/*SpeedLevel*/0, /*SizeLevel*/0}



Comment at: llvm/lib/Passes/PassBuilder.cpp:407
   // Hoisting of scalars and load expressions.
-  if (Level > O1) {
+  if (Level.getSpeedupLevel() >= 2) {
 if (EnableGVNHoist)

Nit, all similar checks below are Level.getSpeedupLevel() > 1, make this one 
consistent.



Comment at: llvm/lib/Passes/PassBuilder.cpp:487
   PTO.LoopUnrolling)
-LPM2.addPass(LoopFullUnrollPass(Level, /*OnlyWhenForced=*/false,
+LPM2.addPass(LoopFullUnrollPass(Level.getSpeedupLevel(),
+/*OnlyWhenForced=*/false,

This results in a behavior, change, right? I.e. we used to inadvertently get 
the O3 threshold for full unrolling with Oz/Os but no longer will. If so, make 
sure you note this in the patch summary. Also add a test.



Comment at: llvm/lib/Passes/PassBuilder.cpp:973
   if (EnableUnrollAndJam && PTO.LoopUnrolling) {
-OptimizePM.addPass(LoopUnrollAndJamPass(Level));
+OptimizePM.addPass(LoopUnrollAndJamPass(Level.getSpeedupLevel()));
   }

This one and the loop unrolling pass below will also get a change in behavior 
for Os/Oz, correct? That seems reasonable, but needs to be noted in summary and 
tested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72547



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


[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 238142.
ychen edited the summary of this revision.
ychen added a comment.

- fix test when clang is the host compiler


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72404

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/thinlto-debug-pm.c
  lld/COFF/Config.h
  lld/COFF/Driver.cpp
  lld/COFF/LTO.cpp
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/LTO.cpp
  lld/test/COFF/lto-opt-level.ll
  lld/test/ELF/lto/opt-level.ll
  lld/test/wasm/lto/opt-level.ll
  lld/wasm/Config.h
  lld/wasm/Driver.cpp
  lld/wasm/LTO.cpp
  llvm/include/llvm/LTO/Config.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
  llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/test/LTO/X86/Inputs/opt-level-size.ll
  llvm/test/LTO/X86/opt-level-size.ll
  llvm/test/tools/lto/opt-level.ll
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp
  llvm/tools/lto/lto.cpp

Index: llvm/tools/lto/lto.cpp
===
--- llvm/tools/lto/lto.cpp
+++ llvm/tools/lto/lto.cpp
@@ -28,14 +28,13 @@
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/raw_ostream.h"
 
-// extra command-line flags needed for LTOCodeGenerator
-static cl::opt
+static cl::opt
 OptLevel("O",
- cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
+ cl::desc("Optimization level. [-O0, -O1, -O2, -Os, -Oz or -O3] "
   "(default = '-O2')"),
  cl::Prefix,
  cl::ZeroOrMore,
- cl::init('2'));
+ cl::init("2"));
 
 static cl::opt
 DisableInline("disable-inlining", cl::init(false),
@@ -165,9 +164,15 @@
 CG->setAttr(attrs);
   }
 
-  if (OptLevel < '0' || OptLevel > '3')
-report_fatal_error("Optimization level must be between 0 and 3");
-  CG->setOptLevel(OptLevel - '0');
+  LLVMContext &Ctx = CG->getContext();
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getOptLevel(OptLevel)))
+CG->setOptLevel(*Result);
+
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getSizeLevel(OptLevel)))
+CG->setSizeLevel(*Result);
+
   CG->setFreestanding(EnableFreestanding);
 }
 
@@ -487,25 +492,19 @@
   CodeGen->setTargetOptions(InitTargetOptionsFromCodeGenFlags());
   CodeGen->setFreestanding(EnableFreestanding);
 
-  if (OptLevel.getNumOccurrences()) {
-if (OptLevel < '0' || OptLevel > '3')
-  report_fatal_error("Optimization level must be between 0 and 3");
-CodeGen->setOptLevel(OptLevel - '0');
-switch (OptLevel) {
-case '0':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::None);
-  break;
-case '1':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Less);
-  break;
-case '2':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Default);
-  break;
-case '3':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Aggressive);
-  break;
-}
-  }
+  LLVMContext Ctx;
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getOptLevel(OptLevel)))
+CodeGen->setOptLevel(*Result);
+  else
+return nullptr;
+
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getSizeLevel(OptLevel)))
+CodeGen->setSizeLevel(*Result);
+  else
+return nullptr;
+
   return wrap(CodeGen);
 }
 
Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -29,10 +29,11 @@
 using namespace llvm;
 using namespace lto;
 
-static cl::opt
-OptLevel("O", cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
-   "(default = '-O2')"),
- cl::Prefix, cl::ZeroOrMore, cl::init('2'));
+static cl::opt
+OptLevel("O",
+ cl::desc("Optimization level. [-O0, -O1, -O2, -Os, -Oz, or "
+  "-O3] (default = '-O2')"),
+ cl::Prefix, cl::ZeroOrMore, cl::init("2"));
 
 static cl::opt CGOptLevel(
 "cg-opt-level",
@@ -244,7 +245,10 @@
   Conf.OptPipeline = OptPipeline;
   Conf.AAPipeline = AAPipeline;
 
-  Conf.OptLevel = OptLevel - '0';
+  Conf.OptLevel =
+  check(llvm::lto::getOptLevel(OptLevel), "invalid optimization level");
+  Conf.SizeLevel =
+  check(llvm::lto::getSizeLevel(OptLevel), "invalid optimization level");
   Conf.UseNewPM = UseNewPM;
   switch (CGOptLevel) {
   case '0':
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -62,10 +62,11 @@
 
 using namespace llvm;
 
-static cl::opt
-OptLevel("O", cl::desc("Optimization le

[PATCH] D72675: Fix -ffast-math/-ffp-contract interaction

2020-01-14 Thread Warren Ristow via Phabricator via cfe-commits
wristow updated this revision to Diff 238143.
wristow retitled this revision from "ix -ffast-math/-ffp-contract interaction" 
to "Fix -ffast-math/-ffp-contract interaction".
wristow added a comment.

Addressed comments from @hfinkel .


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

https://reviews.llvm.org/D72675

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fast-math.c
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/test/CodeGen/PowerPC/fmf-propagation.ll
  llvm/test/CodeGen/X86/fp-contract.ll

Index: llvm/test/CodeGen/X86/fp-contract.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/fp-contract.ll
@@ -0,0 +1,204 @@
+; Tests for -ffp-contract/-ffast-math interaction.
+; Specifically, -ffp-contract=off must suppress the use of FMA.
+
+; RUN: llc < %s -mcpu=haswell | FileCheck %s --check-prefix=FMA
+
+; Scalar versions:
+
+define float @MulAddPlain(float %a, float %b, float %c) {
+; FMA-LABEL: MulAddPlain:
+; FMA:   vmulss
+; FMA-NEXT:  vaddss
+; FMA-NEXT:  ret
+  %mul = fmul float %a, %b
+  %add = fadd float %mul, %c
+  ret float %add
+}
+
+define float @MulAddFast(float %a, float %b, float %c) {
+; FMA-LABEL: MulAddFast:
+; FMA:   vfmadd213ss
+; FMA-NEXT:  ret
+  %mul = fmul fast float %a, %b
+  %add = fadd fast float %mul, %c
+  ret float %add
+}
+
+define float @MulAddContract(float %a, float %b, float %c) {
+; FMA-LABEL: MulAddContract:
+; FMA:   vfmadd213ss
+; FMA-NEXT:  ret
+  %mul = fmul contract float %a, %b
+  %add = fadd contract float %mul, %c
+  ret float %add
+}
+
+; Enabling all the fast-math-flags except 'contract' does not enable fused operations.
+define float @MulAddFastNoContract(float %a, float %b, float %c) {
+; FMA-LABEL: MulAddFastNoContract:
+; FMA:   vmulss
+; FMA-NEXT:  vaddss
+; FMA-NEXT:  ret
+  %mul = fmul nnan ninf nsz arcp afn reassoc float %a, %b
+  %add = fadd nnan ninf nsz arcp afn reassoc float %mul, %c
+  ret float %add
+}
+
+define float @MulAddReassoc(float %a, float %b, float %c) {
+; FMA-LABEL: MulAddReassoc:
+; FMA:   vmulss
+; FMA-NEXT:  vaddss
+; FMA-NEXT:  ret
+  %mul = fmul reassoc float %a, %b
+  %add = fadd reassoc float %mul, %c
+  ret float %add
+}
+
+define float @MulSubPlain(float %a, float %b, float %c) {
+; FMA-LABEL: MulSubPlain:
+; FMA:   vmulss
+; FMA-NEXT:  vsubss
+; FMA-NEXT:  ret
+  %mul = fmul float %a, %b
+  %sub = fsub float %mul, %c
+  ret float %sub
+}
+
+define float @MulSubFast(float %a, float %b, float %c) {
+; FMA-LABEL: MulSubFast:
+; FMA:   vfmsub213ss
+; FMA-NEXT:  ret
+  %mul = fmul fast float %a, %b
+  %sub = fsub fast float %mul, %c
+  ret float %sub
+}
+
+define float @MulSubContract(float %a, float %b, float %c) {
+; FMA-LABEL: MulSubContract:
+; FMA:   vfmsub213ss
+; FMA-NEXT:  ret
+  %mul = fmul contract float %a, %b
+  %sub = fsub contract float %mul, %c
+  ret float %sub
+}
+
+; Enabling all the fast-math-flags except 'contract' does not enable fused operations.
+define float @MulSubFastNoContract(float %a, float %b, float %c) {
+; FMA-LABEL: MulSubFastNoContract:
+; FMA:   vmulss
+; FMA-NEXT:  vsubss
+; FMA-NEXT:  ret
+  %mul = fmul nnan ninf nsz arcp afn reassoc float %a, %b
+  %sub = fsub nnan ninf nsz arcp afn reassoc float %mul, %c
+  ret float %sub
+}
+
+define float @MulSubReassoc(float %a, float %b, float %c) {
+; FMA-LABEL: MulSubReassoc:
+; FMA:   vmulss
+; FMA-NEXT:  vsubss
+; FMA-NEXT:  ret
+  %mul = fmul reassoc float %a, %b
+  %sub = fsub reassoc float %mul, %c
+  ret float %sub
+}
+
+; Vector versions:
+
+define <4 x float> @VecMulAddPlain(<4 x float> %a, <4 x float> %b, <4 x float> %c) {
+; FMA-LABEL: VecMulAddPlain:
+; FMA:   vmulps
+; FMA-NEXT:  vaddps
+; FMA-NEXT:  ret
+  %mul = fmul <4 x float> %a, %b
+  %add = fadd <4 x float> %mul, %c
+  ret <4 x float> %add
+}
+
+define <4 x float> @VecMulAddFast(<4 x float> %a, <4 x float> %b, <4 x float> %c) {
+; FMA-LABEL: VecMulAddFast:
+; FMA:   vfmadd213ps
+; FMA-NEXT:  ret
+  %mul = fmul fast <4 x float> %a, %b
+  %add = fadd fast <4 x float> %mul, %c
+  ret <4 x float> %add
+}
+
+define <4 x float> @VecMulAddContract(<4 x float> %a, <4 x float> %b, <4 x float> %c) {
+; FMA-LABEL: VecMulAddContract:
+; FMA:   vfmadd213ps
+; FMA-NEXT:  ret
+  %mul = fmul contract <4 x float> %a, %b
+  %add = fadd contract <4 x float> %mul, %c
+  ret <4 x float> %add
+}
+
+; Enabling all the fast-math-flags except 'contract' does not enable fused operations.
+define <4 x float> @VecMulAddFastNoContract(<4 x float> %a, <4 x float> %b, <4 x float> %c) {
+; FMA-LABEL: VecMulAddFastNoContract:
+; FMA:   vmulps
+; FMA-NEXT:  vaddps
+; FMA-NEXT:  ret
+  %mul = fmul nnan ninf nsz arcp afn reassoc <4 x float> %a, %b
+  %add = fadd nnan ninf nsz arcp afn reassoc <4 x float> %mul, %c
+  ret <4 x float> %add
+}
+
+define <4 x float> @VecMulAddReassoc(<4 x float> %a, <4 x float> %b, <4 x float> %c) {
+; FMA-LABEL: VecMulAddReassoc:

[clang] c9ee5e9 - Fix windows bot failures in c410adb092c9cb51ddb0b55862b70f2aa8c5b16f

2020-01-14 Thread Rong Xu via cfe-commits

Author: Rong Xu
Date: 2020-01-14T16:32:17-08:00
New Revision: c9ee5e996e3c89a751a35e8b771870e0ec24f3c0

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

LOG: Fix windows bot failures in c410adb092c9cb51ddb0b55862b70f2aa8c5b16f
(clang diagnostic handler for IR input files)

Added: 


Modified: 
clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c 
b/clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
index 3c410571a90b..389d24425cc4 100644
--- a/clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
+++ b/clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
@@ -20,5 +20,5 @@ __attribute__((noinline)) void foo(int m) {
 bar();
 }
 // CHECK-REMARK: remark: {{.*}}.c:
-// CHECK-WARNING: warning: Potential performance regression from use of 
__builtin_expect(): Annotation was correct on {{.*}}.c:{{[0-9]*}}:26: 50.00% 
(12 / 24) of profiled executions.
+// CHECK-WARNING: warning: Potential performance regression from use of 
__builtin_expect(): Annotation was correct on {{.*}}.c:{{[0-9]*}}:{{[0-9]*}}: 
50.00% (12 / 24) of profiled executions.
 // CHECK-NOWARNING-NOT: warning: {{.*}}.c:{{[0-9]*}}:26: 50.00% (12 / 24)



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


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

2020-01-14 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: llvm/include/llvm/Support/FileUtilities.h:38
+#if defined(_AIX)
+  SmallString<128> getLoadModuleFilenameForFunctionAIX(void (*Func)(void));
+#endif

This should be an internal function in the `.cpp` file implementing the 
following function. It should not be declared in an interface `.h` file.



Comment at: llvm/include/llvm/Support/FileUtilities.h:42
+  template 
+  SmallString<128> getLoadModuleFilenameForFunction(FuncAddrType FuncAddr) {
+if (!FuncAddr) {

The description of `FileUtilities.h` does not seem to encompass what this 
function does. Perhaps `SystemUtils.h` works better? fyi, when posting patches 
to Phabricator, the "full context" (using `diff -U `) should be 
provided.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72736



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


[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

2020-01-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I think I liked the first version of this patch better. I would say, if the AST 
after instantiation remains the same as it was before D69950 
, then the first one seems like the right fix. 
The pattern AST will just be missing a node to represent the promotion from the 
bitfield to a full integer, and then again to a boolean.


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

https://reviews.llvm.org/D72242



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


[PATCH] D72742: Don't assume promotable integers are zero/sign-extended already in x86-64 ABI.

2020-01-14 Thread Emilio Cobos Álvarez via Phabricator via cfe-commits
emilio created this revision.
Herald added a reviewer: jdoerfert.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Sign-extension is not guaranteed by the ABI, and thus the callee cannot assume
it.

This fixes PR44228 and PR12207.

With these changes, there are still two tests that need updating:

- CodeGenObjC/optimized-setter.m fails with:

  clang: llvm/lib/IR/Instructions.cpp:400: void 
llvm::CallInst::init(llvm::FunctionType *, llvm::Value *, ArrayRef, ArrayRef, const llvm::Twine &): Assertion `(i >= 
FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling 
a function with a bad signature!"' failed.



- OpenMP/parallel_for_simd_codegen.cpp fails with:

  clang: clang/lib/CodeGen/CGCall.cpp:3858: clang::CodeGen::RValue 
clang::CodeGen::CodeGenFunction::EmitCall(const clang::CodeGen::CGFunctionInfo 
&, const clang::CodeGen::CGCallee &, clang::CodeGen::ReturnValueSlot, const 
clang::CodeGen::CallArgList &, llvm::CallBase **, clang::SourceLocation): 
Assertion `IRFuncTy == TypeFromVal' failed.

These two are probably bad assumptions in some of the ObjC / OpenMP-specific
code, but I want to check this patch is on the right track before digging more.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72742

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/2007-06-18-SextAttrAggregate.c
  clang/test/CodeGen/avx512-reduceMinMaxIntrin.c
  clang/test/CodeGen/catch-implicit-integer-sign-changes.c
  clang/test/CodeGen/function-attributes.c
  clang/test/CodeGen/regcall.c
  clang/test/CodeGen/x86_64-arguments-nacl.c
  clang/test/CodeGen/x86_64-arguments.c
  clang/test/CodeGenCXX/blocks.cpp
  clang/test/CodeGenCXX/const-init-cxx11.cpp
  clang/test/CodeGenCXX/cxx1z-initializer-aggregate.cpp
  clang/test/CodeGenCXX/exceptions.cpp
  clang/test/CodeGenCXX/forward-enum.cpp
  clang/test/CodeGenCXX/value-init.cpp
  clang/test/CodeGenCXX/virtual-bases.cpp
  clang/test/CodeGenObjC/arc-blocks.m
  clang/test/CodeGenObjC/arc-literals.m
  clang/test/CodeGenObjC/arc-property.m
  clang/test/CodeGenObjC/arc-ternary-op.m
  clang/test/CodeGenObjC/atomic-aggregate-property.m
  clang/test/CodeGenObjC/objc-literal-tests.m
  clang/test/CodeGenObjC/objc_copyStruct.m
  clang/test/CodeGenObjC/property-atomic-bool.m
  clang/test/CodeGenObjCXX/property-object-reference-1.mm
  llvm/test/CodeGen/X86/x86-64-arg.ll

Index: llvm/test/CodeGen/X86/x86-64-arg.ll
===
--- llvm/test/CodeGen/X86/x86-64-arg.ll
+++ llvm/test/CodeGen/X86/x86-64-arg.ll
@@ -1,6 +1,5 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc < %s | FileCheck %s
-
 ; The input value is already sign extended, don't re-extend it.
 ; This testcase corresponds to:
 ;   int test(short X) { return (int)X; }
Index: clang/test/CodeGenObjCXX/property-object-reference-1.mm
===
--- clang/test/CodeGenObjCXX/property-object-reference-1.mm
+++ clang/test/CodeGenObjCXX/property-object-reference-1.mm
@@ -28,4 +28,6 @@
 // CHECK: store %struct.TCPPObject* [[cppObject:%.*]], %struct.TCPPObject** [[cppObjectaddr]], align 8
 // CHECK:  [[THREE:%.*]] = load %struct.TCPPObject*, %struct.TCPPObject** [[cppObjectaddr]], align 8
 // CHECK:  [[FOUR:%.*]] = bitcast %struct.TCPPObject* [[THREE]] to i8*
-// CHECK:  call void @objc_copyStruct(i8* [[TWO:%.*]], i8* [[FOUR]], i64 256, i1 zeroext true, i1 zeroext false)
+// CHECK:  [[FIVE:%.*]] = load i8, i8* %coerce, align 1
+// CHECK:  [[SIX:%.*]] = load i8, i8* %coerce1, align 1
+// CHECK:  call void @objc_copyStruct(i8* [[TWO:%.*]], i8* [[FOUR]], i64 256, i8 [[FIVE]], i8 [[SIX]])
Index: clang/test/CodeGenObjC/property-atomic-bool.m
===
--- clang/test/CodeGenObjC/property-atomic-bool.m
+++ clang/test/CodeGenObjC/property-atomic-bool.m
@@ -5,7 +5,7 @@
 // CHECK:   %[[TOBOOL:.*]] = trunc i8 %[[ATOMIC_LOAD]] to i1
 // CHECK:   ret i1 %[[TOBOOL]]
 
-// CHECK: define internal void @"\01-[A0 setP:]"({{.*}} i1 zeroext {{.*}})
+// CHECK: define internal void @"\01-[A0 setP:]"({{.*}} i8* {{.*}})
 // CHECK:   store atomic i8 %{{.*}}, i8* %{{.*}} seq_cst
 // CHECK:   ret void
 
@@ -14,7 +14,7 @@
 // CHECK:   %[[TOBOOL:.*]] = trunc i8 %load to i1
 // CHECK:   ret i1 %[[TOBOOL]]
 
-// CHECK: define internal void @"\01-[A1 setP:]"({{.*}} i1 zeroext %p)
+// CHECK: define internal void @"\01-[A1 setP:]"({{.*}} i8 %p.coerce)
 // CHECK:   store atomic i8 %{{.*}}, i8* %{{.*}} unordered
 // CHECK:   ret void
 
Index: clang/test/CodeGenObjC/objc_copyStruct.m
===
--- clang/test/CodeGenObjC/objc_copyStruct.m
+++ clang/test/CodeGenObjC/objc_copyStruct.m
@@ -1,5 +1,5 @@
-// RUN: %clang -target x86_64-unknown-windows-msvc -fobjc-runtime=ios -Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
-// RUN

[PATCH] D72523: [remark][diagnostics] Using clang diagnostic handler for IR input files

2020-01-14 Thread Rong Xu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG60d39479221d: [remark][diagnostics] Using clang diagnostic 
handler for IR input files (authored by xur).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D72523?vs=237810&id=238129#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72523

Files:
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGen/Inputs/thinlto_expect1.proftext
  clang/test/CodeGen/Inputs/thinlto_expect2.proftext
  clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
  clang/test/CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll

Index: clang/test/CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
===
--- clang/test/CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
+++ clang/test/CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
@@ -28,7 +28,7 @@
 ; YAML-NEXT: ...
 
 ; Next try with pass remarks to stderr
-; RUN: %clang -target x86_64-scei-ps4 -O2 -x ir %t.o -fthinlto-index=%t.thinlto.bc -mllvm -pass-remarks=inline -fdiagnostics-show-hotness -o %t2.o -c 2>&1 | FileCheck %s
+; RUN: %clang -target x86_64-scei-ps4 -O2 -x ir %t.o -fthinlto-index=%t.thinlto.bc -Rpass=inline -fdiagnostics-show-hotness -o %t2.o -c 2>&1 | FileCheck %s
 
 ; CHECK: tinkywinky inlined into main with (cost=0, threshold=337) (hotness: 300)
 
Index: clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
===
--- /dev/null
+++ clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
@@ -0,0 +1,24 @@
+// Test clang diagnositic handler works in IR file compilation.
+
+// REQUIRES: x86-registered-target
+
+// RUN: llvm-profdata merge -o %t1.profdata %S/Inputs/thinlto_expect1.proftext
+// RUN: %clang -O2 -fexperimental-new-pass-manager -flto=thin -g -fprofile-use=%t1.profdata -c -o %t1.bo %s
+// RUN: llvm-lto -thinlto -o %t %t1.bo
+// RUN: %clang -cc1 -O2 -fexperimental-new-pass-manager -x ir %t1.bo -fthinlto-index=%t.thinlto.bc -emit-obj -Rpass-analysis=info 2>&1 | FileCheck %s -check-prefix=CHECK-REMARK
+// RUN: llvm-profdata merge -o %t2.profdata %S/Inputs/thinlto_expect2.proftext
+// RUN: %clang -cc1 -O2 -fexperimental-new-pass-manager -x ir %t1.bo -fthinlto-index=%t.thinlto.bc -fprofile-instrument-use-path=%t2.profdata -emit-obj -Wmisexpect 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
+// RUN: %clang -cc1 -O2 -fexperimental-new-pass-manager -x ir %t1.bo -fthinlto-index=%t.thinlto.bc -fprofile-instrument-use-path=%t2.profdata -emit-obj 2>&1 | FileCheck %s -allow-empty -check-prefix=CHECK-NOWARNING
+
+int sum;
+__attribute__((noinline)) void bar() {
+  sum = 1234;
+}
+
+__attribute__((noinline)) void foo(int m) {
+  if (__builtin_expect(m > 9, 1))
+bar();
+}
+// CHECK-REMARK: remark: {{.*}}.c:
+// CHECK-WARNING: warning: Potential performance regression from use of __builtin_expect(): Annotation was correct on {{.*}}.c:{{[0-9]*}}:26: 50.00% (12 / 24) of profiled executions.
+// CHECK-NOWARNING-NOT: warning: {{.*}}.c:{{[0-9]*}}:26: 50.00% (12 / 24)
Index: clang/test/CodeGen/Inputs/thinlto_expect2.proftext
===
--- /dev/null
+++ clang/test/CodeGen/Inputs/thinlto_expect2.proftext
@@ -0,0 +1,20 @@
+# CSIR level Instrumentation Flag
+:csir
+foo
+# Func Hash:
+25571299074
+# Num Counters:
+2
+# Counter Values:
+12
+24
+
+foo
+# Func Hash:
+1152921530178146050
+# Num Counters:
+2
+# Counter Values:
+24
+12
+
Index: clang/test/CodeGen/Inputs/thinlto_expect1.proftext
===
--- /dev/null
+++ clang/test/CodeGen/Inputs/thinlto_expect1.proftext
@@ -0,0 +1,11 @@
+# IR level Instrumentation Flag
+:ir
+foo
+# Func Hash:
+25571299074
+# Num Counters:
+2
+# Counter Values:
+12
+24
+
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -151,6 +151,29 @@
   FrontendTimesIsEnabled = TimePasses;
   llvm::TimePassesIsEnabled = TimePasses;
 }
+
+// This constructor is used in installing an empty BackendConsumer
+// to use the clang diagnostic handler for IR input files. It avoids
+// initializing the OS field.
+BackendConsumer(BackendAction Action, DiagnosticsEngine &Diags,
+const HeaderSearchOptions &HeaderSearchOpts,
+const PreprocessorOptions &PPOpts,
+const CodeGenOptions &CodeGenOpts,
+const TargetOptions &TargetOpts,
+const LangOptions &LangOpts, bool TimePasses,
+SmallVector LinkModules, LLVMContext &C,
+CoverageSourceInfo *CoverageInfo = nullptr)
+: Diags(D

[clang] 60d3947 - [remark][diagnostics] Using clang diagnostic handler for IR input files

2020-01-14 Thread Rong Xu via cfe-commits

Author: Rong Xu
Date: 2020-01-14T15:44:57-08:00
New Revision: 60d39479221d6bc09060f7816bcd7c54eb286603

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

LOG: [remark][diagnostics] Using clang diagnostic handler for IR input files

For IR input files, we currently use LLVM diagnostic handler even the
compilation is from clang. As a result, we are not able to use -Rpass
to get the transformation reports. Some warnings are not handled
properly either: We found many mysterious warnings in our ThinLTO backend
compilations in SamplePGO and CSPGO. An example of the warning:
"warning: net/proto2/public/metadata_lite.h:51:21: 0.02% (1 / 4999)"

This turns out to be a warning by Wmisexpect, which is supposed to be
filtered out by default. But since the filter is in clang's
diagnostic hander, we emit these incomplete warnings from LLVM's
diagnostic handler.

This patch uses clang diagnostic handler for IR input files. We create
a fake backendconsumer just to install the diagnostic handler.

With this change, we will have proper handling of all the warnings and we can
use -Rpass* options in IR input files compilation.
Also note that with is patch, LLVM's diagnostic options, like
"-mllvm -pass-remarks=*", are no longer be able to get optimization remarks.

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

Added: 
clang/test/CodeGen/Inputs/thinlto_expect1.proftext
clang/test/CodeGen/Inputs/thinlto_expect2.proftext
clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c

Modified: 
clang/lib/CodeGen/CodeGenAction.cpp
clang/test/CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenAction.cpp 
b/clang/lib/CodeGen/CodeGenAction.cpp
index 7f3f358d3d98..7065e78f19a2 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -151,6 +151,29 @@ namespace clang {
   FrontendTimesIsEnabled = TimePasses;
   llvm::TimePassesIsEnabled = TimePasses;
 }
+
+// This constructor is used in installing an empty BackendConsumer
+// to use the clang diagnostic handler for IR input files. It avoids
+// initializing the OS field.
+BackendConsumer(BackendAction Action, DiagnosticsEngine &Diags,
+const HeaderSearchOptions &HeaderSearchOpts,
+const PreprocessorOptions &PPOpts,
+const CodeGenOptions &CodeGenOpts,
+const TargetOptions &TargetOpts,
+const LangOptions &LangOpts, bool TimePasses,
+SmallVector LinkModules, LLVMContext &C,
+CoverageSourceInfo *CoverageInfo = nullptr)
+: Diags(Diags), Action(Action), HeaderSearchOpts(HeaderSearchOpts),
+  CodeGenOpts(CodeGenOpts), TargetOpts(TargetOpts), LangOpts(LangOpts),
+  Context(nullptr),
+  LLVMIRGeneration("irgen", "LLVM IR Generation Time"),
+  LLVMIRGenerationRefCount(0),
+  Gen(CreateLLVMCodeGen(Diags, "", HeaderSearchOpts, PPOpts,
+CodeGenOpts, C, CoverageInfo)),
+  LinkModules(std::move(LinkModules)) {
+  FrontendTimesIsEnabled = TimePasses;
+  llvm::TimePassesIsEnabled = TimePasses;
+}
 llvm::Module *getModule() const { return Gen->GetModule(); }
 std::unique_ptr takeModule() {
   return std::unique_ptr(Gen->ReleaseModule());
@@ -616,10 +639,20 @@ void BackendConsumer::UnsupportedDiagHandler(
   StringRef Filename;
   unsigned Line, Column;
   bool BadDebugInfo = false;
-  FullSourceLoc Loc =
-  getBestLocationFromDebugLoc(D, BadDebugInfo, Filename, Line, Column);
+  FullSourceLoc Loc;
+  std::string Msg;
+  raw_string_ostream MsgStream(Msg);
 
-  Diags.Report(Loc, diag::err_fe_backend_unsupported) << D.getMessage().str();
+  // Context will be nullptr for IR input files, we will construct the diag
+  // message from llvm::DiagnosticInfoUnsupported.
+  if (Context != nullptr) {
+Loc = getBestLocationFromDebugLoc(D, BadDebugInfo, Filename, Line, Column);
+MsgStream << D.getMessage();
+  } else {
+DiagnosticPrinterRawOStream DP(MsgStream);
+D.print(DP);
+  }
+  Diags.Report(Loc, diag::err_fe_backend_unsupported) << MsgStream.str();
 
   if (BadDebugInfo)
 // If we were not able to translate the file:line:col information
@@ -635,10 +668,21 @@ void BackendConsumer::MisExpectDiagHandler(
   StringRef Filename;
   unsigned Line, Column;
   bool BadDebugInfo = false;
-  FullSourceLoc Loc =
-  getBestLocationFromDebugLoc(D, BadDebugInfo, Filename, Line, Column);
+  FullSourceLoc Loc;
+  std::string Msg;
+  raw_string_ostream MsgStream(Msg);
+  DiagnosticPrinterRawOStream DP(MsgStream);
 
-  Diags.Report(Loc, diag::warn_profile_data_misexpect) << D.getMsg

[PATCH] D69585: PerformPendingInstatiations() already in the PCH

2020-01-14 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

I don't see any crashes in OpenMP tests, other tests just must be updated by 
the author, if this patch will ever going to be landed. I don't think it is a 
good idea to have a not fully functional implementation, even guarded by the 
option.


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

https://reviews.llvm.org/D69585



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


[PATCH] D72463: [Driver][X86] Add -malign-branch* and -malign-branch-within-32B-boundaries

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 61862 tests passed, 1 failed 
and 781 were skipped.

  failed: 
libc++.std/thread/thread_mutex/thread_mutex_requirements/thread_sharedtimedmutex_requirements/thread_sharedtimedmutex_class/try_lock.pass.cpp

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72463



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


[PATCH] D71848: Allow the discovery of Android NDK's triple-prefixed binaries.

2020-01-14 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

Since this change is not android-only, please update change description, and 
update some non-android tests.

E.g. maybe the tests in clang/test/Driver/linux-ld.c for 
ubuntu_14.04_multiarch_tree should check the path at which ld is found. While 
the existing Inputs/ubuntu_14.04_multiarch_tree doesn't have any "ld" files 
populated, and the tests aren't checking for ld's path at all, it would be 
reasonable to add such files and then check the result.

This is what the layout of the "ld" files look like in current ubuntu versions 
on x86_64. It seems that it was almost the same back in 2014 -- except the 
triple-less names were the primary file, and the others linked to them. That's 
not really relevant to the test, anyways, just the filenames existing and being 
executable.

  lrwxrwxrwx  /usr/bin/ld.bfd -> x86_64-linux-gnu-ld.bfd
  lrwxrwxrwx  /usr/bin/ld.gold -> x86_64-linux-gnu-ld.gold
  lrwxrwxrwx  /usr/bin/ld -> x86_64-linux-gnu-ld
  -rwxr-xr-x  /usr/bin/x86_64-linux-gnu-ld.bfd
  -rwxr-xr-x  /usr/bin/x86_64-linux-gnu-ld.gold
  -rwxr-xr-x  /usr/bin/x86_64-linux-gnu-ld -> x86_64-linux-gnu-ld.bfd
  -rwxr-xr-x  /usr/bin/powerpc64le-linux-gnu-ld.bfd
  -rwxr-xr-x  /usr/bin/powerpc64le-linux-gnu-ld.gold
  -rwxr-xr-x  /usr/bin/powerpc64le-linux-gnu-ld -> powerpc64le-linux-gnu-ld.bfd

Before this clang patch, we would've defaulted to /usr/bin/ld unless the target 
string was specified exactly as "x86_64-linux-gnu" or "powerpc64le-linux-gnu". 
Afterwards, we can also chose those tools for any other triple which we can 
detect as matching those gcc installation triples.

This would even have the useful effect of allowing an invocation like "clang 
-target powerpc64le-unknown-linux-gnu" to work, which it doesn't do currently 
-- because it defaults to /usr/bin/ld, which is an x86_64 linker.




Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2578
 getProgramPaths().push_back(getDriver().Dir);
+  getProgramPrefixes().push_back(Twine(GCCInstallation.getTriple().str() + 
"-").str());
+

I suspect this doesn't actually work here, since GCCInstallation.init() hasn't 
yet been called. But you have the same in Linux.cpp, after the init() call, 
which seems better.




Comment at: clang/lib/Driver/ToolChains/Linux.cpp:242
  .str());
+PPrefixes.push_back(Twine(GCCInstallation.getTriple().str() + "-").str());
   }

Probably should check that GCCInstallation.getTriple() != Triple before adding, 
in order to avoid duplicating entries in the search-list.



Comment at: clang/test/Driver/android-triple-version.c:1
+// Android's target triples can contain a version number in the environment
+// field (e.g. arm-linux-androideabi9).

This seems like too many test-cases. It doesn't seem to me that they're 
actually adding any meaningful coverage, after the first 3?



Comment at: clang/test/Driver/android-triple-version.c:6
+// Ensure no execute permissions on .../bin/{target-triple}/ld.
+// RUN: chmod -x %S/Inputs/basic_android_ndk_tree/arm-linux-androideabi/bin/ld
+// RUN: chmod -x %S/Inputs/basic_android_ndk_tree/aarch64-linux-android/bin/ld

You shouldn't edit files in the Inputs tree (or add/remove files there either). 
If this script stops, it may be left in an edited state, which would be bad. 
Also, sometimes it might be read-only.

Another way to achieve this test goal may be with -fuse-ld=prefixtest, and then 
create bin/$triple-ld.prefixtest, but not $triple/bin/ld.prefixtest


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71848



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


[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61850 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488



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


[PATCH] D72121: [clang-tidy] Fix readability-identifier-naming missing member variables

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

In D72121#1817733 , @Eugene.Zelenko 
wrote:

> Please also close PRs.


Done


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

https://reviews.llvm.org/D72121



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


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

2020-01-14 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: llvm/include/llvm/Support/FileUtilities.h:44
+if (!FuncAddr) {
+  return "";
+}

I'm not sure that this function should handle failure by returning an empty 
string. The error condition can be made explicit by making the return type of 
the function `llvm::Expected>`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72736



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


[PATCH] D62686: [RISCV] Add support for save/restore of callee-saved registers via libcalls

2020-01-14 Thread Ana Pazos via Phabricator via cfe-commits
apazos added a comment.

Lewis, your latest patch looks good, we just had another run with no new 
failures. But we know it will have issues with -g. So I think we should not 
merge it yet. Do you have a version of the patch that creates the labels for 
the compiler-generated save/restore lib calls, so that this optimization does 
not depend on D71593 ? We could merge that 
version then, and when D71593  is accepted, 
you just have to rework/remove the label generation part of the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62686



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


[PATCH] D72463: [Driver][X86] Add -malign-branch* and -malign-branch-within-32B-boundaries

2020-01-14 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 238120.
MaskRay marked 2 inline comments as done.
MaskRay added a comment.

Make driver a thin wrapper since we are going to add a master option in MC 
(D72738 )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72463

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/x86-malign-branch.c
  clang/test/Driver/x86-malign-branch.s

Index: clang/test/Driver/x86-malign-branch.s
===
--- /dev/null
+++ clang/test/Driver/x86-malign-branch.s
@@ -0,0 +1,13 @@
+/// Test that -malign-branch* and -mbranches-within-32B-boundaries are handled for assembly files.
+
+// RUN: %clang -target x86_64 -malign-branch-boundary=16 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY
+// BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+
+// RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE
+// TYPE: "-mllvm" "-x86-align-branch=fused+jcc+jmp"
+
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=5 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX
+// PREFIX: "-mllvm" "-x86-align-branch-prefix-size=5"
+
+// RUN: %clang -target x86_64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck %s --check-prefix=32B
+// 32B: "-mllvm" "-x86-branches-within-32B-boundaries"
Index: clang/test/Driver/x86-malign-branch.c
===
--- /dev/null
+++ clang/test/Driver/x86-malign-branch.c
@@ -0,0 +1,39 @@
+/// Test that -malign-branch* and -mbranches-within-32B-boundaries are parsed and converted to -mllvm options.
+
+/// Test -malign-branch-boundary=
+// RUN: %clang -target x86_64 -malign-branch-boundary=16 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY
+// BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+
+// RUN: %clang -target x86_64 -malign-branch-boundary=8 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-ERR
+// RUN: %clang -target x86_64 -malign-branch-boundary=15 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-ERR
+// BOUNDARY-ERR: invalid argument {{.*}} to -malign-branch-boundary=
+
+/// Test -malign-branch=
+// RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE0
+// TYPE0: "-mllvm" "-x86-align-branch=fused+jcc+jmp"
+// RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp,ret,call,indirect %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE1
+// TYPE1: "-mllvm" "-x86-align-branch=fused+jcc+jmp+ret+call+indirect"
+
+// RUN: %clang -target x86_64 -malign-branch=fused,foo,bar %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE-ERR
+// TYPE-ERR: invalid argument 'foo' to -malign-branch=; each element must be one of: fused, jcc, jmp, call, ret, indirect
+// TYPE-ERR: invalid argument 'bar' to -malign-branch=; each element must be one of: fused, jcc, jmp, call, ret, indirect
+
+/// Test -malign-branch-prefix-size=
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=0 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-0
+// PREFIX-0: "-mllvm" "-x86-align-branch-prefix-size=0"
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=5 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-5
+// PREFIX-5: "-mllvm" "-x86-align-branch-prefix-size=5"
+
+// RUN: %clang -target x86_64 -malign-branch-prefix-size=6 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-6
+// PREFIX-6: invalid argument
+
+/// Test -mbranches-within-32B-boundaries
+// RUN: %clang -target x86_64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck %s --check-prefix=32B
+// 32B: "-mllvm" "-x86-branches-within-32B-boundaries"
+
+/// Unsupported on other targets.
+// RUN: %clang -target aarch64 -malign-branch=jmp %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// RUN: %clang -target aarch64 -malign-branch-boundary=7 %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// RUN: %clang -target aarch64 -malign-branch-prefix-size=15 %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// RUN: %clang -target aarch64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
+// UNUSED: warning: argument unused
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2015,8 +2015,60 @@
 CmdArgs.push_back("-mpacked-stack");
 }
 
+static void addX86AlignBranchArgs(const Driver &D, const ArgList &Args,
+  ArgStringList &CmdArgs) {
+  if (Args.hasArg(options::OPT_mbranches_within_32B_boundaries)) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-x86-branches-within-32B-boundaries");
+  }
+  if (const Arg *A = 

[clang] 23058f9 - [OPENMP]Do not use RTTI by default for NVPTX devices.

2020-01-14 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-01-14T18:12:06-05:00
New Revision: 23058f9dd4d7e18239fd63b6da52549514b45fda

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

LOG: [OPENMP]Do not use RTTI by default for NVPTX devices.

NVPTX does not support RTTI, so disable it by default.

Added: 
clang/test/Driver/openmp-offload-gpu.cpp

Modified: 
clang/lib/Driver/ToolChain.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index cab97b1a601a..3ebbd30195b3 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -68,7 +68,8 @@ static ToolChain::RTTIMode CalculateRTTIMode(const ArgList 
&Args,
   }
 
   // -frtti is default, except for the PS4 CPU.
-  return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled : ToolChain::RM_Enabled;
+  return (Triple.isPS4CPU() || Triple.isNVPTX()) ? ToolChain::RM_Disabled
+ : ToolChain::RM_Enabled;
 }
 
 ToolChain::ToolChain(const Driver &D, const llvm::Triple &T,

diff  --git a/clang/test/Driver/openmp-offload-gpu.cpp 
b/clang/test/Driver/openmp-offload-gpu.cpp
new file mode 100644
index ..9da7308506ae
--- /dev/null
+++ b/clang/test/Driver/openmp-offload-gpu.cpp
@@ -0,0 +1,20 @@
+///
+/// Perform several driver tests for OpenMP offloading
+///
+
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: powerpc-registered-target
+// REQUIRES: nvptx-registered-target
+
+/// ###
+
+/// PTXAS is passed -c flag by default when offloading to an NVIDIA device 
using OpenMP
+/// Check that the flag is passed when -fopenmp-relocatable-target is used.
+// RUN:   %clangxx -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:  -save-temps -no-canonical-prefixes %s -x c++ -c 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-RTTI %s
+
+// CHK-RTTI: clang{{.*}}" "-triple" "nvptx64-nvidia-cuda"
+// CHK-RTTI-SAME: "-fno-rtti"
+



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


[PATCH] D72624: [WIP] TargetMachine Hook for Module Metadata

2020-01-14 Thread Sam Elliott via Phabricator via cfe-commits
lenary added a comment.

One thing to note about my patch, above: I have not made the TargetMachine 
DataLayout non-const, but I wanted to ensure that this might be possible in 
future, which is why calling `initializeOptionsWithModuleMetadata` must be done 
before the first call to `createDataLayout`. At the moment, the RISC-V ABI data 
layouts are based only on riscv32 vs riscv64, not the `target-abi` metadata 
(all riscv32 ABIs use the same data layout, all riscv64 ABIs use the same data 
layout), but I know Mips has more complex logic for computing their data layout 
based on their ABI.

In D72624#1820580 , @tejohnson wrote:

> The ThinLTO "link", which is where the modules are added serially, does not 
> read IR, only the summaries, which are linked together into a large index 
> used to drive ThinLTO whole program analysis. So you can't really read the 
> module flags directly during addModule, they need to be propagated via the 
> summary flags. The ThinLTO backends which are subsequently fired off in 
> parallel do read IR. In those backends, depending on the results of the 
> ThinLTO analysis phase, we may use IRMover to link in ("import) functions 
> from other modules. At that point, the module flags from any modules that 
> backend is importing from will be combined and any errors due to conficting 
> values will be issued.


This has been a very helpful explanation of ThinLTO.

> Thinking through this some more, rather than attempting to fully validate the 
> consistency of the module flags across all modules in ThinLTO mode, just rely 
> on some checking when we merge subsections of the IR in the ThinLTO backends 
> during this importing, which will happen automatically. This is presumably 
> where the checking is desirable anyway (in terms of the cases you are most 
> interested in catching with ThinLTO, because the IR is getting merged). Note 
> that unlike in the full LTO case, where the IR is merged before you create 
> the TM, in the ThinLTO case the TM will be created before any of this 
> cross-module importing (partial IR merging), so with your patch presumably it 
> will just use whatever module flag is on that original Module for it's 
> corresponding ThinLTO backend. But since it sounds like any difference in 
> these module flags is an error, it will just get flagged a little later but 
> not affect how the TM is set up in the correct case. Does that sound 
> reasonable?

That does sound reasonable. I want errors to be reported, which it sounds like 
will happen, even if it is only "lazily" when using ThinLTO.

At some point in the future the ThinLTO summaries might want to gain knowledge 
of the module flags, which would help with eager error reporting (i.e., ThinLTO 
telling the user that two modules are incompatible before it does any 
analysis), but I think that is a step too far for this patch.

I shall look at making a patch with the RISC-V specific behaviour that @khchen 
and I intend implement on top of this, and then running more tests (including 
doing llvm test-suite runs with each kind of LTO enabled).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72624



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


[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 61849 tests passed, 1 failed 
and 781 were skipped.

  failed: 
libc++.std/thread/thread_mutex/thread_mutex_requirements/thread_mutex_requirements_mutex/thread_mutex_class/try_lock.pass.cpp

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488



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


[PATCH] D69778: Make -fmodules-codegen and -fmodules-debuginfo work also with precompiled headers

2020-01-14 Thread Luboš Luňák via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcbc9d22e49b4: make -fmodules-codegen and -fmodules-debuginfo 
work also with PCHs (authored by llunak).

Changed prior to commit:
  https://reviews.llvm.org/D69778?vs=227634&id=238115#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69778

Files:
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Modules/Inputs/codegen-flags/foo.h
  clang/test/PCH/codegen.cpp

Index: clang/test/PCH/codegen.cpp
===
--- /dev/null
+++ clang/test/PCH/codegen.cpp
@@ -0,0 +1,30 @@
+// This test is the PCH version of Modules/codegen-flags.test . It uses its inputs.
+// The purpose of this test is just verify that the codegen options work with PCH as well.
+// All the codegen functionality should be tested in Modules/.
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// REQUIRES: x86-registered-target
+
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules-codegen -x c++-header -building-pch-with-obj -emit-pch %S/../Modules/Inputs/codegen-flags/foo.h -o %t/foo-cg.pch
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules-debuginfo -x c++-header -building-pch-with-obj -emit-pch %S/../Modules/Inputs/codegen-flags/foo.h -o %t/foo-di.pch
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited -o - %s -include-pch %t/foo-cg.pch -building-pch-with-obj -fmodules-codegen | FileCheck --check-prefix=CG %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited -o - %s -include-pch %t/foo-di.pch -building-pch-with-obj -fmodules-debuginfo | FileCheck --check-prefix=DI %s
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited -o - -include-pch %t/foo-cg.pch %S/../Modules/Inputs/codegen-flags/use.cpp | FileCheck --check-prefix=CG-USE %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited -o - -include-pch %t/foo-di.pch %S/../Modules/Inputs/codegen-flags/use.cpp | FileCheck --check-prefix=DI-USE %s
+
+// CG: define weak_odr void @_Z2f1v
+// CG: DICompileUnit
+// CG-NOT: DICompositeType
+
+// CG-USE: declare void @_Z2f1v
+// CG-USE: DICompileUnit
+// CG-USE: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "foo"
+
+// DI-NOT: define
+// DI: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "foo"
+
+// DI-USE: define linkonce_odr void @_Z2f1v
+// DI-USE: = !DICompositeType(tag: DW_TAG_structure_type, name: "foo", {{.*}}, flags: DIFlagFwdDecl
Index: clang/test/Modules/Inputs/codegen-flags/foo.h
===
--- clang/test/Modules/Inputs/codegen-flags/foo.h
+++ clang/test/Modules/Inputs/codegen-flags/foo.h
@@ -1,4 +1,7 @@
+#ifndef FOO_H
+#define FOO_H
 struct foo {
 };
 inline void f1() {
 }
+#endif
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -1010,15 +1010,16 @@
 
   if (D->getStorageDuration() == SD_Static) {
 bool ModulesCodegen = false;
-if (Writer.WritingModule &&
-!D->getDescribedVarTemplate() && !D->getMemberSpecializationInfo() &&
+if (!D->getDescribedVarTemplate() && !D->getMemberSpecializationInfo() &&
 !isa(D)) {
   // When building a C++ Modules TS module interface unit, a strong
   // definition in the module interface is provided by the compilation of
   // that module interface unit, not by its users. (Inline variables are
   // still emitted in module users.)
   ModulesCodegen =
-  (Writer.WritingModule->Kind == Module::ModuleInterfaceUnit &&
+  (((Writer.WritingModule &&
+ Writer.WritingModule->Kind == Module::ModuleInterfaceUnit) ||
+Writer.Context->getLangOpts().BuildingPCHWithObjectFile) &&
Writer.Context->GetGVALinkageForVariable(D) == GVA_StrongExternal);
 }
 Record.push_back(ModulesCodegen);
@@ -2425,9 +2426,11 @@
 
   assert(FD->doesThisDeclarationHaveABody());
   bool ModulesCodegen = false;
-  if (Writer->WritingModule && !FD->isDependentContext()) {
+  if (!FD->isDependentContext()) {
 Optional Linkage;
-if (Writer->WritingModule->Kind == Module::ModuleInterfaceUnit) {
+if ((Writer->WritingModule &&
+ Writer->WritingModule->Kind == Module::ModuleInterfaceUnit) ||
+Writer->Context->getLangOpts().BuildingPCHWithObjectFile) {
   // When building a C++ Modules TS module interface unit, a strong
   // definition in the module interface is provided by the compilation of
   // that module interface unit, not by its users. (Inline functions are
Index: clang/lib/Serialization/AS

[PATCH] D71387: pass -mabi to LTO linker only in RISC-V targets, enable RISC-V LTO

2020-01-14 Thread Sam Elliott via Phabricator via cfe-commits
lenary added a comment.

@efriedma To keep you in the loop, D72624  is 
the patch to add a target hook for setting the TargetMachine options based on 
module metadata. That patch does not add any RISC-V specific functionality, it 
only lays the groundwork for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71387



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


[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:112
+  
+  Flags use of the `C` standard library functions 'memset', 'memcpy' and
+  'memcmp' and similar derivatives on non-trivial types.

Please use double back-ticks to highlight function names.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-oop57-cpp.rst:6
+
+  Flags use of the `C` standard library functions 'memset', 'memcpy' and
+  'memcmp' and similar derivatives on non-trivial types.

Please use double back-ticks to highlight function names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488



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


[PATCH] D72488: [clang-tidy] Add check for CERT-OOP57-CPP

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 238114.
njames93 added a comment.

- remove `This check` from docs... again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72488

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/NonTrivialTypesLibcMemoryCallsCheck.cpp
  clang-tools-extra/clang-tidy/cert/NonTrivialTypesLibcMemoryCallsCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-oop57-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/cert-oop57-cpp.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-oop57-cpp.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-oop57-cpp.cpp
@@ -0,0 +1,90 @@
+// RUN: %check_clang_tidy %s cert-oop57-cpp %t -- \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: cert-oop57-cpp.MemSetNames, value: mymemset}, \
+// RUN:  {key: cert-oop57-cpp.MemCpyNames, value: mymemcpy}, \
+// RUN:  {key: cert-oop57-cpp.MemCmpNames, value: mymemcmp}]}' \
+// RUN: --
+
+void mymemset(void *, unsigned char, decltype(sizeof(int)));
+void mymemcpy(void *, const void *, decltype(sizeof(int)));
+int mymemcmp(const void *, const void *, decltype(sizeof(int)));
+
+namespace std {
+void memset(void *, unsigned char, decltype(sizeof(int)));
+void memcpy(void *, const void *, decltype(sizeof(int)));
+void memmove(void *, const void *, decltype(sizeof(int)));
+void strcpy(void *, const void *, decltype(sizeof(int)));
+int memcmp(const void *, const void *, decltype(sizeof(int)));
+int strcmp(const void *, const void *, decltype(sizeof(int)));
+} // namespace std
+
+struct Trivial {
+  int I;
+  int J;
+};
+
+struct NonTrivial {
+  int I;
+  int J;
+
+  NonTrivial() : I(0), J(0) {}
+  NonTrivial &operator=(const NonTrivial &Other) {
+I = Other.I;
+J = Other.J;
+return *this;
+  }
+
+  bool operator==(const Trivial &Other) const {
+return I == Other.I && J == Other.J;
+  }
+  bool operator!=(const Trivial &Other) const {
+return !(*this == Other);
+  }
+};
+
+void foo(const Trivial &Other) {
+  Trivial Data;
+  std::memset(&Data, 0, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  std::memset(&Data, 0, sizeof(Trivial));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  std::memcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memcpy' on a non-trivially copyable class is undefined
+  std::memmove(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'memmove' on a non-trivially copyable class is undefined
+  std::strcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: calling 'strcpy' on a non-trivially copyable class is undefined
+  std::memcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'memcmp'
+  std::strcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES-NOT: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'strcmp'
+}
+
+void bar(const NonTrivial &Other) {
+  NonTrivial Data;
+  std::memset(&Data, 0, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  // Check it detects sizeof(Type) as well as sizeof(Instantiation)
+  std::memset(&Data, 0, sizeof(NonTrivial));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memset' on a non-trivially default constructible class is undefined
+  std::memcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memcpy' on a non-trivially copyable class is undefined
+  std::memmove(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'memmove' on a non-trivially copyable class is undefined
+  std::strcpy(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'strcpy' on a non-trivially copyable class is undefined
+  std::memcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'memcmp'
+  std::strcmp(&Data, &Other, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: consider using comparison operators instead of calling 'strcmp'
+}
+
+void baz(const NonTrivial &Other) {
+  NonTrivial Data;
+  mymemset(&Data, 0, sizeof(Data));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: calling 'mymemset' on a non-trivially default constructible class is undefined
+  mymemcpy(&Data, &Other, sizeof(Data));
+  // C

[PATCH] D71714: [Sema] Fix -Warray-bounds false negative when casting an out-of-bounds array item

2020-01-14 Thread Ilya Mirsky via Phabricator via cfe-commits
ilya marked 4 inline comments as done.
ilya added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:13384
   case Stmt::MemberExprClass: {
 expr = cast(expr)->getBase();
 break;

rsmith wrote:
> ilya wrote:
> > rsmith wrote:
> > > Hmm, don't we need to do different things for dot and arrow in this case?
> > There are several test cases for an out of bounds access on an array member 
> > using dot and arrow operators in array-bounds.cpp. Do you have a specific 
> > test case for which you think the code is broken?
> > There are several test cases for an out of bounds access on an array member 
> > using dot and arrow operators in array-bounds.cpp. Do you have a specific 
> > test case for which you think the code is broken?
> 
> Sure. There's a false negative for this:
> 
> ```
> struct A { int n; };
> A *a[4];
> int *n = &a[4]->n;
> ```
> 
> ... because we incorrectly visit the left-hand side of the `->` with 
> `AllowOnePastEnd == 1`. The left-hand side of `->` is subject to 
> lvalue-to-rvalue conversion, so can't be one-past-the-end regardless of the 
> context in which the `->` appears.
> ... because we incorrectly visit the left-hand side of the -> with 
> AllowOnePastEnd == 1. The left-hand side of -> is subject to lvalue-to-rvalue 
> conversion, so can't be one-past-the-end regardless of the context in which 
> the -> appears.

Thanks for clarifying. So basically we don't want to allow one-past-end for 
MemberExpr?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71714



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


[PATCH] D72723: Built-in functions for AMDGPU MFMA instructions.

2020-01-14 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

LGTM




Comment at: llvm/lib/Target/AMDGPU/AMDGPU.td:487
 
+def FeatureMfma1Insts : SubtargetFeature<"mfma1-insts",
+  "HasMfma1Insts",

We already have the HasMAIInsts feature 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72723



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


[PATCH] D71714: [Sema] Fix -Warray-bounds false negative when casting an out-of-bounds array item

2020-01-14 Thread Ilya Mirsky via Phabricator via cfe-commits
ilya updated this revision to Diff 238106.
ilya added a comment.

Address rsmith's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71714

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Parser/cxx-ambig-decl-expr.cpp
  clang/test/SemaCXX/array-bounds.cpp

Index: clang/test/SemaCXX/array-bounds.cpp
===
--- clang/test/SemaCXX/array-bounds.cpp
+++ clang/test/SemaCXX/array-bounds.cpp
@@ -27,7 +27,7 @@
 };
 
 void f1(int a[1]) {
-  int val = a[3]; // no warning for function argumnet
+  int val = a[3]; // no warning for function argument
 }
 
 void f2(const int (&a)[2]) { // expected-note {{declared here}}
@@ -133,7 +133,7 @@
 
 int test_sizeof_as_condition(int flag) {
   int arr[2] = { 0, 0 }; // expected-note {{array 'arr' declared here}}
-  if (flag) 
+  if (flag)
 return sizeof(char) != sizeof(char) ? arr[2] : arr[1];
   return sizeof(char) == sizeof(char) ? arr[2] : arr[1]; // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
 }
@@ -241,7 +241,7 @@
 }
 
 int test_pr11007_aux(const char * restrict, ...);
-  
+
 // Test checking with varargs.
 void test_pr11007() {
   double a[5]; // expected-note {{array 'a' declared here}}
@@ -309,3 +309,33 @@
 foo(); // expected-note 1{{in instantiation of function template specialization}}
   };
 }
+
+namespace PR44343 {
+  const unsigned int array[2] = {0, 1}; // expected-note 5{{array 'array' declared here}}
+
+  const int i1 = (const int)array[2]; // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+  const int i2 = static_cast(array[2]); // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+  const int &i3 = reinterpret_cast(array[2]); // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+  unsigned int &i4 = const_cast(array[2]); // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+  int i5 = int(array[2]); // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+  const unsigned int *i6 = &(1 > 0 ? array[2] : array[1]); // no warning for one-past-end element's address retrieval
+
+  // Test dynamic cast
+  struct Base {
+virtual ~Base();
+  };
+  struct Derived : Base {
+  };
+  Base baseArr[2]; // expected-note {{array 'baseArr' declared here}}
+  Derived *d1 = dynamic_cast(&baseArr[2]); // FIXME: Should actually warn because dynamic_cast accesses the vptr
+  Derived &d2 = dynamic_cast(baseArr[2]); // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+
+  // Test operator `&` in combination with operators `.` and `->`
+  struct A {
+int n;
+  };
+  A a[2]; // expected-note {{array 'a' declared here}}
+  int *n = &a[2].n; // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+  A *aPtr[2]; // expected-note {{array 'aPtr' declared here}}
+  int *n2 = &aPtr[2]->n; // expected-warning {{array index 2 is past the end of the array (which contains 2 elements)}}
+}
Index: clang/test/Parser/cxx-ambig-decl-expr.cpp
===
--- clang/test/Parser/cxx-ambig-decl-expr.cpp
+++ clang/test/Parser/cxx-ambig-decl-expr.cpp
@@ -24,7 +24,7 @@
 
   // This is array indexing not an array declarator because a comma expression
   // is not syntactically a constant-expression.
-  int(x[1,1]); // expected-warning 2{{unused}}
+  int(x[1,0]); // expected-warning 2{{unused}}
 
   // This is array indexing not an array declaration because a braced-init-list
   // is not syntactically a constant-expression.
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -13368,62 +13368,63 @@
 << ND->getDeclName());
 }
 
-void Sema::CheckArrayAccess(const Expr *expr) {
-  int AllowOnePastEnd = 0;
-  while (expr) {
-expr = expr->IgnoreParenImpCasts();
-switch (expr->getStmtClass()) {
-  case Stmt::ArraySubscriptExprClass: {
-const ArraySubscriptExpr *ASE = cast(expr);
-CheckArrayAccess(ASE->getBase(), ASE->getIdx(), ASE,
- AllowOnePastEnd > 0);
-expr = ASE->getBase();
-break;
-  }
-  case Stmt::MemberExprClass: {
-expr = cast(expr)->getBase();
-break;
-  }
-  case Stmt::OMPArraySectionExprClass: {
-const OMPArraySectionExpr *ASE = cast(expr);
-if (ASE->getLowerBound())
-  CheckArrayAccess(ASE->getBase(), ASE->getLowerBound(),
-   /*ASE=*/nullptr, AllowOnePastEnd > 0);
-return;
-  }
-  case Stmt::U

[PATCH] D69779: -fmodules-codegen should not emit extern templates

2020-01-14 Thread Luboš Luňák via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG729530f68fe1: -fmodules-codegen should not emit extern 
templates (authored by llunak).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69779

Files:
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Modules/codegen-extern-template.cpp
  clang/test/Modules/codegen-extern-template.h
  clang/test/Modules/codegen-extern-template.modulemap


Index: clang/test/Modules/codegen-extern-template.modulemap
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.modulemap
@@ -0,0 +1 @@
+module foo { header "codegen-extern-template.h" }
Index: clang/test/Modules/codegen-extern-template.h
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.h
@@ -0,0 +1,12 @@
+// header for codegen-extern-template.cpp
+#ifndef CODEGEN_EXTERN_TEMPLATE_H
+#define CODEGEN_EXTERN_TEMPLATE_H
+
+template 
+inline T foo() { return 10; }
+
+extern template int foo();
+
+inline int bar() { return foo(); }
+
+#endif
Index: clang/test/Modules/codegen-extern-template.cpp
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules -fmodules-codegen 
-emit-module -fmodule-name=foo %S/codegen-extern-template.modulemap -x c++ -o 
%t.pcm
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fmodules -fmodule-file=%t.pcm %s 
-emit-llvm -o - | FileCheck %s
+// expected-no-diagnostics
+
+#include "codegen-extern-template.h"
+
+template int foo();
+
+// CHECK: define weak_odr i32 @_Z3fooIiET_v
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2437,11 +2437,12 @@
 }
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
-  // non-always_inline functions.
+  // non-always_inline functions, unless they are available elsewhere.
   if (!FD->hasAttr()) {
 if (!Linkage)
   Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-ModulesCodegen = *Linkage != GVA_Internal;
+ModulesCodegen =
+*Linkage != GVA_Internal && *Linkage != GVA_AvailableExternally;
   }
 }
   }


Index: clang/test/Modules/codegen-extern-template.modulemap
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.modulemap
@@ -0,0 +1 @@
+module foo { header "codegen-extern-template.h" }
Index: clang/test/Modules/codegen-extern-template.h
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.h
@@ -0,0 +1,12 @@
+// header for codegen-extern-template.cpp
+#ifndef CODEGEN_EXTERN_TEMPLATE_H
+#define CODEGEN_EXTERN_TEMPLATE_H
+
+template 
+inline T foo() { return 10; }
+
+extern template int foo();
+
+inline int bar() { return foo(); }
+
+#endif
Index: clang/test/Modules/codegen-extern-template.cpp
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules -fmodules-codegen -emit-module -fmodule-name=foo %S/codegen-extern-template.modulemap -x c++ -o %t.pcm
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fmodules -fmodule-file=%t.pcm %s -emit-llvm -o - | FileCheck %s
+// expected-no-diagnostics
+
+#include "codegen-extern-template.h"
+
+template int foo();
+
+// CHECK: define weak_odr i32 @_Z3fooIiET_v
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2437,11 +2437,12 @@
 }
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
-  // non-always_inline functions.
+  // non-always_inline functions, unless they are available elsewhere.
   if (!FD->hasAttr()) {
 if (!Linkage)
   Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-ModulesCodegen = *Linkage != GVA_Internal;
+ModulesCodegen =
+*Linkage != GVA_Internal && *Linkage != GVA_AvailableExternally;
   }
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D72547: [llvm] Make new pass manager's OptimizationLevel a class

2020-01-14 Thread Mircea Trofin via Phabricator via cfe-commits
mtrofin updated this revision to Diff 238107.
mtrofin marked 2 inline comments as done.
mtrofin added a comment.

Alternative: expose speedup/size components to more closely align with legacy PM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72547

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/Passes/PassBuilder.cpp

Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -243,20 +243,18 @@
 
 extern cl::opt FlattenedProfileUsed;
 
-static bool isOptimizingForSize(PassBuilder::OptimizationLevel Level) {
-  switch (Level) {
-  case PassBuilder::O0:
-  case PassBuilder::O1:
-  case PassBuilder::O2:
-  case PassBuilder::O3:
-return false;
-
-  case PassBuilder::Os:
-  case PassBuilder::Oz:
-return true;
-  }
-  llvm_unreachable("Invalid optimization level!");
-}
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::O0 = {0,
+   0};
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::O1 = {1,
+   0};
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::O2 = {2,
+   0};
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::O3 = {3,
+   0};
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::Os = {2,
+   1};
+const PassBuilder::OptimizationLevel PassBuilder::OptimizationLevel::Oz = {2,
+   2};
 
 namespace {
 
@@ -395,7 +393,7 @@
 PassBuilder::buildFunctionSimplificationPipeline(OptimizationLevel Level,
  ThinLTOPhase Phase,
  bool DebugLogging) {
-  assert(Level != O0 && "Must request optimizations!");
+  assert(Level != OptimizationLevel::O0 && "Must request optimizations!");
   FunctionPassManager FPM(DebugLogging);
 
   // Form SSA out of local memory accesses after breaking apart aggregates into
@@ -406,7 +404,7 @@
   FPM.addPass(EarlyCSEPass(true /* Enable mem-ssa. */));
 
   // Hoisting of scalars and load expressions.
-  if (Level > O1) {
+  if (Level.getSpeedupLevel() >= 2) {
 if (EnableGVNHoist)
   FPM.addPass(GVNHoistPass());
 
@@ -418,7 +416,7 @@
   }
 
   // Speculative execution if the target has divergent branches; otherwise nop.
-  if (Level > O1) {
+  if (Level.getSpeedupLevel() > 1) {
 FPM.addPass(SpeculativeExecutionPass());
 
 // Optimize based on known information about branches, and cleanup afterward.
@@ -426,11 +424,11 @@
 FPM.addPass(CorrelatedValuePropagationPass());
   }
   FPM.addPass(SimplifyCFGPass());
-  if (Level == O3)
+  if (Level == OptimizationLevel::O3)
 FPM.addPass(AggressiveInstCombinePass());
   FPM.addPass(InstCombinePass());
 
-  if (!isOptimizingForSize(Level))
+  if (!Level.isOptimizingForSize())
 FPM.addPass(LibCallsShrinkWrapPass());
 
   invokePeepholeEPCallbacks(FPM, Level);
@@ -438,11 +436,11 @@
   // For PGO use pipeline, try to optimize memory intrinsics such as memcpy
   // using the size value profile. Don't perform this when optimizing for size.
   if (PGOOpt && PGOOpt->Action == PGOOptions::IRUse &&
-  !isOptimizingForSize(Level) && Level > O1)
+  (Level.getSpeedupLevel() > 1 && !Level.isOptimizingForSize()))
 FPM.addPass(PGOMemOPSizeOpt());
 
   // TODO: Investigate the cost/benefit of tail call elimination on debugging.
-  if (Level > O1)
+  if (Level.getSpeedupLevel() > 1)
 FPM.addPass(TailCallElimPass());
   FPM.addPass(SimplifyCFGPass());
 
@@ -469,7 +467,7 @@
   LPM1.addPass(LoopSimplifyCFGPass());
 
   // Rotate Loop - disable header duplication at -Oz
-  LPM1.addPass(LoopRotatePass(Level != Oz));
+  LPM1.addPass(LoopRotatePass(Level != OptimizationLevel::Oz));
   // TODO: Investigate promotion cap for O1.
   LPM1.addPass(LICMPass(PTO.LicmMssaOptCap, PTO.LicmMssaNoAccForPromotionCap));
   LPM1.addPass(SimpleLoopUnswitchPass());
@@ -486,7 +484,8 @@
   if ((Phase != ThinLTOPhase::PreLink || !PGOOpt ||
PGOOpt->Action != PGOOptions::SampleUse) &&
   PTO.LoopUnrolling)
-LPM2.addPass(LoopFullUnrollPass(Level, /*OnlyWhenForced=*/false,
+LPM2.addPass(LoopFullUnrollPass(Level.getSpeedupLevel(),
+/*OnlyWhenForced=*/false,
 PTO.ForgetAllSCEVInLoopUnroll));
 
   for (auto &C : LoopOptimizerEndEPCallbacks)
@@ -509,7 +508,7 @@
   FPM.addP

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

2020-01-14 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D72553#1820692 , @njames93 wrote:

> - moved check from llvm module to performance


Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553



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


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

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61861 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553



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


[PATCH] D72675: ix -ffast-math/-ffp-contract interaction

2020-01-14 Thread Warren Ristow via Phabricator via cfe-commits
wristow marked 3 inline comments as done.
wristow added a comment.

Thanks for the quick feedback @hfinkel




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2721
   if (!MathErrno && AssociativeMath && ReciprocalMath && !SignedZeros &&
-  !TrappingMath)
+  !TrappingMath && !FPContractDisabled)
 CmdArgs.push_back("-menable-unsafe-fp-math");

hfinkel wrote:
> I think that you just need
> 
>   && !FPContract.equals("off")
> 
> or
> 
>   && !(FPContract.equals("off") || FPContract.equals("on"))
> 
> of which I think the latter. fp-contract=no is also not a 
> fast-math-compatible setting in that regard, right?
Eliminating the `FPContractDisabled` variable, and instead checking that the 
value isn't "off" (or maybe isn't ("off" or "on")), sounds good.  I'm not 100% 
sure of whether just "off" or both "off" and "on" ought to be checked.  More on 
that in the discussion about `__FAST_MATH__` in one of your other comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2745
   if (!FPContract.empty())
 CmdArgs.push_back(Args.MakeArgString("-ffp-contract=" + FPContract));
 

hfinkel wrote:
> So now we pass it twice, because we also pass it here?
Whoops.  This one was here originally, so I'll leave it here, and delete the 
one I needlessly added, above.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2763
   if (!HonorINFs && !HonorNaNs && !MathErrno && AssociativeMath &&
   ReciprocalMath && !SignedZeros && !TrappingMath && !RoundingFPMath) {
+if (!FPContractDisabled)

hfinkel wrote:
> You want the check here, I think, and not below so that if parts of fast-math 
> are disabled `__FAST_MATH__` is not set. That seems to be what the 
> comment/code currently do, although what does GCC do in this regard?
I had originally included the check with the set of conditions of line 2763, 
but then the `warn_drv_overriding_flag_option` warning (below) was missed in 
the case of `-ffp-model=fast -ffp-contract=off`.  So I think the check does 
need to remain inside the above conditional.

Regarding the `__FAST_MATH__` aspect and whether `ffp-contract=on` also ought 
to suppress the `-ffast-math` emission (and what GCC does), this is somewhat 
fuzzy for me.  After getting your comments, I'm leaning toward including both 
the "off" and "on" in the check (rather than only disabling it in the case of 
"off", as the current patch does).  But I want to at least note my observations 
here, to make the current situation with both Clang and GCC clear, in case 
others want to chime in.

Somewhat surprisingly to me, GCC's behavior wrt `__FAST_MATH__` seems buggy in 
general, so it's not a good base to compare against.  For example, the 
following set of switches result in the `__FAST_MATH__` macro being defined 
(although I expected they would have disabled it):
-ffast-math -fno-associative-math -fno-reciprocal-math -frounding-math

(I've just tested GCC 7.4.0.)

I could have sworn that in the past that for GCC I had seen this sort of 
disabling of part of the "fast-math set" result in the disabling of the def of 
`__FAST_MATH__`.  As you'd expect with Clang (from the comment in our code 
code), the above switches //do //suppress the definition of `__FAST_MATH__`.

That said, GCC does suppress the `__FAST_MATH__` def in //some //situations.  
E.g., both GCC and Clang suppress it with the following switches:
-ffast-math -fmath-errno
-ffast-math -ftrapping-math
-ffast-math -fsigned-zeros

In any case, for the `-ffp-contract` switch, none of the settings suppress the 
def of `__FAST_MATH__` with GCC.  That is, all of the following result in 
`__FAST_MATH__` being defined:
-ffast-math -ffp-contract=fast
-ffast-math -ffp-contract=on
-ffast-math -ffp-contract=off

I think that's buggy (but hard to know if it's `-ffp-contract` specific, or 
part of the general buggyness of GCC and `__FAST_MATH__`).  Clang (prior to the 
change described here) also defines `__FAST_MATH__` in all of these 
`-ffp-contract` situations.  But I think that's just part of the bug I'm trying 
to address here.

Bottom line: The intended semantics are somewhat fuzzy to me.  I'd say:
-ffast-math -ffp-contract=fast  // should leave __FAST_MATH__ defined
-ffast-math -ffp-contract=off   // should not define __FAST_MATH__
-ffast-math -ffp-contract=on// unsure 

For that last one ("unsure ???"), in the current patch I was leaving 
`__FAST_MATH__` defined.  But I'm now leaning toward also suppressing the 
`__FAST_MATH__` def in that case.  Unless anyone disagrees, I'll include that 
change when I update the patch.


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

https://reviews.llvm.org/D72675



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


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

2020-01-14 Thread Jonathan Crowther via Phabricator via cfe-commits
Jonathan.Crowther created this revision.
Jonathan.Crowther added reviewers: hubert.reinterpretcast, xingxue.
Herald added subscribers: llvm-commits, cfe-commits, arphaman, hiraditya.
Herald added projects: clang, LLVM.

Implemented (for AIX) a function to take any function and return the path of 
the load module it is located in. Used this function to implement 
`getMainExecutable` for AIX (instead of incorrectly attempting to use `/proc`) 
Additionally, fixed multiple locations where `getMainExecutable` was used 
incorrectly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72736

Files:
  clang/lib/Tooling/CompilationDatabase.cpp
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
  clang/tools/libclang/CIndexer.cpp
  llvm/include/llvm/Support/FileUtilities.h
  llvm/lib/Support/FileUtilities.cpp
  llvm/lib/Support/Unix/Path.inc
  llvm/unittests/Support/ProgramTest.cpp

Index: llvm/unittests/Support/ProgramTest.cpp
===
--- llvm/unittests/Support/ProgramTest.cpp
+++ llvm/unittests/Support/ProgramTest.cpp
@@ -58,6 +58,8 @@
 static cl::opt
 ProgramTestStringArg2("program-test-string-arg2");
 
+void DummyFunction() {}
+
 class ProgramEnvTest : public testing::Test {
   std::vector EnvTable;
   std::vector EnvStorage;
@@ -114,8 +116,8 @@
 exit(0);
 
   // getMainExecutable returns an absolute path; prepend the long-path prefix.
-  std::string MyAbsExe =
-  sys::fs::getMainExecutable(TestMainArgv0, &ProgramTestStringArg1);
+  void *MainAddr = (void *)(intptr_t)DummyFunction;
+  std::string MyAbsExe = sys::fs::getMainExecutable(TestMainArgv0, MainAddr);
   std::string MyExe;
   if (!StringRef(MyAbsExe).startswith("?\\"))
 MyExe.append("?\\");
@@ -160,8 +162,8 @@
 exit(1);
   }
 
-  std::string my_exe =
-  sys::fs::getMainExecutable(TestMainArgv0, &ProgramTestStringArg1);
+  void *MainAddr = (void *)(intptr_t)DummyFunction;
+  std::string my_exe = sys::fs::getMainExecutable(TestMainArgv0, MainAddr);
   StringRef argv[] = {
   my_exe,
   "--gtest_filter=ProgramEnvTest.CreateProcessTrailingSlash",
@@ -197,8 +199,8 @@
 exit(0);
   }
 
-  std::string Executable =
-  sys::fs::getMainExecutable(TestMainArgv0, &ProgramTestStringArg1);
+  void *MainAddr = (void *)(intptr_t)DummyFunction;
+  std::string Executable = sys::fs::getMainExecutable(TestMainArgv0, MainAddr);
   StringRef argv[] = {Executable,
   "--gtest_filter=ProgramEnvTest.TestExecuteNoWait"};
 
@@ -252,8 +254,8 @@
 exit(0);
   }
 
-  std::string Executable =
-  sys::fs::getMainExecutable(TestMainArgv0, &ProgramTestStringArg1);
+  void *MainAddr = (void *)(intptr_t)DummyFunction;
+  std::string Executable = sys::fs::getMainExecutable(TestMainArgv0, MainAddr);
   StringRef argv[] = {
   Executable, "--gtest_filter=ProgramEnvTest.TestExecuteAndWaitTimeout"};
 
Index: llvm/lib/Support/Unix/Path.inc
===
--- llvm/lib/Support/Unix/Path.inc
+++ llvm/lib/Support/Unix/Path.inc
@@ -87,6 +87,7 @@
 #include 
 #elif defined(_AIX)
 #include 
+#include 
 
 //  depends on `uint` to be a typedef from  to
 // `uint_t`; however,  does not always declare `uint`. We provide
@@ -222,7 +223,7 @@
   if (getprogpath(exe_path, argv0) != NULL)
 return exe_path;
 #elif defined(__NetBSD__) || defined(__OpenBSD__) || defined(__minix) ||   \
-defined(__DragonFly__) || defined(__FreeBSD_kernel__) || defined(_AIX)
+defined(__DragonFly__) || defined(__FreeBSD_kernel__)
   const char *curproc = "/proc/curproc/file";
   char exe_path[PATH_MAX];
   if (sys::fs::exists(curproc)) {
@@ -238,6 +239,8 @@
   // If we don't have procfs mounted, fall back to argv[0]
   if (getprogpath(exe_path, argv0) != NULL)
 return exe_path;
+#elif defined(_AIX)
+  return getLoadModuleFilenameForFunction(MainAddr).str();
 #elif defined(__linux__) || defined(__CYGWIN__) || defined(__gnu_hurd__)
   char exe_path[MAXPATHLEN];
   const char *aPath = "/proc/self/exe";
Index: llvm/lib/Support/FileUtilities.cpp
===
--- llvm/lib/Support/FileUtilities.cpp
+++ llvm/lib/Support/FileUtilities.cpp
@@ -27,6 +27,16 @@
 #include 
 #include 
 
+// These typedefs are needed for sys/ldr.h to work on AIX
+#if defined(_AIX)
+typedef unsigned int uint;
+typedef unsigned short ushort;
+typedef void *__ptr64;
+static_assert(sizeof(__ptr64) == 8u, "__ptr64 size error.");
+#include 
+#include 
+#endif
+
 using namespace llvm;
 
 static bool isSignedChar(char C) {
@@ -268,6 +278,55 @@
   return CompareFailed;
 }
 
+#if defined(_AIX)
+// Returns the name of the load module that contains the entry point of the
+// function referenced by fp.
+SmallString<128> llvm::getLoadModuleFilenameForFunctionAIX(void (*fp)(void)) {
+  int PrevErrno = errno;
+
+  size_t BufSize = 2048u;
+  std::unique_ptr Buf;
+  while (true) {
+Buf = std::make_un

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

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 238104.
njames93 added a comment.

- moved check from llvm module to performance


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553

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

Index: clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.cpp
@@ -0,0 +1,82 @@
+// RUN: %check_clang_tidy %s performance-prefer-pre-increment %t
+
+template 
+class Iterator {
+  T *Current;
+
+public:
+  Iterator(T *Pointer) : Current(Pointer) {}
+  T &operator*() const { return *Current; }
+  Iterator &operator++() { return ++Current, *this; }
+  Iterator operator++(int) {
+Iterator Copy = *this;
+++Current;
+return Copy;
+  }
+  Iterator &operator--() { return --Current, *this; }
+  Iterator operator--(int) {
+Iterator Copy = *this;
+--Current;
+return Copy;
+  }
+};
+
+template 
+class PostfixIterator {
+  T *Current;
+
+public:
+  PostfixIterator(T *Pointer) : Current(Pointer) {}
+  T &operator*() const { return *Current; }
+  PostfixIterator operator++(int) {
+PostfixIterator Copy = *this;
+++Current;
+return Copy;
+  }
+  PostfixIterator operator--(int) {
+PostfixIterator Copy = *this;
+--Current;
+return Copy;
+  }
+};
+
+void foo() {
+  int Array[32];
+  Iterator It(&Array[0]);
+  It++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES: {{^}}  ++It;
+  It--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES: {{^}}  --It;
+  (*It)++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES: {{^}}  ++(*It);
+  (*It)--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES: {{^}}  --(*It);
+
+  *It++;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  *It--;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-decrement instead of Post-decrement
+
+  PostfixIterator PfIt(&Array[0]);
+  PfIt++;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES-NOT: {{^}}  ++PfIt;
+  PfIt--;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES-NOT: {{^}}  --PfIt;
+  (*PfIt)++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES: {{^}}  ++(*PfIt);
+  (*PfIt)--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES: {{^}}  --(*PfIt);
+
+  *PfIt++;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  *PfIt--;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-decrement instead of Post-decrement
+}
Index: clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment.c
@@ -0,0 +1,123 @@
+// RUN: %check_clang_tidy %s performance-prefer-pre-increment %t
+
+#define INC(X) X++
+#define DEC(X) X--
+
+void foo(int A) {
+  for (int I = 0; I < 10; I++) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use Pre-increment instead of Post-increment
+// CHECK-FIXES: {{^}}  for (int I = 0; I < 10; ++I) {
+  }
+  for (int I = 0; I < 10; ++I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  }
+  for (int I = 0; I < 10; A = I++) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  }
+
+  for (int I = 10; I < 0; I--) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use Pre-decrement instead of Post-decrement
+// CHECK-FIXES: {{^}}  for (int I = 10; I <

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added a comment.

In D72404#1820628 , @tycho wrote:

> In D72404#1820461 , 
> @merge_guards_bot wrote:
>
> > {icon times-circle color=red} Unit tests: fail. 61858 tests passed, 1 
> > failed and 781 were skipped.
> >
> >   failed: Clang.CodeGen/thinlto-debug-pm.c
>
>
> I think that failure can be fixed with something like this:
>
>   diff --git a/clang/test/CodeGen/thinlto-debug-pm.c 
> b/clang/test/CodeGen/thinlto-debug-pm.c
>index 5f449d493af..9d6d69afd13 100644
>--- a/clang/test/CodeGen/thinlto-debug-pm.c
>+++ b/clang/test/CodeGen/thinlto-debug-pm.c
>@@ -13,17 +13,17 @@
> // O0123sz-NEWPM: Running analysis: PassInstrumentationAnalysis
> // O0123sz-NEWPM: Starting llvm::Module pass manager run.
> // O0123sz-NEWPM: Running pass: WholeProgramDevirtPass
>-// O0123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O0123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy
> // O0123sz-NEWPM: Running pass: LowerTypeTestsPass
> // O0123sz-NEWPM: Invalidating all non-preserved analyses for:
>-// O0123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O0123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running pass: ForceFunctionAttrsPass
> // O123sz-NEWPM: Running pass: PassManager
> // O123sz-NEWPM: Starting llvm::Module pass manager run.
> // O123sz-NEWPM: Running pass: PGOIndirectCallPromotion
> // O123sz-NEWPM: Running analysis: ProfileSummaryAnalysis
> // O123sz-NEWPM: Running pass: InferFunctionAttrsPass
>-// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running pass: 
> ModuleToFunctionPassAdaptor >
> // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
> // O123sz-NEWPM: Starting llvm::Function pass manager run.
>@@ -41,9 +41,9 @@
> // O123sz-NEWPM: Running pass: CalledValuePropagationPass
> // O123sz-NEWPM: Running pass: GlobalOptPass
> // O123sz-NEWPM: Invalidating all non-preserved analyses for:
>-// O123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running pass: 
> ModuleToFunctionPassAdaptor
>-// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running analysis: DominatorTreeAnalysis on foo
> // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
> // O123sz-NEWPM: Running analysis: AssumptionAnalysis on foo
>@@ -57,7 +57,7 @@
> // O123sz-NEWPM: Running analysis: BasicAA on foo
> // O123sz-NEWPM: Running analysis: ScopedNoAliasAA on foo
> // O123sz-NEWPM: Running analysis: TypeBasedAA on foo
>-// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy, 
> llvm::Function> on foo
>+// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy on foo
> // O123sz-NEWPM: Running pass: SimplifyCFGPass on foo
> // O123sz-NEWPM: Running analysis: TargetIRAnalysis on foo
> // O123sz-NEWPM: Finished llvm::Function pass manager run.
>@@ -70,7 +70,7 @@
> // O123sz-NEWPM: Running analysis: LazyCallGraphAnalysis
> // O123sz-NEWPM: Running analysis: FunctionAnalysisManagerCGSCCProxy on 
> (foo)
> // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on (foo)
>-// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy, 
> llvm::LazyCallGraph::SCC, llvm::LazyCallG>
>+// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&> o>
> // O123sz-NEWPM: Starting CGSCC pass manager run.
> // O123sz-NEWPM: Running pass: InlinerPass on (foo)
> // O123sz-NEWPM: Running pass: PostOrderFunctionAttrsPass on (foo)
>   


Thank you. It turns out that GCC&Clang disagree on `__PRETTY_FUNCTION__` for 
type alias (using). will fix those.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72404



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


[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2020-01-14 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.
Herald added a subscriber: wuzish.

Ping, I don't think I have any actionable feedback here and I'd like to get 
this landed before Clang 10 branches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67678



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


[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2020-01-14 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 238099.
rsmith added a comment.
Herald added subscribers: kbarton, nemanjai.

Rebase and slightly expand release notes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67678

Files:
  clang/docs/CommandGuide/clang.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Headers/ppc_wrappers/emmintrin.h
  clang/test/Headers/altivec-header.c
  clang/test/Headers/arm-neon-header.c
  clang/test/Headers/x86-intrinsics-headers.c
  clang/test/Headers/x86intrin-2.c
  clang/test/Headers/x86intrin.c
  clang/test/Sema/vector-assign.c
  clang/test/Sema/vector-cast.c
  clang/test/Sema/vector-ops.c

Index: clang/test/Sema/vector-ops.c
===
--- clang/test/Sema/vector-ops.c
+++ clang/test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=all
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: clang/test/Sema/vector-cast.c
===
--- clang/test/Sema/vector-cast.c
+++ clang/test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 4 'float' values)}}
   counter -= a0;
 }
Index: clang/test/Sema/vector-assign.c
===

[PATCH] D44352: [Concepts] Type Constraints

2020-01-14 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.

Some cleanups (mainly parameters that are no longer necessary), then this is 
good to go. Thanks!




Comment at: clang/include/clang/Basic/LangOptions.def:146
 LANGOPT(DllExportInlines  , 1, 1, "dllexported classes dllexport inline 
methods")
-LANGOPT(RelaxedTemplateTemplateArgs, 1, 0, "C++17 relaxed matching of template 
template arguments")
+LANGOPT(RelaxedTemplateTemplateArgs, 1, 1, "C++17 relaxed matching of template 
template arguments")
 

This change has no effect because the default value is unconditionally 
overwritten in `CompilerInvocation.cpp`. Revert for now; we can flip this flag 
as a separate change.



Comment at: clang/lib/AST/DeclTemplate.cpp:110-114
+  if (const auto *TTP = dyn_cast(P))
+if (TTP->isExpandedParameterPack()) {
+  NumRequiredArgs += TTP->getNumExpansionParameters();
+  continue;
+}

Do we need something like this for expanded template template parameter packs?



Comment at: clang/lib/Parse/ParseExprCXX.cpp:2713
 SourceLocation *TemplateKWLoc,
-UnqualifiedId &Result) {
+UnqualifiedId &Result, bool SuppressDiag) {
   if (TemplateKWLoc)

This `SuppressDiag` parameter is never set by any caller; please remove it.



Comment at: clang/lib/Parse/ParseTemplate.cpp:684
+  // user intended and parse a non-type parameter with an error type.
+  /*ErrorInTypeSpec=*/ScopeError);
+}

`ScopeError` is always `false` here; you can remove the `ErrorInTypeSpec` 
parameter and the comment here.



Comment at: clang/lib/Parse/ParseTemplate.cpp:707
+bool Parser::TryAnnotateTypeConstraint(CXXScopeSpec &SS) {
+  if (!getLangOpts().ConceptsTS || Tok.is(tok::annot_template_id) ||
+  Tok.isNot(tok::identifier))

The `Tok.is` check here is redundant; it's a subset of the following 
`Tok.isNot` check.



Comment at: clang/lib/Sema/SemaTemplate.cpp:136
+  bool &MemberOfUnknownSpecialization,
+  NamedDecl **FoundDecl) {
   assert(getLangOpts().CPlusPlus && "No template names in C!");

This new parameter appears to be unused now.



Comment at: clang/lib/Sema/SemaTemplate.cpp:7088
+  //  concepts.
+  if (getLangOpts().RelaxedTemplateTemplateArgs || getLangOpts().ConceptsTS) {
 // Quick check for the common case:

This is not appropriate; `-fconcepts-ts` (or hopefully soon `-std=c++2a`) 
should not override the value of this `LangOpt`.

Please revert this change and manually turn on 
`-frelaxed-template-template-args` as necessary in the corresponding test cases.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:645-659
 static Optional getExpandedPackSize(NamedDecl *Param) {
+  if (auto *TTP = dyn_cast(Param))
+if (TTP->isExpandedParameterPack())
+  return TTP->getNumExpansionParameters();
+
   if (auto *NTTP = dyn_cast(Param))
 if (NTTP->isExpandedParameterPack())

Looks like we repeat this (at least) three times. (And one of the instances is 
missing the template template parameter case.) Please consider moving this to 
somewhere more central (`DeclTemplate.h`?) -- as a separate patch, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D44352



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


[PATCH] D72041: [clangd] Handle go-to-definition in macro invocations where the target appears in the expansion multiple times

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61848 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon check-circle color=green} clang-format: pass.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72041



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


[clang] a48600c - [OPENMP]Do not emit special virtual function for NVPTX target.

2020-01-14 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-01-14T16:59:22-05:00
New Revision: a48600c0a653d34f4af760f117755ed1776adf9d

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

LOG: [OPENMP]Do not emit special virtual function for NVPTX target.

There are no special virtual function handlers (like __cxa_pure_virtual)
defined for NVPTX target, so just emit such functions as null pointers
to prevent issues with linking and unresolved references.

Added: 
clang/test/OpenMP/nvptx_target_pure_deleted_codegen.cpp

Modified: 
clang/lib/CodeGen/CGVTables.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index a8dce3c2e859..59631e802373 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -676,7 +676,12 @@ void CodeGenVTables::addVTableComponent(
   // Method is acceptable, continue processing as usual.
 }
 
-auto getSpecialVirtualFn = [&](StringRef name) {
+auto getSpecialVirtualFn = [&](StringRef name) -> llvm::Constant * {
+  // For NVPTX devices in OpenMP emit special functon as null pointers,
+  // otherwise linking ends up with unresolved references.
+  if (CGM.getLangOpts().OpenMP && CGM.getLangOpts().OpenMPIsDevice &&
+  CGM.getTriple().isNVPTX())
+return llvm::ConstantPointerNull::get(CGM.Int8PtrTy);
   llvm::FunctionType *fnTy =
   llvm::FunctionType::get(CGM.VoidTy, /*isVarArg=*/false);
   llvm::Constant *fn = cast(

diff  --git a/clang/test/OpenMP/nvptx_target_pure_deleted_codegen.cpp 
b/clang/test/OpenMP/nvptx_target_pure_deleted_codegen.cpp
new file mode 100644
index ..1e83cf6f8704
--- /dev/null
+++ b/clang/test/OpenMP/nvptx_target_pure_deleted_codegen.cpp
@@ -0,0 +1,34 @@
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - -fno-rtti | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - -fno-rtti | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - -fno-rtti | 
FileCheck %s
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+
+// CHECK-DAG: @_ZTV7Derived = linkonce_odr hidden unnamed_addr constant { [3 x 
i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%class.Derived*)* 
@_ZN7Derived3fooEv to i8*)] }
+// CHECK-DAG: @_ZTV4Base = linkonce_odr hidden unnamed_addr constant { [3 x 
i8*] } zeroinitializer
+class Base {
+  public:
+  virtual void foo() = 0;
+};
+
+class Derived : public Base {
+public:
+  void foo() override {}
+  void bar() = delete;
+};
+
+void target() {
+#pragma omp target
+  {
+  Derived D;
+  D.foo();
+  }
+}
+
+#endif



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


[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Steven Noonan via Phabricator via cfe-commits
tycho added a subscriber: merge_guards_bot.
tycho added a comment.

In D72404#1820461 , @merge_guards_bot 
wrote:

> {icon times-circle color=red} Unit tests: fail. 61858 tests passed, 1 failed 
> and 781 were skipped.
>
>   failed: Clang.CodeGen/thinlto-debug-pm.c


I think that failure can be fixed with something like this:

  diff --git a/clang/test/CodeGen/thinlto-debug-pm.c 
b/clang/test/CodeGen/thinlto-debug-pm.c
  index 5f449d493af..15f366dc52d 100644
  --- a/clang/test/CodeGen/thinlto-debug-pm.c
  +++ b/clang/test/CodeGen/thinlto-debug-pm.c
  @@ -13,17 +13,17 @@
   // O0123sz-NEWPM: Running analysis: PassInstrumentationAnalysis
   // O0123sz-NEWPM: Starting llvm::Module pass manager run.
   // O0123sz-NEWPM: Running pass: WholeProgramDevirtPass
  -// O0123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O0123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy
   // O0123sz-NEWPM: Running pass: LowerTypeTestsPass
   // O0123sz-NEWPM: Invalidating all non-preserved analyses for:
  -// O0123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O0123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running pass: ForceFunctionAttrsPass
   // O123sz-NEWPM: Running pass: PassManager
   // O123sz-NEWPM: Starting llvm::Module pass manager run.
   // O123sz-NEWPM: Running pass: PGOIndirectCallPromotion
   // O123sz-NEWPM: Running analysis: ProfileSummaryAnalysis
   // O123sz-NEWPM: Running pass: InferFunctionAttrsPass
  -// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running pass: 
ModuleToFunctionPassAdaptor >
   // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
   // O123sz-NEWPM: Starting llvm::Function pass manager run.
  @@ -41,9 +41,9 @@
   // O123sz-NEWPM: Running pass: CalledValuePropagationPass
   // O123sz-NEWPM: Running pass: GlobalOptPass
   // O123sz-NEWPM: Invalidating all non-preserved analyses for:
  -// O123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running pass: ModuleToFunctionPassAdaptor
  -// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running analysis: DominatorTreeAnalysis on foo
   // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
   // O123sz-NEWPM: Running analysis: AssumptionAnalysis on foo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72404



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


[PATCH] D68115: Zero initialize padding in unions

2020-01-14 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

In D68115#1820579 , @aaron.ballman 
wrote:

> In D68115#1820462 , @vitalybuka 
> wrote:
>
> > I would be happy to finish this patch if we agree on something.
> >
> > So if I understand this the proposal is to have something like 
> > -fzero-union-padding which is off by default.
> >  When it's OFF compiler will continue to do whatever it does now.
> >  When it's ON it will set zeroes into padding with or without 
> > -ftrivial-auto-var-init.
> >  Is this correct?
>
>
> In general, I believe so, yes. To be clear, it only sets zeros into union 
> padding, not *all* padding. I do not have an opinion on whether we want it to 
> be `-fzero-union-padding` as opposed to `-finit-union-padding` that honors 
> the pattern from `-ftrivial-auto-init=pattern` and defaults to zero if no 
> pattern is specified.


They whole point of the patch was to avoid breaking code by 
-ftrivial-auto-init=pattern  with "MyUnion my_union = {}".  So to fix that only 
`-fzero-union-padding` behavior helpful.
`-ftrivial-auto-init=pattern` as-is already inits union padding with patterns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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


[PATCH] D72041: [clangd] Handle go-to-definition in macro invocations where the target appears in the expansion multiple times

2020-01-14 Thread Nathan Ridge via Phabricator via cfe-commits
nridge updated this revision to Diff 238094.
nridge added a comment.

Revise the approach to treat non-first expansions as not-selected


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72041

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/Selection.h
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -334,7 +334,18 @@
#define ADDRESSOF(X) &X;
int *j = ADDRESSOF(^i);
   )cpp",
-
+  R"cpp(// Macro argument appearing multiple times in expansion
+#define VALIDATE_TYPE(x) (void)x;
+#define ASSERT(expr)   \
+  do { \
+VALIDATE_TYPE(expr);   \
+if (!expr);\
+  } while (false)
+bool [[waldo]]() { return true; }
+void foo() {
+  ASSERT(wa^ldo());
+}
+  )cpp",
   R"cpp(// Symbol concatenated inside macro (not supported)
int *pi;
#define POINTER(X) p ## X;
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -368,7 +368,7 @@
 
 // Regression test: this used to match the injected X, not the outer X.
 TEST(SelectionTest, InjectedClassName) {
-  const char* Code = "struct ^X { int x; };";
+  const char *Code = "struct ^X { int x; };";
   auto AST = TestTU::withCode(Annotations(Code).code()).build();
   auto T = makeSelectionTree(Code, AST);
   ASSERT_EQ("CXXRecordDecl", nodeKind(T.commonAncestor())) << T;
@@ -461,7 +461,8 @@
 }
 
 TEST(SelectionTest, MacroArgExpansion) {
-  // If a macro arg is expanded several times, we consider them all selected.
+  // If a macro arg is expanded several times, we only consider the first one
+  // selected.
   const char *Case = R"cpp(
 int mul(int, int);
 #define SQUARE(X) mul(X, X);
@@ -470,15 +471,8 @@
   Annotations Test(Case);
   auto AST = TestTU::withCode(Test.code()).build();
   auto T = makeSelectionTree(Case, AST);
-  // Unfortunately, this makes the common ancestor the CallExpr...
-  // FIXME: hack around this by picking one?
-  EXPECT_EQ("CallExpr", T.commonAncestor()->kind());
-  EXPECT_FALSE(T.commonAncestor()->Selected);
-  EXPECT_EQ(2u, T.commonAncestor()->Children.size());
-  for (const auto* N : T.commonAncestor()->Children) {
-EXPECT_EQ("IntegerLiteral", N->kind());
-EXPECT_TRUE(N->Selected);
-  }
+  EXPECT_EQ("IntegerLiteral", T.commonAncestor()->kind());
+  EXPECT_TRUE(T.commonAncestor()->Selected);
 
   // Verify that the common assert() macro doesn't suffer from this.
   // (This is because we don't associate the stringified token with the arg).
@@ -495,7 +489,7 @@
 }
 
 TEST(SelectionTest, Implicit) {
-  const char* Test = R"cpp(
+  const char *Test = R"cpp(
 struct S { S(const char*); };
 int f(S);
 int x = f("^");
Index: clang-tools-extra/clangd/Selection.h
===
--- clang-tools-extra/clangd/Selection.h
+++ clang-tools-extra/clangd/Selection.h
@@ -103,15 +103,15 @@
 Selection Selected;
 // Walk up the AST to get the DeclContext of this Node,
 // which is not the node itself.
-const DeclContext& getDeclContext() const;
+const DeclContext &getDeclContext() const;
 // Printable node kind, like "CXXRecordDecl" or "AutoTypeLoc".
 std::string kind() const;
 // If this node is a wrapper with no syntax (e.g. implicit cast), return
 // its contents. (If multiple wrappers are present, unwraps all of them).
-const Node& ignoreImplicit() const;
+const Node &ignoreImplicit() const;
 // If this node is inside a wrapper with no syntax (e.g. implicit cast),
 // return that wrapper. (If multiple are present, unwraps all of them).
-const Node& outerImplicit() const;
+const Node &outerImplicit() const;
   };
   // The most specific common ancestor of all the selected nodes.
   // Returns nullptr if the common ancestor is the root.
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -52,8 +52,7 @@
 // On traversing an AST node, its token range is erased from the unclaimed set.
 // The tokens actually removed are associated with that node, and hit-tested
 // against the selection to determine whether the node is selected.
-template 
-class IntervalSet {
+template  class IntervalSet {
 public:
   IntervalSet(llvm::ArrayRef Range

[PATCH] D72624: [WIP] TargetMachine Hook for Module Metadata

2020-01-14 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D72624#1820598 , @dblaikie wrote:

> (just a general comment that this code review should be only in service of 
> the design discussion happening on llvm-dev - please don't approve/commit 
> this without closing out the design discussion there if there are actionable 
> conclusions from this review)


Got it, I will just look at from the LTO perspective. The target ABI specifics 
I haven't followed very closely and are not really my expertise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72624



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


[clang] a3490e3 - Remove trailing `;`. NFC.

2020-01-14 Thread Michael Liao via cfe-commits

Author: Michael Liao
Date: 2020-01-14T16:52:20-05:00
New Revision: a3490e3e3d38d502179329f76138d96c5b2bab88

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

LOG: Remove trailing `;`. NFC.

Added: 


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

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/Tree.cpp 
b/clang/lib/Tooling/Syntax/Tree.cpp
index 9f028c0be3b4..9a6270ec4cce 100644
--- a/clang/lib/Tooling/Syntax/Tree.cpp
+++ b/clang/lib/Tooling/Syntax/Tree.cpp
@@ -29,7 +29,7 @@ static void traverse(syntax::Node *N,
   traverse(static_cast(N), [&](const syntax::Node *N) {
 Visit(const_cast(N));
   });
-};
+}
 } // namespace
 
 syntax::Arena::Arena(SourceManager &SourceMgr, const LangOptions &LangOpts,



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


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

2020-01-14 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:199-202
+- New alias :doc:`performance-prefer-pre-increment
+  ` to
+  :doc:`llvm-prefer-pre-increment
+  ` was added.

njames93 wrote:
> lebedev.ri wrote:
> > Are we **really** **really** sure this is the correct relation direction?
> > This isn't an llvm-specific guideline that may be applicable to other code,
> > but a known generic C++ guideline that llvm coding guide follows.
> You're probably right, I added this to llvm first, then thought about alias. 
> Which module should its primary be
> I'd say performancepersonally. Cppcoreguidelines has [[ 
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#enforcement-8
>  | 1 little note ]] about it but I dont think that justifies putting the 
> check in there.
I would agree with `performance` module.
Putting it in cppcoreguidelines would be the same - why there, it's not an 
Cppcoreguidelines invention?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553



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


[PATCH] D72624: [WIP] TargetMachine Hook for Module Metadata

2020-01-14 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

(just a general comment that this code review should be only in service of the 
design discussion happening on llvm-dev - please don't approve/commit this 
without closing out the design discussion there if there are actionable 
conclusions from this review)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72624



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


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

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 marked an inline comment as done.
njames93 added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:199-202
+- New alias :doc:`performance-prefer-pre-increment
+  ` to
+  :doc:`llvm-prefer-pre-increment
+  ` was added.

lebedev.ri wrote:
> Are we **really** **really** sure this is the correct relation direction?
> This isn't an llvm-specific guideline that may be applicable to other code,
> but a known generic C++ guideline that llvm coding guide follows.
You're probably right, I added this to llvm first, then thought about alias. 
Which module should its primary be
I'd say performancepersonally. Cppcoreguidelines has [[ 
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#enforcement-8
 | 1 little note ]] about it but I dont think that justifies putting the check 
in there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553



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


[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

2020-01-14 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

> Well, just like for all the other FP builder methods, you can use the 
> setIsFPConstrained method on the builder object to switch between strict and 
> non-strict mode. Does this not suffice, or is there anything particular about 
> the comparisons that would require anything extra?

Ah, sorry, I forgot that `IsFPConstrained` is about whether we emit the 
intrinsics at all and not whether the intrinsics are currently recording real 
constraints.

I think I have a slight preference for the second option, where there's a 
single method that does all the work for the two cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71467



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


[PATCH] D69779: -fmodules-codegen should not emit extern templates

2020-01-14 Thread David Blaikie via Phabricator via cfe-commits
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.

Looks good - thanks for your patience!


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

https://reviews.llvm.org/D69779



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


[PATCH] D69779: -fmodules-codegen should not emit extern templates

2020-01-14 Thread Luboš Luňák via Phabricator via cfe-commits
llunak updated this revision to Diff 238089.
llunak added a comment.

This version uses a module based on the code posted above.


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

https://reviews.llvm.org/D69779

Files:
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Modules/codegen-extern-template.cpp
  clang/test/Modules/codegen-extern-template.h
  clang/test/Modules/codegen-extern-template.modulemap


Index: clang/test/Modules/codegen-extern-template.modulemap
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.modulemap
@@ -0,0 +1 @@
+module foo { header "codegen-extern-template.h" }
Index: clang/test/Modules/codegen-extern-template.h
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.h
@@ -0,0 +1,12 @@
+// header for codegen-extern-template.cpp
+#ifndef CODEGEN_EXTERN_TEMPLATE_H
+#define CODEGEN_EXTERN_TEMPLATE_H
+
+template 
+inline T foo() { return 10; }
+
+extern template int foo();
+
+inline int bar() { return foo(); }
+
+#endif
Index: clang/test/Modules/codegen-extern-template.cpp
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules -fmodules-codegen 
-emit-module -fmodule-name=foo %S/codegen-extern-template.modulemap -x c++ -o 
%t.pcm
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fmodules -fmodule-file=%t.pcm %s 
-emit-llvm -o - | FileCheck %s
+// expected-no-diagnostics
+
+#include "codegen-extern-template.h"
+
+template int foo();
+
+// CHECK: define weak_odr i32 @_Z3fooIiET_v
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2412,11 +2412,12 @@
 }
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
-  // non-always_inline functions.
+  // non-always_inline functions, unless they are available elsewhere.
   if (!FD->hasAttr()) {
 if (!Linkage)
   Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-ModulesCodegen = *Linkage != GVA_Internal;
+ModulesCodegen =
+*Linkage != GVA_Internal && *Linkage != GVA_AvailableExternally;
   }
 }
   }


Index: clang/test/Modules/codegen-extern-template.modulemap
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.modulemap
@@ -0,0 +1 @@
+module foo { header "codegen-extern-template.h" }
Index: clang/test/Modules/codegen-extern-template.h
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.h
@@ -0,0 +1,12 @@
+// header for codegen-extern-template.cpp
+#ifndef CODEGEN_EXTERN_TEMPLATE_H
+#define CODEGEN_EXTERN_TEMPLATE_H
+
+template 
+inline T foo() { return 10; }
+
+extern template int foo();
+
+inline int bar() { return foo(); }
+
+#endif
Index: clang/test/Modules/codegen-extern-template.cpp
===
--- /dev/null
+++ clang/test/Modules/codegen-extern-template.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules -fmodules-codegen -emit-module -fmodule-name=foo %S/codegen-extern-template.modulemap -x c++ -o %t.pcm
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fmodules -fmodule-file=%t.pcm %s -emit-llvm -o - | FileCheck %s
+// expected-no-diagnostics
+
+#include "codegen-extern-template.h"
+
+template int foo();
+
+// CHECK: define weak_odr i32 @_Z3fooIiET_v
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2412,11 +2412,12 @@
 }
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
-  // non-always_inline functions.
+  // non-always_inline functions, unless they are available elsewhere.
   if (!FD->hasAttr()) {
 if (!Linkage)
   Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-ModulesCodegen = *Linkage != GVA_Internal;
+ModulesCodegen =
+*Linkage != GVA_Internal && *Linkage != GVA_AvailableExternally;
   }
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D68115: Zero initialize padding in unions

2020-01-14 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D68115#1820462 , @vitalybuka wrote:

> I would be happy to finish this patch if we agree on something.
>
> So if I understand this the proposal is to have something like 
> -fzero-union-padding which is off by default.
>  When it's OFF compiler will continue to do whatever it does now.
>  When it's ON it will set zeroes into padding with or without 
> -ftrivial-auto-var-init.
>  Is this correct?


In general, I believe so, yes. To be clear, it only sets zeros into union 
padding, not *all* padding. I do not have an opinion on whether we want it to 
be `-fzero-union-padding` as opposed to `-finit-union-padding` that honors the 
pattern from `-ftrivial-auto-init=pattern` and defaults to zero if no pattern 
is specified.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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


[PATCH] D72624: [WIP] TargetMachine Hook for Module Metadata

2020-01-14 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D72624#1820281 , @lenary wrote:

> In D72624#1817464 , @tejohnson wrote:
>
> >
>
>
> Thank you for your feedback! It has been very helpful.
>
> > I'm not sure if ThinLTOCodeGenerator.cpp and LTOBackend.cpp were 
> > intentionally left out due to the LTO concerns mentioned in the description?
>
> Mostly left out because I wasn't sure how to attack them. I've got an update 
> to this patch which I'm testing right now and it looks much better. I will 
> post that imminently.
>
> > Note if we are just passing in the Module and updating the TM based on 
> > that, it wouldn't hit the threading issue I mentioned in D72245 
> > , but neither would you get the proper 
> > aggregation/checking across ThinLTO'ed modules.
>
> Ok, right, so I think I know what else this patch needs to do. At the moment, 
> I think the `ModFlagBehavior` for module flags are not being checked during 
> ThinLTO. I think this is something that has to be checked for compatibility 
> in `ThinLTOCodeGenerator::addModule` (like the triple is checked for 
> compatibility).


And LTO::addModule (just to add confusion, there are two LTO APIs, 
ThinLTOCodeGenerator is the old one and LTO is the new one, the latter being 
used by lld and the gold plugin).

I had mentioned using LTO::addModule to do the checking in the other patch, but 
there is a complication I should mention:

> I see that the checking behaviour is in `IRMover`, but I don't think ThinLTO 
> uses that, and I don't feel familiar enough with ThinLTO to be sure.

The ThinLTO "link", which is where the modules are added serially, does not 
read IR, only the summaries, which are linked together into a large index used 
to drive ThinLTO whole program analysis. So you can't really read the module 
flags directly during addModule, they need to be propagated via the summary 
flags. The ThinLTO backends which are subsequently fired off in parallel do 
read IR. In those backends, depending on the results of the ThinLTO analysis 
phase, we may use IRMover to link in ("import) functions from other modules. At 
that point, the module flags from any modules that backend is importing from 
will be combined and any errors due to conficting values will be issued.

Thinking through this some more, rather than attempting to fully validate the 
consistency of the module flags across all modules in ThinLTO mode, just rely 
on some checking when we merge subsections of the IR in the ThinLTO backends 
during this importing, which will happen automatically. This is presumably 
where the checking is desirable anyway (in terms of the cases you are most 
interested in catching with ThinLTO, because the IR is getting merged). Note 
that unlike in the full LTO case, where the IR is merged before you create the 
TM, in the ThinLTO case the TM will be created before any of this cross-module 
importing (partial IR merging), so with your patch presumably it will just use 
whatever module flag is on that original Module for it's corresponding ThinLTO 
backend. But since it sounds like any difference in these module flags is an 
error, it will just get flagged a little later but not affect how the TM is set 
up in the correct case. Does that sound reasonable?

> The update to my patch will not address this part of ThinLTO.

I'll take a look through your patch later today or tomorrow, but it may be just 
fine from the above perspective.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72624



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


[PATCH] D68115: Zero initialize padding in unions

2020-01-14 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added a comment.

In D68115#1820462 , @vitalybuka wrote:

> So if I understand this the proposal is to have something like 
> -fzero-union-padding which is off by default.
>  When it's OFF compiler will continue to do whatever it does now.
>  When it's ON it will set zeroes into padding with or without 
> -ftrivial-auto-var-init.
>  Is this correct?


That's my understanding and I would find such an option useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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


[PATCH] D72041: [clangd] Handle go-to-definition in macro invocations where the target appears in the expansion multiple times

2020-01-14 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

In D72041#1800189 , @sammccall wrote:

> - the allSelectedNodes API on SelectionTree feels non-orthogonal: it's only 
> meaningful here because the input happened to be a point and thus touches a 
> single token and therefore node. If the input was a range, then this API 
> doesn't help, because it loses the sense of "topmost" node.


Good point!

> - maybe the function we want walks down the tree as if finding the common 
> ancestor, but may descend to return the roots of multiple subtrees if they 
> are located in distinct expansions of the same macro arg
> - or maybe we just want to treat non-first expansions as not-selected? That 
> would about this issue I think

I'm thinking of going with the second suggestion, because it doesn't require 
changes to the SelectionTree API, and therefore addresses this concern:

> - it seems unfortunate to solve this mostly in xrefs rather than mostly in 
> SelectionTree. All the other clients potentially want this behavior.

without touching all the clients of SelectionTree.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72041



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


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

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61861 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553



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


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

2020-01-14 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Happy to see this check!




Comment at: clang-tools-extra/docs/ReleaseNotes.rst:199-202
+- New alias :doc:`performance-prefer-pre-increment
+  ` to
+  :doc:`llvm-prefer-pre-increment
+  ` was added.

Are we **really** **really** sure this is the correct relation direction?
This isn't an llvm-specific guideline that may be applicable to other code,
but a known generic C++ guideline that llvm coding guide follows.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553



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


[PATCH] D69779: -fmodules-codegen should not emit extern templates

2020-01-14 Thread Luboš Luňák via Phabricator via cfe-commits
llunak updated this revision to Diff 238086.
llunak added a comment.

I've updated the test as requested.

However I've noticed that a PCH-based test for this relies on 
https://reviews.llvm.org/D69585 . The fix works (of course), but it requires a 
PCH/module with the instantiation.


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

https://reviews.llvm.org/D69779

Files:
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/PCH/codegen-extern-template.cpp
  clang/test/PCH/codegen-extern-template.h


Index: clang/test/PCH/codegen-extern-template.h
===
--- /dev/null
+++ clang/test/PCH/codegen-extern-template.h
@@ -0,0 +1,12 @@
+// header for codegen-extern-template.cpp
+#ifndef CODEGEN_EXTERN_TEMPLATE_H
+#define CODEGEN_EXTERN_TEMPLATE_H
+
+template 
+inline T foo() { return 10; }
+
+extern template int foo();
+
+inline int bar() { return foo(); }
+
+#endif
Index: clang/test/PCH/codegen-extern-template.cpp
===
--- /dev/null
+++ clang/test/PCH/codegen-extern-template.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -x c++-header 
-building-pch-with-obj -pch-instantiate-templates -fmodules-codegen -emit-pch 
%S/codegen-extern-template.h -o %t.pch
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s -include-pch 
%t.pch | FileCheck %s
+// expected-no-diagnostics
+
+#include "codegen-extern-template.h"
+
+template int foo();
+
+// CHECK: define weak_odr i32 @_Z3fooIiET_v
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2412,11 +2412,12 @@
 }
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
-  // non-always_inline functions.
+  // non-always_inline functions, unless they are available elsewhere.
   if (!FD->hasAttr()) {
 if (!Linkage)
   Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-ModulesCodegen = *Linkage != GVA_Internal;
+ModulesCodegen =
+*Linkage != GVA_Internal && *Linkage != GVA_AvailableExternally;
   }
 }
   }


Index: clang/test/PCH/codegen-extern-template.h
===
--- /dev/null
+++ clang/test/PCH/codegen-extern-template.h
@@ -0,0 +1,12 @@
+// header for codegen-extern-template.cpp
+#ifndef CODEGEN_EXTERN_TEMPLATE_H
+#define CODEGEN_EXTERN_TEMPLATE_H
+
+template 
+inline T foo() { return 10; }
+
+extern template int foo();
+
+inline int bar() { return foo(); }
+
+#endif
Index: clang/test/PCH/codegen-extern-template.cpp
===
--- /dev/null
+++ clang/test/PCH/codegen-extern-template.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple=x86_64-linux-gnu -x c++-header -building-pch-with-obj -pch-instantiate-templates -fmodules-codegen -emit-pch %S/codegen-extern-template.h -o %t.pch
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s -include-pch %t.pch | FileCheck %s
+// expected-no-diagnostics
+
+#include "codegen-extern-template.h"
+
+template int foo();
+
+// CHECK: define weak_odr i32 @_Z3fooIiET_v
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2412,11 +2412,12 @@
 }
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
-  // non-always_inline functions.
+  // non-always_inline functions, unless they are available elsewhere.
   if (!FD->hasAttr()) {
 if (!Linkage)
   Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-ModulesCodegen = *Linkage != GVA_Internal;
+ModulesCodegen =
+*Linkage != GVA_Internal && *Linkage != GVA_AvailableExternally;
   }
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D72668: [Driver][test] Fix Driver/hexagon-toolchain-elf.c for -DCLANG_DEFAULT_LINKER=lld builds

2020-01-14 Thread Fangrui Song via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1ca51c06729d: [Driver][test] Fix 
Driver/hexagon-toolchain-elf.c for… (authored by MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D72668?vs=237816&id=238085#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72668

Files:
  clang/test/Driver/hexagon-toolchain-elf.c


Index: clang/test/Driver/hexagon-toolchain-elf.c
===
--- clang/test/Driver/hexagon-toolchain-elf.c
+++ clang/test/Driver/hexagon-toolchain-elf.c
@@ -538,11 +538,12 @@
 // CHECK080:  "-Wreturn-type"
 
 // 
-
-// Default, not passing -fuse-ld
+// Default, hexagon-link is used
 // 
-
 // RUN: %clang -### -target hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
 // RUN:   -mcpu=hexagonv60 \
+// RUN:   -fuse-ld=fake-value-to-ignore-CLANG_DEFAULT_LINKER \
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK081 %s
 // REQUIRES: hexagon-registered-target


Index: clang/test/Driver/hexagon-toolchain-elf.c
===
--- clang/test/Driver/hexagon-toolchain-elf.c
+++ clang/test/Driver/hexagon-toolchain-elf.c
@@ -538,11 +538,12 @@
 // CHECK080:  "-Wreturn-type"
 
 // -
-// Default, not passing -fuse-ld
+// Default, hexagon-link is used
 // -
 // RUN: %clang -### -target hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
 // RUN:   -mcpu=hexagonv60 \
+// RUN:   -fuse-ld=fake-value-to-ignore-CLANG_DEFAULT_LINKER \
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK081 %s
 // REQUIRES: hexagon-registered-target
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2020-01-14 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 238082.
njames93 added a comment.

- fix spelling mistake


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72553

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

Index: clang-tools-extra/test/clang-tidy/checkers/llvm-prefer-pre-increment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/llvm-prefer-pre-increment.cpp
@@ -0,0 +1,82 @@
+// RUN: %check_clang_tidy %s llvm-prefer-pre-increment %t
+
+template 
+class Iterator {
+  T *Current;
+
+public:
+  Iterator(T *Pointer) : Current(Pointer) {}
+  T &operator*() const { return *Current; }
+  Iterator &operator++() { return ++Current, *this; }
+  Iterator operator++(int) {
+Iterator Copy = *this;
+++Current;
+return Copy;
+  }
+  Iterator &operator--() { return --Current, *this; }
+  Iterator operator--(int) {
+Iterator Copy = *this;
+--Current;
+return Copy;
+  }
+};
+
+template 
+class PostfixIterator {
+  T *Current;
+
+public:
+  PostfixIterator(T *Pointer) : Current(Pointer) {}
+  T &operator*() const { return *Current; }
+  PostfixIterator operator++(int) {
+PostfixIterator Copy = *this;
+++Current;
+return Copy;
+  }
+  PostfixIterator operator--(int) {
+PostfixIterator Copy = *this;
+--Current;
+return Copy;
+  }
+};
+
+void foo() {
+  int Array[32];
+  Iterator It(&Array[0]);
+  It++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES: {{^}}  ++It;
+  It--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES: {{^}}  --It;
+  (*It)++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES: {{^}}  ++(*It);
+  (*It)--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES: {{^}}  --(*It);
+
+  *It++;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  *It--;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-decrement instead of Post-decrement
+
+  PostfixIterator PfIt(&Array[0]);
+  PfIt++;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES-NOT: {{^}}  ++PfIt;
+  PfIt--;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES-NOT: {{^}}  --PfIt;
+  (*PfIt)++;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-increment instead of Post-increment
+  // CHECK-FIXES: {{^}}  ++(*PfIt);
+  (*PfIt)--;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: Use Pre-decrement instead of Post-decrement
+  // CHECK-FIXES: {{^}}  --(*PfIt);
+
+  *PfIt++;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  *PfIt--;
+  // CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-decrement instead of Post-decrement
+}
Index: clang-tools-extra/test/clang-tidy/checkers/llvm-prefer-pre-increment.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/llvm-prefer-pre-increment.c
@@ -0,0 +1,123 @@
+// RUN: %check_clang_tidy %s llvm-prefer-pre-increment %t
+
+#define INC(X) X++
+#define DEC(X) X--
+
+void foo(int A) {
+  for (int I = 0; I < 10; I++) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use Pre-increment instead of Post-increment
+// CHECK-FIXES: {{^}}  for (int I = 0; I < 10; ++I) {
+  }
+  for (int I = 0; I < 10; ++I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  }
+  for (int I = 0; I < 10; A = I++) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: Use Pre-increment instead of Post-increment
+  }
+
+  for (int I = 10; I < 0; I--) {
+// CHECK-MESSAGES: [[@LINE-1]]:27: warning: Use Pre-decrement instead of Post-decrement
+// CHECK-FIXES: {{^}}  for (int I = 10; I < 0; --I) {
+  }
+  for (int I = 10; I < 0; --I) {
+// CHECK-MESSAGES-NOT: [[@LINE-1]]:{{\d*}}: warning: 

[clang] 1ca51c0 - [Driver][test] Fix Driver/hexagon-toolchain-elf.c for -DCLANG_DEFAULT_LINKER=lld builds

2020-01-14 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-01-14T13:18:23-08:00
New Revision: 1ca51c06729d7f7326fcc2a826e07d1c92158dfd

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

LOG: [Driver][test] Fix Driver/hexagon-toolchain-elf.c for 
-DCLANG_DEFAULT_LINKER=lld builds

Reviewed By: nathanchance, sidneym

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

Added: 


Modified: 
clang/test/Driver/hexagon-toolchain-elf.c

Removed: 




diff  --git a/clang/test/Driver/hexagon-toolchain-elf.c 
b/clang/test/Driver/hexagon-toolchain-elf.c
index cf7d8bdb3931..44bff6f703a2 100644
--- a/clang/test/Driver/hexagon-toolchain-elf.c
+++ b/clang/test/Driver/hexagon-toolchain-elf.c
@@ -538,11 +538,12 @@
 // CHECK080:  "-Wreturn-type"
 
 // 
-
-// Default, not passing -fuse-ld
+// Default, hexagon-link is used
 // 
-
 // RUN: %clang -### -target hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
 // RUN:   -mcpu=hexagonv60 \
+// RUN:   -fuse-ld=fake-value-to-ignore-CLANG_DEFAULT_LINKER \
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK081 %s
 // REQUIRES: hexagon-registered-target



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


[PATCH] D72730: [clang-tools-extra] run-clang-tidy -export-fixes exports only fixes, not all warnings

2020-01-14 Thread Alexander Lanin via Phabricator via cfe-commits
AlexanderLanin created this revision.
AlexanderLanin added a project: clang-tools-extra.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
AlexanderLanin added a comment.

Important: I'm not a python expert. It works fine as far as I can tell. I would 
feel better if someone with more than a day python experience would say that it 
is fine.


The generated file is now small enough to not hinder any post processing.

>> Create a yaml file to store suggested fixes in, which can be applied with 
>> clang-apply-replacements.

So it's enough to store the fixes, not all the warnings.
Before this change the resulting file was simply too large as it contained all 
warnings, least of which had FIX-ITs.

This is trivially achievable with no measureable runtime overhead during 
run-clang-tidy runs, instead of post processing where even parsing the file 
once is extremely slow.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72730

Files:
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py


Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -105,6 +105,16 @@
   start.append(f)
   return start
 
+# returns whether passed yaml Diagnostic (see mergekey) element contains FIX-IT
+def isAutoFixable(diag):
+  if diag["DiagnosticMessage"]["Replacements"]: return True
+
+  if "Notes" in diag:
+for note in diag["Notes"]:
+  if "Replacements" in note and note["Replacements"]:
+return True
+
+  return False
 
 def merge_replacement_files(tmpdir, mergefile):
   """Merge all replacement files in a directory into a single file"""
@@ -116,7 +126,9 @@
 content = yaml.safe_load(open(replacefile, 'r'))
 if not content:
   continue # Skip empty files.
-merged.extend(content.get(mergekey, []))
+for d in content.get(mergekey, []):
+  if isAutoFixable(d):
+merged.append(d)
 
   if merged:
 # MainSourceFile: The key is required by the definition inside


Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -105,6 +105,16 @@
   start.append(f)
   return start
 
+# returns whether passed yaml Diagnostic (see mergekey) element contains FIX-IT
+def isAutoFixable(diag):
+  if diag["DiagnosticMessage"]["Replacements"]: return True
+
+  if "Notes" in diag:
+for note in diag["Notes"]:
+  if "Replacements" in note and note["Replacements"]:
+return True
+
+  return False
 
 def merge_replacement_files(tmpdir, mergefile):
   """Merge all replacement files in a directory into a single file"""
@@ -116,7 +126,9 @@
 content = yaml.safe_load(open(replacefile, 'r'))
 if not content:
   continue # Skip empty files.
-merged.extend(content.get(mergekey, []))
+for d in content.get(mergekey, []):
+  if isAutoFixable(d):
+merged.append(d)
 
   if merged:
 # MainSourceFile: The key is required by the definition inside
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D72730: [clang-tools-extra] run-clang-tidy -export-fixes exports only fixes, not all warnings

2020-01-14 Thread Alexander Lanin via Phabricator via cfe-commits
AlexanderLanin added a comment.

Important: I'm not a python expert. It works fine as far as I can tell. I would 
feel better if someone with more than a day python experience would say that it 
is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72730



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


[PATCH] D68115: Zero initialize padding in unions

2020-01-14 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

In D68115#1819418 , @aaron.ballman 
wrote:

> In D68115#1811091 , @lebedev.ri 
> wrote:
>
> > In D68115#1811089 , 
> > @hubert.reinterpretcast wrote:
> >
> > > In D68115#1810891 , @lebedev.ri 
> > > wrote:
> > >
> > > > Does this have to be an unilateral change,
> > > >  likely penalizing non-`-ftrivial-auto-var-init=` cases,
> > > >  i.e. [why] can't it be **only** done for when 
> > > > `-ftrivial-auto-var-init=` is enabled?
> > >
> > >
> > > We left off near that conclusion 
> > > (https://reviews.llvm.org/D68115#1686887);
> >
> >
> > Would be great if @rsmith / @aaron.ballman could comment on that
>
>
> I don't have super strong opinions on it, but I think a separate feature for 
> zeroing union padding is what gives users the most flexibility.
>
> In D68115#1811089 , 
> @hubert.reinterpretcast wrote:
>
> > A separate option to control zeroing for union padding would help in cases 
> > where the zeroing does not happen for reasons other than 
> > `-ftrivial-auto-var-init`.
>
>
> Agreed.


I would be happy to finish this patch if we agree on something.

So if I understand this the proposal is to have something like 
-fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without 
-ftrivial-auto-var-init.
Is this correct?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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


[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 61858 tests passed, 1 failed 
and 781 were skipped.

  failed: Clang.CodeGen/thinlto-debug-pm.c

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72404



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


[clang] 986202f - [clang][test][NFC] Use more widely supported sanitizer for file dependency tests

2020-01-14 Thread Jan Korous via cfe-commits

Author: Jan Korous
Date: 2020-01-14T12:55:11-08:00
New Revision: 986202fad41529af8288aca54f2ff62d4c501d71

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

LOG: [clang][test][NFC] Use more widely supported sanitizer for file dependency 
tests

The tests aren't concerned at all by the actual sanitizer - only by blacklist 
being reported as a dependency.
We're unfortunately limited by platform support for any particular sanitizer 
but we can at least use one that is widely supported.

Post-commit review:
https://reviews.llvm.org/D72729

Added: 

clang/test/Frontend/Inputs/resource_dir_with_sanitizer_blacklist/share/ubsan_blacklist.txt

Modified: 
clang/test/Frontend/dependency-gen.c

Removed: 

clang/test/Frontend/Inputs/resource_dir_with_cfi_blacklist/share/cfi_blacklist.txt



diff  --git 
a/clang/test/Frontend/Inputs/resource_dir_with_cfi_blacklist/share/cfi_blacklist.txt
 
b/clang/test/Frontend/Inputs/resource_dir_with_sanitizer_blacklist/share/ubsan_blacklist.txt
similarity index 100%
rename from 
clang/test/Frontend/Inputs/resource_dir_with_cfi_blacklist/share/cfi_blacklist.txt
rename to 
clang/test/Frontend/Inputs/resource_dir_with_sanitizer_blacklist/share/ubsan_blacklist.txt

diff  --git a/clang/test/Frontend/dependency-gen.c 
b/clang/test/Frontend/dependency-gen.c
index 1db9b04c1d9f..a42804d9f214 100644
--- a/clang/test/Frontend/dependency-gen.c
+++ b/clang/test/Frontend/dependency-gen.c
@@ -21,7 +21,7 @@
 // RUN: %clang -MD -MF - %s -fsyntax-only -I ./ | FileCheck 
-check-prefix=CHECK-SIX %s
 // CHECK-SIX: {{ }}x.h
 // RUN: echo "fun:foo" > %t.blacklist
-// RUN: %clang -MD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_cfi_blacklist -fsanitize=cfi-vcall 
-flto -fvisibility=hidden -fsanitize-blacklist=%t.blacklist -I ./ | FileCheck 
-check-prefix=CHECK-SEVEN %s
+// RUN: %clang -MD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_sanitizer_blacklist 
-fsanitize=undefined -flto -fvisibility=hidden 
-fsanitize-blacklist=%t.blacklist -I ./ | FileCheck -check-prefix=CHECK-SEVEN %s
 // CHECK-SEVEN: .blacklist
 // CHECK-SEVEN: {{ }}x.h
 #ifndef INCLUDE_FLAG_TEST
@@ -30,17 +30,17 @@
 
 // RUN: echo "fun:foo" > %t.blacklist1
 // RUN: echo "fun:foo" > %t.blacklist2
-// RUN: %clang -MD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_cfi_blacklist -fsanitize=cfi-vcall 
-flto -fvisibility=hidden -fsanitize-blacklist=%t.blacklist1 
-fsanitize-blacklist=%t.blacklist2 -I ./ | FileCheck 
-check-prefix=TWO-BLACK-LISTS %s
+// RUN: %clang -MD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_sanitizer_blacklist 
-fsanitize=undefined -flto -fvisibility=hidden 
-fsanitize-blacklist=%t.blacklist1 -fsanitize-blacklist=%t.blacklist2 -I ./ | 
FileCheck -check-prefix=TWO-BLACK-LISTS %s
 // TWO-BLACK-LISTS: dependency-gen.o:
 // TWO-BLACK-LISTS-DAG: blacklist1
 // TWO-BLACK-LISTS-DAG: blacklist2
 // TWO-BLACK-LISTS-DAG: x.h
 // TWO-BLACK-LISTS-DAG: dependency-gen.c
 
-// RUN: %clang -MD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_cfi_blacklist -fsanitize=cfi-vcall 
-flto -fvisibility=hidden -I ./ | FileCheck -check-prefix=USER-AND-SYS-DEPS %s
+// RUN: %clang -MD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_sanitizer_blacklist 
-fsanitize=undefined -flto -fvisibility=hidden -I ./ | FileCheck 
-check-prefix=USER-AND-SYS-DEPS %s
 // USER-AND-SYS-DEPS: dependency-gen.o:
-// USER-AND-SYS-DEPS-DAG: cfi_blacklist.txt
+// USER-AND-SYS-DEPS-DAG: ubsan_blacklist.txt
 
-// RUN: %clang -MMD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_cfi_blacklist -fsanitize=cfi-vcall 
-flto -fvisibility=hidden -I ./ | FileCheck -check-prefix=ONLY-USER-DEPS %s
+// RUN: %clang -MMD -MF - %s -fsyntax-only 
-resource-dir=%S/Inputs/resource_dir_with_sanitizer_blacklist 
-fsanitize=undefined -flto -fvisibility=hidden -I ./ | FileCheck 
-check-prefix=ONLY-USER-DEPS %s
 // ONLY-USER-DEPS: dependency-gen.o:
-// NOT-ONLY-USER-DEPS: cfi_blacklist.txt
\ No newline at end of file
+// NOT-ONLY-USER-DEPS: ubsan_blacklist.txt



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


  1   2   3   >