[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-29 Thread Momchil Velikov via Phabricator via cfe-commits 
chill added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:849-857
+// These pointer authentication instructions require armv8.3a
+let Predicates = [HasV8_3a, HasPA] in {
 let Uses = [LR], Defs = [LR] in {
   def PACIAZ   : SystemNoOperands<0b000, "hint\t#24">;
   def PACIBZ   : SystemNoOperands<0b010, "hint\t#26">;
   let isAuthenticated = 1 in {
 def AUTIAZ   : SystemNoOperands<0b100, "hint\t#28">;

wxz2020 wrote:
> wxz2020 wrote:
> > ktkachov wrote:
> > > IIRC these instructions are deliberately allowed in pre-armv8.3 targets 
> > > because they are encoded in the NOP-space and can be deployed on 
> > > pre-armv8.3 targets 
> > I will do some research on this.
> According to the documents, pointer authenticatoin got officially supporoted 
> starting from armv8.3.  
These instructions are executed as NOP on pre v8.3-A architectures. It allows 
you to have a single compatible binary that works correctly on pre v8.3-a (ofc, 
without pointer authentication), as well as on
8.3-a and later cores, with pointer authentication.

Please, remove the predicates.


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

https://reviews.llvm.org/D78129



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

[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-29 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:89
 CPU = llvm::sys::getHostCPUName();
-
   if (CPU == "generic") {

Remove stray change.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:167
 AARCH64_CPU_NAME("thunderx2t99", ARMV8_1A, FK_CRYPTO_NEON_FP_ARMV8, false,
- (AArch64::AEK_NONE))
+ (AArch64::AEK_CRC | AEK_CRYPTO | AEK_FP | AEK_SIMD | AEK_LSE 
| AEK_RAND))
+AARCH64_CPU_NAME("thunderx3t110", ARMV8_3A, FK_CRYPTO_NEON_FP_ARMV8, false,

Is this change also correcting the options for the x2t99? I think that should 
be a separate patch if so.


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

https://reviews.llvm.org/D78129



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

[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-29 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett added inline comments.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:168
+ (AArch64::AEK_CRC | AEK_CRYPTO | AEK_FP | AEK_SIMD | AEK_LSE 
| AEK_RAND))
+AARCH64_CPU_NAME("thunderx3t110", ARMV8_3A, FK_CRYPTO_NEON_FP_ARMV8, false,
+ (AArch64::AEK_CRC | AEK_CRYPTO | AEK_FP | AEK_SIMD | AEK_LSE 
| AEK_RAND | AArch64::AEK_PROFILE | AArch64::AEK_RAS))

Add a tests for this in llvm/unittests/Support/TargetParserTest.cpp (there are 
existing ones for "thunderx2t99").
Might need to update "NumAArch64CPUArchs" too.


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

https://reviews.llvm.org/D78129



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

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

2020-04-29 Thread Balázs Kéri via Phabricator via cfe-commits 
balazske created this revision.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
gamesh411, dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun.
Herald added a reviewer: Szelethus.
Herald added a project: clang.

The check of VLA size was done previously for variable declarations
(of VLA type) only. Now it is done for typedef (and type-alias)
and sizeof expressions with VLA too.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79072

Files:
  clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/Analysis/vla.c

Index: clang/test/Analysis/vla.c
===
--- clang/test/Analysis/vla.c
+++ clang/test/Analysis/vla.c
@@ -89,6 +89,17 @@
 check_negative_sized_VLA_11_sub(x);
 }
 
+void check_VLA_typedef() {
+  int x = -1;
+  typedef int VLA[x]; // expected-warning{{Declared variable-length array (VLA) has negative size}}
+}
+
+size_t check_VLA_sizeof() {
+  int x = -1;
+  size_t s = sizeof(int[x]); // expected-warning{{Declared variable-length array (VLA) has negative size}}
+  return s;
+}
+
 // Multi-dimensional arrays.
 
 void check_zero_sized_VLA_multi1(int x) {
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -573,6 +573,13 @@
 
 void ExprEngine::VisitDeclStmt(const DeclStmt *DS, ExplodedNode *Pred,
ExplodedNodeSet &Dst) {
+  if (isa(*DS->decl_begin())) {
+ExplodedNodeSet DstPre;
+getCheckerManager().runCheckersForPreStmt(DstPre, Pred, DS, *this);
+getCheckerManager().runCheckersForPostStmt(Dst, DstPre, DS, *this);
+return;
+  }
+
   // Assumption: The CFG has one DeclStmt per Decl.
   const VarDecl *VD = dyn_cast_or_null(*DS->decl_begin());
 
Index: clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
@@ -30,10 +30,16 @@
 using namespace taint;
 
 namespace {
-class VLASizeChecker : public Checker< check::PreStmt > {
+class VLASizeChecker
+: public Checker,
+ check::PreStmt> {
   mutable std::unique_ptr BT;
   enum VLASize_Kind { VLA_Garbage, VLA_Zero, VLA_Tainted, VLA_Negative };
 
+  ProgramStateRef checkVLA(CheckerContext &C, ProgramStateRef State,
+   const VariableArrayType *VLA,
+   const VariableArrayType *&VLALast,
+   llvm::SmallVector &VLASizes) const;
   ProgramStateRef checkVLASize(CheckerContext &C, ProgramStateRef State,
const Expr *SizeE) const;
 
@@ -43,9 +49,39 @@
 
 public:
   void checkPreStmt(const DeclStmt *DS, CheckerContext &C) const;
+  void checkPreStmt(const UnaryExprOrTypeTraitExpr *UETTE,
+CheckerContext &C) const;
 };
 } // end anonymous namespace
 
+ProgramStateRef
+VLASizeChecker::checkVLA(CheckerContext &C, ProgramStateRef State,
+ const VariableArrayType *VLA,
+ const VariableArrayType *&VLALast,
+ llvm::SmallVector &VLASizes) const {
+  assert(VLA && "Function should be called with non-null VLA argument.");
+
+  VLALast = nullptr;
+  // Walk over the VLAs for every dimension until a non-VLA is found.
+  // Collect the sizes in VLASizes, put the most inner VLA to `VLALast`.
+  // In "vla[x][2][y][3]" this will be the array for index "y".
+  // There is a VariableArrayType for every dimension (here "x", "2", "y")
+  // until a non-vla is found.
+  while (VLA) {
+const Expr *SizeE = VLA->getSizeExpr();
+State = checkVLASize(C, State, SizeE);
+if (!State)
+  return nullptr;
+VLASizes.push_back(SizeE);
+VLALast = VLA;
+VLA = C.getASTContext().getAsVariableArrayType(VLA->getElementType());
+  };
+  assert(VLALast &&
+ "Array should have at least one variably-modified dimension.");
+
+  return State;
+}
+
 ProgramStateRef VLASizeChecker::checkVLASize(CheckerContext &C,
  ProgramStateRef State,
  const Expr *SizeE) const {
@@ -146,36 +182,34 @@
   if (!DS->isSingleDecl())
 return;
 
-  const VarDecl *VD = dyn_cast(DS->getSingleDecl());
-  if (!VD)
-return;
-
   ASTContext &Ctx = C.getASTContext();
   SValBuilder &SVB = C.getSValBuilder();
   ProgramStateRef State = C.getState();
+  QualType TypeToCheck;
 
-  const VariableArrayType *VLA = Ctx.getAsVariableArrayType(VD->getType());
+  const VarDecl *VD = dyn_cast(DS->getSingleDecl());
+
+  if (VD)
+TypeToCheck = VD->getType().getCanonicalType();
+  else if (const auto *TND = dyn_c

[PATCH] D79076: [clang] [MinGW] Add the compiler rt libdirs to the search path

2020-04-29 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo created this revision.
mstorsjo added reviewers: rnk, hans.
Herald added a project: clang.

This matches what is done for MSVC in b8000c0ce84541c5b5535419234fb65ce77d6756 
. Since 
that commit, compiler rt sanitizer libraries aren't linked to with absolute 
path on windows, but using their basenames, requiring the libdirs to be passed 
to the linker.

This fixes undefined behaviour sanitizer on MinGW after 
b8000c0ce84541c5b5535419234fb65ce77d6756 
.

Not sure what would be a good test for this, as the 
lib/clang//lib/windows directory doesn't exist, it won't show up in 
tests...


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79076

Files:
  clang/lib/Driver/ToolChains/MinGW.cpp


Index: clang/lib/Driver/ToolChains/MinGW.cpp
===
--- clang/lib/Driver/ToolChains/MinGW.cpp
+++ clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto &LibPath : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here


Index: clang/lib/Driver/ToolChains/MinGW.cpp
===
--- clang/lib/Driver/ToolChains/MinGW.cpp
+++ clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto &LibPath : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78990: [analyzer] Allow bindings of the CompoundLiteralRegion

2020-04-29 Thread Artem Dergachev via Phabricator via cfe-commits 
NoQ added a comment.

Yay unit tests! Let's squash those mutually cancelling bugs.




Comment at: clang/unittests/StaticAnalyzer/StoreTest.cpp:22-32
+  struct TestContext {
+StoreManager &SManager;
+SValBuilder &Builder;
+MemRegionManager &MRManager;
+ASTContext &ASTContext;
+
+/* implicit */ TestContext(ExprEngine &Engine)

Why was this necessary? All these variables seem to be already available in the 
surrounding scope as fields in `ExprEngineConsumer`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78990



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

[PATCH] D78286: [analyzer] Track runtime types represented by Obj-C Class objects

2020-04-29 Thread Artem Dergachev via Phabricator via cfe-commits 
NoQ added a comment.

Perfect! Please get yourself some commit access already -__-


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78286



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

[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

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



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:207-210
+  {{"fread", 4},
+   {&StreamChecker::preFread,
+std::bind(&StreamChecker::evalFreadFwrite, _1, _2, _3, _4,
+  ErrorFEof | ErrorFError),

Szelethus wrote:
> What does this mean? I guess not the possible states after an fread call, but 
> rather the possible states after a **failed** fread call, but then...
Name of the parameter may be misleading, for `evalFreadFwrite` the last 
argument describes the new state after the operation has failed.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:225-228
   {{"feof", 1},
{&StreamChecker::preDefault,
-&StreamChecker::evalFeofFerror,
-0,
-{StreamState::FError, StreamState::NoError}}},
-  // Note: ferror can result in Unknown if at the call there is a
-  // PossibleErrors with all 3 error states (including NoError).
-  // Then if ferror is false the remaining error could be FEof or NoError.
+std::bind(&StreamChecker::evalFeofFerror, _1, _2, _3, _4, ErrorFEof),
+0}},

Szelethus wrote:
> ...this doesn't make much sense, `feof` doesn't **cause** and error, it 
> merely detects it.
At `evalFeofFerror` the last parameter simply indicates if it is the `feof` or 
the `ferror` case.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:478
+
+  // FIXME: Check for stream in EOF state?
+

Szelethus wrote:
> Will that be the next patch? :D Eager to see it!
It may be too big change to add it as well here (or cause more difficulties). 
But it should be a  check for `ErrorFEof` in the `ErrorState` (and add another 
bug type). This is not a fatal error.

It may be more difficult to make `fread` return the feof error again if it 
starts already with feof state. (Because the state with FEof should be split 
from the generic error state that can contain other possible errors.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78374



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

[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-29 Thread Sjoerd Meijer via Phabricator via cfe-commits 
SjoerdMeijer added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64.td:849
+  HasV8_1aOps,
+  HasV8_3aOps]>;
+

`HasV8_3aOps` implies `HasV8_2aOps`, which implies `HasV8_1aOps`.
So you can just remove `HasV8_1aOps`? 



Comment at: llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td:13
+//===--===//
+
+//===--===//

I don't intend to check the numbers here, but just curious if there's an 
optimisation guide if people are curious?



Comment at: llvm/test/CodeGen/AArch64/loop-micro-op-buffer-size-t110.ll:1
+; REQUIRES: asserts
+; RUN: opt -mcpu=thunderx3t110 -loop-unroll --debug-only=loop-unroll 
--debug-only=basicblock-utils -S -unroll-allow-partial < %s 2>&1 | FileCheck %s

Couple of question about this test.
Looks like you're both testing output on stdout and stderr, and your checks for 
this are interleaved. If I am not mistaken, the behaviour of this can vary on 
different platforms, and thus may fail on different platforms.

But more importantly, what is this test exactly testing? The file name gives 
away a hint of course, but I don't see yet how this interact with loop 
unrolling. Is the loop unroller looking at MaxInterleaveFactor that is set 
here, but is that what we are testing here?



Comment at: llvm/test/CodeGen/AArch64/loop-micro-op-buffer-size-t110.ll:25
+; CHECK: %val5 = add nuw nsw i32 %counter, 10
+; CHECK-NOT: %val = add i32 %counter, 5
+; CHECK-NOT: %val = add i32 %counter, 6

I guess there won't be another define %val, it will be %val6, so this CHECK-NOT 
will never match even if there's another add?


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

https://reviews.llvm.org/D78129



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

[clang] 239c53b - [analyzer] Track runtime types represented by Obj-C Class objects

2020-04-29 Thread Valeriy Savchenko via cfe-commits 

Author: Valeriy Savchenko
Date: 2020-04-29T13:35:53+03:00
New Revision: 239c53b72b18d6fd6c5ad9a6d27cd09b950dc97a

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

LOG: [analyzer] Track runtime types represented by Obj-C Class objects

Summary:
Objective-C Class objects can be used to do a dynamic dispatch on
class methods. The analyzer had a few places where we tried to overcome
the dynamic nature of it and still guess the actual function that
is being called. That was done mostly using some simple heuristics
covering the most widespread cases (e.g. [[self class] classmethod]).
This solution introduces a way to track types represented by Class
objects and work with that instead of direct AST matching.

rdar://problem/50739539

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

Added: 
clang/test/Analysis/class-object-state-dump.m

Modified: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicType.h
clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeInfo.h
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
clang/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
clang/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
clang/lib/StaticAnalyzer/Core/CallEvent.cpp
clang/lib/StaticAnalyzer/Core/DynamicType.cpp
clang/lib/StaticAnalyzer/Core/ProgramState.cpp
clang/test/Analysis/cast-value-state-dump.cpp
clang/test/Analysis/inlining/InlineObjCClassMethod.m
clang/test/Analysis/inlining/ObjCDynTypePopagation.m
clang/test/Analysis/retain-release-inline.m

Removed: 




diff  --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
index 8b4be2784f38..bc562a4ca6f1 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
@@ -1115,9 +1115,6 @@ class ObjCMethodCall : public CallEvent {
   /// Returns the value of the receiver at the time of this call.
   SVal getReceiverSVal() const;
 
-  /// Return the value of 'self' if available.
-  SVal getSelfSVal() const;
-
   /// Get the interface for the receiver.
   ///
   /// This works whether this is an instance message or a class message.

diff  --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicType.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicType.h
index 356401d77561..2679339537e8 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicType.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicType.h
@@ -36,6 +36,10 @@ DynamicTypeInfo getDynamicTypeInfo(ProgramStateRef State, 
const MemRegion *MR);
 const DynamicTypeInfo *getRawDynamicTypeInfo(ProgramStateRef State,
  const MemRegion *MR);
 
+/// Get dynamic type information stored in a class object represented by \p 
Sym.
+DynamicTypeInfo getClassObjectDynamicTypeInfo(ProgramStateRef State,
+  SymbolRef Sym);
+
 /// Get dynamic cast information from \p CastFromTy to \p CastToTy of \p MR.
 const DynamicCastInfo *getDynamicCastInfo(ProgramStateRef State,
   const MemRegion *MR,
@@ -50,6 +54,16 @@ ProgramStateRef setDynamicTypeInfo(ProgramStateRef State, 
const MemRegion *MR,
 ProgramStateRef setDynamicTypeInfo(ProgramStateRef State, const MemRegion *MR,
QualType NewTy, bool CanBeSubClassed = 
true);
 
+/// Set constraint on a type contained in a class object; return the new state.
+ProgramStateRef setClassObjectDynamicTypeInfo(ProgramStateRef State,
+  SymbolRef Sym,
+  DynamicTypeInfo NewTy);
+
+/// Set constraint on a type contained in a class object; return the new state.
+ProgramStateRef setClassObjectDynamicTypeInfo(ProgramStateRef State,
+  SymbolRef Sym, QualType NewTy,
+  bool CanBeSubClassed = true);
+
 /// Set dynamic type and cast information of the region; return the new state.
 ProgramStateRef setDynamicTypeAndCastInfo(ProgramStateRef State,
   const MemRegion *MR,
@@ -63,6 +77,10 @@ ProgramStateRef removeDeadTypes(ProgramStateRef State, 
SymbolReaper &SR);
 /// Removes the dead cast informations from \p State.
 ProgramStateRef removeDeadCasts(ProgramStateRef State, SymbolReaper &SR);
 
+/// Removes the dead Class object type informatio

[PATCH] D79079: [clangd] Make use of URIs in FileShardedIndex

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

This makes FileShardedIndex more robust and gets rid of the need for a
URIToFileCache, as it is done by the callers now and it is only once per file,
rather than once per symbol.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79079

Files:
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/FileIndex.h
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp

Index: clang-tools-extra/clangd/unittests/FileIndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -568,13 +568,12 @@
 
   IF.Cmd = tooling::CompileCommand(testRoot(), "b.cc", {"clang"}, "out");
 
-  FileShardedIndex ShardedIndex(std::move(IF), testPath("b.cc"));
-  ASSERT_THAT(
-  ShardedIndex.getAllFiles(),
-  UnorderedElementsAre(testPath("a.h"), testPath("b.h"), testPath("b.cc")));
+  FileShardedIndex ShardedIndex(std::move(IF));
+  ASSERT_THAT(ShardedIndex.getAllSources(),
+  UnorderedElementsAre(AHeaderUri, BHeaderUri, BSourceUri));
 
   {
-auto Shard = ShardedIndex.getShard(testPath("a.h"));
+auto Shard = ShardedIndex.getShard(AHeaderUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("1")));
 EXPECT_THAT(Shard.Refs.getValue(), IsEmpty());
 EXPECT_THAT(
@@ -586,7 +585,7 @@
 EXPECT_TRUE(Shard.Cmd.hasValue());
   }
   {
-auto Shard = ShardedIndex.getShard(testPath("b.h"));
+auto Shard = ShardedIndex.getShard(BHeaderUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("2")));
 EXPECT_THAT(Shard.Refs.getValue(), IsEmpty());
 EXPECT_THAT(
@@ -599,7 +598,7 @@
 EXPECT_TRUE(Shard.Cmd.hasValue());
   }
   {
-auto Shard = ShardedIndex.getShard(testPath("b.cc"));
+auto Shard = ShardedIndex.getShard(BSourceUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("2")));
 EXPECT_THAT(Shard.Refs.getValue(), UnorderedElementsAre(Pair(Sym1.ID, _)));
 EXPECT_THAT(Shard.Relations.getValue(), IsEmpty());
Index: clang-tools-extra/clangd/index/FileIndex.h
===
--- clang-tools-extra/clangd/index/FileIndex.h
+++ clang-tools-extra/clangd/index/FileIndex.h
@@ -159,16 +159,16 @@
 struct FileShardedIndex {
   /// \p HintPath is used to convert file URIs stored in symbols into absolute
   /// paths.
-  explicit FileShardedIndex(IndexFileIn Input, PathRef HintPath);
+  explicit FileShardedIndex(IndexFileIn Input);
 
-  /// Returns absolute paths for all files that has a shard.
-  std::vector getAllFiles() const;
+  /// Returns uris for all files that has a shard.
+  std::vector getAllSources() const;
 
-  /// Generates index shard for the \p File. Note that this function results in
+  /// Generates index shard for the \p Uri. Note that this function results in
   /// a copy of all the relevant data.
   /// Returned index will always have Symbol/Refs/Relation Slabs set, even if
   /// they are empty.
-  IndexFileIn getShard(PathRef File) const;
+  llvm::Optional getShard(llvm::StringRef Uri) const;
 
 private:
   // Contains all the information that belongs to a single file.
@@ -185,7 +185,7 @@
 
   // Keeps all the information alive.
   const IndexFileIn Index;
-  // Mapping from absolute paths to slab information.
+  // Mapping from URIs to slab information.
   llvm::StringMap Shards;
   // Used to build RefSlabs.
   llvm::DenseMap RefToSymID;
Index: clang-tools-extra/clangd/index/FileIndex.cpp
===
--- clang-tools-extra/clangd/index/FileIndex.cpp
+++ clang-tools-extra/clangd/index/FileIndex.cpp
@@ -29,6 +29,7 @@
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
@@ -96,27 +97,6 @@
  std::move(Relations));
 }
 
-// Resolves URI to file paths with cache.
-class URIToFileCache {
-public:
-  URIToFileCache(PathRef HintPath) : HintPath(HintPath) {}
-
-  llvm::StringRef operator[](llvm::StringRef FileURI) {
-if (FileURI.empty())
-  return "";
-auto I = URIToPathCache.try_emplace(FileURI);
-if (I.second) {
-  I.first->second = llvm::cantFail(URI::resolve(FileURI, HintPath),
-   "Failed to resolve URI");
-}
-return I.first->second;
-  }
-
-private:
-  PathRef HintPath;
-  llvm::StringMap URIToPathCache;
-};
-
 // We keep only the node "U" and its edges. Any node other than "U" will be

[PATCH] D79000: [clang-format] C# property formatting can be controlled by config options

2020-04-29 Thread Jonathan B Coe via Phabricator via cfe-commits 
jbcoe added a comment.

  public int Style2
  { get; set }

appears in MS examples 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties

  public int Style2 { get; set }

is the style we use in our code (where the formatter will be put to immediate 
use).

Other options can be added/supported (maybe a CSharpPropertyStyle enum?) but I 
don't think I'm going to have time to devote to that in the immediate future. 
Happy to review/advise as needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79000



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

[PATCH] D78286: [analyzer] Track runtime types represented by Obj-C Class objects

2020-04-29 Thread Valeriy Savchenko via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG239c53b72b18: [analyzer] Track runtime types represented by 
Obj-C Class objects (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78286

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicType.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeInfo.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  clang/lib/StaticAnalyzer/Checkers/CastValueChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/DynamicType.cpp
  clang/lib/StaticAnalyzer/Core/ProgramState.cpp
  clang/test/Analysis/cast-value-state-dump.cpp
  clang/test/Analysis/class-object-state-dump.m
  clang/test/Analysis/inlining/InlineObjCClassMethod.m
  clang/test/Analysis/inlining/ObjCDynTypePopagation.m
  clang/test/Analysis/retain-release-inline.m

Index: clang/test/Analysis/retain-release-inline.m
===
--- clang/test/Analysis/retain-release-inline.m
+++ clang/test/Analysis/retain-release-inline.m
@@ -13,6 +13,7 @@
 // It includes the basic definitions for the test cases below.
 //===--===//
 #define NULL 0
+#define nil ((id)0)
 typedef unsigned int __darwin_natural_t;
 typedef unsigned long uintptr_t;
 typedef unsigned int uint32_t;
@@ -21,14 +22,14 @@
 typedef signed long CFIndex;
 typedef CFIndex CFByteOrder;
 typedef struct {
-CFIndex location;
-CFIndex length;
+  CFIndex location;
+  CFIndex length;
 } CFRange;
 static __inline__ __attribute__((always_inline)) CFRange CFRangeMake(CFIndex loc, CFIndex len) {
-CFRange range;
-range.location = loc;
-range.length = len;
-return range;
+  CFRange range;
+  range.location = loc;
+  range.length = len;
+  return range;
 }
 typedef const void * CFTypeRef;
 typedef const struct __CFString * CFStringRef;
@@ -91,6 +92,7 @@
 - (BOOL)isEqual:(id)object;
 - (id)retain;
 - (oneway void)release;
+- (Class)class;
 - (id)autorelease;
 - (id)init;
 @end  @protocol NSCopying  - (id)copyWithZone:(NSZone *)zone;
@@ -100,6 +102,7 @@
 @interface NSObject  {}
 + (id)allocWithZone:(NSZone *)zone;
 + (id)alloc;
++ (Class)class;
 - (void)dealloc;
 @end
 @interface NSObject (NSCoderMethods)
@@ -481,3 +484,33 @@
   [self test_inline_tiny_when_reanalyzing];
 }
 @end
+
+// Original problem: rdar://problem/50739539
+@interface MyClassThatLeaksDuringInit : NSObject
+
++ (MyClassThatLeaksDuringInit *)getAnInstance1;
++ (MyClassThatLeaksDuringInit *)getAnInstance2;
+
+@end
+
+@implementation MyClassThatLeaksDuringInit
+
++ (MyClassThatLeaksDuringInit *)getAnInstance1 {
+  return [[[MyClassThatLeaksDuringInit alloc] init] autorelease]; // expected-warning{{leak}}
+}
+
++ (MyClassThatLeaksDuringInit *)getAnInstance2 {
+  return self class] alloc] init] autorelease]; // expected-warning{{leak}}
+}
+
+- (instancetype)init {
+  if (1) {
+return nil;
+  }
+
+  if (nil != (self = [super init])) {
+  }
+  return self;
+}
+
+@end
Index: clang/test/Analysis/inlining/ObjCDynTypePopagation.m
===
--- clang/test/Analysis/inlining/ObjCDynTypePopagation.m
+++ clang/test/Analysis/inlining/ObjCDynTypePopagation.m
@@ -7,68 +7,67 @@
 PublicSubClass2 *getObj();
 
 @implementation PublicParent
-- (int) getZeroOverridden {
-   return 1;
+- (int)getZeroOverridden {
+  return 1;
 }
-- (int) getZero {
-   return 0;
+- (int)getZero {
+  return 0;
 }
 @end
 
 @implementation PublicSubClass2
-- (int) getZeroOverridden {
-   return 0;
+- (int)getZeroOverridden {
+  return 0;
 }
 
 /* Test that we get the right type from call to alloc. */
-+ (void) testAllocSelf {
++ (void)testAllocSelf {
   id a = [self alloc];
   clang_analyzer_eval([a getZeroOverridden] == 0); // expected-warning{{TRUE}}
 }
 
-
-+ (void) testAllocClass {
++ (void)testAllocClass {
   id a = [PublicSubClass2 alloc];
   clang_analyzer_eval([a getZeroOverridden] == 0); // expected-warning{{TRUE}}
 }
 
-+ (void) testAllocSuperOverriden {
++ (void)testAllocSuperOverriden {
   id a = [super alloc];
   // Evaluates to 1 in the parent.
-  clang_analyzer_eval([a getZeroOverridden] == 0); // expected-warning{{FALSE}} 
+  clang_analyzer_eval([a getZeroOverridden] == 0); // expected-warning{{FALSE}}
 }
 
-+ (void) testAllocSuper {
++ (void)testAllocSuper {
   id a = [super alloc];
   clang_analyzer_eval([a getZero] == 0); // expected-warning{{TRUE}}
 }
 
-+ (void) testAllocInit {
++ (void)testAllocInit {
   id a = [[self alloc] init];
   clang_analyzer_eval([a getZeroOverridden] == 0); // expecte

[PATCH] D78118: [analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries

2020-04-29 Thread Balázs Kéri via Phabricator via cfe-commits 
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:651
+// Get the declaration of a function proto as written in the source file.
+StringRef ToString(const FunctionDecl *FD) {
+  const auto &SM = ACtx.getSourceManager();

Maybe the `Decl::print` method can be used? I pretty-prints the declaration 
(hopefully there is an option to print only the prototype), otherwise we can 
get the code as written in the source-file(?) that makes comparing the output 
more difficult. 



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:681
+if (DisplayLoadedSummaries)
+  llvm::errs() << "Loaded summary for " << ToString(FD) << "\n";
 return;

I would prefer to display the function prototype in a separate line (if not 
only the name is included in the string). Or at least enclose the prototype 
with `'` characters. Or the `Loaded summary for: ` form.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78118



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

[clang] 42a56bf - [SveEmitter] Add builtins for gather prefetches

2020-04-29 Thread Sander de Smalen via cfe-commits 

Author: Sander de Smalen
Date: 2020-04-29T11:52:49+01:00
New Revision: 42a56bf63f699a620a57c34474510d9937ebf715

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

LOG: [SveEmitter] Add builtins for gather prefetches

Patch by Andrzej Warzynski

Reviewed By: efriedma

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/TargetBuiltins.h
clang/include/clang/Basic/arm_sve.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CodeGenFunction.h
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
clang/utils/TableGen/SveEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetBuiltins.h 
b/clang/include/clang/Basic/TargetBuiltins.h
index 0a06ba3e5ecc..bf07a8950f28 100644
--- a/clang/include/clang/Basic/TargetBuiltins.h
+++ b/clang/include/clang/Basic/TargetBuiltins.h
@@ -242,6 +242,7 @@ namespace clang {
 bool isReverseCompare() const { return Flags & ReverseCompare; }
 bool isAppendSVALL() const { return Flags & IsAppendSVALL; }
 bool isInsertOp1SVALL() const { return Flags & IsInsertOp1SVALL; }
+bool isGatherPrefetch() const { return Flags & IsGatherPrefetch; }
 
 uint64_t getBits() const { return Flags; }
 bool isFlagSet(uint64_t Flag) const { return Flags & Flag; }

diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index 20a055bc6d38..a028487a96b9 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -98,6 +98,8 @@
 // G: pointer to uint32_t
 // H: pointer to uint64_t
 
+// Q: const pointer to void
+
 // S: const pointer to int8_t
 // T: const pointer to int16_t
 // U: const pointer to int32_t
@@ -185,6 +187,7 @@ def IsByteIndexed : FlagType<0x0100>;
 def IsAppendSVALL : FlagType<0x0200>; // Appends SV_ALL as the 
last operand.
 def IsInsertOp1SVALL  : FlagType<0x0400>; // Inserts SV_ALL as the 
second operand.
 def IsPrefetch: FlagType<0x0800>; // Contiguous prefetches.
+def IsGatherPrefetch  : FlagType<0x1000>;
 def ReverseCompare: FlagType<0x2000>; // Compare operands must 
be swapped.
 
 // These must be kept in sync with the flags in 
include/clang/Basic/TargetBuiltins.h
@@ -569,6 +572,39 @@ def SVPRFH_VNUM : MInst<"svprfh_vnum", "vPclJ", "s", 
[IsPrefetch], MemEltTyInt16
 def SVPRFW_VNUM : MInst<"svprfw_vnum", "vPclJ", "i", [IsPrefetch], 
MemEltTyInt32, "aarch64_sve_prf">;
 def SVPRFD_VNUM : MInst<"svprfd_vnum", "vPclJ", "l", [IsPrefetch], 
MemEltTyInt64, "aarch64_sve_prf">;
 
+// Prefetch (Vector bases)
+def SVPRFB_GATHER_BASES : MInst<"svprfb_gather[_{2}base]", "vPdJ", "UiUl", 
[IsGatherPrefetch], MemEltTyInt8,  "aarch64_sve_prfb_gather_scalar_offset">;
+def SVPRFH_GATHER_BASES : MInst<"svprfh_gather[_{2}base]", "vPdJ", "UiUl", 
[IsGatherPrefetch], MemEltTyInt16, "aarch64_sve_prfh_gather_scalar_offset">;
+def SVPRFW_GATHER_BASES : MInst<"svprfw_gather[_{2}base]", "vPdJ", "UiUl", 
[IsGatherPrefetch], MemEltTyInt32, "aarch64_sve_prfw_gather_scalar_offset">;
+def SVPRFD_GATHER_BASES : MInst<"svprfd_gather[_{2}base]", "vPdJ", "UiUl", 
[IsGatherPrefetch], MemEltTyInt64, "aarch64_sve_prfd_gather_scalar_offset">;
+
+// Prefetch (Scalar base, Vector offsets)
+def SVPRFB_GATHER_32B_OFFSETS_S : MInst<"svprfb_gather_[{3}]offset", "vPQdJ", 
"i",  [IsGatherPrefetch], MemEltTyInt8,  "aarch64_sve_prfb_gather_sxtw_index">;
+def SVPRFH_GATHER_32B_OFFSETS_S : MInst<"svprfh_gather_[{3}]index",  "vPQdJ", 
"i",  [IsGatherPrefetch], MemEltTyInt16, "aarch64_sve_prfh_gather_sxtw_index">;
+def SVPRFW_GATHER_32B_OFFSETS_S : MInst<"svprfw_gather_[{3}]index",  "vPQdJ", 
"i",  [IsGatherPrefetch], MemEltTyInt32, "aarch64_sve_prfw_gather_sxtw_index">;
+def SVPRFD_GATHER_32B_OFFSETS_S : MInst<"svprfd_gather_[{3}]index",  "vPQdJ", 
"i",  [IsGatherPrefetch], MemEltTyInt64, "aarch64_sve_prfd_gather_sxtw_index">;
+
+def SVPRFB_GATHER_64B_OFFSETS_S : MInst<"svprfb_gather_[{3}]offset", "vPQdJ", 
"l",  [IsGatherPrefetch], MemEltTyInt8,  "aarch64_sve_prfb_gather_index">;
+def SVPRFH_GATHER_64B_OFFSETS_S : MInst<"svprfh_gather_[{3}]index",  "vPQdJ", 
"l",  [IsGatherPrefetch], MemEltTyInt16, "aarch64_sve_prfh_gather_index">;
+def SVPRFW_GATHER_64B_OFFSETS_S : MInst<"svprfw_gather_[{3}]index",  "vPQdJ", 
"l",  [IsGatherPrefetch], MemEltTyInt32, "aarch64_sve_prfw_gather_index">;
+def SVPRFD_GATHER_64B_OFFSETS_S : MInst<"svprfd_gather_[{3}]index",  "vPQdJ", 
"l",  [IsGatherPrefetch], MemEltTyInt64, "aarch64_sve_prfd_gather_index">;
+
+d

[PATCH] D79079: [clangd] Make use of URIs in FileShardedIndex

2020-04-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits 
kadircet updated this revision to Diff 260878.
kadircet added a comment.

- Return None and change PathRef to auto since it is URI now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79079

Files:
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/FileIndex.h
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp

Index: clang-tools-extra/clangd/unittests/FileIndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -568,13 +568,12 @@
 
   IF.Cmd = tooling::CompileCommand(testRoot(), "b.cc", {"clang"}, "out");
 
-  FileShardedIndex ShardedIndex(std::move(IF), testPath("b.cc"));
-  ASSERT_THAT(
-  ShardedIndex.getAllFiles(),
-  UnorderedElementsAre(testPath("a.h"), testPath("b.h"), testPath("b.cc")));
+  FileShardedIndex ShardedIndex(std::move(IF));
+  ASSERT_THAT(ShardedIndex.getAllSources(),
+  UnorderedElementsAre(AHeaderUri, BHeaderUri, BSourceUri));
 
   {
-auto Shard = ShardedIndex.getShard(testPath("a.h"));
+auto Shard = ShardedIndex.getShard(AHeaderUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("1")));
 EXPECT_THAT(Shard.Refs.getValue(), IsEmpty());
 EXPECT_THAT(
@@ -586,7 +585,7 @@
 EXPECT_TRUE(Shard.Cmd.hasValue());
   }
   {
-auto Shard = ShardedIndex.getShard(testPath("b.h"));
+auto Shard = ShardedIndex.getShard(BHeaderUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("2")));
 EXPECT_THAT(Shard.Refs.getValue(), IsEmpty());
 EXPECT_THAT(
@@ -599,7 +598,7 @@
 EXPECT_TRUE(Shard.Cmd.hasValue());
   }
   {
-auto Shard = ShardedIndex.getShard(testPath("b.cc"));
+auto Shard = ShardedIndex.getShard(BSourceUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("2")));
 EXPECT_THAT(Shard.Refs.getValue(), UnorderedElementsAre(Pair(Sym1.ID, _)));
 EXPECT_THAT(Shard.Relations.getValue(), IsEmpty());
Index: clang-tools-extra/clangd/index/FileIndex.h
===
--- clang-tools-extra/clangd/index/FileIndex.h
+++ clang-tools-extra/clangd/index/FileIndex.h
@@ -159,16 +159,16 @@
 struct FileShardedIndex {
   /// \p HintPath is used to convert file URIs stored in symbols into absolute
   /// paths.
-  explicit FileShardedIndex(IndexFileIn Input, PathRef HintPath);
+  explicit FileShardedIndex(IndexFileIn Input);
 
-  /// Returns absolute paths for all files that has a shard.
-  std::vector getAllFiles() const;
+  /// Returns uris for all files that has a shard.
+  std::vector getAllSources() const;
 
-  /// Generates index shard for the \p File. Note that this function results in
+  /// Generates index shard for the \p Uri. Note that this function results in
   /// a copy of all the relevant data.
   /// Returned index will always have Symbol/Refs/Relation Slabs set, even if
   /// they are empty.
-  IndexFileIn getShard(PathRef File) const;
+  llvm::Optional getShard(llvm::StringRef Uri) const;
 
 private:
   // Contains all the information that belongs to a single file.
@@ -185,7 +185,7 @@
 
   // Keeps all the information alive.
   const IndexFileIn Index;
-  // Mapping from absolute paths to slab information.
+  // Mapping from URIs to slab information.
   llvm::StringMap Shards;
   // Used to build RefSlabs.
   llvm::DenseMap RefToSymID;
Index: clang-tools-extra/clangd/index/FileIndex.cpp
===
--- clang-tools-extra/clangd/index/FileIndex.cpp
+++ clang-tools-extra/clangd/index/FileIndex.cpp
@@ -29,6 +29,7 @@
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
@@ -96,27 +97,6 @@
  std::move(Relations));
 }
 
-// Resolves URI to file paths with cache.
-class URIToFileCache {
-public:
-  URIToFileCache(PathRef HintPath) : HintPath(HintPath) {}
-
-  llvm::StringRef operator[](llvm::StringRef FileURI) {
-if (FileURI.empty())
-  return "";
-auto I = URIToPathCache.try_emplace(FileURI);
-if (I.second) {
-  I.first->second = llvm::cantFail(URI::resolve(FileURI, HintPath),
-   "Failed to resolve URI");
-}
-return I.first->second;
-  }
-
-private:
-  PathRef HintPath;
-  llvm::StringMap URIToPathCache;
-};
-
 // We keep only the node "U" and its edges. Any node other than "U" will be
 // empty in the resultant graph.
 IncludeGraph getSubGraph(llvm::StringRef URI, const IncludeGraph &FullGraph) {
@@ -137,24 +117,21 @@
 }
 } // namespace
 
-FileShardedIndex

[PATCH] D78677: [SveEmitter] Add builtins for gather prefetches

2020-04-29 Thread Sander de Smalen via Phabricator via cfe-commits 
sdesmalen marked an inline comment as done.
sdesmalen added a comment.

Thanks for reviewing!




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7739
+
+// Index needs to be passed as scaled offset.
+llvm::Type *MemEltTy = SVEBuiltinMemEltTy(TypeFlags);

efriedma wrote:
> `} else {`, so you aren't multiplying by zero?
Good catch, I've fixed that before committing.


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

https://reviews.llvm.org/D78677



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

[PATCH] D78677: [SveEmitter] Add builtins for gather prefetches

2020-04-29 Thread Sander de Smalen via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG42a56bf63f69: [SveEmitter] Add builtins for gather 
prefetches (authored by sdesmalen).

Changed prior to commit:
  https://reviews.llvm.org/D78677?vs=259589&id=260879#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78677

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -606,6 +606,12 @@
 Float = true;
 ElementBitwidth = 64;
 break;
+  case 'Q':
+Constant = true;
+Pointer = true;
+Void = true;
+NumVectors = 0;
+break;
   case 'S':
 Constant = true;
 Pointer = true;
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
@@ -116,3 +116,77 @@
   // CHECK: @llvm.aarch64.sve.prf.nxv4i1( %[[PG]], i8* %[[I8_BASE]], i32 0)
   return svprfw_vnum(pg, base, vnum, SV_PLDL1KEEP);
 }
+
+void test_svprfw_gather_u32base(svbool_t pg, svuint32_t bases)
+{
+  // CHECK-LABEL: test_svprfw_gather_u32base
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv4i32( %[[PG]],  %bases, i64 0, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather,_u32base,,)(pg, bases, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u64base(svbool_t pg, svuint64_t bases)
+{
+  // CHECK-LABEL: test_svprfw_gather_u64base
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv2i64( %[[PG]],  %bases, i64 0, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather,_u64base,,)(pg, bases, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_s32index(svbool_t pg, const void *base, svint32_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_s32index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.sxtw.index.nxv4i32( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,s32,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_s64index(svbool_t pg, const void *base, svint64_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_s64index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.index.nxv2i64( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,s64,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u32index(svbool_t pg, const void *base, svuint32_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_u32index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.uxtw.index.nxv4i32( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,u32,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u64index(svbool_t pg, const void *base, svuint64_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_u64index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.index.nxv2i64( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,u64,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u32base_index(svbool_t pg, svuint32_t bases, int64_t index)
+{
+  // CHECK-LABEL: test_svprfw_gather_u32base_index
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK-DAG: %[[SHL:.*]] = shl i64 %index, 2
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv4i32( %[[PG]],  %bases, i64 %[[SHL]], i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather,_u32base,_index,)(pg, bases, index, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u64base_index(svbool_t pg, svuint64_t bases, int64_t index)
+{
+  // CHECK-LABEL: test_svprfw_gather_u64base_index
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // C

[clang] db97a12 - Fix Wparentheses gcc warning. NFC.

2020-04-29 Thread Simon Pilgrim via cfe-commits 

Author: Simon Pilgrim
Date: 2020-04-29T12:21:05+01:00
New Revision: db97a12454a95556dd7cd812105088c7e8852d92

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

LOG: Fix Wparentheses gcc warning. NFC.

It should be either a float(32) or an int(32).

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 7672d95219fa..55f106e7c300 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -3070,7 +3070,7 @@ llvm::Value 
*CodeGenFunction::EmitCMSEClearRecord(llvm::Value *Src,
 llvm::Value *CodeGenFunction::EmitCMSEClearFP16(llvm::Value *Src) {
   llvm::Type *RetTy = Src->getType();
   assert(RetTy->isFloatTy() ||
- RetTy->isIntegerTy() && RetTy->getIntegerBitWidth() == 32);
+ (RetTy->isIntegerTy() && RetTy->getIntegerBitWidth() == 32));
   if (RetTy->isFloatTy()) {
 llvm::Value *T0 = Builder.CreateBitCast(Src, Builder.getIntNTy(32));
 llvm::Value *T1 = Builder.CreateAnd(T0, 0x, "cmse.clear");



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

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

? are you removing something?



Comment at: clang/docs/ClangFormatStyleOptions.rst:2062
  {
- [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber *u, 
NSNumber *v) {
+ [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
+ *u, NSNumber *v) {

unrelated change



Comment at: clang/lib/Format/Format.cpp:1143
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowShortEnumsOnASingleLine = (Language != FormatStyle::LK_Cpp);
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;

I think its ok to leave it was, just if up the unit tests

(the fact you didn't see this suggests you are not running the unit tests 
please ensure you are)


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

https://reviews.llvm.org/D78982



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

[PATCH] D78874: [clang] Add vendor identity for Hygon Dhyana processor

2020-04-29 Thread Jinke Fan via Phabricator via cfe-commits 
fanjinke added a comment.

Hi Craig，

I can't commit the patch myself because I don't have access.
Could you please help me？

Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78874



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

[PATCH] D79079: [clangd] Make use of URIs in FileShardedIndex

2020-04-29 Thread Sam McCall via Phabricator via cfe-commits 
sammccall added a comment.

LG but I think we can skip one lot of conversion, let me know what you think.




Comment at: clang-tools-extra/clangd/index/Background.cpp:183
 const auto &IGN = IndexIt.getValue();
 // Note that sources do not contain any information regarding missing
 // headers, since we don't even know what absolute path they should fall 
in.

is this really important enough to be worth saying twice :-)



Comment at: clang-tools-extra/clangd/index/FileIndex.cpp:390
 PreambleSymbols.update(
-File, std::make_unique(std::move(*IF.Symbols)),
+*AbsPath, std::make_unique(std::move(*IF.Symbols)),
 std::make_unique(),

I don't actually think it's important that we use filenames as the 
PreambleSymbols sharding key. We can skip the whole resolving thing and just 
use the URIs. We should go through and update docs to change "path" to "key" in 
FileSymbols I guess. Am I missing something?

Sorry I think I alluded to this a bit cryptically...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79079



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

[clang] 23f4edf - [analyzer] Fix build error. NFC.

2020-04-29 Thread Valeriy Savchenko via cfe-commits 

Author: Valeriy Savchenko
Date: 2020-04-29T15:24:10+03:00
New Revision: 23f4edf1fe38b8d4c6dbc7fc8e197f1f1f8c6710

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

LOG: [analyzer] Fix build error. NFC.

Move DenseMapInfo specialization to llvm namespace

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/CallEvent.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/CallEvent.cpp 
b/clang/lib/StaticAnalyzer/Core/CallEvent.cpp
index 55d343048345..cd15cd872d9d 100644
--- a/clang/lib/StaticAnalyzer/Core/CallEvent.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -1172,7 +1172,8 @@ struct PrivateMethodKey {
   bool IsClassMethod;
 };
 
-template <> struct llvm::DenseMapInfo {
+namespace llvm {
+template <> struct DenseMapInfo {
   using InterfaceInfo = DenseMapInfo;
   using SelectorInfo = DenseMapInfo;
 
@@ -1199,6 +1200,7 @@ template <> struct llvm::DenseMapInfo {
LHS.IsClassMethod == RHS.IsClassMethod;
   }
 };
+} // end namespace llvm
 
 const ObjCMethodDecl *
 lookupRuntimeDefinition(const ObjCInterfaceDecl *Interface,



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

[clang] a4dac6d - [SveEmitter] Add builtins for svmov_b and svnot_b.

2020-04-29 Thread Sander de Smalen via cfe-commits 

Author: Sander de Smalen
Date: 2020-04-29T13:33:18+01:00
New Revision: a4dac6d4e0eae47eaa51bac72c048b1e3cd89c8b

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

LOG: [SveEmitter] Add builtins for svmov_b and svnot_b.

These are custom expanded in CGBuiltin:

  svmov_b_z(pg, op) <=> svand_b_z(pg, op, op)
  svnot_b_z(pg, op) <=> sveor_b_z(pg, op, pg)

Reviewers: SjoerdMeijer, efriedma, ctetreau, rengolin

Reviewed By: efriedma

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

Added: 
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c

Modified: 
clang/include/clang/Basic/arm_sve.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c

Removed: 




diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index a028487a96b9..5eaeadeb06d3 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -984,8 +984,10 @@ def SVPTRUE : SInst<"svptrue_{d}", "P",  
"PcPsPiPl", MergeNone, "aarch64
 def SVAND_B_Z  : SInst<"svand[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_and_z">;
 def SVBIC_B_Z  : SInst<"svbic[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_bic_z">;
 def SVEOR_B_Z  : SInst<"sveor[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_eor_z">;
+def SVMOV_B_Z  : SInst<"svmov[_b]_z",  "PPP",  "Pc", MergeNone>; // Uses 
custom expansion
 def SVNAND_B_Z : SInst<"svnand[_b]_z", "", "Pc", MergeNone, 
"aarch64_sve_nand_z">;
 def SVNOR_B_Z  : SInst<"svnor[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_nor_z">;
+def SVNOT_B_Z  : SInst<"svnot[_b]_z",  "PPP",  "Pc", MergeNone>; // Uses 
custom expansion
 def SVORN_B_Z  : SInst<"svorn[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_orn_z">;
 def SVORR_B_Z  : SInst<"svorr[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_orr_z">;
 

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index e0b7e8a2dd78..2fa9ed9b2443 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -7990,6 +7990,23 @@ Value 
*CodeGenFunction::EmitAArch64SVEBuiltinExpr(unsigned BuiltinID,
   switch (BuiltinID) {
   default:
 return nullptr;
+
+  case SVE::BI__builtin_sve_svmov_b_z: {
+// svmov_b_z(pg, op) <=> svand_b_z(pg, op, op)
+SVETypeFlags TypeFlags(Builtin->TypeModifier);
+llvm::Type* OverloadedTy = getSVEType(TypeFlags);
+Function *F = CGM.getIntrinsic(Intrinsic::aarch64_sve_and_z, OverloadedTy);
+return Builder.CreateCall(F, {Ops[0], Ops[1], Ops[1]});
+  }
+
+  case SVE::BI__builtin_sve_svnot_b_z: {
+// svnot_b_z(pg, op) <=> sveor_b_z(pg, op, pg)
+SVETypeFlags TypeFlags(Builtin->TypeModifier);
+llvm::Type* OverloadedTy = getSVEType(TypeFlags);
+Function *F = CGM.getIntrinsic(Intrinsic::aarch64_sve_eor_z, OverloadedTy);
+return Builder.CreateCall(F, {Ops[0], Ops[1], Ops[0]});
+  }
+
   case SVE::BI__builtin_sve_svpfalse_b:
 return ConstantInt::getFalse(Ty);
 

diff  --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c 
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c
new file mode 100644
index ..609c3d22b472
--- /dev/null
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu 
-target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall 
-emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple 
aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns 
-S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+svbool_t test_svmov_b_z(svbool_t pg, svbool_t op)
+{
+  // CHECK-LABEL: test_svmov_b_z
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.and.z.nxv16i1( %pg,  %op, 
 %op)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svmov,_b,_z,)(pg, op);
+}

diff  --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c 
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
index 8ce0dd47c6cf..45703d895d3c 100644
--- a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
@@ -219,3 +219,11 @@ svuint64_t test_svnot_u64_x(svbool_t pg, svuint64_t op)
   // CHECK: ret  %[[INTRINSIC]]
   return SVE_ACLE_FUNC(svnot,_u64,_x,)(pg, op);
 }
+
+svbool_t test_svnot_b_z(svbool_t pg, svbool_t op)
+{
+  // CHECK-LABEL: test_svnot_b_z
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.eor.z.nxv16

[PATCH] D79039: [SveEmitter] Add builtins for svmov_b and svnot_b.

2020-04-29 Thread Sander de Smalen via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa4dac6d4e0ea: [SveEmitter] Add builtins for svmov_b and 
svnot_b. (authored by sdesmalen).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79039

Files:
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c


Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
@@ -219,3 +219,11 @@
   // CHECK: ret  %[[INTRINSIC]]
   return SVE_ACLE_FUNC(svnot,_u64,_x,)(pg, op);
 }
+
+svbool_t test_svnot_b_z(svbool_t pg, svbool_t op)
+{
+  // CHECK-LABEL: test_svnot_b_z
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.eor.z.nxv16i1( %pg,  %op, 
 %pg)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svnot,_b,_z,)(pg, op);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mov.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu 
-target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall 
-emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple 
aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns 
-S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+svbool_t test_svmov_b_z(svbool_t pg, svbool_t op)
+{
+  // CHECK-LABEL: test_svmov_b_z
+  // CHECK: %[[INTRINSIC:.*]] = call  
@llvm.aarch64.sve.and.z.nxv16i1( %pg,  %op, 
 %op)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svmov,_b,_z,)(pg, op);
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -7990,6 +7990,23 @@
   switch (BuiltinID) {
   default:
 return nullptr;
+
+  case SVE::BI__builtin_sve_svmov_b_z: {
+// svmov_b_z(pg, op) <=> svand_b_z(pg, op, op)
+SVETypeFlags TypeFlags(Builtin->TypeModifier);
+llvm::Type* OverloadedTy = getSVEType(TypeFlags);
+Function *F = CGM.getIntrinsic(Intrinsic::aarch64_sve_and_z, OverloadedTy);
+return Builder.CreateCall(F, {Ops[0], Ops[1], Ops[1]});
+  }
+
+  case SVE::BI__builtin_sve_svnot_b_z: {
+// svnot_b_z(pg, op) <=> sveor_b_z(pg, op, pg)
+SVETypeFlags TypeFlags(Builtin->TypeModifier);
+llvm::Type* OverloadedTy = getSVEType(TypeFlags);
+Function *F = CGM.getIntrinsic(Intrinsic::aarch64_sve_eor_z, OverloadedTy);
+return Builder.CreateCall(F, {Ops[0], Ops[1], Ops[0]});
+  }
+
   case SVE::BI__builtin_sve_svpfalse_b:
 return ConstantInt::getFalse(Ty);
 
Index: clang/include/clang/Basic/arm_sve.td
===
--- clang/include/clang/Basic/arm_sve.td
+++ clang/include/clang/Basic/arm_sve.td
@@ -984,8 +984,10 @@
 def SVAND_B_Z  : SInst<"svand[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_and_z">;
 def SVBIC_B_Z  : SInst<"svbic[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_bic_z">;
 def SVEOR_B_Z  : SInst<"sveor[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_eor_z">;
+def SVMOV_B_Z  : SInst<"svmov[_b]_z",  "PPP",  "Pc", MergeNone>; // Uses 
custom expansion
 def SVNAND_B_Z : SInst<"svnand[_b]_z", "", "Pc", MergeNone, 
"aarch64_sve_nand_z">;
 def SVNOR_B_Z  : SInst<"svnor[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_nor_z">;
+def SVNOT_B_Z  : SInst<"svnot[_b]_z",  "PPP",  "Pc", MergeNone>; // Uses 
custom expansion
 def SVORN_B_Z  : SInst<"svorn[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_orn_z">;
 def SVORR_B_Z  : SInst<"svorr[_b]_z",  "", "Pc", MergeNone, 
"aarch64_sve_orr_z">;
 


Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_not.c
@@ -219,3 +219,11 @@
   // CHECK: ret  %[[INTRINSIC]]
   return SVE_ACLE_FUNC(svnot,_u64,_x,)(pg, op);
 }
+
+svbool_t test_svnot_b_z(svbool_t pg, svbool_t op)
+{
+  // CHECK-LABEL: test_svnot_b_z
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.eor.z.nxv16i1( %pg,  %op,  %pg)
+  // CHECK: ret  %[[INTRINSIC]]
+  return SVE_ACLE_FUNC(svnot,_b,_z,)(pg, op);
+}
Index: clang/

[clang] 209ab6d - Revert 6654719 "[CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC"

2020-04-29 Thread Hans Wennborg via cfe-commits 

Author: Hans Wennborg
Date: 2020-04-29T15:12:43+02:00
New Revision: 209ab6d8835cd88320ceb814893759cfbda91d15

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

LOG: Revert 6654719 "[CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does 
not imply PIC"

It broke building libclang.dll in Windows builds configured with
LLVM_ENABLE_PIC=OFF. See discussion on the cfe-commits thread.

Added: 


Modified: 
clang/tools/libclang/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/libclang/CMakeLists.txt 
b/clang/tools/libclang/CMakeLists.txt
index 9368501592a9..bb2b14cc8e27 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -77,7 +77,7 @@ if(MSVC)
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if(LLVM_ENABLE_PIC)
+if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
   set(ENABLE_SHARED SHARED)
 endif()
 



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

Re: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

2020-04-29 Thread Hans Wennborg via cfe-commits 
On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
 wrote:
>
>
> Author: David Zarzycki
> Date: 2020-04-26T07:16:42-04:00
> New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
>
> URL: 
> https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220
> DIFF: 
> https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220.diff
>
> LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

But it does imply building libclang.dll.

Your change broke building libclang.dll when configured with "cmake
-GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
-DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on Windows, see the
discussion here: https://reviews.llvm.org/D74564#1884556

I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.

>
> Added:
>
>
> Modified:
> clang/tools/libclang/CMakeLists.txt
>
> Removed:
>
>
>
> 
> diff  --git a/clang/tools/libclang/CMakeLists.txt 
> b/clang/tools/libclang/CMakeLists.txt
> index bb2b14cc8e27..9368501592a9 100644
> --- a/clang/tools/libclang/CMakeLists.txt
> +++ b/clang/tools/libclang/CMakeLists.txt
> @@ -77,7 +77,7 @@ if(MSVC)
>set(LLVM_EXPORTED_SYMBOL_FILE)
>  endif()
>
> -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> +if(LLVM_ENABLE_PIC)
>set(ENABLE_SHARED SHARED)
>  endif()
>
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added a comment.

@craig.topper Did this look OK/  Is there anything else you want from this?


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

https://reviews.llvm.org/D78785



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

[PATCH] D78756: [SveEmitter] Add builtins for svreinterpret

2020-04-29 Thread Sander de Smalen via Phabricator via cfe-commits 
sdesmalen marked an inline comment as done.
sdesmalen added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7880
+return Builder.CreateBitCast(Val, Ty);
+  }
+

efriedma wrote:
> I'm vaguely suspicious this might be wrong for big-endian targets.  I mean, 
> this isn't unreasonable, but users might be surprised if svreinterpret isn't 
> a no-op.
For SVE the loads and stores (svld1 and svst1) are all endian safe, so no 
special consideration needs to be taken for big endian targets.

The ACLE specifies that:
> The svreinterpret functions simply reinterpret a vector of one type as a 
> vector of another type, without changing any of the bits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78756



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

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Kirill Bobyrev via Phabricator via cfe-commits 
kbobyrev created this revision.
kbobyrev added a reviewer: sammccall.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov, mgorny.
Herald added a project: clang.
kbobyrev added a comment.

Otherwise sources including `Index.pb.h` or `Index.grpc.pb.h` can be compiled 
before the those headers are generated.

https://github.com/kirillbobyrev/indexing-tools/runs/629305684 (disregard the 
mess in the repo)


Dependencies ensure that Protobufs are generated before all libraries
depending on the headers are **built**, not linked.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79085

Files:
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt


Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -14,3 +14,4 @@
 
   grpc++
   )
+add_dependencies(clangd-index-server RemoteIndexProtos)
Index: clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -7,3 +7,4 @@
   protobuf
   clangDaemon
   )
+add_dependencies(clangdRemoteMarshalling RemoteIndexProtos)
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -19,6 +19,7 @@
 grpc++
 clangDaemon
 )
+  add_dependencies(clangdRemoteIndex RemoteIndexProtos)
 
   add_subdirectory(marshalling)
   add_subdirectory(server)


Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -14,3 +14,4 @@
 
   grpc++
   )
+add_dependencies(clangd-index-server RemoteIndexProtos)
Index: clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -7,3 +7,4 @@
   protobuf
   clangDaemon
   )
+add_dependencies(clangdRemoteMarshalling RemoteIndexProtos)
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -19,6 +19,7 @@
 grpc++
 clangDaemon
 )
+  add_dependencies(clangdRemoteIndex RemoteIndexProtos)
 
   add_subdirectory(marshalling)
   add_subdirectory(server)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

2020-04-29 Thread Kirill Bobyrev via Phabricator via cfe-commits 
kbobyrev accepted this revision.
kbobyrev added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D78442: Create a warning flag for 'warn_conv_*_not_used'

2020-04-29 Thread Ronald Wampler via Phabricator via cfe-commits 
rdwampler added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78442



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

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Kirill Bobyrev via Phabricator via cfe-commits 
kbobyrev added a comment.

Otherwise sources including `Index.pb.h` or `Index.grpc.pb.h` can be compiled 
before the those headers are generated.

https://github.com/kirillbobyrev/indexing-tools/runs/629305684 (disregard the 
mess in the repo)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79085



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

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Sam McCall via Phabricator via cfe-commits 
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Haha, CMake :-(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79085



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

[PATCH] D79087: [SVE][Codegen] Lower legal min & max operations

2020-04-29 Thread Kerry McLaughlin via Phabricator via cfe-commits 
kmclaughlin created this revision.
kmclaughlin added reviewers: sdesmalen, efriedma, dancgr.
Herald added subscribers: psnobl, rkruppe, hiraditya, kristof.beyls, tschuett.
Herald added a reviewer: rengolin.
Herald added a project: LLVM.

This patch adds AArch64ISD nodes for [S|U]MIN_PRED
and [S|U]MAX_PRED, and lowers both SVE intrinsics and
IR operations for min and max to these nodes.

There are two forms of these instructions for SVE: a predicated
form and an immediate (unpredicated) form. The patterns
which existed for the latter have been updated to match a
predicated node with an immediate and map this
to the immediate instruction.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79087

Files:
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.h
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll

Index: llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
===
--- llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
+++ llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
@@ -32,8 +32,8 @@
   ret  %div
 }
 
-define  @sdiv_widen_i32( %a,  %b) {
-; CHECK-LABEL: @sdiv_widen_i32
+define  @sdiv_promote_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_promote_i32
 ; CHECK-DAG: ptrue p0.d
 ; CHECK-DAG: sxtw z1.d, p0/m, z1.d
 ; CHECK-DAG: sxtw z0.d, p0/m, z0.d
@@ -85,8 +85,8 @@
   ret  %div
 }
 
-define  @udiv_widen_i32( %a,  %b) {
-; CHECK-LABEL: @udiv_widen_i32
+define  @udiv_promote_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_promote_i32
 ; CHECK-DAG: ptrue p0.d
 ; CHECK-DAG: and z1.d, z1.d, #0x
 ; CHECK-DAG: and z0.d, z0.d, #0x
@@ -105,3 +105,179 @@
   %div = udiv  %a, %b
   ret  %div
 }
+
+;
+; SMIN
+;
+
+define  @smin_i8( %a,  %b,  %c) {
+; CHECK-LABEL: @smin_i8
+; CHECK-DAG: ptrue p0.b
+; CHECK-DAG: smin z0.b, p0/m, z0.b, z1.b
+; CHECK-NEXT: ret
+  %cmp = icmp slt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @smin_i16( %a,  %b,  %c) {
+; CHECK-LABEL: @smin_i16
+; CHECK-DAG: ptrue p0.h
+; CHECK-DAG: smin z0.h, p0/m, z0.h, z1.h
+; CHECK-NEXT: ret
+  %cmp = icmp slt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @smin_i32( %a,  %b,  %c) {
+; CHECK-LABEL: smin_i32:
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: smin z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %cmp = icmp slt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @smin_i64( %a,  %b,  %c) {
+; CHECK-LABEL: smin_i64:
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: smin z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %cmp = icmp slt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+;
+; UMIN
+;
+
+define  @umin_i8( %a,  %b,  %c) {
+; CHECK-LABEL: @umin_i8
+; CHECK-DAG: ptrue p0.b
+; CHECK-DAG: umin z0.b, p0/m, z0.b, z1.b
+; CHECK-NEXT: ret
+  %cmp = icmp ult  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @umin_i16( %a,  %b,  %c) {
+; CHECK-LABEL: @umin_i16
+; CHECK-DAG: ptrue p0.h
+; CHECK-DAG: umin z0.h, p0/m, z0.h, z1.h
+; CHECK-NEXT: ret
+  %cmp = icmp ult  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @umin_i32( %a,  %b,  %c) {
+; CHECK-LABEL: umin_i32:
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: umin z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %cmp = icmp ult  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @umin_i64( %a,  %b,  %c) {
+; CHECK-LABEL: umin_i64:
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: umin z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %cmp = icmp ult  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+;
+; SMAX
+;
+
+define  @smax_i8( %a,  %b,  %c) {
+; CHECK-LABEL: @smax_i8
+; CHECK-DAG: ptrue p0.b
+; CHECK-DAG: smax z0.b, p0/m, z0.b, z1.b
+; CHECK-NEXT: ret
+  %cmp = icmp sgt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @smax_i16( %a,  %b,  %c) {
+; CHECK-LABEL: @smax_i16
+; CHECK-DAG: ptrue p0.h
+; CHECK-DAG: smax z0.h, p0/m, z0.h, z1.h
+; CHECK-NEXT: ret
+  %cmp = icmp sgt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @smax_i32( %a,  %b,  %c) {
+; CHECK-LABEL: smax_i32:
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: smax z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %cmp = icmp sgt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @smax_i64( %a,  %b,  %c) {
+; CHECK-LABEL: smax_i64:
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: smax z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %cmp = icmp sgt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+;
+; UMAX
+;
+
+define  @umax_i8( %a,  %b,  %c) {
+; CHECK-LABEL: @umax_i8
+; CHECK-DAG: ptrue p0.b
+; CHECK-DAG: umax z0.b, p0/m, z0.b, z1.b
+; CHECK-NEXT: ret
+  %cmp = icmp ugt  %a, %b
+  %min = select  %cmp,  %a,  %b
+  ret  %min
+}
+
+define  @umax_i16( %a,  %b,  %c) {
+; CHECK-LABEL: @umax_i16
+; CHECK-DAG: ptrue p0.h
+; CHECK-DAG: umax z0.h, p0/m, z0.h, z1.h
+; CHECK-NEXT: ret
+  %cmp = icmp ugt  %a, %b
+

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Sam McCall via Phabricator via cfe-commits 
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/index/remote/CMakeLists.txt:22
 )
+  add_dependencies(clangdRemoteIndex RemoteIndexProtos)
 

is this equivalent to `DEPENDS RemoteIndexProtos` in the library?
Slightly clearer probably.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79085



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

Re: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

2020-04-29 Thread David Zarzycki via cfe-commits 
Hans,

Non-Windows non-PIC setups were working just fine until four days ago when 
D75068 landed. I tried to narrowly unbreak non-Windows non-PIC systems but 
apparently that broke Windows. For that, I'm sorry. That being said, 
non-Windows systems are broken again and this breakable was foreseeable given 
my revert. What is your plan for non-Windows systems?

As a part of the post-revert discussion in D75068, cristian.adam suggested that 
the check for WIN32 should be added back, but nobody followed through on that. 
What is stopping us from adding Christian's proposed change? Specifically:

if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))

Dave

On Wed, Apr 29, 2020, at 9:19 AM, Hans Wennborg wrote:
> On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
>  wrote:
> >
> >
> > Author: David Zarzycki
> > Date: 2020-04-26T07:16:42-04:00
> > New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
> >
> > URL: 
> > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220
> > DIFF: 
> > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220.diff
> >
> > LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC
> 
> But it does imply building libclang.dll.
> 
> Your change broke building libclang.dll when configured with "cmake
> -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
> -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on Windows, see the
> discussion here: https://reviews.llvm.org/D74564#1884556
> 
> I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.
> 
> >
> > Added:
> >
> >
> > Modified:
> > clang/tools/libclang/CMakeLists.txt
> >
> > Removed:
> >
> >
> >
> > 
> > diff  --git a/clang/tools/libclang/CMakeLists.txt 
> > b/clang/tools/libclang/CMakeLists.txt
> > index bb2b14cc8e27..9368501592a9 100644
> > --- a/clang/tools/libclang/CMakeLists.txt
> > +++ b/clang/tools/libclang/CMakeLists.txt
> > @@ -77,7 +77,7 @@ if(MSVC)
> >set(LLVM_EXPORTED_SYMBOL_FILE)
> >  endif()
> >
> > -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> > +if(LLVM_ENABLE_PIC)
> >set(ENABLE_SHARED SHARED)
> >  endif()
> >
> >
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] ad97ccf - [clangd] Move non-clang base pieces into separate support/ lib. NFCI

2020-04-29 Thread Sam McCall via cfe-commits 

Author: Sam McCall
Date: 2020-04-29T15:57:12+02:00
New Revision: ad97ccf6b26a29262c9cbf5b3e7f6e84c6dcf55f

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

LOG: [clangd] Move non-clang base pieces into separate support/ lib. NFCI

Summary:
This enforces layering, reduces a sprawling clangd/ directory, and makes life
easier for embedders.

Reviewers: kbobyrev

Subscribers: mgorny, ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, 
jfb, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Added: 
clang-tools-extra/clangd/support/CMakeLists.txt
clang-tools-extra/clangd/support/Cancellation.cpp
clang-tools-extra/clangd/support/Cancellation.h
clang-tools-extra/clangd/support/Context.cpp
clang-tools-extra/clangd/support/Context.h
clang-tools-extra/clangd/support/FSProvider.cpp
clang-tools-extra/clangd/support/FSProvider.h
clang-tools-extra/clangd/support/Function.h
clang-tools-extra/clangd/support/Logger.cpp
clang-tools-extra/clangd/support/Logger.h
clang-tools-extra/clangd/support/Path.h
clang-tools-extra/clangd/support/Shutdown.cpp
clang-tools-extra/clangd/support/Shutdown.h
clang-tools-extra/clangd/support/Threading.cpp
clang-tools-extra/clangd/support/Threading.h
clang-tools-extra/clangd/support/Trace.cpp
clang-tools-extra/clangd/support/Trace.h
clang-tools-extra/clangd/unittests/support/CancellationTests.cpp
clang-tools-extra/clangd/unittests/support/ContextTests.cpp
clang-tools-extra/clangd/unittests/support/FunctionTests.cpp
clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
clang-tools-extra/clangd/unittests/support/TraceTests.cpp

Modified: 
clang-tools-extra/clangd/CMakeLists.txt
clang-tools-extra/clangd/ClangdLSPServer.cpp
clang-tools-extra/clangd/ClangdLSPServer.h
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/CodeComplete.h
clang-tools-extra/clangd/CompileCommands.cpp
clang-tools-extra/clangd/Compiler.cpp
clang-tools-extra/clangd/Diagnostics.cpp
clang-tools-extra/clangd/Diagnostics.h
clang-tools-extra/clangd/DraftStore.cpp
clang-tools-extra/clangd/DraftStore.h
clang-tools-extra/clangd/FS.h
clang-tools-extra/clangd/FileDistance.cpp
clang-tools-extra/clangd/FindSymbols.cpp
clang-tools-extra/clangd/FindTarget.cpp
clang-tools-extra/clangd/Format.cpp
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
clang-tools-extra/clangd/GlobalCompilationDatabase.h
clang-tools-extra/clangd/HeaderSourceSwitch.cpp
clang-tools-extra/clangd/Headers.cpp
clang-tools-extra/clangd/Headers.h
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/IncludeFixer.cpp
clang-tools-extra/clangd/JSONTransport.cpp
clang-tools-extra/clangd/ParsedAST.cpp
clang-tools-extra/clangd/ParsedAST.h
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/Preamble.h
clang-tools-extra/clangd/Protocol.cpp
clang-tools-extra/clangd/QueryDriverDatabase.cpp
clang-tools-extra/clangd/Selection.cpp
clang-tools-extra/clangd/SemanticHighlighting.cpp
clang-tools-extra/clangd/SourceCode.cpp
clang-tools-extra/clangd/SourceCode.h
clang-tools-extra/clangd/TUScheduler.cpp
clang-tools-extra/clangd/TUScheduler.h
clang-tools-extra/clangd/XRefs.cpp
clang-tools-extra/clangd/XRefs.h
clang-tools-extra/clangd/fuzzer/clangd-fuzzer.cpp
clang-tools-extra/clangd/index/Background.cpp
clang-tools-extra/clangd/index/Background.h
clang-tools-extra/clangd/index/BackgroundIndexLoader.cpp
clang-tools-extra/clangd/index/BackgroundIndexLoader.h
clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp
clang-tools-extra/clangd/index/BackgroundQueue.cpp
clang-tools-extra/clangd/index/BackgroundRebuild.cpp
clang-tools-extra/clangd/index/FileIndex.cpp
clang-tools-extra/clangd/index/FileIndex.h
clang-tools-extra/clangd/index/Index.cpp
clang-tools-extra/clangd/index/IndexAction.cpp
clang-tools-extra/clangd/index/MemIndex.cpp
clang-tools-extra/clangd/index/Merge.cpp
clang-tools-extra/clangd/index/Serialization.cpp
clang-tools-extra/clangd/index/SymbolCollector.cpp
clang-tools-extra/clangd/index/YAMLSerialization.cpp
clang-tools-extra/clangd/index/dex/Dex.cpp
clang-tools-extra/clangd/index/remote/CMakeLists.txt
clang-tools-extra/clangd/index/remote/Client.cpp
clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
cl

Re: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

2020-04-29 Thread Hans Wennborg via cfe-commits 
Your suggestion of

> if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))

sounds good to me. I don't know what the non-Windows non-PIC problem
was exactly (your commit didn't mention it), so maybe it's best if you
land that to verify it fixes the issue?

Thanks,
Hans

On Wed, Apr 29, 2020 at 3:59 PM David Zarzycki  wrote:
>
> Hans,
>
> Non-Windows non-PIC setups were working just fine until four days ago when 
> D75068 landed. I tried to narrowly unbreak non-Windows non-PIC systems but 
> apparently that broke Windows. For that, I'm sorry. That being said, 
> non-Windows systems are broken again and this breakable was foreseeable given 
> my revert. What is your plan for non-Windows systems?
>
> As a part of the post-revert discussion in D75068, cristian.adam suggested 
> that the check for WIN32 should be added back, but nobody followed through on 
> that. What is stopping us from adding Christian's proposed change? 
> Specifically:
>
> if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
>
> Dave
>
> On Wed, Apr 29, 2020, at 9:19 AM, Hans Wennborg wrote:
> > On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
> >  wrote:
> > >
> > >
> > > Author: David Zarzycki
> > > Date: 2020-04-26T07:16:42-04:00
> > > New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
> > >
> > > URL: 
> > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220
> > > DIFF: 
> > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220.diff
> > >
> > > LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC
> >
> > But it does imply building libclang.dll.
> >
> > Your change broke building libclang.dll when configured with "cmake
> > -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
> > -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on Windows, see the
> > discussion here: https://reviews.llvm.org/D74564#1884556
> >
> > I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.
> >
> > >
> > > Added:
> > >
> > >
> > > Modified:
> > > clang/tools/libclang/CMakeLists.txt
> > >
> > > Removed:
> > >
> > >
> > >
> > > 
> > > diff  --git a/clang/tools/libclang/CMakeLists.txt 
> > > b/clang/tools/libclang/CMakeLists.txt
> > > index bb2b14cc8e27..9368501592a9 100644
> > > --- a/clang/tools/libclang/CMakeLists.txt
> > > +++ b/clang/tools/libclang/CMakeLists.txt
> > > @@ -77,7 +77,7 @@ if(MSVC)
> > >set(LLVM_EXPORTED_SYMBOL_FILE)
> > >  endif()
> > >
> > > -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> > > +if(LLVM_ENABLE_PIC)
> > >set(ENABLE_SHARED SHARED)
> > >  endif()
> > >
> > >
> > >
> > >
> > > ___
> > > cfe-commits mailing list
> > > cfe-commits@lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73951: [Clang] [Driver]Add logic to search for flang frontend

2020-04-29 Thread Andrzej Warzynski via Phabricator via cfe-commits 
awarzynski added a comment.

The suggested flag, `-fortran-fe`, feels quite powerful and I wonder whether 
it's required this early into the development of the Flang driver?

IIUC, this flag would be used to workaround the fact that currently `flang` is 
a bash script and hence can't be used when the driver is in the `flang` mode. 
`-fortran-fe` could be use to redirect the call to `flang-tmp` (the temporary 
flang driver that will eventually replace the bash script with similar name). 
Wouldn't it be less work if we just used `flang-tmp` instead of `flang` here: 
https://github.com/llvm/llvm-project/blob/42a56bf63f699a620a57c34474510d9937ebf715/clang/lib/Driver/ToolChains/Flang.cpp#L72?
 Once the driver is ready to replace the bash script, we could revert the 
change in Flang.cpp (`flang-tmp` -> `flang`).

Are there any other usecases that we should cater for at this point? Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73951



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

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Kirill Bobyrev via Phabricator via cfe-commits 
kbobyrev updated this revision to Diff 260906.
kbobyrev marked 2 inline comments as done.
kbobyrev added a comment.

Use DEPENDS instead of add_dependencies.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79085

Files:
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt


Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -4,6 +4,9 @@
   )
 add_clang_executable(clangd-index-server
   Server.cpp
+
+  DEPENDS
+  RemoteIndexProtos
   )
 target_link_libraries(clangd-index-server
   PRIVATE
Index: clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -6,4 +6,7 @@
 
   protobuf
   clangDaemon
+
+  DEPENDS
+  RemoteIndexProtos
   )
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -18,6 +18,9 @@
 protobuf
 grpc++
 clangDaemon
+
+DEPENDS
+RemoteIndexProtos
 )
 
   add_subdirectory(marshalling)


Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -4,6 +4,9 @@
   )
 add_clang_executable(clangd-index-server
   Server.cpp
+
+  DEPENDS
+  RemoteIndexProtos
   )
 target_link_libraries(clangd-index-server
   PRIVATE
Index: clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -6,4 +6,7 @@
 
   protobuf
   clangDaemon
+
+  DEPENDS
+  RemoteIndexProtos
   )
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -18,6 +18,9 @@
 protobuf
 grpc++
 clangDaemon
+
+DEPENDS
+RemoteIndexProtos
 )
 
   add_subdirectory(marshalling)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

2020-04-29 Thread Sam McCall via Phabricator via cfe-commits 
sammccall updated this revision to Diff 260905.
sammccall added a comment.

Update CMakeLists for non-default configurations, optimistically.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Cancellation.cpp
  clang-tools-extra/clangd/Cancellation.h
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/Compiler.cpp
  clang-tools-extra/clangd/Context.cpp
  clang-tools-extra/clangd/Context.h
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/Diagnostics.h
  clang-tools-extra/clangd/DraftStore.cpp
  clang-tools-extra/clangd/DraftStore.h
  clang-tools-extra/clangd/FS.h
  clang-tools-extra/clangd/FSProvider.cpp
  clang-tools-extra/clangd/FSProvider.h
  clang-tools-extra/clangd/FileDistance.cpp
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/Format.cpp
  clang-tools-extra/clangd/Function.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/HeaderSourceSwitch.cpp
  clang-tools-extra/clangd/Headers.cpp
  clang-tools-extra/clangd/Headers.h
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/IncludeFixer.cpp
  clang-tools-extra/clangd/JSONTransport.cpp
  clang-tools-extra/clangd/Logger.cpp
  clang-tools-extra/clangd/Logger.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/Path.h
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/QueryDriverDatabase.cpp
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/Shutdown.cpp
  clang-tools-extra/clangd/Shutdown.h
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/TUScheduler.h
  clang-tools-extra/clangd/Threading.cpp
  clang-tools-extra/clangd/Threading.h
  clang-tools-extra/clangd/Trace.cpp
  clang-tools-extra/clangd/Trace.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/fuzzer/clangd-fuzzer.cpp
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/Background.h
  clang-tools-extra/clangd/index/BackgroundIndexLoader.cpp
  clang-tools-extra/clangd/index/BackgroundIndexLoader.h
  clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp
  clang-tools-extra/clangd/index/BackgroundQueue.cpp
  clang-tools-extra/clangd/index/BackgroundRebuild.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/FileIndex.h
  clang-tools-extra/clangd/index/Index.cpp
  clang-tools-extra/clangd/index/IndexAction.cpp
  clang-tools-extra/clangd/index/MemIndex.cpp
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExpandAutoType.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp
  clang-tools-extra/clangd/support/CMakeLists.txt
  clang-tools-extra/clangd/support/Cancellation.cpp
  clang-tools-extra/clangd/support/Cancellation.h
  clang-tools-extra/clangd/support/Context.cpp
  clang-tools-extra/clangd/support/Context.h
  clang-tools-extra/clangd/support/FSProvider

[PATCH] D79076: [clang] [MinGW] Add the compiler rt libdirs to the search path

2020-04-29 Thread Reid Kleckner via Phabricator via cfe-commits 
rnk accepted this revision.
rnk added a comment.

lgtm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79076



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

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

2020-04-29 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/docs/UsersManual.rst:786
+
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496

MaskRay wrote:
> aganea wrote:
> > Why not just `-fproc-stat-report` in this case?
> It can save an `Option`..
I was thinking in terms of user experience, I find it a bit awkward. If you 
want stdin, you say `mytool < file`, if you want stdout you say `mytool` and 
pipe the output down the line. Is there a need to state the output when we're 
not writing to a file?

There is a precedent for this, other tools like xray have `llvm-xray account %s 
-o -`, but it's there for completness, you could just say `llvm-xray account 
%s`.



Comment at: clang/docs/UsersManual.rst:787
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496
+  ld: output=a.out, total=8000, user=8000, mem=53548

MaskRay wrote:
> aganea wrote:
> > I think it is better if the units are specified along (and 
> > locale-formatted, if possible):
> > ```
> > clang-11: output=/tmp/foo-123456.o  total=84,000 ms  user=76,000 ms  
> > mem=87,496 kb
> > ```
> Sorry, I tend to disagree with the argument for decimal separators and locale 
> differences. They make behaviors divergent and make the output difficult to 
> parse by a script. (Scripts may have to use `LANG=C clang 
> -fproc-stat-report=-` to cancel the locale effect)
In my sense, CSV or YAML are for machine parsing, TXT is for human consumption. 
A script should not parse a human-targetted output.
Maybe an option is missing here to set the format? Again xray has `-f=text` or 
`-f=csv`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78903



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

2020-04-29 Thread Sam McCall via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGad97ccf6b26a: [clangd] Move non-clang base pieces into 
separate support/ lib. NFCI (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Cancellation.cpp
  clang-tools-extra/clangd/Cancellation.h
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/Compiler.cpp
  clang-tools-extra/clangd/Context.cpp
  clang-tools-extra/clangd/Context.h
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/Diagnostics.h
  clang-tools-extra/clangd/DraftStore.cpp
  clang-tools-extra/clangd/DraftStore.h
  clang-tools-extra/clangd/FS.h
  clang-tools-extra/clangd/FSProvider.cpp
  clang-tools-extra/clangd/FSProvider.h
  clang-tools-extra/clangd/FileDistance.cpp
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/Format.cpp
  clang-tools-extra/clangd/Function.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/HeaderSourceSwitch.cpp
  clang-tools-extra/clangd/Headers.cpp
  clang-tools-extra/clangd/Headers.h
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/IncludeFixer.cpp
  clang-tools-extra/clangd/JSONTransport.cpp
  clang-tools-extra/clangd/Logger.cpp
  clang-tools-extra/clangd/Logger.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/Path.h
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/QueryDriverDatabase.cpp
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/Shutdown.cpp
  clang-tools-extra/clangd/Shutdown.h
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/TUScheduler.h
  clang-tools-extra/clangd/Threading.cpp
  clang-tools-extra/clangd/Threading.h
  clang-tools-extra/clangd/Trace.cpp
  clang-tools-extra/clangd/Trace.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/fuzzer/clangd-fuzzer.cpp
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/Background.h
  clang-tools-extra/clangd/index/BackgroundIndexLoader.cpp
  clang-tools-extra/clangd/index/BackgroundIndexLoader.h
  clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp
  clang-tools-extra/clangd/index/BackgroundQueue.cpp
  clang-tools-extra/clangd/index/BackgroundRebuild.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/FileIndex.h
  clang-tools-extra/clangd/index/Index.cpp
  clang-tools-extra/clangd/index/IndexAction.cpp
  clang-tools-extra/clangd/index/MemIndex.cpp
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/unimplemented/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/unimplemented/UnimplementedClient.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExpandAutoType.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp
  clang-tools-extra/clangd/support/CMakeLists.txt
  clang-tools-extra/clangd/support/Cancellation.cpp
  clang-tools-extra/clangd/support/Cancellation.h
  clang-tools-extra/clangd/support/Context.cpp
  clang-tools-extra/clangd/supp

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

2020-04-29 Thread Aaron Smith via Phabricator via cfe-commits 
asmith marked 6 inline comments as done.
asmith added a comment.

The is done unless there are other comments.




Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

MyDeveloperDay wrote:
> ? are you removing something?
These are changes from running the python script to regenerate the docs. 
Someone forgot to run the script. This info is no longer in the header.



Comment at: clang/docs/ClangFormatStyleOptions.rst:2062
  {
- [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber *u, 
NSNumber *v) {
+ [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
+ *u, NSNumber *v) {

MyDeveloperDay wrote:
> unrelated change
Not my change. The column is too long so looks like someone manually edited the 
file.



Comment at: clang/lib/Format/Format.cpp:1143
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowShortEnumsOnASingleLine = (Language != FormatStyle::LK_Cpp);
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;

MyDeveloperDay wrote:
> I think its ok to leave it was, just if up the unit tests
> 
> (the fact you didn't see this suggests you are not running the unit tests 
> please ensure you are)
You need to use the latest changes. The is only applied when the style is Msft 
and C++. See the GetMicrosoftStyle() method.


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

https://reviews.llvm.org/D78982



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

[clang] e00071d - Fixing typo (singed -> signed); NFC

2020-04-29 Thread Aaron Ballman via cfe-commits 

Author: Aaron Ballman
Date: 2020-04-29T10:33:21-04:00
New Revision: e00071db0854ae9030e3b80a1f82c7cd66d57930

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

LOG: Fixing typo (singed -> signed); NFC

Added: 


Modified: 
clang/lib/Parse/ParseDecl.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 864b7b12fbab..f7d8619ad667 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -2742,7 +2742,7 @@ bool Parser::ParseImplicitInt(DeclSpec &DS, CXXScopeSpec 
*SS,
 default:
   // This is probably supposed to be a type. This includes cases like:
   //   int f(itn);
-  //   struct S { unsinged : 4; };
+  //   struct S { unsigned : 4; };
   break;
 }
   }



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

Re: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

2020-04-29 Thread David Zarzycki via cfe-commits 
Okay, sounds good. For whatever it may be worth, I pasted the build failure to 
D75068 shortly after it landed with the hope that the original author(s) would 
commit a quick fix, but that didn't happen.


On Wed, Apr 29, 2020, at 10:23 AM, Hans Wennborg wrote:
> Your suggestion of
> 
> > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> 
> sounds good to me. I don't know what the non-Windows non-PIC problem
> was exactly (your commit didn't mention it), so maybe it's best if you
> land that to verify it fixes the issue?
> 
> Thanks,
> Hans
> 
> On Wed, Apr 29, 2020 at 3:59 PM David Zarzycki  wrote:
> >
> > Hans,
> >
> > Non-Windows non-PIC setups were working just fine until four days ago when 
> > D75068 landed. I tried to narrowly unbreak non-Windows non-PIC systems but 
> > apparently that broke Windows. For that, I'm sorry. That being said, 
> > non-Windows systems are broken again and this breakable was foreseeable 
> > given my revert. What is your plan for non-Windows systems?
> >
> > As a part of the post-revert discussion in D75068, cristian.adam suggested 
> > that the check for WIN32 should be added back, but nobody followed through 
> > on that. What is stopping us from adding Christian's proposed change? 
> > Specifically:
> >
> > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> >
> > Dave
> >
> > On Wed, Apr 29, 2020, at 9:19 AM, Hans Wennborg wrote:
> > > On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
> > >  wrote:
> > > >
> > > >
> > > > Author: David Zarzycki
> > > > Date: 2020-04-26T07:16:42-04:00
> > > > New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
> > > >
> > > > URL: 
> > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220
> > > > DIFF: 
> > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653a38c35f35e5d54cef220.diff
> > > >
> > > > LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply 
> > > > PIC
> > >
> > > But it does imply building libclang.dll.
> > >
> > > Your change broke building libclang.dll when configured with "cmake
> > > -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
> > > -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on Windows, see the
> > > discussion here: https://reviews.llvm.org/D74564#1884556
> > >
> > > I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.
> > >
> > > >
> > > > Added:
> > > >
> > > >
> > > > Modified:
> > > > clang/tools/libclang/CMakeLists.txt
> > > >
> > > > Removed:
> > > >
> > > >
> > > >
> > > > 
> > > > diff  --git a/clang/tools/libclang/CMakeLists.txt 
> > > > b/clang/tools/libclang/CMakeLists.txt
> > > > index bb2b14cc8e27..9368501592a9 100644
> > > > --- a/clang/tools/libclang/CMakeLists.txt
> > > > +++ b/clang/tools/libclang/CMakeLists.txt
> > > > @@ -77,7 +77,7 @@ if(MSVC)
> > > >set(LLVM_EXPORTED_SYMBOL_FILE)
> > > >  endif()
> > > >
> > > > -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> > > > +if(LLVM_ENABLE_PIC)
> > > >set(ENABLE_SHARED SHARED)
> > > >  endif()
> > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > cfe-commits mailing list
> > > > cfe-commits@lists.llvm.org
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> > >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

2020-04-29 Thread Cristian Adam via cfe-commits 
Hi, 

Thank you David for not reverting my 3rd attempt to get libclang to build 
statically on Windows.

In my defense the commit landed on a Saturday, and while I usually hack on 
weekends, but now I'm involved in moving to a new home and I wasn't able to 
reply to your message.

I'm sorry for the trouble of getting the revert and failed build. I thought I 
had everything covered this time...

Cheers
Cristian.

> -Original Message-
> From: David Zarzycki 
> Sent: Wednesday, 29 April 2020 16:37
> To: Hans Wennborg 
> Cc: Cristian Adam ; David Zarzycki via cfe-commits  comm...@lists.llvm.org>; Nico Weber 
> Subject: Re: [clang] 6654719 - [CMake] Fix logic error: NOT
> LIBCLANG_BUILD_STATIC does not imply PIC
> 
> Okay, sounds good. For whatever it may be worth, I pasted the build failure to
> D75068 shortly after it landed with the hope that the original author(s) would
> commit a quick fix, but that didn't happen.
> 
> 
> On Wed, Apr 29, 2020, at 10:23 AM, Hans Wennborg wrote:
> > Your suggestion of
> >
> > > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> >
> > sounds good to me. I don't know what the non-Windows non-PIC problem
> > was exactly (your commit didn't mention it), so maybe it's best if you
> > land that to verify it fixes the issue?
> >
> > Thanks,
> > Hans
> >
> > On Wed, Apr 29, 2020 at 3:59 PM David Zarzycki  wrote:
> > >
> > > Hans,
> > >
> > > Non-Windows non-PIC setups were working just fine until four days ago
> when D75068 landed. I tried to narrowly unbreak non-Windows non-PIC systems
> but apparently that broke Windows. For that, I'm sorry. That being said, non-
> Windows systems are broken again and this breakable was foreseeable given my
> revert. What is your plan for non-Windows systems?
> > >
> > > As a part of the post-revert discussion in D75068, cristian.adam suggested
> that the check for WIN32 should be added back, but nobody followed through
> on that. What is stopping us from adding Christian's proposed change?
> Specifically:
> > >
> > > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> > >
> > > Dave
> > >
> > > On Wed, Apr 29, 2020, at 9:19 AM, Hans Wennborg wrote:
> > > > On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
> > > >  wrote:
> > > > >
> > > > >
> > > > > Author: David Zarzycki
> > > > > Date: 2020-04-26T07:16:42-04:00
> > > > > New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
> > > > >
> > > > > URL:
> > > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653
> > > > > a38c35f35e5d54cef220
> > > > > DIFF:
> > > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653
> > > > > a38c35f35e5d54cef220.diff
> > > > >
> > > > > LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not
> > > > > imply PIC
> > > >
> > > > But it does imply building libclang.dll.
> > > >
> > > > Your change broke building libclang.dll when configured with
> > > > "cmake -GNinja -DCMAKE_BUILD_TYPE=Release
> > > > -DLLVM_ENABLE_PROJECTS=clang
> > > > -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on
> Windows, see
> > > > the discussion here: https://reviews.llvm.org/D74564#1884556
> > > >
> > > > I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.
> > > >
> > > > >
> > > > > Added:
> > > > >
> > > > >
> > > > > Modified:
> > > > > clang/tools/libclang/CMakeLists.txt
> > > > >
> > > > > Removed:
> > > > >
> > > > >
> > > > >
> > > > >
> 
> > > > >  diff  --git
> > > > > a/clang/tools/libclang/CMakeLists.txt
> > > > > b/clang/tools/libclang/CMakeLists.txt
> > > > > index bb2b14cc8e27..9368501592a9 100644
> > > > > --- a/clang/tools/libclang/CMakeLists.txt
> > > > > +++ b/clang/tools/libclang/CMakeLists.txt
> > > > > @@ -77,7 +77,7 @@ if(MSVC)
> > > > >set(LLVM_EXPORTED_SYMBOL_FILE)
> > > > >  endif()
> > > > >
> > > > > -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> > > > > +if(LLVM_ENABLE_PIC)
> > > > >set(ENABLE_SHARED SHARED)
> > > > >  endif()
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > cfe-commits mailing list
> > > > > cfe-commits@lists.llvm.org
> > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> > > >
> >
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

asmith wrote:
> MyDeveloperDay wrote:
> > ? are you removing something?
> These are changes from running the python script to regenerate the docs. 
> Someone forgot to run the script. This info is no longer in the header.
If a change isn't related to your feature, simply ignore it, but don't include 
other changes in yours. If this has truly gone then we need to handle that 
separately



Comment at: clang/lib/Format/Format.cpp:1143
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowShortEnumsOnASingleLine = (Language != FormatStyle::LK_Cpp);
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;

asmith wrote:
> MyDeveloperDay wrote:
> > I think its ok to leave it was, just if up the unit tests
> > 
> > (the fact you didn't see this suggests you are not running the unit tests 
> > please ensure you are)
> You need to use the latest changes. The is only applied when the style is 
> Msft and C++. See the GetMicrosoftStyle() method.
I don't think you should change the style based on the language here, either on 
or off, but not changing based on language because what about "ObjectiveC"?

As I added the Microsoft style to allow C# development I think its ok to set 
this to what you originally had, but fix up the tests


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

https://reviews.llvm.org/D78982



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

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Kirill Bobyrev via Phabricator via cfe-commits 
kbobyrev added a comment.

In D79085#2010025 , @sammccall wrote:

> Haha, CMake :-(


Now that I know this it kind of makes sense (I guess it's faster to just build 
everything and then link when all deps are ready), just something I didn't 
think about :)




Comment at: clang-tools-extra/clangd/index/remote/CMakeLists.txt:22
 )
+  add_dependencies(clangdRemoteIndex RemoteIndexProtos)
 

sammccall wrote:
> is this equivalent to `DEPENDS RemoteIndexProtos` in the library?
> Slightly clearer probably.
Ah, true, I had a feeling there was something like this on top of my mind, but 
forgot about `DEPENDS` :) Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79085



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

[PATCH] D73768: clang-format: [JS] document InsertTrailingCommas.

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

I'm trying to prevent this from getting deleted in D78982: [clang-format] Fix 
Microsoft style for C++ enums 

@mprobst When you added this documentation did you add it to Format.h and 
regenerate the rst text.

ClangFormatStyleOptions.rst should be generated using the 
`clang/docs/tools/dump_format_style.py`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73768



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

[PATCH] D75453: [Driver][ARM] parse version of arm/thumb architecture correctly

2020-04-29 Thread Jan Ole Hüser via Phabricator via cfe-commits 
j0le updated this revision to Diff 260912.
j0le retitled this revision from "[Driver][ARM] fix undefined behaviour when 
checking architecture version" to "[Driver][ARM] parse version of arm/thumb 
architecture correctly".
j0le edited the summary of this revision.
j0le added a comment.

Changed title and summary to not contain the phrase "undefined behaviour".
Extended the test case with a test, that passes the argument "-mcpu=cortex-m1" 
to clang, which causes the architecture part of the triple to become 
"thumbv6m". This tests the body of the if statement.


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

https://reviews.llvm.org/D75453

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/windows-thumbv7em.cpp


Index: clang/test/Driver/windows-thumbv7em.cpp
===
--- /dev/null
+++ clang/test/Driver/windows-thumbv7em.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang -target thumb-none-windows-eabi-coff -mcpu=cortex-m7 -### -c %s 
2>&1 \
+// RUN: | FileCheck %s --check-prefix CHECK-V7
+// CHECK-V7-NOT: error: the target architecture 'thumbv7em' is not supported 
by the target 'thumbv7em-none-windows-eabi'
+
+// RUN: %clang -target thumb-none-windows-eabi-coff -mcpu=cortex-m1 -### -c %s 
2>&1 \
+// RUN: | FileCheck %s --check-prefix CHECK-V6
+// CHECK-V6: error: the target architecture 'thumbv6m' is not supported by the 
target 'thumbv6m-none-windows-eabi'
+
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4090,9 +4090,10 @@
   if (Triple.isOSWindows() && (Triple.getArch() == llvm::Triple::arm ||
Triple.getArch() == llvm::Triple::thumb)) {
 unsigned Offset = Triple.getArch() == llvm::Triple::arm ? 4 : 6;
-unsigned Version;
-Triple.getArchName().substr(Offset).getAsInteger(10, Version);
-if (Version < 7)
+unsigned Version = 0;
+bool Failure =
+Triple.getArchName().substr(Offset).consumeInteger(10, Version);
+if (Failure || Version < 7)
   D.Diag(diag::err_target_unsupported_arch) << Triple.getArchName()
 << TripleStr;
   }


Index: clang/test/Driver/windows-thumbv7em.cpp
===
--- /dev/null
+++ clang/test/Driver/windows-thumbv7em.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang -target thumb-none-windows-eabi-coff -mcpu=cortex-m7 -### -c %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix CHECK-V7
+// CHECK-V7-NOT: error: the target architecture 'thumbv7em' is not supported by the target 'thumbv7em-none-windows-eabi'
+
+// RUN: %clang -target thumb-none-windows-eabi-coff -mcpu=cortex-m1 -### -c %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix CHECK-V6
+// CHECK-V6: error: the target architecture 'thumbv6m' is not supported by the target 'thumbv6m-none-windows-eabi'
+
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4090,9 +4090,10 @@
   if (Triple.isOSWindows() && (Triple.getArch() == llvm::Triple::arm ||
Triple.getArch() == llvm::Triple::thumb)) {
 unsigned Offset = Triple.getArch() == llvm::Triple::arm ? 4 : 6;
-unsigned Version;
-Triple.getArchName().substr(Offset).getAsInteger(10, Version);
-if (Version < 7)
+unsigned Version = 0;
+bool Failure =
+Triple.getArchName().substr(Offset).consumeInteger(10, Version);
+if (Failure || Version < 7)
   D.Diag(diag::err_target_unsupported_arch) << Triple.getArchName()
 << TripleStr;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

2020-04-29 Thread Yvan Roux via Phabricator via cfe-commits 
yroux updated this revision to Diff 260916.
yroux edited the summary of this revision.
yroux added a comment.

Here is a new update of the patch.

I remove the logic to disable LowOverheadLoops pass since Eli has added the 
live-ins infos inside outlined functions in D78605 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.h
  llvm/lib/Target/ARM/ARMTargetMachine.cpp
  llvm/test/CodeGen/ARM/machine-outliner-tail.ll
  llvm/test/CodeGen/ARM/machine-outliner-thunk.ll
  llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
  llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir

Index: llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
@@ -0,0 +1,76 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=arm-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @outline_cpsr_r12_ok() #0 { ret void }
+  define void @dont_outline_cpsr() #0 { ret void }
+  define void @dont_outline_r12() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   outline_cpsr_r12_ok
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: outline_cpsr_r12_ok
+  ; CHECK: bb.0:
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  ; CHECK: bb.1:
+  ; CHECK:   $r12 = MOVi 1, 14 /* CC::al */, $noreg, $noreg
+  ; CHECK:   CMPri $r12, 42, 14 /* CC::al */, $noreg, implicit-def $cpsr
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  bb.0:
+liveins: $cpsr, $r12
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.1:
+$r12 = MOVi 1, 14, $noreg, $noreg
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.2:
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_cpsr
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_cpsr
+  ; CHECK-NOT: BL @OUTLINED_FUNCTION_0
+  bb.0:
+liveins: $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.1:
+liveins: $cpsr
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_r12
+tracksRegLiveness: true
+body: |
+  bb.0:
+liveins: $r12
+; CHECK-LABEL: name: dont_outline_r12
+; CHECK-NOT: BL @OUTLINED_FUNCTION_0
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+$r2 = MOVr $r12, 14, $noreg, $noreg
+BX_RET 14, $noreg
Index: llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
@@ -0,0 +1,113 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=thumbv7-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @dont_outline_asm() #0 { ret void }
+  define void @dont_outline_lr() #0 { ret void }
+  define void @dont_outline_it() #0 { ret void }
+  define void @dont_outline_pic() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   dont_outline_asm
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_asm
+  ; CHECK: bb.0:
+  ; CHECK:   INLINEASM &"movs  r0, #42", 1
+  ; CHECK:   tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION_0
+  ; CHECK: bb.1:
+  ; CHECK:   INLINEASM &"movs  r0, #42", 1
+  ; CHECK:   tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION_0
+  bb.0:
+INLINEASM &"movs  r0, #42", 1
+$r0, dead $cpsr = tMOVi8 1, 14, $noreg
+$r1, dead $cpsr = tMOVi8 1, 14, $noreg
+$r2, dead $cpsr = tMOVi8 1, 14, $noreg
+$r3, dead $cpsr = tMOVi8 1, 14, $noreg
+tBL 14, $noreg, @z
+  bb.1:
+INLINEASM &"movs  r0, #42", 1
+$r0, dead $cpsr = tMOVi8 1, 14, $noreg
+$r1, dead $cpsr = tMOVi8 1, 14, $noreg
+$r2, dead $cpsr = tMOVi8 1, 14, $noreg
+$r3, dead $cpsr = tMOVi8 1, 14, $noreg
+tBL 14, $noreg, @z
+  bb.2:
+tBX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_lr
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_lr
+  ; CHECK-NOT: t

[clang-tools-extra] 4645ef1 - [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Kirill Bobyrev via cfe-commits 

Author: Kirill Bobyrev
Date: 2020-04-29T17:01:03+02:00
New Revision: 4645ef17ff1aa30e1890b7c8230b590ef830081b

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

LOG: [clangd] Add CMake dependencies for Protobuf-generated files

Summary:
Dependencies ensure that Protobufs are generated before all libraries
depending on the headers are **built**, not linked.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, 
usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/index/remote/CMakeLists.txt
clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
clang-tools-extra/clangd/index/remote/server/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/index/remote/CMakeLists.txt 
b/clang-tools-extra/clangd/index/remote/CMakeLists.txt
index a358aae0ef6b..81287b58afa5 100644
--- a/clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ b/clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -19,6 +19,9 @@ if (CLANGD_ENABLE_REMOTE)
 grpc++
 clangDaemon
 clangdSupport
+
+DEPENDS
+RemoteIndexProtos
 )
 
   add_subdirectory(marshalling)

diff  --git a/clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt 
b/clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
index 0e5e5133eed5..75e57edd45d9 100644
--- a/clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ b/clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -7,4 +7,7 @@ add_clang_library(clangdRemoteMarshalling
   protobuf
   clangDaemon
   clangdSupport
+
+  DEPENDS
+  RemoteIndexProtos
   )

diff  --git a/clang-tools-extra/clangd/index/remote/server/CMakeLists.txt 
b/clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
index 019b77eb98ba..b87541f98ef4 100644
--- a/clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ b/clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -4,6 +4,9 @@ set(LLVM_LINK_COMPONENTS
   )
 add_clang_executable(clangd-index-server
   Server.cpp
+
+  DEPENDS
+  RemoteIndexProtos
   )
 target_link_libraries(clangd-index-server
   PRIVATE



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

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

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

Overall the changes look good to me here. I had a small nit inline. But I 
wonder if we actually should add more code in the analyzer core to better model 
the sizes of memory regions corresponding to the VLAs.




Comment at: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp:576
ExplodedNodeSet &Dst) {
+  if (isa(*DS->decl_begin())) {
+ExplodedNodeSet DstPre;

At first, it might be confusing why do we need to handle typedefs at all. I 
think it might worth adding a comment about VLAs. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79072



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

[PATCH] D73354: clang-format: insert trailing commas into containers.

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added inline comments.



Comment at: clang/include/clang/Format/Format.h:563
+  };
+
+  TrailingCommaStyle InsertTrailingCommas;

I think we need to add some text in here to ensure it gets documented 
automatically in ClangFormatStyleOptions.rst rather than the by hand version 
done in {D73768} otherwise revisions like {D78982} will end up removing it..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73354



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

[PATCH] D79085: [clangd] Add CMake dependencies for Protobuf-generated files

2020-04-29 Thread Kirill Bobyrev via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4645ef17ff1a: [clangd] Add CMake dependencies for 
Protobuf-generated files (authored by kbobyrev).

Changed prior to commit:
  https://reviews.llvm.org/D79085?vs=260906&id=260920#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79085

Files:
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt


Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -4,6 +4,9 @@
   )
 add_clang_executable(clangd-index-server
   Server.cpp
+
+  DEPENDS
+  RemoteIndexProtos
   )
 target_link_libraries(clangd-index-server
   PRIVATE
Index: clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -7,4 +7,7 @@
   protobuf
   clangDaemon
   clangdSupport
+
+  DEPENDS
+  RemoteIndexProtos
   )
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -19,6 +19,9 @@
 grpc++
 clangDaemon
 clangdSupport
+
+DEPENDS
+RemoteIndexProtos
 )
 
   add_subdirectory(marshalling)


Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -4,6 +4,9 @@
   )
 add_clang_executable(clangd-index-server
   Server.cpp
+
+  DEPENDS
+  RemoteIndexProtos
   )
 target_link_libraries(clangd-index-server
   PRIVATE
Index: clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt
@@ -7,4 +7,7 @@
   protobuf
   clangDaemon
   clangdSupport
+
+  DEPENDS
+  RemoteIndexProtos
   )
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -19,6 +19,9 @@
 grpc++
 clangDaemon
 clangdSupport
+
+DEPENDS
+RemoteIndexProtos
 )
 
   add_subdirectory(marshalling)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

2020-04-29 Thread Yvan Roux via Phabricator via cfe-commits 
yroux updated this revision to Diff 260921.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.h
  llvm/lib/Target/ARM/ARMTargetMachine.cpp
  llvm/test/CodeGen/ARM/machine-outliner-tail.ll
  llvm/test/CodeGen/ARM/machine-outliner-thunk.ll
  llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
  llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir

Index: llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
@@ -0,0 +1,76 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=arm-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @outline_cpsr_r12_ok() #0 { ret void }
+  define void @dont_outline_cpsr() #0 { ret void }
+  define void @dont_outline_r12() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   outline_cpsr_r12_ok
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: outline_cpsr_r12_ok
+  ; CHECK: bb.0:
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  ; CHECK: bb.1:
+  ; CHECK:   $r12 = MOVi 1, 14 /* CC::al */, $noreg, $noreg
+  ; CHECK:   CMPri $r12, 42, 14 /* CC::al */, $noreg, implicit-def $cpsr
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  bb.0:
+liveins: $cpsr, $r12
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.1:
+$r12 = MOVi 1, 14, $noreg, $noreg
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.2:
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_cpsr
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_cpsr
+  ; CHECK-NOT: BL @OUTLINED_FUNCTION_0
+  bb.0:
+liveins: $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.1:
+liveins: $cpsr
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_r12
+tracksRegLiveness: true
+body: |
+  bb.0:
+liveins: $r12
+; CHECK-LABEL: name: dont_outline_r12
+; CHECK-NOT: BL @OUTLINED_FUNCTION_0
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+$r2 = MOVr $r12, 14, $noreg, $noreg
+BX_RET 14, $noreg
Index: llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
@@ -0,0 +1,113 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=thumbv7-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @dont_outline_asm() #0 { ret void }
+  define void @dont_outline_lr() #0 { ret void }
+  define void @dont_outline_it() #0 { ret void }
+  define void @dont_outline_pic() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   dont_outline_asm
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_asm
+  ; CHECK: bb.0:
+  ; CHECK:   INLINEASM &"movs  r0, #42", 1
+  ; CHECK:   tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION_0
+  ; CHECK: bb.1:
+  ; CHECK:   INLINEASM &"movs  r0, #42", 1
+  ; CHECK:   tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION_0
+  bb.0:
+INLINEASM &"movs  r0, #42", 1
+$r0, dead $cpsr = tMOVi8 1, 14, $noreg
+$r1, dead $cpsr = tMOVi8 1, 14, $noreg
+$r2, dead $cpsr = tMOVi8 1, 14, $noreg
+$r3, dead $cpsr = tMOVi8 1, 14, $noreg
+tBL 14, $noreg, @z
+  bb.1:
+INLINEASM &"movs  r0, #42", 1
+$r0, dead $cpsr = tMOVi8 1, 14, $noreg
+$r1, dead $cpsr = tMOVi8 1, 14, $noreg
+$r2, dead $cpsr = tMOVi8 1, 14, $noreg
+$r3, dead $cpsr = tMOVi8 1, 14, $noreg
+tBL 14, $noreg, @z
+  bb.2:
+tBX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_lr
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_lr
+  ; CHECK-NOT: tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION
+  bb.0:
+liveins: $lr
+$r0 = tMOVr $lr, 14, $noreg
+$r1 = tMOVr $lr, 14, $noreg
+$r2 = tMOVr $lr, 14, $noreg
+$r3 = tMOVr $lr, 14, $noreg
+tBL 14, $noreg, @z
+  bb.1:
+liveins: $lr
+$r0 =

Re: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

2020-04-29 Thread David Zarzycki via cfe-commits 
Hi Cristian,

That's alright. No worries. Good luck with the move (especially during the 
pandemic). My three stage test of LLVM+clang+lld+libcxx+libcxxabi is almost 
done, and I'll commit your suggested fix soon.

Dave

On Wed, Apr 29, 2020, at 10:53 AM, Cristian Adam wrote:
> Hi, 
> 
> Thank you David for not reverting my 3rd attempt to get libclang to 
> build statically on Windows.
> 
> In my defense the commit landed on a Saturday, and while I usually hack 
> on weekends, but now I'm involved in moving to a new home and I wasn't 
> able to reply to your message.
> 
> I'm sorry for the trouble of getting the revert and failed build. I 
> thought I had everything covered this time...
> 
> Cheers
> Cristian.
> 
> > -Original Message-
> > From: David Zarzycki 
> > Sent: Wednesday, 29 April 2020 16:37
> > To: Hans Wennborg 
> > Cc: Cristian Adam ; David Zarzycki via cfe-commits 
> >  > comm...@lists.llvm.org>; Nico Weber 
> > Subject: Re: [clang] 6654719 - [CMake] Fix logic error: NOT
> > LIBCLANG_BUILD_STATIC does not imply PIC
> > 
> > Okay, sounds good. For whatever it may be worth, I pasted the build failure 
> > to
> > D75068 shortly after it landed with the hope that the original author(s) 
> > would
> > commit a quick fix, but that didn't happen.
> > 
> > 
> > On Wed, Apr 29, 2020, at 10:23 AM, Hans Wennborg wrote:
> > > Your suggestion of
> > >
> > > > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> > >
> > > sounds good to me. I don't know what the non-Windows non-PIC problem
> > > was exactly (your commit didn't mention it), so maybe it's best if you
> > > land that to verify it fixes the issue?
> > >
> > > Thanks,
> > > Hans
> > >
> > > On Wed, Apr 29, 2020 at 3:59 PM David Zarzycki  wrote:
> > > >
> > > > Hans,
> > > >
> > > > Non-Windows non-PIC setups were working just fine until four days ago
> > when D75068 landed. I tried to narrowly unbreak non-Windows non-PIC systems
> > but apparently that broke Windows. For that, I'm sorry. That being said, 
> > non-
> > Windows systems are broken again and this breakable was foreseeable given my
> > revert. What is your plan for non-Windows systems?
> > > >
> > > > As a part of the post-revert discussion in D75068, cristian.adam 
> > > > suggested
> > that the check for WIN32 should be added back, but nobody followed through
> > on that. What is stopping us from adding Christian's proposed change?
> > Specifically:
> > > >
> > > > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> > > >
> > > > Dave
> > > >
> > > > On Wed, Apr 29, 2020, at 9:19 AM, Hans Wennborg wrote:
> > > > > On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
> > > > >  wrote:
> > > > > >
> > > > > >
> > > > > > Author: David Zarzycki
> > > > > > Date: 2020-04-26T07:16:42-04:00
> > > > > > New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
> > > > > >
> > > > > > URL:
> > > > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653
> > > > > > a38c35f35e5d54cef220
> > > > > > DIFF:
> > > > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653
> > > > > > a38c35f35e5d54cef220.diff
> > > > > >
> > > > > > LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not
> > > > > > imply PIC
> > > > >
> > > > > But it does imply building libclang.dll.
> > > > >
> > > > > Your change broke building libclang.dll when configured with
> > > > > "cmake -GNinja -DCMAKE_BUILD_TYPE=Release
> > > > > -DLLVM_ENABLE_PROJECTS=clang
> > > > > -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on
> > Windows, see
> > > > > the discussion here: https://reviews.llvm.org/D74564#1884556
> > > > >
> > > > > I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.
> > > > >
> > > > > >
> > > > > > Added:
> > > > > >
> > > > > >
> > > > > > Modified:
> > > > > > clang/tools/libclang/CMakeLists.txt
> > > > > >
> > > > > > Removed:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > 
> > > > > >  diff  --git
> > > > > > a/clang/tools/libclang/CMakeLists.txt
> > > > > > b/clang/tools/libclang/CMakeLists.txt
> > > > > > index bb2b14cc8e27..9368501592a9 100644
> > > > > > --- a/clang/tools/libclang/CMakeLists.txt
> > > > > > +++ b/clang/tools/libclang/CMakeLists.txt
> > > > > > @@ -77,7 +77,7 @@ if(MSVC)
> > > > > >set(LLVM_EXPORTED_SYMBOL_FILE)
> > > > > >  endif()
> > > > > >
> > > > > > -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> > > > > > +if(LLVM_ENABLE_PIC)
> > > > > >set(ENABLE_SHARED SHARED)
> > > > > >  endif()
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ___
> > > > > > cfe-commits mailing list
> > > > > > cfe-commits@lists.llvm.org
> > > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> > > > >
> > >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo

[clang] e717e87 - [libclang] Shared libraries require PIC unless WIN32

2020-04-29 Thread David Zarzycki via cfe-commits 

Author: David Zarzycki
Date: 2020-04-29T11:25:45-04:00
New Revision: e717e8744d374e16603157e5135005727bf17901

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

LOG: [libclang] Shared libraries require PIC unless WIN32

Added: 


Modified: 
clang/tools/libclang/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/libclang/CMakeLists.txt 
b/clang/tools/libclang/CMakeLists.txt
index bb2b14cc8e27..f56771b8a594 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -77,7 +77,7 @@ if(MSVC)
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
+if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
   set(ENABLE_SHARED SHARED)
 endif()
 



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

[PATCH] D79094: [SemaObjC] Warn on visibility attributes on an @implementation

2020-04-29 Thread Erik Pilkington via Phabricator via cfe-commits 
erik.pilkington created this revision.
erik.pilkington added reviewers: rjmccall, aaron.ballman.
Herald added subscribers: ributzka, dexonsmith, jkorous.

D60542  added support for attributes on 
`@implementation`s, but CodeGen always looks for visibility attributes on the 
`@interface`, so these attributes just end up getting ignored. I think we could 
support them on implementations, but it seems like information that should 
really belong in the header. This patch explicitly ignores them with a warning.

rdar://60045616


https://reviews.llvm.org/D79094

Files:
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Parser/attributes.mm


Index: clang/test/Parser/attributes.mm
===
--- clang/test/Parser/attributes.mm
+++ clang/test/Parser/attributes.mm
@@ -15,9 +15,11 @@
 
 @interface EXP I @end // expected-error {{postfix attributes are not allowed 
on Objective-C directives, place them in front of '@interface'}}
 EXP @interface I2 @end
+EXP @interface I2 (Cat) @end
 
 @implementation EXP I @end // expected-error-re {{postfix attributes are not 
allowed on Objective-C directives{{$
-EXP @implementation I2 @end
+EXP @implementation I2 @end // expected-warning{{attribute ignored}}
+EXP @implementation I2 (Cat) @end // expected-warning{{attribute ignored}}
 
 @class EXP OC; // expected-error-re {{postfix attributes are not allowed on 
Objective-C directives{{$
 EXP @class OC2; // expected-error {{prefix attribute must be followed by an 
interface, protocol, or implementation}}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2570,8 +2570,9 @@
 
 static void handleVisibilityAttr(Sema &S, Decl *D, const ParsedAttr &AL,
  bool isTypeVisibility) {
-  // Visibility attributes don't mean anything on a typedef.
-  if (isa(D)) {
+  // Visibility attributes don't mean anything on a typedef, and aren't
+  // permitted on an @implementation.
+  if (isa(D) || isa(D)) {
 S.Diag(AL.getRange().getBegin(), diag::warn_attribute_ignored) << AL;
 return;
   }


Index: clang/test/Parser/attributes.mm
===
--- clang/test/Parser/attributes.mm
+++ clang/test/Parser/attributes.mm
@@ -15,9 +15,11 @@
 
 @interface EXP I @end // expected-error {{postfix attributes are not allowed on Objective-C directives, place them in front of '@interface'}}
 EXP @interface I2 @end
+EXP @interface I2 (Cat) @end
 
 @implementation EXP I @end // expected-error-re {{postfix attributes are not allowed on Objective-C directives{{$
-EXP @implementation I2 @end
+EXP @implementation I2 @end // expected-warning{{attribute ignored}}
+EXP @implementation I2 (Cat) @end // expected-warning{{attribute ignored}}
 
 @class EXP OC; // expected-error-re {{postfix attributes are not allowed on Objective-C directives{{$
 EXP @class OC2; // expected-error {{prefix attribute must be followed by an interface, protocol, or implementation}}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2570,8 +2570,9 @@
 
 static void handleVisibilityAttr(Sema &S, Decl *D, const ParsedAttr &AL,
  bool isTypeVisibility) {
-  // Visibility attributes don't mean anything on a typedef.
-  if (isa(D)) {
+  // Visibility attributes don't mean anything on a typedef, and aren't
+  // permitted on an @implementation.
+  if (isa(D) || isa(D)) {
 S.Diag(AL.getRange().getBegin(), diag::warn_attribute_ignored) << AL;
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

2020-04-29 Thread Aaron Smith via Phabricator via cfe-commits 
asmith added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

MyDeveloperDay wrote:
> MyDeveloperDay wrote:
> > asmith wrote:
> > > MyDeveloperDay wrote:
> > > > ? are you removing something?
> > > These are changes from running the python script to regenerate the docs. 
> > > Someone forgot to run the script. This info is no longer in the header.
> > If a change isn't related to your feature, simply ignore it, but don't 
> > include other changes in yours. If this has truly gone then we need to 
> > handle that separately
> This is from {D73768} we may need to determine why the code was not put into 
> Format.h but that can be handled by a separate revision
This is generated by a script. I don't think it's a good idea to edit an 
automatically generated file. I can exclude the change to the RST completely 
and someone can regenerate the RST in a follow on patch.


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

https://reviews.llvm.org/D78982



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

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

see D79095: [clang-format] NFC Correct clang-format headers file so 
documentation can be once again autogenerated  
this should be handled separately.




Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

MyDeveloperDay wrote:
> asmith wrote:
> > MyDeveloperDay wrote:
> > > ? are you removing something?
> > These are changes from running the python script to regenerate the docs. 
> > Someone forgot to run the script. This info is no longer in the header.
> If a change isn't related to your feature, simply ignore it, but don't 
> include other changes in yours. If this has truly gone then we need to handle 
> that separately
This is from {D73768} we may need to determine why the code was not put into 
Format.h but that can be handled by a separate revision


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

https://reviews.llvm.org/D78982



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

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

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



Comment at: clang/docs/ClangFormatStyleOptions.rst:1752
  LngFunctionDeclaration();
 
+**InsertTrailingCommas** (``TrailingCommaStyle``)

NOTE: options are alphabetic in Format.h and so the position within the rst 
file will change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79095



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

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: mprobst, krasimir, mitchell-stellar, asmith.
MyDeveloperDay added projects: clang, clang-format.
MyDeveloperDay edited the summary of this revision.
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added inline comments.
MyDeveloperDay retitled this revision from "[clang-format] NFC Correct 
clang-format headers file so documentation can be one again autogenerated" to 
"[clang-format] NFC Correct clang-format headers file so documentation can be 
once again autogenerated".



Comment at: clang/docs/ClangFormatStyleOptions.rst:1752
  LngFunctionDeclaration();
 
+**InsertTrailingCommas** (``TrailingCommaStyle``)

NOTE: options are alphabetic in Format.h and so the position within the rst 
file will change.


`ClangFormatStyleOptions.rst` should ALWAYS be autogenerated from Format.h 
using `clang/docs/tools/dump_format_style.py` if not its liable to get removed 
leaving options undocumented.

This revision reworks the documentation for D73354: clang-format: insert 
trailing commas into containers.  D73768: 
clang-format: [JS] document InsertTrailingCommas. 
 to ensure we can continue to regenerated

Fix other minor changes that ensure the documentation remains consistent 
(Format.h obviously got re clang-formatted after the rst had been regenerated 
previously)

Generated documentation will look like

F11824218: image.png 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79095

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -561,6 +561,21 @@
 TCS_Wrapped,
   };
 
+  /// If set to ``TCS_Wrapped`` will insert trailing commas in container
+  /// literals (arrays and objects) that wrap across multiple lines.
+  /// It is currently only available for JavaScript
+  /// and disabled by default ``TCS_None``.
+  /// ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
+  /// as inserting the comma disables bin-packing.
+  /// \code
+  ///   TSC_Wrapped:
+  ///   const someArray = [
+  ///   aa,
+  ///   aa,
+  ///   aa,
+  ///   //^ inserted
+  ///   ]
+  /// \endcode
   TrailingCommaStyle InsertTrailingCommas;
 
   /// If ``false``, a function declaration's or function definition's
@@ -2133,7 +2148,7 @@
 /// appears within a line (e.g. consecutive assignments and declarations).
 UT_ForContinuationAndIndentation,
 /// Use tabs for line continuation and indentation, and spaces for
-/// alignemnt.
+/// alignment.
 UT_AlignWithSpaces,
 /// Use tabs whenever we need to fill whitespace that spans at least from
 /// one tab stop to the next one.
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -717,26 +717,6 @@
 aaa);
 }
 
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that wrap
-  across multiple lines. It is currently only available for JavaScript and
-  disabled by default (``TCS_None``).
-
-  ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments`` as
-  inserting the comma disables bin-packing.
-
-  .. code-block:: c++
-
-TSC_Wrapped:
-const someArray = [
-  aa,
-  aa,
-  aa,
-  //^ inserted
-]
-
-
 **BinPackParameters** (``bool``)
   If ``false``, a function declaration's or function definition's
   parameters will either all be on the same line or will have one line each.
@@ -1770,6 +1750,38 @@
  LngReturnType
  LngFunctionDeclaration();
 
+**InsertTrailingCommas** (``TrailingCommaStyle``)
+  If set to ``TCS_Wrapped`` will insert trailing commas in container
+  literals (arrays and objects) that wrap across multiple lines.
+  It is currently only available for JavaScript
+  and disabled by default ``TCS_None``.
+  ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
+  as inserting the comma disables bin-packing.
+
+  .. code-block:: c++
+
+TSC_Wrapped:
+const someArray = [
+aa,
+aa,
+aa,
+//^ inserted
+

[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

2020-04-29 Thread Yvan Roux via Phabricator via cfe-commits 
yroux added inline comments.



Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5606
+  // candidates.
+  auto CantGuaranteeValueAcrossCall = [&TRI](outliner::Candidate &C) {
+// If the unsafe registers in this block are all dead, then we don't need

yroux wrote:
> samparker wrote:
> > Does this code work with the DSP instructions that read/write the Q and GE 
> > flags? I have a nasty feeling that we don't model their register usage.
> Good question, I'll test that
From what I saw in my testing of DSP instructions, these flags are handled by 
CPSR usage, so this code seems good to me, do you have something else in mind ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066



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

[PATCH] D78118: [analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries

2020-04-29 Thread Gabor Marton via Phabricator via cfe-commits 
martong marked 4 inline comments as done.
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:651
+// Get the declaration of a function proto as written in the source file.
+StringRef ToString(const FunctionDecl *FD) {
+  const auto &SM = ACtx.getSourceManager();

balazske wrote:
> Maybe the `Decl::print` method can be used? I pretty-prints the declaration 
> (hopefully there is an option to print only the prototype), otherwise we can 
> get the code as written in the source-file(?) that makes comparing the output 
> more difficult. 
Yeah, thanks! I switched to use that!



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:681
+if (DisplayLoadedSummaries)
+  llvm::errs() << "Loaded summary for " << ToString(FD) << "\n";
 return;

balazske wrote:
> I would prefer to display the function prototype in a separate line (if not 
> only the name is included in the string). Or at least enclose the prototype 
> with `'` characters. Or the `Loaded summary for: ` form.
Ok I use the `Loaded summary for: ` form from now on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78118



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

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

2020-04-29 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

In D79095#2010250 , @krasimir wrote:

> Awesome! Thank you!
>  Now that we've got "clang/phabricator/lint/git" robots that leave comments 
> on patches, we may want to think about a way to have this automatically 
> enforced in the future.


Thats a great idea.. do you know who looks after those scripts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79095



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

[PATCH] D78118: [analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries

2020-04-29 Thread Gabor Marton via Phabricator via cfe-commits 
martong updated this revision to Diff 260930.
martong marked 2 inline comments as done.
martong added a comment.

- Use Decl::print and 'for: '


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78118

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/std-c-library-functions.c

Index: clang/test/Analysis/std-c-library-functions.c
===
--- clang/test/Analysis/std-c-library-functions.c
+++ clang/test/Analysis/std-c-library-functions.c
@@ -30,6 +30,35 @@
 // RUN:   -triple thumbv7-a15-linux \
 // RUN:   -verify
 
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-config apiModeling.StdCLibraryFunctions:DisplayLoadedSummaries=true \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -triple i686-unknown-linux 2>&1 | FileCheck %s
+
+//  CHECK: Loaded summary for: int isalnum(int)
+// CHECK-NEXT: Loaded summary for: int isalpha(int)
+// CHECK-NEXT: Loaded summary for: int isascii(int)
+// CHECK-NEXT: Loaded summary for: int isblank(int)
+// CHECK-NEXT: Loaded summary for: int isdigit(int)
+// CHECK-NEXT: Loaded summary for: int isgraph(int)
+// CHECK-NEXT: Loaded summary for: int islower(int)
+// CHECK-NEXT: Loaded summary for: int isprint(int)
+// CHECK-NEXT: Loaded summary for: int ispunct(int)
+// CHECK-NEXT: Loaded summary for: int isspace(int)
+// CHECK-NEXT: Loaded summary for: int isupper(int)
+// CHECK-NEXT: Loaded summary for: int isxdigit(int)
+// CHECK-NEXT: Loaded summary for: int getc(FILE *)
+// CHECK-NEXT: Loaded summary for: int fgetc(FILE *)
+// CHECK-NEXT: Loaded summary for: int getchar()
+// CHECK-NEXT: Loaded summary for: ssize_t read(int, void *, size_t)
+// CHECK-NEXT: Loaded summary for: ssize_t write(int, const void *, size_t)
+// CHECK-NEXT: Loaded summary for: unsigned int fread(void *restrict, size_t, size_t, FILE *)
+// CHECK-NEXT: Loaded summary for: unsigned int fwrite(const void *restrict, size_t, size_t, FILE *restrict)
+// CHECK-NEXT: Loaded summary for: ssize_t getline(char **, size_t *, FILE *)
+
 void clang_analyzer_eval(int);
 
 int glob;
Index: clang/test/Analysis/analyzer-config.c
===
--- clang/test/Analysis/analyzer-config.c
+++ clang/test/Analysis/analyzer-config.c
@@ -11,6 +11,7 @@
 // CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtExec = 0x04
 // CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtRead = 0x01
 // CHECK-NEXT: alpha.security.taint.TaintPropagation:Config = ""
+// CHECK-NEXT: apiModeling.StdCLibraryFunctions:DisplayLoadedSummaries = false
 // CHECK-NEXT: apply-fixits = false
 // CHECK-NEXT: avoid-suppressing-null-argument-paths = false
 // CHECK-NEXT: c++-allocator-inlining = true
@@ -106,4 +107,4 @@
 // CHECK-NEXT: unroll-loops = false
 // CHECK-NEXT: widen-loops = false
 // CHECK-NEXT: [stats]
-// CHECK-NEXT: num-entries = 103
+// CHECK-NEXT: num-entries = 104
Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -300,6 +300,8 @@
   DefaultBool ChecksEnabled[CK_NumCheckKinds];
   CheckerNameRef CheckNames[CK_NumCheckKinds];
 
+  bool DisplayLoadedSummaries = false;
+
 private:
   Optional findFunctionSummary(const FunctionDecl *FD,
 CheckerContext &C) const;
@@ -639,8 +641,12 @@
   struct AddToFunctionSummaryMap {
 const ASTContext &ACtx;
 FunctionSummaryMapType ⤅
-AddToFunctionSummaryMap(const ASTContext &ACtx, FunctionSummaryMapType &FSM)
-: ACtx(ACtx), Map(FSM) {}
+bool DisplayLoadedSummaries;
+AddToFunctionSummaryMap(const ASTContext &ACtx, FunctionSummaryMapType &FSM,
+bool DisplayLoadedSummaries)
+: ACtx(ACtx), Map(FSM), DisplayLoadedSummaries(DisplayLoadedSummaries) {
+}
+
 // Add a summary to a FunctionDecl found by lookup. The lookup is performed
 // by the given Name, and in the global scope. The summary will be attached
 // to the found FunctionDecl only if the signatures match.
@@ -655,6 +661,11 @@
 auto Res = Map.insert({FD->getCanonicalDecl(), S});
 assert(Res.second && "Function already has a summary set!");
 (void)Res;
+if (DisplayLoadedSummaries) {
+  llvm::errs() << "Loaded summary for: ";
+  FD->print(llvm::errs());
+  llvm::errs() << "\n";
+}
 return;
   }
 }

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

2020-04-29 Thread Krasimir Georgiev via Phabricator via cfe-commits 
krasimir added a comment.

Awesome! Thank you!
Now that we've got "clang/phabricator/lint/git" robots that leave comments on 
patches, we may want to think about a way to have this automatically enforced 
in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79095



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

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

2020-04-29 Thread Aaron Smith via Phabricator via cfe-commits 
asmith updated this revision to Diff 260932.
asmith retitled this revision from "[clang-format] Fix Microsoft style for C++ 
enums" to "[clang-format] Fix Microsoft style for enums".
asmith edited the summary of this revision.
asmith added a comment.

Enable for C#


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

https://reviews.llvm.org/D78982

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -343,7 +343,13 @@
 }
 
 TEST_F(FormatTestCSharp, CSharpKeyWordEscaping) {
-  verifyFormat("public enum var { none, @string, bool, @enum }");
+  verifyFormat("public enum var\n"
+   "{\n"
+   "none,\n"
+   "@string,\n"
+   "bool,\n"
+   "@enum\n"
+   "}");
 }
 
 TEST_F(FormatTestCSharp, CSharpNullCoalescing) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -1298,6 +1298,20 @@
"}");
 }
 
+TEST_F(FormatTest, ShortEnums) {
+  FormatStyle Style = getLLVMStyle();
+  Style.AllowShortEnumsOnASingleLine = true;
+  verifyFormat("enum { A, B, C } ShortEnum1, ShortEnum2;", Style);
+  Style.AllowShortEnumsOnASingleLine = false;
+  verifyFormat("enum\n"
+   "{\n"
+   "  A,\n"
+   "  B,\n"
+   "  C\n"
+   "} ShortEnum1, ShortEnum2;",
+   Style);
+}
+  
 TEST_F(FormatTest, ShortCaseLabels) {
   FormatStyle Style = getLLVMStyle();
   Style.AllowShortCaseLabelsOnASingleLine = true;
@@ -12934,6 +12948,7 @@
   CHECK_PARSE_BOOL(AllowAllConstructorInitializersOnNextLine);
   CHECK_PARSE_BOOL(AllowAllParametersOfDeclarationOnNextLine);
   CHECK_PARSE_BOOL(AllowShortCaseLabelsOnASingleLine);
+  CHECK_PARSE_BOOL(AllowShortEnumsOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortLoopsOnASingleLine);
   CHECK_PARSE_BOOL(BinPackArguments);
   CHECK_PARSE_BOOL(BinPackParameters);
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -98,7 +98,7 @@
   void readTokenWithJavaScriptASI();
   void parseStructuralElement();
   bool tryToParseBracedList();
-  bool parseBracedList(bool ContinueOnSemicolons = false,
+  bool parseBracedList(bool ContinueOnSemicolons = false, bool IsEnum = false,
tok::TokenKind ClosingBraceKind = tok::r_brace);
   void parseParens();
   void parseSquare(bool LambdaIntroducer = false);
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1724,6 +1724,7 @@
 }
 
 bool UnwrappedLineParser::parseBracedList(bool ContinueOnSemicolons,
+  bool IsEnum,
   tok::TokenKind ClosingBraceKind) {
   bool HasError = false;
   
@@ -1764,6 +1765,8 @@
   }
 }
 if (FormatTok->Tok.getKind() == ClosingBraceKind) {
+  if (IsEnum && !Style.AllowShortEnumsOnASingleLine)
+addUnwrappedLine();
   nextToken();
   return !HasError;
 }
@@ -1822,6 +1825,8 @@
   break;
 case tok::comma:
   nextToken();
+  if (IsEnum && !Style.AllowShortEnumsOnASingleLine)
+addUnwrappedLine();
   break;
 default:
   nextToken();
@@ -2280,9 +2285,18 @@
 return true;
   }
 
+  if (!Style.AllowShortEnumsOnASingleLine)
+addUnwrappedLine();
   // Parse enum body.
   nextToken();
-  bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true);
+  if (!Style.AllowShortEnumsOnASingleLine) {
+addUnwrappedLine();
+Line->Level += 1;
+  }
+  bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true,
+   /*IsEnum=*/true);
+  if (!Style.AllowShortEnumsOnASingleLine)
+Line->Level -= 1;
   if (HasError) {
 if (FormatTok->is(tok::semi))
   nextToken();
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -397,6 +397,8 @@
Style.AllowAllConstructorInitializersOnNextLine);
 IO.mapOptional("AllowAllParametersOfDeclarationOnNextLine",
Style.AllowAllParametersOfDeclarationOnNextLine);
+IO.mapOptional("AllowShortE

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

2020-04-29 Thread Aaron Smith via Phabricator via cfe-commits 
asmith marked 2 inline comments as done.
asmith added inline comments.



Comment at: clang/lib/Format/Format.cpp:1143
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowShortEnumsOnASingleLine = (Language != FormatStyle::LK_Cpp);
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;

MyDeveloperDay wrote:
> asmith wrote:
> > MyDeveloperDay wrote:
> > > I think its ok to leave it was, just if up the unit tests
> > > 
> > > (the fact you didn't see this suggests you are not running the unit tests 
> > > please ensure you are)
> > You need to use the latest changes. The is only applied when the style is 
> > Msft and C++. See the GetMicrosoftStyle() method.
> I don't think you should change the style based on the language here, either 
> on or off, but not changing based on language because what about "ObjectiveC"?
> 
> As I added the Microsoft style to allow C# development I think its ok to set 
> this to what you originally had, but fix up the tests
Ive enabled this for C#. I don't see the connection between ObjectiveC and 
Microsoft Style.


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

https://reviews.llvm.org/D78982



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

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

2020-04-29 Thread Serge Pavlov via Phabricator via cfe-commits 
sepavloff marked 3 inline comments as done.
sepavloff added inline comments.



Comment at: clang/docs/UsersManual.rst:770
+   $ cat abc
+   clang-11,"/tmp/foo-123456.o",92000,84000,87536
+   ld,"a.out",900,8000,53568

aganea wrote:
> Please add a header to the output .CSV, specifying the units of measure where 
> relevant.
CSV was chosen because such file is a simple union of records. It is convenient 
if multiple processes write to it. A process locks the file, writes to it and 
unlock it.

If header is required, thing get more complicated. A process locks file, then 
moves to the end and get current position. If it is the beginning of the file, 
this process if the first writer, so it writes header. Then it writes line of 
data and unlock file.

On the other hand, CSV file is proposed for parsing by scripts. Does such 
complication really makes sense?



Comment at: clang/docs/UsersManual.rst:786
+
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496

aganea wrote:
> MaskRay wrote:
> > aganea wrote:
> > > Why not just `-fproc-stat-report` in this case?
> > It can save an `Option`..
> I was thinking in terms of user experience, I find it a bit awkward. If you 
> want stdin, you say `mytool < file`, if you want stdout you say `mytool` and 
> pipe the output down the line. Is there a need to state the output when we're 
> not writing to a file?
> 
> There is a precedent for this, other tools like xray have `llvm-xray account 
> %s -o -`, but it's there for completness, you could just say `llvm-xray 
> account %s`.
Agree, it looks awkward. I will add variant without value.



Comment at: clang/docs/UsersManual.rst:787
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496
+  ld: output=a.out, total=8000, user=8000, mem=53548

aganea wrote:
> MaskRay wrote:
> > aganea wrote:
> > > I think it is better if the units are specified along (and 
> > > locale-formatted, if possible):
> > > ```
> > > clang-11: output=/tmp/foo-123456.o  total=84,000 ms  user=76,000 ms  
> > > mem=87,496 kb
> > > ```
> > Sorry, I tend to disagree with the argument for decimal separators and 
> > locale differences. They make behaviors divergent and make the output 
> > difficult to parse by a script. (Scripts may have to use `LANG=C clang 
> > -fproc-stat-report=-` to cancel the locale effect)
> In my sense, CSV or YAML are for machine parsing, TXT is for human 
> consumption. A script should not parse a human-targetted output.
> Maybe an option is missing here to set the format? Again xray has `-f=text` 
> or `-f=csv`.
I don't think an option for output format is needed here (but it could be 
useful if we supported JSON in addition to CSV). However the proposed format 
indeed is more readable. I am going to change printing accordingly, but without 
locale specifics. For users of this feature C locale is convenient.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78903



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread Craig Topper via Phabricator via cfe-commits 
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D78785



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

[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-04-29 Thread Balogh , Ádám via Phabricator via cfe-commits 
baloghadamsoftware updated this revision to Diff 260944.
baloghadamsoftware added a comment.

Now I made some good progress, thank you @NoQ for your suggestions. Not all of 
them are implemented yet (currently the +-1 with the indices seem to be 
working, thus I will fix that part later), but now I managed to reduce failing 
tests from 340 to 19. Most of these tests are about missing notes, so the next 
task is handling the new `ParamRegion` in the bug reporter visitors. I already 
made some progress there too.


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

https://reviews.llvm.org/D77229

Files:
  clang/include/clang/StaticAnalyzer/Checkers/SValExplainer.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/Regions.def
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
  clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/InvalidatedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MismatchedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/lib/StaticAnalyzer/Core/Store.cpp
  clang/lib/StaticAnalyzer/Core/SymbolManager.cpp
  clang/test/Analysis/container-modeling.cpp
  clang/test/Analysis/explain-svals.cpp
  clang/test/Analysis/iterator-modeling.cpp
  clang/test/Analysis/temporaries.cpp

Index: clang/test/Analysis/temporaries.cpp
===
--- clang/test/Analysis/temporaries.cpp
+++ clang/test/Analysis/temporaries.cpp
@@ -890,12 +890,9 @@
 public:
   ~C() {
 glob = 1;
-// FIXME: Why is destructor not inlined in C++17
 clang_analyzer_checkInlined(true);
 #ifdef TEMPORARY_DTORS
-#if __cplusplus < 201703L
-// expected-warning@-3{{TRUE}}
-#endif
+// expected-warning@-2{{TRUE}}
 #endif
   }
 };
@@ -914,16 +911,11 @@
   // temporaries returned from functions, so we took the wrong branch.
   coin && is(get()); // no-crash
   if (coin) {
-// FIXME: Why is destructor not inlined in C++17
 clang_analyzer_eval(glob);
 #ifdef TEMPORARY_DTORS
-#if __cplusplus < 201703L
-// expected-warning@-3{{TRUE}}
-#else
-// expected-warning@-5{{UNKNOWN}}
-#endif
+// expected-warning@-2{{TRUE}}
 #else
-// expected-warning@-8{{UNKNOWN}}
+// expected-warning@-4{{UNKNOWN}}
 #endif
   } else {
 // The destructor is not called on this branch.
Index: clang/test/Analysis/iterator-modeling.cpp
===
--- clang/test/Analysis/iterator-modeling.cpp
+++ clang/test/Analysis/iterator-modeling.cpp
@@ -1862,7 +1862,7 @@
 void clang_analyzer_printState();
 
 void print_state(std::vector &V) {
-  const auto i0 = V.cbegin();
+  auto i0 = V.cbegin();
   clang_analyzer_printState();
 
 // CHECK:  "checker_messages": [
@@ -1871,7 +1871,8 @@
 // CHECK-NEXT: "i0 : Valid ; Container == SymRegion{reg_$[[#]] & V>} ; Offset == conj_$[[#]]{long, LC[[#]], S[[#]], #[[#]]}"
 // CHECK-NEXT:   ]}
 
-  const auto i1 = V.cend();
+  ++i0;
+  auto i1 = V.cend();
   clang_analyzer_printState();
   
 // CHECK:  "checker_messages": [
@@ -1879,4 +1880,6 @@
 // CHECK-NEXT: "Iterator Positions :",
 // CHECK-NEXT: "i1 : Valid ; Container == SymRegion{reg_$[[#]] & V>} ; Offset == conj_$[[#]]{long, LC[[#]], S[[#]], #[[#]]}"
 // CHECK-NEXT:   ]}
+
+  --i1;
 }
Index: clang/test/Analysis/explain-svals.cpp
===
--- clang/test/Analysis/explain-svals.cpp
+++ clang/test/Analysis/explain-svals.cpp
@@ -93,6 +93,6 @@
 } // end of anonymous namespace
 
 void test_6() {
-  clang_analyzer_explain(conjure_S()); // expected-warning-re^lazily frozen compound value of temporary object constructed at statement 'conjure_S\(\)'$
+  clang_analyzer_explain(conjure_S()); // expected-warning-re^lazily frozen compound value of parameter 0 of function 'clang_analyzer_explain\(\)'$
   clang_analyzer_explain(conjure_S().z); // expected-warning-re^value derived from \(symbol of type 'int' conjured at statement 'conjure_S\(\)'\) for field 'z' of temporary object cons

[PATCH] D78979: OpenCL: Include builtin header by default

2020-04-29 Thread Sven van Haastregt via Phabricator via cfe-commits 
svenvh added a comment.

In D78979#2007643 , @Anastasia wrote:

> > Would it not become confusing since the builtins are going to be included 
> > by default? Should we rename the flag at least? Also ideally it should be 
> > documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header
>
> ah I guess if we leave it under `-cc1 ` we will have the command line 
> interface as follows:
>
> - Driver (without `-cc1`) adds OpenCL header by default that can be 
> overridden by the flag added in this patch.
> - Frontend (with `-cc1`) doesn't add the header by default but there are two 
> flags `-fdeclare-opencl-builtins` or `-finclude-default-header` that allow to 
> include the header.


The name of `-fdeclare-opencl-builtins` becomes a bit non-intuitive, a more 
intuitive name would be something like `-fopencl-tablegen-builtins` perhaps or 
`-fopencl-fast-builtins` if we don't want to mention TableGen.  But since it is 
still an experimental option, I have no objections against postponing the 
renaming until the option has reached maturity.


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

https://reviews.llvm.org/D78979



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread John McCall via Phabricator via cfe-commits 
rjmccall added a comment.

Could you answer my question up-thread about whether ExtInt is currently 
target-limited?  If it isn't, we need to more broadly audit targets.


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

https://reviews.llvm.org/D78785



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

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

2020-04-29 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/docs/UsersManual.rst:770
+   $ cat abc
+   clang-11,"/tmp/foo-123456.o",92000,84000,87536
+   ld,"a.out",900,8000,53568

sepavloff wrote:
> aganea wrote:
> > Please add a header to the output .CSV, specifying the units of measure 
> > where relevant.
> CSV was chosen because such file is a simple union of records. It is 
> convenient if multiple processes write to it. A process locks the file, 
> writes to it and unlock it.
> 
> If header is required, thing get more complicated. A process locks file, then 
> moves to the end and get current position. If it is the beginning of the 
> file, this process if the first writer, so it writes header. Then it writes 
> line of data and unlock file.
> 
> On the other hand, CSV file is proposed for parsing by scripts. Does such 
> complication really makes sense?
Thanks for the explanation! Yes, it would be more complicated indeed if locking 
is required. Let's forget the header if it's not practical.

However that raises a question: is it up to the user/build system to delete the 
log file on startup? Otherwise each build would indefintely append, you 
wouldn't know where your last build started in the log? How do you address that 
currently?



Comment at: clang/docs/UsersManual.rst:787
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496
+  ld: output=a.out, total=8000, user=8000, mem=53548

sepavloff wrote:
> aganea wrote:
> > MaskRay wrote:
> > > aganea wrote:
> > > > I think it is better if the units are specified along (and 
> > > > locale-formatted, if possible):
> > > > ```
> > > > clang-11: output=/tmp/foo-123456.o  total=84,000 ms  user=76,000 ms  
> > > > mem=87,496 kb
> > > > ```
> > > Sorry, I tend to disagree with the argument for decimal separators and 
> > > locale differences. They make behaviors divergent and make the output 
> > > difficult to parse by a script. (Scripts may have to use `LANG=C clang 
> > > -fproc-stat-report=-` to cancel the locale effect)
> > In my sense, CSV or YAML are for machine parsing, TXT is for human 
> > consumption. A script should not parse a human-targetted output.
> > Maybe an option is missing here to set the format? Again xray has `-f=text` 
> > or `-f=csv`.
> I don't think an option for output format is needed here (but it could be 
> useful if we supported JSON in addition to CSV). However the proposed format 
> indeed is more readable. I am going to change printing accordingly, but 
> without locale specifics. For users of this feature C locale is convenient.
Sounds good!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78903



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

[clang] a0e53de - [clang] [MinGW] Add the compiler rt libdirs to the search path

2020-04-29 Thread Martin Storsjö via cfe-commits 

Author: Martin Storsjö
Date: 2020-04-29T20:35:50+03:00
New Revision: a0e53de472c5b9538884f23eb8f47c3bc734b345

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

LOG: [clang] [MinGW] Add the compiler rt libdirs to the search path

This matches what is done for MSVC in
b8000c0ce84541c5b5535419234fb65ce77d6756. Since that commit, compiler
rt sanitizer libraries aren't linked to with absolute path on windows,
but using their basenames, requiring the libdirs to be passed to
the linker.

This fixes undefined behaviour sanitizer on MinGW after
b8000c0ce84541c5b5535419234fb65ce77d6756.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/MinGW.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/MinGW.cpp 
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 6139764e4601..ce01c8816263 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@ void tools::MinGW::Linker::ConstructJob(Compilation &C, 
const JobAction &JA,
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto &LibPath : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here



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

[clang] 5a1d9c0 - Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread Erich Keane via cfe-commits 

Author: Erich Keane
Date: 2020-04-29T11:04:25-07:00
New Revision: 5a1d9c0f5ac85b486a539b1d9558205821f17b33

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

LOG: Fix x86/x86_64 calling convention for _ExtInt

After speaking with Craig Topper about some recent defects, he pointed
out that _ExtInts should be passed indirectly if larger than the largest
int register, and like ints when smaller than that.  This patch
implements that.

Note that this changed the way vaargs worked quite a bit, but they still
work.

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

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/ext-int-sanitizer.cpp
clang/test/CodeGen/ext-int.c
clang/test/CodeGenCXX/ext-int.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index 0a5fb27ba015..e77daad9668b 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -1822,6 +1822,15 @@ ABIArgInfo X86_32ABIInfo::classifyArgumentType(QualType 
Ty,
 return ABIArgInfo::getExtend(Ty);
   }
 
+  if (const auto * EIT = Ty->getAs()) {
+if (EIT->getNumBits() <= 64) {
+  if (InReg)
+return ABIArgInfo::getDirectInReg();
+  return ABIArgInfo::getDirect();
+}
+return getIndirectResult(Ty, /*ByVal=*/false, State);
+  }
+
   if (InReg)
 return ABIArgInfo::getDirectInReg();
   return ABIArgInfo::getDirect();
@@ -2785,6 +2794,15 @@ void X86_64ABIInfo::classify(QualType Ty, uint64_t 
OffsetBase,
 return;
   }
 
+  if (const auto *EITy = Ty->getAs()) {
+if (EITy->getNumBits() <= 64)
+  Current = Integer;
+else if (EITy->getNumBits() <= 128)
+  Lo = Hi = Integer;
+// Larger values need to get passed in memory.
+return;
+  }
+
   if (const ConstantArrayType *AT = getContext().getAsConstantArrayType(Ty)) {
 // Arrays are treated like structures.
 
@@ -2959,8 +2977,9 @@ ABIArgInfo 
X86_64ABIInfo::getIndirectReturnResult(QualType Ty) const {
 if (const EnumType *EnumTy = Ty->getAs())
   Ty = EnumTy->getDecl()->getIntegerType();
 
-return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
-  : ABIArgInfo::getDirect());
+if (!Ty->isExtIntType())
+  return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
+: ABIArgInfo::getDirect());
   }
 
   return getNaturalAlignIndirect(Ty);
@@ -2992,7 +3011,8 @@ ABIArgInfo X86_64ABIInfo::getIndirectResult(QualType Ty,
   // the argument in the free register. This does not seem to happen currently,
   // but this code would be much safer if we could mark the argument with
   // 'onstack'. See PR12193.
-  if (!isAggregateTypeForABI(Ty) && !IsIllegalVectorType(Ty)) {
+  if (!isAggregateTypeForABI(Ty) && !IsIllegalVectorType(Ty) &&
+  !Ty->isExtIntType()) {
 // Treat an enum type as its underlying type.
 if (const EnumType *EnumTy = Ty->getAs())
   Ty = EnumTy->getDecl()->getIntegerType();
@@ -4083,6 +4103,17 @@ ABIArgInfo WinX86_64ABIInfo::classify(QualType Ty, 
unsigned &FreeSSERegs,
 }
   }
 
+  if (Ty->isExtIntType()) {
+// MS x64 ABI requirement: "Any argument that doesn't fit in 8 bytes, or is
+// not 1, 2, 4, or 8 bytes, must be passed by reference."
+// However, non-power-of-two _ExtInts will be passed as 1,2,4 or 8 bytes
+// anyway as long is it fits in them, so we don't have to check the power 
of
+// 2.
+if (Width <= 64)
+  return ABIArgInfo::getDirect();
+return ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
+  }
+
   return ABIArgInfo::getDirect();
 }
 

diff  --git a/clang/test/CodeGen/ext-int-sanitizer.cpp 
b/clang/test/CodeGen/ext-int-sanitizer.cpp
index ddf3180e1a1b..eaaab1b56c34 100644
--- a/clang/test/CodeGen/ext-int-sanitizer.cpp
+++ b/clang/test/CodeGen/ext-int-sanitizer.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-gnu-linux 
-fsanitize=array-bounds,enum,float-cast-overflow,integer-divide-by-zero,implicit-unsigned-integer-truncation,implicit-signed-integer-truncation,implicit-integer-sign-change,unsigned-integer-overflow,signed-integer-overflow,shift-base,shift-exponent
 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s 
+// RUN: %clang_cc1 -triple x86_64-gnu-linux 
-fsanitize=array-bounds,enum,float-cast-overflow,integer-divide-by-zero,implicit-unsigned-integer-truncation,implicit-signed-integer-truncation,implicit-integer-sign-change,unsigned-integer-overflow,signed-integer-overflow,shift-base,shift-exponent
 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
 
 
 // CHECK: define void @_Z6BoundsRA10_KiU7_ExtIntILi15EEi
@@ -56,9 +56,11 @@ void UIntTruncation(unsigned _ExtInt(35) E, unsigned int i, 
unsi

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added a comment.

In D78785#2010546 , @rjmccall wrote:

> Could you answer my question up-thread about whether ExtInt is currently 
> target-limited?  If it isn't, we need to more broadly audit targets.


Yikes!  I missed that question, I'm sorry :/

We aren't limiting it, as it is supposed to be a C language feature (and in 
fact, is more useful certain on non-x86 chips!).  We likely need an audit, 
though in TargetInfo I didn't see any other 'classify' functions other than 
these 3 (X86, x86-64Win, x86-64-Linux).


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

https://reviews.llvm.org/D78785



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

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

2020-04-29 Thread Melanie Blower via Phabricator via cfe-commits 
mibintc marked an inline comment as done.
mibintc added inline comments.



Comment at: clang/include/clang/AST/Expr.h:2701
 
+  FPOptions FPFeatures;
+

mibintc wrote:
> erichkeane wrote:
> > This type already has trailing-storage type stuff.  I think in the past 
> > review @rjmccall encouraged you to put this in the fake-trailing-storage  
> > like above.
> whoops i meant that to go to the CallExprBits
Adding FPOptions to CallExprBits makes the field too large, I'm going to drop 
adding FPOptions to CallExpr, i'll add it via trailingstorage in a separate 
patch if it's needed.



Comment at: clang/lib/Parse/ParsePragma.cpp:2534
+  PP.Lex(Tok);
+  if (Tok.isNot(tok::l_paren)) {
+PP.Diag(FloatControlLoc, diag::err_expected) << tok::l_paren;

erichkeane wrote:
> Replace this with BalancedDelimiterTracker instead, it gives consistent 
> errors and are a bit easier to use.  Additionally, I think it does some 
> fixups that allow us to recover better.
> 
> I'd also suggest some refactoring with the PragmaFloatControlKind if/elses 
> below.  Perhaps handle the closing paren at the end, and do a switch-case for 
> that handling.
BalancedDelimiterTracker doesn't work here because there's no access to the 
Parser object. Rewriting it would be an extensive change and I'm doubtful about 
making this change. PragmaHandler is defined in Lex. I think there are 60 
pragma's that use the PragmaHandler. 



Comment at: clang/lib/Sema/SemaAttr.cpp:1023
+  Diag(Loc, diag::err_pragma_fenv_requires_precise);
 CurFPFeatures.setAllowFEnvAccess();
 break;

erichkeane wrote:
> Should we still be setting this even if there was an error?
> Should we still be setting this even if there was an error?
It's not harmful to set it, if there's an error diagnostic then there is no 
codegen right?





Comment at: clang/lib/Serialization/ASTReaderStmt.cpp:684
 void ASTStmtReader::VisitUnaryOperator(UnaryOperator *E) {
+  bool hasFP_Features;
   VisitExpr(E);

mibintc wrote:
> erichkeane wrote:
> > Rather than this variable, why not just ask 'E' below?
> yes i could do that. it would be a function call
i made some changes in this area, eliminating setHasStoredFPFeatures


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

[PATCH] D79106: [clangd] Move inserted include from detail -> documentation.

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

Many clients try to display all the detail inline, with poor results.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79106

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1660,8 +1660,8 @@
   EXPECT_EQ(R.insertText, "Foo::x");
   EXPECT_EQ(R.insertTextFormat, InsertTextFormat::PlainText);
   EXPECT_EQ(R.filterText, "x");
-  EXPECT_EQ(R.detail, "int\n\"foo.h\"");
-  EXPECT_EQ(R.documentation, "This is x().");
+  EXPECT_EQ(R.detail, "int");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
   EXPECT_THAT(R.additionalTextEdits, IsEmpty());
   EXPECT_EQ(R.sortText, sortText(1.0, "x"));
   EXPECT_FALSE(R.deprecated);
@@ -1683,7 +1683,8 @@
 
   C.BundleSize = 2;
   R = C.render(Opts);
-  EXPECT_EQ(R.detail, "[2 overloads]\n\"foo.h\"");
+  EXPECT_EQ(R.detail, "[2 overloads]");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
 
   C.Deprecated = true;
   R = C.render(Opts);
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1831,8 +1831,12 @@
: ReturnType;
   LSP.deprecated = Deprecated;
   if (InsertInclude)
-LSP.detail += "\n" + InsertInclude->Header;
-  LSP.documentation = Documentation;
+LSP.documentation = llvm::formatv("#include {0}", InsertInclude->Header);
+  if (!Documentation.empty()) {
+if (!LSP.documentation.empty())
+  LSP.documentation += "\n";
+LSP.documentation += Documentation;
+  }
   LSP.sortText = sortText(Score.Total, Name);
   LSP.filterText = Name;
   LSP.textEdit = {CompletionTokenRange, RequiredQualifier + Name};


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1660,8 +1660,8 @@
   EXPECT_EQ(R.insertText, "Foo::x");
   EXPECT_EQ(R.insertTextFormat, InsertTextFormat::PlainText);
   EXPECT_EQ(R.filterText, "x");
-  EXPECT_EQ(R.detail, "int\n\"foo.h\"");
-  EXPECT_EQ(R.documentation, "This is x().");
+  EXPECT_EQ(R.detail, "int");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
   EXPECT_THAT(R.additionalTextEdits, IsEmpty());
   EXPECT_EQ(R.sortText, sortText(1.0, "x"));
   EXPECT_FALSE(R.deprecated);
@@ -1683,7 +1683,8 @@
 
   C.BundleSize = 2;
   R = C.render(Opts);
-  EXPECT_EQ(R.detail, "[2 overloads]\n\"foo.h\"");
+  EXPECT_EQ(R.detail, "[2 overloads]");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
 
   C.Deprecated = true;
   R = C.render(Opts);
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1831,8 +1831,12 @@
: ReturnType;
   LSP.deprecated = Deprecated;
   if (InsertInclude)
-LSP.detail += "\n" + InsertInclude->Header;
-  LSP.documentation = Documentation;
+LSP.documentation = llvm::formatv("#include {0}", InsertInclude->Header);
+  if (!Documentation.empty()) {
+if (!LSP.documentation.empty())
+  LSP.documentation += "\n";
+LSP.documentation += Documentation;
+  }
   LSP.sortText = sortText(Score.Total, Name);
   LSP.filterText = Name;
   LSP.textEdit = {CompletionTokenRange, RequiredQualifier + Name};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78756: [SveEmitter] Add builtins for svreinterpret

2020-04-29 Thread Eli Friedman via Phabricator via cfe-commits 
efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7880
+return Builder.CreateBitCast(Val, Ty);
+  }
+

sdesmalen wrote:
> efriedma wrote:
> > I'm vaguely suspicious this might be wrong for big-endian targets.  I mean, 
> > this isn't unreasonable, but users might be surprised if svreinterpret 
> > isn't a no-op.
> For SVE the loads and stores (svld1 and svst1) are all endian safe, so no 
> special consideration needs to be taken for big endian targets.
> 
> The ACLE specifies that:
> > The svreinterpret functions simply reinterpret a vector of one type as a 
> > vector of another type, without changing any of the bits.
"bitcast" is specified to mean "reinterpret the bits like a store+load".  On 
big-endian NEON (and, I assume, SVE), that isn't a no-op.  See 
http://llvm.org/docs/BigEndianNEON.html .

I mean, if the answer here is "yes, svreinterpret is supposed to lower to a 
REV", then that's fine.  But I'd like to see some explciit acknowledgement that 
that's intentional.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78756



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

[PATCH] D79076: [clang] [MinGW] Add the compiler rt libdirs to the search path

2020-04-29 Thread Martin Storsjö via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa0e53de472c5: [clang] [MinGW] Add the compiler rt libdirs to 
the search path (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79076

Files:
  clang/lib/Driver/ToolChains/MinGW.cpp


Index: clang/lib/Driver/ToolChains/MinGW.cpp
===
--- clang/lib/Driver/ToolChains/MinGW.cpp
+++ clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto &LibPath : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here


Index: clang/lib/Driver/ToolChains/MinGW.cpp
===
--- clang/lib/Driver/ToolChains/MinGW.cpp
+++ clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto &LibPath : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread Erich Keane via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a1d9c0f5ac8: Fix x86/x86_64 calling convention for _ExtInt 
(authored by erichkeane).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/ext-int-sanitizer.cpp
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp

Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -98,7 +98,7 @@
 };
 
 void UnderlyingTypeUsage(AsEnumUnderlyingType Param) {
-  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i9 %
+  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i16 %
   // WIN: define dso_local void @"?UnderlyingTypeUsage@@YAXW4AsEnumUnderlyingType@@@Z"(i9 %
   AsEnumUnderlyingType Var;
   // CHECK: alloca i9, align 2
@@ -106,13 +106,13 @@
 }
 
 unsigned _ExtInt(33) ManglingTestRetParam(unsigned _ExtInt(33) Param) {
-// LIN: define i33 @_Z20ManglingTestRetParamU7_ExtIntILi33EEj(i33 %
+// LIN: define i64 @_Z20ManglingTestRetParamU7_ExtIntILi33EEj(i64 %
 // WIN: define dso_local i33 @"?ManglingTestRetParam@@YAU?$_UExtInt@$0CB@@__clang@@U12@@Z"(i33
   return 0;
 }
 
 _ExtInt(33) ManglingTestRetParam(_ExtInt(33) Param) {
-// LIN: define i33 @_Z20ManglingTestRetParamU7_ExtIntILi33EEi(i33 %
+// LIN: define i64 @_Z20ManglingTestRetParamU7_ExtIntILi33EEi(i64 %
 // WIN: define dso_local i33 @"?ManglingTestRetParam@@YAU?$_ExtInt@$0CB@@__clang@@U12@@Z"(i33
   return 0;
 }
@@ -155,13 +155,14 @@
 
   _ExtInt(92) A = __builtin_va_arg(args, _ExtInt(92));
   // LIN: %[[AD1:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P1:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD1]], i32 0, i32 2
-  // LIN: %[[OFA1:.+]] = load i8*, i8** %[[OFA_P1]]
-  // LIN: %[[BC1:.+]] = bitcast i8* %[[OFA1]] to i92*
-  // LIN: %[[OFANEXT1:.+]] = getelementptr i8, i8* %[[OFA1]], i32 16
-  // LIN: store i8* %[[OFANEXT1]], i8** %[[OFA_P1]]
+  // LIN: %[[OFA_P1:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD1]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P1]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[GPOFFSET]], 32
+  // LIN: br i1 %[[FITSINGP]]
+  // LIN: %[[BC1:.+]] = phi i92*
   // LIN: %[[LOAD1:.+]] = load i92, i92* %[[BC1]]
   // LIN: store i92 %[[LOAD1]], i92*
+
   // WIN: %[[CUR1:.+]] = load i8*, i8** %[[ARGS]]
   // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 16
   // WIN: store i8* %[[NEXT1]], i8** %[[ARGS]]
@@ -171,15 +172,16 @@
 
   _ExtInt(31) B = __builtin_va_arg(args, _ExtInt(31));
   // LIN: %[[AD2:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P2:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD2]], i32 0, i32 2
-  // LIN: %[[OFA2:.+]] = load i8*, i8** %[[OFA_P2]]
-  // LIN: %[[BC2:.+]] = bitcast i8* %[[OFA2]] to i31*
-  // LIN: %[[OFANEXT2:.+]] = getelementptr i8, i8* %[[OFA2]], i32 8
-  // LIN: store i8* %[[OFANEXT2]], i8** %[[OFA_P2]]
-  // LIN: %[[LOAD2:.+]] = load i31, i31* %[[BC2]]
-  // LIN: store i31 %[[LOAD2]], i31*
+  // LIN: %[[OFA_P2:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD2]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P2]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[GPOFFSET]], 40
+  // LIN: br i1 %[[FITSINGP]]
+  // LIN: %[[BC1:.+]] = phi i31*
+  // LIN: %[[LOAD1:.+]] = load i31, i31* %[[BC1]]
+  // LIN: store i31 %[[LOAD1]], i31*
+
   // WIN: %[[CUR2:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT2:.+]] = getelementptr inbounds i8, i8* %[[CUR2]], i64 8 
+  // WIN: %[[NEXT2:.+]] = getelementptr inbounds i8, i8* %[[CUR2]], i64 8
   // WIN: store i8* %[[NEXT2]], i8** %[[ARGS]]
   // WIN: %[[BC2:.+]] = bitcast i8* %[[CUR2]] to i31*
   // WIN: %[[LOADV2:.+]] = load i31, i31* %[[BC2]]
@@ -187,13 +189,14 @@
 
   _ExtInt(16) C = __builtin_va_arg(args, _ExtInt(16));
   // LIN: %[[AD3:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P3:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD3]], i32 0, i32 2
-  // LIN: %[[OFA3:.+]] = load i8*, i8** %[[OFA_P3]]
-  // LIN: %[[BC3:.+]] = bitcast i8* %[[OFA3]] to i16*
-  // LIN: %[[OFANEXT3:.+]] = getelementptr i8, i8* %[[OFA3]], i32 8
-  // LIN: store i8* %[[OFANEXT3]], i8** %[[OFA_P3]]
-  // LIN: %[[LOAD3:.+]] = load i16, i16* %[[BC3]]
-  // LIN: store i16 %[[LOAD3]], i16*
+  // LIN: %[[OFA_P3:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD3]], i32 0, i32 0
+  // LIN: %[

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread John McCall via Phabricator via cfe-commits 
rjmccall added a comment.

Every target does something similar, they just all do it in different ways 
because they're mostly written by different people.

We should restrict this feature to targets where we've adequately audited the 
ABI.  It's not a feature until the ABI work is done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D79087: [SVE][Codegen] Lower legal min & max operations

2020-04-29 Thread Eli Friedman via Phabricator via cfe-commits 
efriedma added a subscriber: huihuiz.
efriedma added inline comments.



Comment at: llvm/lib/Target/AArch64/SVEInstrFormats.td:3851
+  def : SVE_1_Op_Imm_Arith_Pred_Pat(NAME # _S)>;
+  def : SVE_1_Op_Imm_Arith_Pred_Pat(NAME # _D)>;
 }

I don't see any test for this part of the patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79087



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

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

2020-04-29 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added a comment.

2 small things, @rjmccall  and @sepavloff , anything else?




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:870
+def err_pragma_fenv_requires_precise : Error<
+  "'#pragma STDC FENV_ACCESS ON' is illegal when precise is disabled">;
 def warn_cxx_ms_struct :

The last 4 can be done via selects as well!  Save a couple more spaces before 
we have to up the diagnostic id size :) 




Comment at: clang/include/clang/Sema/Sema.h:558
 
+  // This stacks the current state of Sema.CurFPFeatures
+  PragmaStack FpPragmaStack;

erichkeane wrote:
> This comment is really oddly phrased and uses the 'stack'-noun as a verb?  
> Something like: (please feel free to wordsmith): "This stack tracks the 
> current state of Sema.CurFPFeatures."?
Just needs a period at the end.



Comment at: clang/lib/Parse/ParsePragma.cpp:2534
+  PP.Lex(Tok);
+  if (Tok.isNot(tok::l_paren)) {
+PP.Diag(FloatControlLoc, diag::err_expected) << tok::l_paren;

mibintc wrote:
> erichkeane wrote:
> > Replace this with BalancedDelimiterTracker instead, it gives consistent 
> > errors and are a bit easier to use.  Additionally, I think it does some 
> > fixups that allow us to recover better.
> > 
> > I'd also suggest some refactoring with the PragmaFloatControlKind if/elses 
> > below.  Perhaps handle the closing paren at the end, and do a switch-case 
> > for that handling.
> BalancedDelimiterTracker doesn't work here because there's no access to the 
> Parser object. Rewriting it would be an extensive change and I'm doubtful 
> about making this change. PragmaHandler is defined in Lex. I think there are 
> 60 pragma's that use the PragmaHandler. 
Thats unfortunate :/  That type does some nice fixup work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

[clang] b5a4dee - [NFC] Split ext-int calling convention tests into their own file.

2020-04-29 Thread Erich Keane via cfe-commits 

Author: Erich Keane
Date: 2020-04-29T12:20:21-07:00
New Revision: b5a4deec6a70da8a1024a2227be66f88e9276b08

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

LOG: [NFC] Split ext-int calling convention tests into their own file.

I'm currently auditing all of the calling convention implications of
_ExtInt for all platforms, so splitting them up into their own test will
make this a much easier task to organize.

Added: 
clang/test/CodeGen/ext-int-cc.c

Modified: 
clang/test/CodeGen/ext-int.c

Removed: 




diff  --git a/clang/test/CodeGen/ext-int-cc.c b/clang/test/CodeGen/ext-int-cc.c
new file mode 100644
index ..41410be65497
--- /dev/null
+++ b/clang/test/CodeGen/ext-int-cc.c
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=LIN64
+// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN64
+// RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=LIN32
+// RUN: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=WIN32
+
+// Make sure 128 and 64 bit versions are passed like integers, and that >128
+// is passed indirectly.
+void ParamPassing(_ExtInt(129) a, _ExtInt(128) b, _ExtInt(64) c) {}
+// LIN64: define void @ParamPassing(i129* byval(i129) align 8 %{{.+}}, i64 
%{{.+}}, i64 %{{.+}}, i64 %{{.+}})
+// WIN64: define dso_local void @ParamPassing(i129* %{{.+}}, i128* %{{.+}}, 
i64 %{{.+}})
+// LIN32: define void @ParamPassing(i129* %{{.+}}, i128* %{{.+}}, i64 %{{.+}})
+// WIN32: define dso_local void @ParamPassing(i129* %{{.+}}, i128* %{{.+}}, 
i64 %{{.+}})
+void ParamPassing2(_ExtInt(129) a, _ExtInt(127) b, _ExtInt(63) c) {}
+// LIN64: define void @ParamPassing2(i129* byval(i129) align 8 %{{.+}}, i64 
%{{.+}}, i64 %{{.+}}, i64 %{{.+}})
+// WIN64: define dso_local void @ParamPassing2(i129* %{{.+}}, i127* %{{.+}}, 
i63 %{{.+}})
+// LIN32: define void @ParamPassing2(i129* %{{.+}}, i127* %{{.+}}, i63 %{{.+}})
+// WIN32: define dso_local void @ParamPassing2(i129* %{{.+}}, i127* %{{.+}}, 
i63 %{{.+}})
+_ExtInt(63) ReturnPassing(){}
+// LIN64: define i64 @ReturnPassing(
+// WIN64: define dso_local i63 @ReturnPassing(
+// LIN32: define i63 @ReturnPassing(
+// WIN32: define dso_local i63 @ReturnPassing(
+_ExtInt(64) ReturnPassing2(){}
+// LIN64: define i64 @ReturnPassing2(
+// WIN64: define dso_local i64 @ReturnPassing2(
+// LIN32: define i64 @ReturnPassing2(
+// WIN32: define dso_local i64 @ReturnPassing2(
+_ExtInt(127) ReturnPassing3(){}
+// LIN64: define { i64, i64 } @ReturnPassing3(
+// WIN64: define dso_local void @ReturnPassing3(i127* noalias sret
+// LIN32: define i127 @ReturnPassing3(
+// WIN32: define dso_local i127 @ReturnPassing3(
+_ExtInt(128) ReturnPassing4(){}
+// LIN64: define { i64, i64 } @ReturnPassing4(
+// WIN64: define dso_local void @ReturnPassing4(i128* noalias sret
+// LIN32: define i128 @ReturnPassing4(
+// WIN32: define dso_local i128 @ReturnPassing4(
+_ExtInt(129) ReturnPassing5(){}
+// LIN64: define void @ReturnPassing5(i129* noalias sret
+// WIN64: define dso_local void @ReturnPassing5(i129* noalias sret
+// LIN32: define i129 @ReturnPassing5(
+// WIN32: define dso_local i129 @ReturnPassing5(

diff  --git a/clang/test/CodeGen/ext-int.c b/clang/test/CodeGen/ext-int.c
index 8f90c0db27c7..196bb810b61a 100644
--- a/clang/test/CodeGen/ext-int.c
+++ b/clang/test/CodeGen/ext-int.c
@@ -1,8 +1,7 @@
-// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,LIN64,CHECK64
-// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,WIN64,CHECK64
-// RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=CHECK,LIN32,CHECK32
-// RUNX: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,WIN32,CHECK32
-
+// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK64
+// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK64
+// RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=CHECK,LIN32
+// RUN: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=CHECK,WIN32
 
 void GenericTest(_ExtInt(3) a, unsigned _ExtInt(3) b, _ExtInt(4) c) {
   // CHECK: define {{.*}}v

[PATCH] D78979: OpenCL: Include builtin header by default

2020-04-29 Thread Anastasia Stulova via Phabricator via cfe-commits 
Anastasia added a comment.

In D78979#2007760 , @yaxunl wrote:

> In D78979#2007643 , @Anastasia wrote:
>
> > ah I guess if we leave it under `-cc1 ` we will have the command line 
> > interface as follows:
> >
> > - Driver (without `-cc1`) adds OpenCL header by default that can be 
> > overridden by the flag added in this patch.
> > - Frontend (with `-cc1`) doesn't add the header by default but there are 
> > two flags `-fdeclare-opencl-builtins` or `-finclude-default-header` that 
> > allow to include the header.
> >
> >   Is my understanding correct? We should reflect this is the User Manual.
>
>
> I think -finclude-default-header -fno-include-default-header better becomes 
> both driver and -cc1 option since users are likely to use it with driver. It 
> may also be used with other languages e.g. HIP.


If we change `-finclude-default-header` to driver option, what would it do 
since the header is added by default?

Unless as @arsenm pointed out we want to get rid of custom OpenCL options and 
just use standard ones for C/C++...


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

https://reviews.llvm.org/D78979



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

[PATCH] D78979: OpenCL: Include builtin header by default

2020-04-29 Thread Anastasia Stulova via Phabricator via cfe-commits 
Anastasia added a comment.

In D78979#2010527 , @svenvh wrote:

> In D78979#2007643 , @Anastasia wrote:
>
> > > Would it not become confusing since the builtins are going to be included 
> > > by default? Should we rename the flag at least? Also ideally it should be 
> > > documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header
> >
> > ah I guess if we leave it under `-cc1 ` we will have the command line 
> > interface as follows:
> >
> > - Driver (without `-cc1`) adds OpenCL header by default that can be 
> > overridden by the flag added in this patch.
> > - Frontend (with `-cc1`) doesn't add the header by default but there are 
> > two flags `-fdeclare-opencl-builtins` or `-finclude-default-header` that 
> > allow to include the header.
>
>
> The name of `-fdeclare-opencl-builtins` becomes a bit non-intuitive, a more 
> intuitive name would be something like `-fopencl-tablegen-builtins` perhaps 
> or `-fopencl-fast-builtins` if we don't want to mention TableGen.  But since 
> it is still an experimental option, I have no objections against postponing 
> the renaming until the option has reached maturity.


I vote for `-fopencl-fast-builtins`.


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

https://reviews.llvm.org/D78979



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

[PATCH] D74813: [RFC] Add hash of block contents to function block names

2020-04-29 Thread Alex Borcan via Phabricator via cfe-commits 
alexbdv added a comment.

@erik.pilkington would the hash-based numbering be OK for now ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

2020-04-29 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added a comment.

In D78785#2010654 , @rjmccall wrote:

> Every target does something similar, they just all do it in different ways 
> because they're mostly written by different people.
>
> We should restrict this feature to targets where we've adequately audited the 
> ABI.  It's not a feature until the ABI work is done.


I'm discovering that now :)  I'm currently trying to do said audit by going 
down the ABIInfo inheritance tree.  I believe we have at least a month until 
the next release branch date.  If you can help keep me honest here, I'll 
disable _ExtInt for any platforms I haven't done by then at the branch.

Does that seem acceptable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

2020-04-29 Thread Jinsong Ji via Phabricator via cfe-commits 
jsji added a comment.
Herald added a subscriber: wuzish.

Looks like this is causing buildbot failure when built with 
`-DBUILD_SHARED_LIBS=ON`.
http://lab.llvm.org:8011/builders/clang-ppc64le-rhel/builds/3077/steps/build%20stage%201/logs/stdio

  FAILED: lib/libclangDaemon.so.11git 
  : && /home/buildbots/clang.9.0.0/bin/clang++ -... && :
  
tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CodeComplete.cpp.o:(.toc+0x120):
 undefined reference to `pthread_create'
  clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D79113: Revert "Remove false positive in AvoidNonConstGlobalVariables."

2020-04-29 Thread Kim Viggedal via Phabricator via cfe-commits 
vingeldal created this revision.
Herald added subscribers: cfe-commits, kbarton, nemanjai.
Herald added a project: clang.
vingeldal added reviewers: aaron.ballman, lebedev.ri, JonasToth, gribozavr2.
Herald added a subscriber: wuzish.

There was concernes about a false positive in clang-tidy check
AvoidNonConstGlobalVariables after it was merged and a fix for
assumed false positive was submitted in:
https://reviews.llvm.org/D77461

There was also some discussion regarding if this was actually a
false positive or a true positive. An issue was submitted to the
C++ Core Guidelines asking for a clarification in the matter:
https://github.com/isocpp/CppCoreGuidelines/issues/1599

The answer from the C++ Core Guidelines project seems to go
against the previous assumption that this was a matter of a
false positive, so this patch is suggestion to revert the
previous fix of the assumed false positive.

This reverts commit b2d8c89ea48beb83e0392b1f00c9eafa33c09ca8 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79113

Files:
  
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
@@ -231,8 +231,7 @@
 // CHECKING AGAINST FALSE POSITIVES INSIDE FUNCTION SCOPE /
 int main() {
   for (int i = 0; i < 3; ++i) {
-static int staticNonConstLoopVariable = 42;
 int nonConstLoopVariable = 42;
-nonConstInt = nonConstLoopVariable + i + staticNonConstLoopVariable;
+nonConstInt = nonConstLoopVariable + i;
   }
 }
Index: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
+++ 
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
@@ -17,15 +17,11 @@
 namespace tidy {
 namespace cppcoreguidelines {
 
-namespace {
-AST_MATCHER(VarDecl, isLocalVarDecl) { return Node.isLocalVarDecl(); }
-} // namespace
-
 void AvoidNonConstGlobalVariablesCheck::registerMatchers(MatchFinder *Finder) {
   auto GlobalVariable = varDecl(
   hasGlobalStorage(),
   unless(anyOf(
-  isLocalVarDecl(), isConstexpr(), hasType(isConstQualified()),
+  isConstexpr(), hasType(isConstQualified()),
   hasType(referenceType(); // References can't be changed, only the
// data they reference can be changed.
 


Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
@@ -231,8 +231,7 @@
 // CHECKING AGAINST FALSE POSITIVES INSIDE FUNCTION SCOPE /
 int main() {
   for (int i = 0; i < 3; ++i) {
-static int staticNonConstLoopVariable = 42;
 int nonConstLoopVariable = 42;
-nonConstInt = nonConstLoopVariable + i + staticNonConstLoopVariable;
+nonConstInt = nonConstLoopVariable + i;
   }
 }
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
@@ -17,15 +17,11 @@
 namespace tidy {
 namespace cppcoreguidelines {
 
-namespace {
-AST_MATCHER(VarDecl, isLocalVarDecl) { return Node.isLocalVarDecl(); }
-} // namespace
-
 void AvoidNonConstGlobalVariablesCheck::registerMatchers(MatchFinder *Finder) {
   auto GlobalVariable = varDecl(
   hasGlobalStorage(),
   unless(anyOf(
-  isLocalVarDecl(), isConstexpr(), hasType(isConstQualified()),
+  isConstexpr(), hasType(isConstQualified()),
   hasType(referenceType(); // References can't be changed, only the
// data they reference can be changed.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71124: [RISCV] support clang driver to select cpu

2020-04-29 Thread Sam Elliott via Phabricator via cfe-commits 
lenary added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This is looking good.

I remember we discussed this on the LLVM call a few weeks ago - there was a 
discussion as to whether we should be prioritising `-march` or `-mcpu` - do you 
recall the outcome of that discussion?




Comment at: clang/lib/Basic/Targets/RISCV.cpp:166
+bool RISCV32TargetInfo::isValidCPUName(StringRef Name) const {
+  return llvm::RISCV::checkCPUKind(llvm::RISCV::parseCPUKind(Name), false);
+}

It would be good to have `/*Is64Bit=*/` before the boolean arguments to these 
functions.



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:501-516
-  // 3. Choose a default based on the triple
-  //
-  // We deviate from GCC's defaults here:
-  // - On `riscv{XLEN}-unknown-elf` we use the integer calling convention only.
-  // - On all other OSs we use the double floating point calling convention.
-  if (Triple.getArch() == llvm::Triple::riscv32) {
-if (Triple.getOS() == llvm::Triple::UnknownOS)

What's the justification for removing this code?



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:310
+  case llvm::Triple::riscv64:
+if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
+  return A->getValue();

Should we be doing more validation here?



Comment at: llvm/lib/Support/TargetParser.cpp:122
 
+struct CPUInfo {
+  StringLiteral Name;

I think this should be prefixed `RISCV`, or moved into the RISCV namespace if 
you can?



Comment at: llvm/lib/Support/TargetParser.cpp:259-260
+
+  if (features & FK_64BIT)
+Features.push_back("+64bit");
+

It might be worth explicitly adding `-64bit` where FK_64BIT is not set.


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

https://reviews.llvm.org/D71124



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

[clang-tools-extra] bc029fa - [clangd] Still need pthreads in clangDaemon.

2020-04-29 Thread Sam McCall via cfe-commits 

Author: Sam McCall
Date: 2020-04-29T21:41:12+02:00
New Revision: bc029fa6c5cdc28fa2087f721e5ffe27d9b24ecd

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

LOG: [clangd] Still need pthreads in clangDaemon.

Added: 


Modified: 
clang-tools-extra/clangd/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/CMakeLists.txt 
b/clang-tools-extra/clangd/CMakeLists.txt
index 146f1b33599f..b8e179855b9d 100644
--- a/clang-tools-extra/clangd/CMakeLists.txt
+++ b/clang-tools-extra/clangd/CMakeLists.txt
@@ -114,6 +114,7 @@ add_clang_library(clangDaemon
   clangToolingRefactoring
   clangToolingSyntax
   clangdSupport
+  ${LLVM_PTHREAD_LIB}
   ${ALL_CLANG_TIDY_CHECKS}
   )
 



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

[PATCH] D79117: [clang] [Darwin] Add reverse mappings for aarch64/aarch64_32 to darwin arch names

2020-04-29 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo created this revision.
mstorsjo added a reviewer: t.p.northover.
Herald added subscribers: danielkiss, kristof.beyls.
Herald added a project: clang.

These are mapped in MachO::getMachOArchName already, but were missing in 
ToolChain::getDefaultUniversalArchName.

Having these reverse mapped here fixes weird inconsistencies like -dumpmachine 
showing a target triple like "aarch64-apple-darwin", while "clang -target 
aarch64-apple-darwin" didn't use to work (ended up mapped as unknown-apple-ios).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79117

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/darwin-arm64-target.c


Index: clang/test/Driver/darwin-arm64-target.c
===
--- /dev/null
+++ clang/test/Driver/darwin-arm64-target.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target aarch64-apple-darwin %s -miphoneos-version-min=8.0 -### 
2>&1 | FileCheck %s
+
+// CHECK: "-cc1"{{.*}} "-triple" "arm64-apple-ios8.0.0"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -230,9 +230,12 @@
 StringRef ToolChain::getDefaultUniversalArchName() const {
   // In universal driver terms, the arch name accepted by -arch isn't exactly
   // the same as the ones that appear in the triple. Roughly speaking, this is
-  // an inverse of the darwin::getArchTypeForDarwinArchName() function, but the
-  // only interesting special case is powerpc.
+  // an inverse of the darwin::getArchTypeForDarwinArchName() function.
   switch (Triple.getArch()) {
+  case llvm::Triple::aarch64:
+return "arm64";
+  case llvm::Triple::aarch64_32:
+return "arm64_32";
   case llvm::Triple::ppc:
 return "ppc";
   case llvm::Triple::ppc64:


Index: clang/test/Driver/darwin-arm64-target.c
===
--- /dev/null
+++ clang/test/Driver/darwin-arm64-target.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target aarch64-apple-darwin %s -miphoneos-version-min=8.0 -### 2>&1 | FileCheck %s
+
+// CHECK: "-cc1"{{.*}} "-triple" "arm64-apple-ios8.0.0"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -230,9 +230,12 @@
 StringRef ToolChain::getDefaultUniversalArchName() const {
   // In universal driver terms, the arch name accepted by -arch isn't exactly
   // the same as the ones that appear in the triple. Roughly speaking, this is
-  // an inverse of the darwin::getArchTypeForDarwinArchName() function, but the
-  // only interesting special case is powerpc.
+  // an inverse of the darwin::getArchTypeForDarwinArchName() function.
   switch (Triple.getArch()) {
+  case llvm::Triple::aarch64:
+return "arm64";
+  case llvm::Triple::aarch64_32:
+return "arm64_32";
   case llvm::Triple::ppc:
 return "ppc";
   case llvm::Triple::ppc64:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

  1   2   >