[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

2023-11-21 Thread Evgenii Stepanov via cfe-commits

https://github.com/eugenis closed 
https://github.com/llvm/llvm-project/pull/72933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

2023-11-21 Thread Evgenii Stepanov via cfe-commits


@@ -973,11 +973,58 @@
 // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=kcfi %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UBSAN-KCFI
 // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=function -fsanitize=kcfi 
%s -### 2>&1 | FileCheck %s  --check-prefix=CHECK-UBSAN-KCFI 
--check-prefix=CHECK-UBSAN-FUNCTION
 // RUN: %clang --target=x86_64-sie-ps5 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED
+// CHECK-UBSAN-UNDEFINED: 
"-fsanitize={{((alignment|array-bounds|bool|builtin|enum|float-cast-overflow|integer-divide-by-zero|nonnull-attribute|null|pointer-overflow|return|returns-nonnull-attribute|shift-base|shift-exponent|signed-integer-overflow|unreachable|vla-bound),?){17}"}}
 
 // RUN: not %clang --target=armv6t2-eabi -mexecute-only -fsanitize=function %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-FUNCTION
 // RUN: not %clang --target=armv6t2-eabi -mexecute-only -fsanitize=kcfi %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-KCFI
-// RUN: %clang --target=armv6t2-eabi -mexecute-only -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED
+// RUN: %clang --target=armv6t2-eabi -mexecute-only -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED-VPTR
 
 // CHECK-UBSAN-KCFI-DAG: error: invalid argument '-fsanitize=kcfi' not allowed 
with {{('x86_64-sie-ps5'|'armv6t2-unknown-unknown-eabi')}}
 // CHECK-UBSAN-FUNCTION-DAG: error: invalid argument '-fsanitize=function' not 
allowed with {{('x86_64-sie-ps5'|'armv6t2-unknown-unknown-eabi')}}
-// CHECK-UBSAN-UNDEFINED: 
"-fsanitize={{((alignment|array-bounds|bool|builtin|enum|float-cast-overflow|integer-divide-by-zero|nonnull-attribute|null|pointer-overflow|return|returns-nonnull-attribute|shift-base|shift-exponent|signed-integer-overflow|unreachable|vla-bound),?){17}"}}
+// CHECK-UBSAN-UNDEFINED-VPTR: 
"-fsanitize={{((alignment|array-bounds|bool|builtin|enum|float-cast-overflow|integer-divide-by-zero|nonnull-attribute|null|pointer-overflow|return|returns-nonnull-attribute|shift-base|shift-exponent|signed-integer-overflow|unreachable|vla-bound|vptr),?){18}"}}
+
+// * BareMetal *

eugenis wrote:

done

https://github.com/llvm/llvm-project/pull/72933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

2023-11-21 Thread Evgenii Stepanov via cfe-commits


@@ -491,3 +491,26 @@ void baremetal::Linker::ConstructJob(Compilation , const 
JobAction ,
   JA, *this, ResponseFileSupport::AtFileCurCP(),
   Args.MakeArgString(TC.GetLinkerPath()), CmdArgs, Inputs, Output));
 }
+
+SanitizerMask BareMetal::getSupportedSanitizers() const {
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;

eugenis wrote:

thank you, done

https://github.com/llvm/llvm-project/pull/72933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

2023-11-21 Thread Evgenii Stepanov via cfe-commits

https://github.com/eugenis updated 
https://github.com/llvm/llvm-project/pull/72933

>From f665e96f5a941c45591281d66c69f289aa641985 Mon Sep 17 00:00:00 2001
From: Evgenii Stepanov 
Date: Mon, 20 Nov 2023 16:54:24 -0800
Subject: [PATCH 1/2] Allow multiple sanitizers on baremetal targets.

Baremetal targets tend to implement their own runtime support for
sanitizers. Clang driver gatekeeping of allowed sanitizer types is
counter productive.

This change allows anything that does not crash and burn in compilation,
and leaves any potential runtime issues for the user to figure out.
---
 clang/lib/Driver/ToolChains/BareMetal.cpp | 23 ++
 clang/lib/Driver/ToolChains/BareMetal.h   |  1 +
 clang/test/Driver/fsanitize.c | 51 ++-
 3 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/BareMetal.cpp 
b/clang/lib/Driver/ToolChains/BareMetal.cpp
index 842061c1e1488b0..9d60a2b5c27af2b 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.cpp
+++ b/clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -491,3 +491,26 @@ void baremetal::Linker::ConstructJob(Compilation , const 
JobAction ,
   JA, *this, ResponseFileSupport::AtFileCurCP(),
   Args.MakeArgString(TC.GetLinkerPath()), CmdArgs, Inputs, Output));
 }
+
+SanitizerMask BareMetal::getSupportedSanitizers() const {
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
+  const bool IsAArch64 = getTriple().getArch() == llvm::Triple::aarch64 ||
+ getTriple().getArch() == llvm::Triple::aarch64_be;
+  const bool IsRISCV64 = getTriple().getArch() == llvm::Triple::riscv64;
+  SanitizerMask Res = ToolChain::getSupportedSanitizers();
+  Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::KernelAddress;
+  Res |= SanitizerKind::PointerCompare;
+  Res |= SanitizerKind::PointerSubtract;
+  Res |= SanitizerKind::Fuzzer;
+  Res |= SanitizerKind::FuzzerNoLink;
+  Res |= SanitizerKind::Vptr;
+  Res |= SanitizerKind::SafeStack;
+  Res |= SanitizerKind::Thread;
+  Res |= SanitizerKind::Scudo;
+  if (IsX86_64 || IsAArch64 || IsRISCV64) {
+Res |= SanitizerKind::HWAddress;
+Res |= SanitizerKind::KernelHWAddress;
+  }
+  return Res;
+}
diff --git a/clang/lib/Driver/ToolChains/BareMetal.h 
b/clang/lib/Driver/ToolChains/BareMetal.h
index f602ef2be3542fb..67b5aa5998fc3da 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.h
+++ b/clang/lib/Driver/ToolChains/BareMetal.h
@@ -72,6 +72,7 @@ class LLVM_LIBRARY_VISIBILITY BareMetal : public ToolChain {
   void AddLinkRuntimeLib(const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ) const;
   std::string computeSysRoot() const override;
+  SanitizerMask getSupportedSanitizers() const override;
 
 private:
   using OrderedMultilibs =
diff --git a/clang/test/Driver/fsanitize.c b/clang/test/Driver/fsanitize.c
index 9eb800b0d9e2c7f..3cf3e3118a3a932 100644
--- a/clang/test/Driver/fsanitize.c
+++ b/clang/test/Driver/fsanitize.c
@@ -973,11 +973,58 @@
 // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=kcfi %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UBSAN-KCFI
 // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=function -fsanitize=kcfi 
%s -### 2>&1 | FileCheck %s  --check-prefix=CHECK-UBSAN-KCFI 
--check-prefix=CHECK-UBSAN-FUNCTION
 // RUN: %clang --target=x86_64-sie-ps5 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED
+// CHECK-UBSAN-UNDEFINED: 
"-fsanitize={{((alignment|array-bounds|bool|builtin|enum|float-cast-overflow|integer-divide-by-zero|nonnull-attribute|null|pointer-overflow|return|returns-nonnull-attribute|shift-base|shift-exponent|signed-integer-overflow|unreachable|vla-bound),?){17}"}}
 
 // RUN: not %clang --target=armv6t2-eabi -mexecute-only -fsanitize=function %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-FUNCTION
 // RUN: not %clang --target=armv6t2-eabi -mexecute-only -fsanitize=kcfi %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-KCFI
-// RUN: %clang --target=armv6t2-eabi -mexecute-only -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED
+// RUN: %clang --target=armv6t2-eabi -mexecute-only -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED-VPTR
 
 // CHECK-UBSAN-KCFI-DAG: error: invalid argument '-fsanitize=kcfi' not allowed 
with {{('x86_64-sie-ps5'|'armv6t2-unknown-unknown-eabi')}}
 // CHECK-UBSAN-FUNCTION-DAG: error: invalid argument '-fsanitize=function' not 
allowed with {{('x86_64-sie-ps5'|'armv6t2-unknown-unknown-eabi')}}
-// CHECK-UBSAN-UNDEFINED: 
"-fsanitize={{((alignment|array-bounds|bool|builtin|enum|float-cast-overflow|integer-divide-by-zero|nonnull-attribute|null|pointer-overflow|return|returns-nonnull-attribute|shift-base|shift-exponent|signed-integer-overflow|unreachable|vla-bound),?){17}"}}
+// CHECK-UBSAN-UNDEFINED-VPTR: 

[clang] Allow multiple sanitizers on baremetal targets. (PR #72933)

2023-11-20 Thread Evgenii Stepanov via cfe-commits

https://github.com/eugenis created 
https://github.com/llvm/llvm-project/pull/72933

Baremetal targets tend to implement their own runtime support for sanitizers. 
Clang driver gatekeeping of allowed sanitizer types is counter productive.

This change allows anything that does not crash and burn in compilation, and 
leaves any potential runtime issues for the user to figure out.

>From f665e96f5a941c45591281d66c69f289aa641985 Mon Sep 17 00:00:00 2001
From: Evgenii Stepanov 
Date: Mon, 20 Nov 2023 16:54:24 -0800
Subject: [PATCH] Allow multiple sanitizers on baremetal targets.

Baremetal targets tend to implement their own runtime support for
sanitizers. Clang driver gatekeeping of allowed sanitizer types is
counter productive.

This change allows anything that does not crash and burn in compilation,
and leaves any potential runtime issues for the user to figure out.
---
 clang/lib/Driver/ToolChains/BareMetal.cpp | 23 ++
 clang/lib/Driver/ToolChains/BareMetal.h   |  1 +
 clang/test/Driver/fsanitize.c | 51 ++-
 3 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/BareMetal.cpp 
b/clang/lib/Driver/ToolChains/BareMetal.cpp
index 842061c1e1488b0..9d60a2b5c27af2b 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.cpp
+++ b/clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -491,3 +491,26 @@ void baremetal::Linker::ConstructJob(Compilation , const 
JobAction ,
   JA, *this, ResponseFileSupport::AtFileCurCP(),
   Args.MakeArgString(TC.GetLinkerPath()), CmdArgs, Inputs, Output));
 }
+
+SanitizerMask BareMetal::getSupportedSanitizers() const {
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
+  const bool IsAArch64 = getTriple().getArch() == llvm::Triple::aarch64 ||
+ getTriple().getArch() == llvm::Triple::aarch64_be;
+  const bool IsRISCV64 = getTriple().getArch() == llvm::Triple::riscv64;
+  SanitizerMask Res = ToolChain::getSupportedSanitizers();
+  Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::KernelAddress;
+  Res |= SanitizerKind::PointerCompare;
+  Res |= SanitizerKind::PointerSubtract;
+  Res |= SanitizerKind::Fuzzer;
+  Res |= SanitizerKind::FuzzerNoLink;
+  Res |= SanitizerKind::Vptr;
+  Res |= SanitizerKind::SafeStack;
+  Res |= SanitizerKind::Thread;
+  Res |= SanitizerKind::Scudo;
+  if (IsX86_64 || IsAArch64 || IsRISCV64) {
+Res |= SanitizerKind::HWAddress;
+Res |= SanitizerKind::KernelHWAddress;
+  }
+  return Res;
+}
diff --git a/clang/lib/Driver/ToolChains/BareMetal.h 
b/clang/lib/Driver/ToolChains/BareMetal.h
index f602ef2be3542fb..67b5aa5998fc3da 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.h
+++ b/clang/lib/Driver/ToolChains/BareMetal.h
@@ -72,6 +72,7 @@ class LLVM_LIBRARY_VISIBILITY BareMetal : public ToolChain {
   void AddLinkRuntimeLib(const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ) const;
   std::string computeSysRoot() const override;
+  SanitizerMask getSupportedSanitizers() const override;
 
 private:
   using OrderedMultilibs =
diff --git a/clang/test/Driver/fsanitize.c b/clang/test/Driver/fsanitize.c
index 9eb800b0d9e2c7f..3cf3e3118a3a932 100644
--- a/clang/test/Driver/fsanitize.c
+++ b/clang/test/Driver/fsanitize.c
@@ -973,11 +973,58 @@
 // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=kcfi %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UBSAN-KCFI
 // RUN: not %clang --target=x86_64-sie-ps5 -fsanitize=function -fsanitize=kcfi 
%s -### 2>&1 | FileCheck %s  --check-prefix=CHECK-UBSAN-KCFI 
--check-prefix=CHECK-UBSAN-FUNCTION
 // RUN: %clang --target=x86_64-sie-ps5 -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED
+// CHECK-UBSAN-UNDEFINED: 
"-fsanitize={{((alignment|array-bounds|bool|builtin|enum|float-cast-overflow|integer-divide-by-zero|nonnull-attribute|null|pointer-overflow|return|returns-nonnull-attribute|shift-base|shift-exponent|signed-integer-overflow|unreachable|vla-bound),?){17}"}}
 
 // RUN: not %clang --target=armv6t2-eabi -mexecute-only -fsanitize=function %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-FUNCTION
 // RUN: not %clang --target=armv6t2-eabi -mexecute-only -fsanitize=kcfi %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-KCFI
-// RUN: %clang --target=armv6t2-eabi -mexecute-only -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED
+// RUN: %clang --target=armv6t2-eabi -mexecute-only -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UBSAN-UNDEFINED-VPTR
 
 // CHECK-UBSAN-KCFI-DAG: error: invalid argument '-fsanitize=kcfi' not allowed 
with {{('x86_64-sie-ps5'|'armv6t2-unknown-unknown-eabi')}}
 // CHECK-UBSAN-FUNCTION-DAG: error: invalid argument '-fsanitize=function' not 
allowed with {{('x86_64-sie-ps5'|'armv6t2-unknown-unknown-eabi')}}
-// CHECK-UBSAN-UNDEFINED: 

[clang] 8d3c960 - Revert "[clang][dataflow] Store DeclContext of block being analysed in Environment if available."

2022-08-10 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2022-08-10T14:22:04-07:00
New Revision: 8d3c9602959df4caadfade1f40512231f7d6bbe8

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

LOG: Revert "[clang][dataflow] Store DeclContext of block being analysed in 
Environment if available."

Use of uninitialized memory.
https://lab.llvm.org/buildbot/#/builders/74/builds/12713

This reverts commit 8a4c40bfe8e6605ffc9d866f8620618dfdde2875.

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index 1b154010bf365..fc43b6b43575f 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -347,13 +347,6 @@ class Environment {
   /// imply that `Val` is true.
   bool flowConditionImplies(BoolValue ) const;
 
-  /// Returns the `DeclContext` of the block being analysed, if any. Otherwise,
-  /// returns null.
-  const DeclContext *getDeclCtx() { return DeclCtx; }
-
-  /// Sets the `DeclContext` of the block being analysed.
-  void setDeclCtx(const DeclContext *Ctx) { DeclCtx = Ctx; }
-
   /// Returns the `ControlFlowContext` registered for `F`, if any. Otherwise,
   /// returns null.
   const ControlFlowContext *getControlFlowContext(const FunctionDecl *F) {
@@ -384,9 +377,6 @@ class Environment {
   // `DACtx` is not null and not owned by this object.
   DataflowAnalysisContext *DACtx;
 
-  // `DeclContext` of the block being analysed if provided.
-  const DeclContext *DeclCtx;
-
   // In a properly initialized `Environment`, `ReturnLoc` should only be null 
if
   // its `DeclContext` could not be cast to a `FunctionDecl`.
   StorageLocation *ReturnLoc = nullptr;

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index 16c83cad9d9e3..ff27a2a45179b 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -154,7 +154,7 @@ Environment::Environment(DataflowAnalysisContext )
 : DACtx(), FlowConditionToken(()) {}
 
 Environment::Environment(const Environment )
-: DACtx(Other.DACtx), DeclCtx(Other.DeclCtx), ReturnLoc(Other.ReturnLoc),
+: DACtx(Other.DACtx), ReturnLoc(Other.ReturnLoc),
   ThisPointeeLoc(Other.ThisPointeeLoc), DeclToLoc(Other.DeclToLoc),
   ExprToLoc(Other.ExprToLoc), LocToVal(Other.LocToVal),
   MemberLocToStruct(Other.MemberLocToStruct),
@@ -168,11 +168,9 @@ Environment ::operator=(const Environment 
) {
 }
 
 Environment::Environment(DataflowAnalysisContext ,
- const DeclContext )
+ const DeclContext )
 : Environment(DACtx) {
-  setDeclCtx();
-
-  if (const auto *FuncDecl = dyn_cast(DeclCtx)) {
+  if (const auto *FuncDecl = dyn_cast()) {
 assert(FuncDecl->getBody() != nullptr);
 initGlobalVars(*FuncDecl->getBody(), *this);
 for (const auto *ParamDecl : FuncDecl->parameters()) {
@@ -187,7 +185,7 @@ Environment::Environment(DataflowAnalysisContext ,
 ReturnLoc = (ReturnType);
   }
 
-  if (const auto *MethodDecl = dyn_cast(DeclCtx)) {
+  if (const auto *MethodDecl = dyn_cast()) {
 auto *Parent = MethodDecl->getParent();
 assert(Parent != nullptr);
 if (Parent->isLambda())
@@ -212,9 +210,6 @@ Environment Environment::pushCall(const CallExpr *Call) 
const {
 
   const auto *FuncDecl = Call->getDirectCallee();
   assert(FuncDecl != nullptr);
-
-  Env.setDeclCtx(FuncDecl);
-
   // FIXME: In order to allow the callee to reference globals, we probably need
   // to call `initGlobalVars` here in some way.
 
@@ -257,12 +252,12 @@ Environment Environment::pushCall(const CallExpr *Call) 
const {
 
 void Environment::popCall(const Environment ) {
   // We ignore `DACtx` because it's already the same in both. We don't want the
-  // callee's `DeclCtx`, `ReturnLoc` or `ThisPointeeLoc`. We don't bring back
-  // `DeclToLoc` and `ExprToLoc` because we want to be able to later analyze 
the
-  // same callee in a 
diff erent context, and `setStorageLocation` requires there
-  // to not already be a storage location assigned. Conceptually, these maps
-  // capture information from the local scope, so when popping that scope, we 
do
-  // not propagate the maps.
+  // callee's `ReturnLoc` or `ThisPointeeLoc`. We don't bring back `DeclToLoc`
+  // and `ExprToLoc` because we want to be able to later analyze the same 
callee
+  // in a 
diff erent context, and `setStorageLocation` requires there to not
+  // already be a 

[clang] 7587065 - Revert "[clang][dataflow] Analyze constructor bodies"

2022-08-10 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2022-08-10T14:21:56-07:00
New Revision: 75870650433de9e7bfbe86adc1bef2f2a23fe7a3

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

LOG: Revert "[clang][dataflow] Analyze constructor bodies"

https://lab.llvm.org/buildbot/#/builders/74/builds/12713

This reverts commit 000c8fef86abb7f056cbea2de99f21dca4b81bf8.

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/lib/Analysis/FlowSensitive/Transfer.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index 8c169005846ef..1b154010bf365 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -135,7 +135,7 @@ class Environment {
   ///
   /// Requirements:
   ///
-  ///  The callee of `Call` must be a `FunctionDecl`.
+  ///  The callee of `Call` must be a `FunctionDecl` with a body.
   ///
   ///  The body of the callee must not reference globals.
   ///
@@ -143,7 +143,6 @@ class Environment {
   ///
   ///  Each argument of `Call` must already have a `StorageLocation`.
   Environment pushCall(const CallExpr *Call) const;
-  Environment pushCall(const CXXConstructExpr *Call) const;
 
   /// Moves gathered information back into `this` from a `CalleeEnv` created 
via
   /// `pushCall`.
@@ -382,12 +381,6 @@ class Environment {
   StorageLocation (StorageLocation , SkipPast SP) const;
   const StorageLocation (const StorageLocation , SkipPast SP) const;
 
-  /// Shared implementation of `pushCall` overloads. Note that unlike
-  /// `pushCall`, this member is invoked on the environment of the callee, not
-  /// of the caller.
-  void pushCallInternal(const FunctionDecl *FuncDecl,
-ArrayRef Args);
-
   // `DACtx` is not null and not owned by this object.
   DataflowAnalysisContext *DACtx;
 

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index e4af68e53e14e..16c83cad9d9e3 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -207,68 +207,52 @@ Environment::Environment(DataflowAnalysisContext ,
 
 Environment Environment::pushCall(const CallExpr *Call) const {
   Environment Env(*this);
-
   // FIXME: Support references here.
-  Env.ReturnLoc = getStorageLocation(*Call, SkipPast::Reference);
-
-  if (const auto *MethodCall = dyn_cast(Call)) {
-if (const Expr *Arg = MethodCall->getImplicitObjectArgument()) {
-  Env.ThisPointeeLoc = getStorageLocation(*Arg, SkipPast::Reference);
-}
-  }
-
-  Env.pushCallInternal(Call->getDirectCallee(),
-   llvm::makeArrayRef(Call->getArgs(), 
Call->getNumArgs()));
+  Env.ReturnLoc = Env.getStorageLocation(*Call, SkipPast::Reference);
 
-  return Env;
-}
-
-Environment Environment::pushCall(const CXXConstructExpr *Call) const {
-  Environment Env(*this);
-
-  // FIXME: Support references here.
-  Env.ReturnLoc = getStorageLocation(*Call, SkipPast::Reference);
+  const auto *FuncDecl = Call->getDirectCallee();
+  assert(FuncDecl != nullptr);
 
-  Env.ThisPointeeLoc = Env.ReturnLoc;
-
-  Env.pushCallInternal(Call->getConstructor(),
-   llvm::makeArrayRef(Call->getArgs(), 
Call->getNumArgs()));
-
-  return Env;
-}
-
-void Environment::pushCallInternal(const FunctionDecl *FuncDecl,
-   ArrayRef Args) {
-  setDeclCtx(FuncDecl);
+  Env.setDeclCtx(FuncDecl);
 
   // FIXME: In order to allow the callee to reference globals, we probably need
   // to call `initGlobalVars` here in some way.
 
+  if (const auto *MethodCall = dyn_cast(Call)) {
+if (const Expr *Arg = MethodCall->getImplicitObjectArgument()) {
+  Env.ThisPointeeLoc = Env.getStorageLocation(*Arg, SkipPast::Reference);
+}
+  }
+
   auto ParamIt = FuncDecl->param_begin();
+  auto ArgIt = Call->arg_begin();
+  auto ArgEnd = Call->arg_end();
 
   // FIXME: Parameters don't always map to arguments 1:1; examples include
   // overloaded operators implemented as member functions, and parameter packs.
-  for (unsigned ArgIndex = 0; ArgIndex < Args.size(); ++ParamIt, ++ArgIndex) {
+  for (; ArgIt != ArgEnd; ++ParamIt, ++ArgIt) {
 assert(ParamIt != FuncDecl->param_end());
 
-const Expr *Arg = Args[ArgIndex];
-auto *ArgLoc = getStorageLocation(*Arg, SkipPast::Reference);
+const Expr *Arg = *ArgIt;
+auto *ArgLoc = Env.getStorageLocation(*Arg, SkipPast::Reference);
 

[clang] 26089d4 - Revert "[clang][dataflow] Don't crash when caller args are missing storage locations"

2022-08-10 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2022-08-10T14:21:46-07:00
New Revision: 26089d4da489dc17711213f917779e480a78ed51

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

LOG: Revert "[clang][dataflow] Don't crash when caller args are missing storage 
locations"

https://lab.llvm.org/buildbot/#/builders/74/builds/12713

This reverts commit 43b298ea1282f29d448fc0f6ca971bc5fa698355.

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index b3bc52a79a2fc..8c169005846ef 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -140,6 +140,8 @@ class Environment {
   ///  The body of the callee must not reference globals.
   ///
   ///  The arguments of `Call` must map 1:1 to the callee's parameters.
+  ///
+  ///  Each argument of `Call` must already have a `StorageLocation`.
   Environment pushCall(const CallExpr *Call) const;
   Environment pushCall(const CXXConstructExpr *Call) const;
 

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index 119ef337c6319..e4af68e53e14e 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -253,8 +253,7 @@ void Environment::pushCallInternal(const FunctionDecl 
*FuncDecl,
 
 const Expr *Arg = Args[ArgIndex];
 auto *ArgLoc = getStorageLocation(*Arg, SkipPast::Reference);
-if (ArgLoc == nullptr)
-  continue;
+assert(ArgLoc != nullptr);
 
 const VarDecl *Param = *ParamIt;
 auto  = createStorageLocation(*Param);

diff  --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index 0e33df3a38008..af06021abccfd 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -4229,27 +4229,6 @@ TEST(TransferTest, ContextSensitiveReturnArg) {
/*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
 }
 
-TEST(TransferTest, ContextSensitiveReturnInt) {
-  std::string Code = R"(
-int identity(int x) { return x; }
-
-void target() {
-  int y = identity(42);
-  // [[p]]
-}
-  )";
-  runDataflow(Code,
-  [](llvm::ArrayRef<
- std::pair>>
- Results,
- ASTContext ) {
-ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
-// This just tests that the analysis doesn't crash.
-  },
-  {/*.ApplyBuiltinTransfer=*/true,
-   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
-}
-
 TEST(TransferTest, ContextSensitiveMethodLiteral) {
   std::string Code = R"(
 class MyClass {



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


[clang] a730b6a - [NFC] clang-format one function.

2022-02-11 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2022-02-11T15:00:29-08:00
New Revision: a730b6a41ad7e57a015c4a310850b14513ecb70c

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

LOG: [NFC] clang-format one function.

fix code formatting

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

Added: 


Modified: 
clang/lib/CodeGen/CGClass.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGClass.cpp b/clang/lib/CodeGen/CGClass.cpp
index 76b90924750c..b7d6139f720c 100644
--- a/clang/lib/CodeGen/CGClass.cpp
+++ b/clang/lib/CodeGen/CGClass.cpp
@@ -1649,22 +1649,22 @@ namespace {
 }
   };
 
- static void EmitSanitizerDtorCallback(CodeGenFunction , llvm::Value *Ptr,
- CharUnits::QuantityType PoisonSize) {
-   CodeGenFunction::SanitizerScope SanScope();
-   // Pass in void pointer and size of region as arguments to runtime
-   // function
-   llvm::Value *Args[] = {CGF.Builder.CreateBitCast(Ptr, CGF.VoidPtrTy),
-  llvm::ConstantInt::get(CGF.SizeTy, PoisonSize)};
-
-   llvm::Type *ArgTypes[] = {CGF.VoidPtrTy, CGF.SizeTy};
-
-   llvm::FunctionType *FnType =
-   llvm::FunctionType::get(CGF.VoidTy, ArgTypes, false);
-   llvm::FunctionCallee Fn =
-   CGF.CGM.CreateRuntimeFunction(FnType, "__sanitizer_dtor_callback");
-   CGF.EmitNounwindRuntimeCall(Fn, Args);
- }
+  static void EmitSanitizerDtorCallback(CodeGenFunction , llvm::Value *Ptr,
+CharUnits::QuantityType PoisonSize) {
+CodeGenFunction::SanitizerScope SanScope();
+// Pass in void pointer and size of region as arguments to runtime
+// function
+llvm::Value *Args[] = {CGF.Builder.CreateBitCast(Ptr, CGF.VoidPtrTy),
+   llvm::ConstantInt::get(CGF.SizeTy, PoisonSize)};
+
+llvm::Type *ArgTypes[] = {CGF.VoidPtrTy, CGF.SizeTy};
+
+llvm::FunctionType *FnType =
+llvm::FunctionType::get(CGF.VoidTy, ArgTypes, false);
+llvm::FunctionCallee Fn =
+CGF.CGM.CreateRuntimeFunction(FnType, "__sanitizer_dtor_callback");
+CGF.EmitNounwindRuntimeCall(Fn, Args);
+  }
 
   class SanitizeDtorMembers final : public EHScopeStack::Cleanup {
 const CXXDestructorDecl *Dtor;



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


[clang] 66cf68e - [docs] Update ControlFlowIntegrity.rst.

2020-10-02 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2020-10-02T12:01:05-07:00
New Revision: 66cf68ed46789217a8382bb419a0bda1c4e97650

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

LOG: [docs] Update ControlFlowIntegrity.rst.

Expand the list of targets that support cfi-icall.
Add ThinLTO everywhere LTO is mentioned. AFAIK all CFI features are
supported with ThinLTO.

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

Added: 


Modified: 
clang/docs/ControlFlowIntegrity.rst

Removed: 




diff  --git a/clang/docs/ControlFlowIntegrity.rst 
b/clang/docs/ControlFlowIntegrity.rst
index 03e27d3ede89..3f6b3ca6cafb 100644
--- a/clang/docs/ControlFlowIntegrity.rst
+++ b/clang/docs/ControlFlowIntegrity.rst
@@ -76,8 +76,8 @@ For example, you can build your program with
 to use all schemes except for non-virtual member function call and indirect 
call
 checking.
 
-Remember that you have to provide ``-flto`` if at least one CFI scheme is
-enabled.
+Remember that you have to provide ``-flto`` or ``-flto=thin`` if at
+least one CFI scheme is enabled.
 
 Trapping and Diagnostics
 
@@ -217,7 +217,8 @@ statically linked into the program or shared library, and 
calls across
 shared library boundaries are handled as if the callee was not compiled with
 ``-fsanitize=cfi-icall``.
 
-This scheme is currently only supported on the x86 and x86_64 architectures.
+This scheme is currently supported on a limited set of targets: x86,
+x86_64, arm, arch64 and wasm.
 
 ``-fsanitize-cfi-icall-generalize-pointers``
 
@@ -368,7 +369,7 @@ Shared library support
 Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control
 flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
-built with ``-flto``.
+built with ``-flto`` or ``-flto=thin``.
 
 Normally, CFI checks will only be performed for classes that have hidden LTO
 visibility. With this flag enabled, the compiler will emit cross-DSO CFI



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


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

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

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

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

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

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

Reviewers: pcc

Subscribers: cryptoad, cfe-commits

Tags: #clang

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

Added: 


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

Removed: 




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

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



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


[clang] 2a3723e - [memtag] Plug in stack safety analysis.

2020-03-16 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2020-03-16T16:35:25-07:00
New Revision: 2a3723ef114d467179d463539dd73974b87ccf85

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

LOG: [memtag] Plug in stack safety analysis.

Summary:
Run StackSafetyAnalysis at the end of the IR pipeline and annotate
proven safe allocas with !stack-safe metadata. Do not instrument such
allocas in the AArch64StackTagging pass.

Reviewers: pcc, vitalybuka, ostannard

Reviewed By: vitalybuka

Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, gilang, 
llvm-commits

Tags: #clang, #llvm

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

Added: 
clang/test/Driver/memtag.c
llvm/test/Analysis/StackSafetyAnalysis/ipa-attr.ll

Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/Analysis/StackSafetyAnalysis.h
llvm/lib/Analysis/StackSafetyAnalysis.cpp
llvm/lib/Passes/PassRegistry.def
llvm/lib/Target/AArch64/AArch64StackTagging.cpp
llvm/test/CodeGen/AArch64/stack-tagging.ll

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index b6ca46e7e835..28e4ecc7b4bf 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -18,6 +18,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/TargetTransformInfo.h"
 #include "llvm/Bitcode/BitcodeReader.h"
@@ -345,6 +346,11 @@ static void addDataFlowSanitizerPass(const 
PassManagerBuilder ,
   PM.add(createDataFlowSanitizerPass(LangOpts.SanitizerBlacklistFiles));
 }
 
+static void addMemTagOptimizationPasses(const PassManagerBuilder ,
+legacy::PassManagerBase ) {
+  PM.add(createStackSafetyGlobalInfoWrapperPass(/*SetMetadata=*/true));
+}
+
 static TargetLibraryInfoImpl *createTLII(llvm::Triple ,
  const CodeGenOptions ) {
   TargetLibraryInfoImpl *TLII = new TargetLibraryInfoImpl(TargetTriple);
@@ -696,6 +702,11 @@ void EmitAssemblyHelper::CreatePasses(legacy::PassManager 
,
addDataFlowSanitizerPass);
   }
 
+  if (LangOpts.Sanitize.has(SanitizerKind::MemTag)) {
+PMBuilder.addExtension(PassManagerBuilder::EP_OptimizerLast,
+   addMemTagOptimizationPasses);
+  }
+
   // Set up the per-function pass manager.
   FPM.add(new TargetLibraryInfoWrapperPass(*TLII));
   if (CodeGenOpts.VerifyModule)
@@ -1300,6 +1311,11 @@ void EmitAssemblyHelper::EmitAssemblyWithNewPassManager(
   /*CompileKernel=*/true, /*Recover=*/true));
 }
 
+if (CodeGenOpts.OptimizationLevel > 0 &&
+LangOpts.Sanitize.has(SanitizerKind::MemTag)) {
+  MPM.addPass(StackSafetyGlobalAnnotatorPass());
+}
+
 if (CodeGenOpts.OptimizationLevel == 0) {
   addCoroutinePassesAtO0(MPM, LangOpts, CodeGenOpts);
   addSanitizersAtO0(MPM, TargetTriple, LangOpts, CodeGenOpts);

diff  --git a/clang/test/Driver/memtag.c b/clang/test/Driver/memtag.c
new file mode 100644
index ..9c548910048e
--- /dev/null
+++ b/clang/test/Driver/memtag.c
@@ -0,0 +1,23 @@
+// REQUIRES: aarch64-registered-target
+
+// Old pass manager.
+// RUN: %clang -fno-experimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-NO-SAFETY
+// RUN: %clang -O1 -fno-experimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang -O2 -fno-experimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang -O3 -fno-experimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-SAFETY
+
+// New pass manager.
+// RUN: %clang -fexperimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-NO-SAFETY
+// RUN: %clang -O1 -fexperimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang -O2 -fexperimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag %s -S -emit-llvm -o 
- | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang -O3 -fexperimental-new-pass-manager -target 
aarch64-unknown-linux -march=armv8+memtag 

Re: [clang] 522ee29 - Allow newlines in AST Matchers in clang-query files

2019-12-26 Thread Evgenii Stepanov via cfe-commits
Reverted in
https://github.com/llvm/llvm-project/commit/5ca97d0defeed38feec2352692f6bb80297d6712

On Thu, Dec 26, 2019 at 12:41 PM Stephen Kelly via cfe-commits
 wrote:
>
>
> Author: Stephen Kelly
> Date: 2019-12-26T20:40:33Z
> New Revision: 522ee29a4fb3814db604b585c8637247477ec057
>
> URL: 
> https://github.com/llvm/llvm-project/commit/522ee29a4fb3814db604b585c8637247477ec057
> DIFF: 
> https://github.com/llvm/llvm-project/commit/522ee29a4fb3814db604b585c8637247477ec057.diff
>
> LOG: Allow newlines in AST Matchers in clang-query files
>
> Reviewers: aaron.ballman
>
> Subscribers: cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D71842
>
> Added:
>
>
> Modified:
> clang-tools-extra/clang-query/Query.cpp
> clang-tools-extra/clang-query/Query.h
> clang-tools-extra/clang-query/QueryParser.cpp
> clang-tools-extra/clang-query/tool/ClangQuery.cpp
> clang-tools-extra/unittests/clang-query/QueryParserTest.cpp
> clang/include/clang/ASTMatchers/Dynamic/Parser.h
> clang/lib/ASTMatchers/Dynamic/Parser.cpp
> clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
>
> Removed:
>
>
>
> 
> diff  --git a/clang-tools-extra/clang-query/Query.cpp 
> b/clang-tools-extra/clang-query/Query.cpp
> index 675fd968f46e..8eafc5eed750 100644
> --- a/clang-tools-extra/clang-query/Query.cpp
> +++ b/clang-tools-extra/clang-query/Query.cpp
> @@ -101,9 +101,24 @@ bool MatchQuery::run(llvm::raw_ostream , QuerySession 
> ) const {
>  Finder.matchAST(AST->getASTContext());
>
>  if (QS.PrintMatcher) {
> -  std::string prefixText = "Matcher: ";
> -  OS << "\n  " << prefixText << Source << "\n";
> -  OS << "  " << std::string(prefixText.size() + Source.size(), '=') << 
> '\n';
> +  SmallVector Lines;
> +  Source.split(Lines, "\n");
> +  auto FirstLine = Lines[0];
> +  Lines.erase(Lines.begin(), Lines.begin() + 1);
> +  while (!Lines.empty() && Lines.back().empty()) {
> +Lines.resize(Lines.size() - 1);
> +  }
> +  unsigned MaxLength = FirstLine.size();
> +  std::string PrefixText = "Matcher: ";
> +  OS << "\n  " << PrefixText << FirstLine;
> +
> +  for (auto Line : Lines) {
> +OS << "\n" << std::string(PrefixText.size() + 2, ' ') << Line;
> +MaxLength = std::max(MaxLength, Line.rtrim().size());
> +  }
> +
> +  OS << "\n"
> + << "  " << std::string(PrefixText.size() + MaxLength, '=') << 
> "\n\n";
>  }
>
>  for (auto MI = Matches.begin(), ME = Matches.end(); MI != ME; ++MI) {
>
> diff  --git a/clang-tools-extra/clang-query/Query.h 
> b/clang-tools-extra/clang-query/Query.h
> index 56af486984ee..78bcbc79cdf8 100644
> --- a/clang-tools-extra/clang-query/Query.h
> +++ b/clang-tools-extra/clang-query/Query.h
> @@ -44,6 +44,7 @@ struct Query : llvm::RefCountedBase {
>/// \return false if an error occurs, otherwise return true.
>virtual bool run(llvm::raw_ostream , QuerySession ) const = 0;
>
> +  StringRef RemainingContent;
>const QueryKind Kind;
>  };
>
>
> diff  --git a/clang-tools-extra/clang-query/QueryParser.cpp 
> b/clang-tools-extra/clang-query/QueryParser.cpp
> index 4da2f5da79d4..db4b9a4b0530 100644
> --- a/clang-tools-extra/clang-query/QueryParser.cpp
> +++ b/clang-tools-extra/clang-query/QueryParser.cpp
> @@ -26,7 +26,10 @@ namespace query {
>  // is found before End, return StringRef().  Begin is adjusted to exclude the
>  // lexed region.
>  StringRef QueryParser::lexWord() {
> -  Line = Line.ltrim();
> +  Line = Line.drop_while([this](char c) {
> +// Don't trim newlines.
> +return StringRef(" \t\v\f\r").contains(c);
> +  });
>
>if (Line.empty())
>  // Even though the Line is empty, it contains a pointer and
> @@ -34,12 +37,12 @@ StringRef QueryParser::lexWord() {
>  // code completion.
>  return Line;
>
> -  if (Line.front() == '#') {
> -Line = {};
> -return StringRef();
> -  }
> +  StringRef Word;
> +  if (Line.front() == '#')
> +Word = Line.substr(0, 1);
> +  else
> +Word = Line.take_until(isWhitespace);
>
> -  StringRef Word = Line.take_until(isWhitespace);
>Line = Line.drop_front(Word.size());
>return Word;
>  }
> @@ -125,9 +128,25 @@ template  QueryRef 
> QueryParser::parseSetOutputKind() {
>  }
>
>  QueryRef QueryParser::endQuery(QueryRef Q) {
> -  const StringRef Extra = Line;
> -  if (!lexWord().empty())
> -return new InvalidQuery("unexpected extra input: '" + Extra + "'");
> +  StringRef Extra = Line;
> +  StringRef ExtraTrimmed = Extra.drop_while(
> +  [](char c) { return StringRef(" \t\v\f\r").contains(c); });
> +
> +  if ((!ExtraTrimmed.empty() && ExtraTrimmed[0] == '\n') ||
> +  (ExtraTrimmed.size() >= 2 && ExtraTrimmed[0] == '\r' &&
> +   ExtraTrimmed[1] == '\n'))
> +Q->RemainingContent = Extra;
> +  else {
> +StringRef TrailingWord = lexWord();
> +if (!TrailingWord.empty() && 

[clang-tools-extra] 5ca97d0 - Revert "Allow newlines in AST Matchers in clang-query files" + 1

2019-12-26 Thread Evgenii Stepanov via cfe-commits

Author: Evgenii Stepanov
Date: 2019-12-26T18:07:20-08:00
New Revision: 5ca97d0defeed38feec2352692f6bb80297d6712

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

LOG: Revert "Allow newlines in AST Matchers in clang-query files" + 1

Revert "Fix -Wunused-lambda-capture warnings."
This reverts commit 2369560f4a7720b19edfbf9de14ef061307ff773.
This reverts commit 522ee29a4fb3814db604b585c8637247477ec057.

clang/lib/ASTMatchers/Dynamic/Parser.cpp:610:13: warning: implicit conversion 
turns string literal into bool: 'const char [35]' to 'bool' 
[-Wstring-conversion]
assert(!"Newline should never be found here");

Added: 


Modified: 
clang-tools-extra/clang-query/Query.cpp
clang-tools-extra/clang-query/Query.h
clang-tools-extra/clang-query/QueryParser.cpp
clang-tools-extra/clang-query/tool/ClangQuery.cpp
clang-tools-extra/unittests/clang-query/QueryParserTest.cpp
clang/include/clang/ASTMatchers/Dynamic/Parser.h
clang/lib/ASTMatchers/Dynamic/Parser.cpp
clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-query/Query.cpp 
b/clang-tools-extra/clang-query/Query.cpp
index 8eafc5eed750..675fd968f46e 100644
--- a/clang-tools-extra/clang-query/Query.cpp
+++ b/clang-tools-extra/clang-query/Query.cpp
@@ -101,24 +101,9 @@ bool MatchQuery::run(llvm::raw_ostream , QuerySession 
) const {
 Finder.matchAST(AST->getASTContext());
 
 if (QS.PrintMatcher) {
-  SmallVector Lines;
-  Source.split(Lines, "\n");
-  auto FirstLine = Lines[0];
-  Lines.erase(Lines.begin(), Lines.begin() + 1);
-  while (!Lines.empty() && Lines.back().empty()) {
-Lines.resize(Lines.size() - 1);
-  }
-  unsigned MaxLength = FirstLine.size();
-  std::string PrefixText = "Matcher: ";
-  OS << "\n  " << PrefixText << FirstLine;
-
-  for (auto Line : Lines) {
-OS << "\n" << std::string(PrefixText.size() + 2, ' ') << Line;
-MaxLength = std::max(MaxLength, Line.rtrim().size());
-  }
-
-  OS << "\n"
- << "  " << std::string(PrefixText.size() + MaxLength, '=') << "\n\n";
+  std::string prefixText = "Matcher: ";
+  OS << "\n  " << prefixText << Source << "\n";
+  OS << "  " << std::string(prefixText.size() + Source.size(), '=') << 
'\n';
 }
 
 for (auto MI = Matches.begin(), ME = Matches.end(); MI != ME; ++MI) {

diff  --git a/clang-tools-extra/clang-query/Query.h 
b/clang-tools-extra/clang-query/Query.h
index 78bcbc79cdf8..56af486984ee 100644
--- a/clang-tools-extra/clang-query/Query.h
+++ b/clang-tools-extra/clang-query/Query.h
@@ -44,7 +44,6 @@ struct Query : llvm::RefCountedBase {
   /// \return false if an error occurs, otherwise return true.
   virtual bool run(llvm::raw_ostream , QuerySession ) const = 0;
 
-  StringRef RemainingContent;
   const QueryKind Kind;
 };
 

diff  --git a/clang-tools-extra/clang-query/QueryParser.cpp 
b/clang-tools-extra/clang-query/QueryParser.cpp
index a980722de9e6..4da2f5da79d4 100644
--- a/clang-tools-extra/clang-query/QueryParser.cpp
+++ b/clang-tools-extra/clang-query/QueryParser.cpp
@@ -26,10 +26,7 @@ namespace query {
 // is found before End, return StringRef().  Begin is adjusted to exclude the
 // lexed region.
 StringRef QueryParser::lexWord() {
-  Line = Line.drop_while([](char c) {
-// Don't trim newlines.
-return StringRef(" \t\v\f\r").contains(c);
-  });
+  Line = Line.ltrim();
 
   if (Line.empty())
 // Even though the Line is empty, it contains a pointer and
@@ -37,12 +34,12 @@ StringRef QueryParser::lexWord() {
 // code completion.
 return Line;
 
-  StringRef Word;
-  if (Line.front() == '#')
-Word = Line.substr(0, 1);
-  else
-Word = Line.take_until(isWhitespace);
+  if (Line.front() == '#') {
+Line = {};
+return StringRef();
+  }
 
+  StringRef Word = Line.take_until(isWhitespace);
   Line = Line.drop_front(Word.size());
   return Word;
 }
@@ -128,25 +125,9 @@ template  QueryRef 
QueryParser::parseSetOutputKind() {
 }
 
 QueryRef QueryParser::endQuery(QueryRef Q) {
-  StringRef Extra = Line;
-  StringRef ExtraTrimmed = Extra.drop_while(
-  [](char c) { return StringRef(" \t\v\f\r").contains(c); });
-
-  if ((!ExtraTrimmed.empty() && ExtraTrimmed[0] == '\n') ||
-  (ExtraTrimmed.size() >= 2 && ExtraTrimmed[0] == '\r' &&
-   ExtraTrimmed[1] == '\n'))
-Q->RemainingContent = Extra;
-  else {
-StringRef TrailingWord = lexWord();
-if (!TrailingWord.empty() && TrailingWord.front() == '#') {
-  Line = Line.drop_until([](char c) { return c == '\n'; });
-  Line = Line.drop_while([](char c) { return c == '\n'; });
-  return endQuery(Q);
-}
-if (!TrailingWord.empty()) {
-  return new InvalidQuery("unexpected extra input: 

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

2019-09-25 Thread Evgenii Stepanov via cfe-commits
Hi,

this change breaks the build with

/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/clang/lib/Format/Format.cpp:737:44:
error: missing field 'SortPriority' initializer
[-Werror,-Wmissing-field-initializers]
  {"^\"(llvm|llvm-c|clang|clang-c)/", 2},

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/24667/steps/bootstrap%20clang/logs/stdio

On Wed, Sep 25, 2019 at 1:30 PM Paul Hoad via cfe-commits
 wrote:
>
> Author: paulhoad
> Date: Wed Sep 25 13:33:01 2019
> New Revision: 372919
>
> URL: http://llvm.org/viewvc/llvm-project?rev=372919=rev
> Log:
> [clang-format] Modified SortIncludes and IncludeCategories to priority for 
> sorting #includes within the Group Category.
>
> Summary:
> This new Style rule is made as a part of adding support for NetBSD KNF in 
> clang-format. NetBSD have it's own priority of includes which should be 
> followed while formatting NetBSD code. This style sorts the Cpp Includes 
> according to the priorities of NetBSD, as mentioned in the [Style 
> Guide](http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style?rev=HEAD=text/x-cvsweb-markup)
>  The working of this Style rule shown below:
>
> **Configuration:**
> This revision introduces a new field under IncludeCategories named 
> `SortPriority` which defines the priority of ordering the `#includes` and the 
> `Priority` will define the categories for grouping the `#include blocks`.
>
> Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay
>
> Reviewed By: MyDeveloperDay
>
> Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski
>
> Patch By: Manikishan
>
> Tags: #clang, #clang-format
>
> Differential Revision: https://reviews.llvm.org/D64695
>
> Modified:
> cfe/trunk/docs/ClangFormatStyleOptions.rst
> cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
> cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
> cfe/trunk/lib/Format/Format.cpp
> cfe/trunk/lib/Tooling/Inclusions/HeaderIncludes.cpp
> cfe/trunk/lib/Tooling/Inclusions/IncludeStyle.cpp
> cfe/trunk/unittests/Format/SortIncludesTest.cpp
>
> Modified: cfe/trunk/docs/ClangFormatStyleOptions.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormatStyleOptions.rst?rev=372919=372918=372919=diff
> ==
> --- cfe/trunk/docs/ClangFormatStyleOptions.rst (original)
> +++ cfe/trunk/docs/ClangFormatStyleOptions.rst Wed Sep 25 13:33:01 2019
> @@ -1511,6 +1511,13 @@ the configuration (without a prefix: ``A
>can also assign negative priorities if you have certain headers that
>always need to be first.
>
> +  There is a third and optional field ``SortPriority`` which can used while
> +  ``IncludeBloks = IBS_Regroup`` to define the priority in which 
> ``#includes``
> +  should be ordered, and value of ``Priority`` defines the order of
> +  ``#include blocks`` and also enables to group ``#includes`` of different
> +  priority for order.``SortPriority`` is set to the value of ``Priority``
> +  as default if it is not assigned.
> +
>To configure this in the .clang-format file, use:
>
>.. code-block:: yaml
> @@ -1518,12 +1525,14 @@ the configuration (without a prefix: ``A
>  IncludeCategories:
>- Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
>  Priority:2
> +SortPriority:2
>- Regex:   '^(<|"(gtest|gmock|isl|json)/)'
>  Priority:3
>- Regex:   '<[[:alnum:].]+>'
>  Priority:4
>- Regex:   '.*'
>  Priority:1
> +SortPriority:0
>
>  **IncludeIsMainRegex** (``std::string``)
>Specify a regular expression of suffixes that are allowed in the
>
> Modified: cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h?rev=372919=372918=372919=diff
> ==
> --- cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h (original)
> +++ cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h Wed Sep 25 
> 13:33:01 2019
> @@ -32,6 +32,7 @@ public:
>/// 0. Otherwise, returns the priority of the matching category or INT_MAX.
>/// NOTE: this API is not thread-safe!
>int getIncludePriority(StringRef IncludeName, bool CheckMainHeader) const;
> +  int getSortIncludePriority(StringRef IncludeName, bool CheckMainHeader) 
> const;
>
>  private:
>bool isMainHeader(StringRef IncludeName) const;
>
> Modified: cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h?rev=372919=372918=372919=diff
> ==
> --- cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h 

Re: r372903 - [Mangle] Add flag to asm labels to disable '\01' prefixing

2019-09-25 Thread Evgenii Stepanov via cfe-commits
FYI I've fixed a memory leak in the new test in r372925.

On Wed, Sep 25, 2019 at 10:58 AM Vedant Kumar via cfe-commits
 wrote:
>
> Author: vedantk
> Date: Wed Sep 25 11:00:31 2019
> New Revision: 372903
>
> URL: http://llvm.org/viewvc/llvm-project?rev=372903=rev
> Log:
> [Mangle] Add flag to asm labels to disable '\01' prefixing
>
> LLDB synthesizes decls using asm labels. These decls cannot have a mangle
> different than the one specified in the label name. I.e., the '\01' prefix
> should not be added.
>
> Fixes an expression evaluation failure in lldb's TestVirtual.py on iOS.
>
> rdar://45827323
>
> Differential Revision: https://reviews.llvm.org/D67774
>
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/lib/AST/Mangle.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/unittests/AST/DeclTest.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=372903=372902=372903=diff
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Wed Sep 25 11:00:31 2019
> @@ -722,9 +722,25 @@ def AVRSignal : InheritableAttr, TargetS
>
>  def AsmLabel : InheritableAttr {
>let Spellings = [Keyword<"asm">, Keyword<"__asm__">];
> -  let Args = [StringArgument<"Label">];
> +  let Args = [
> +// Label specifies the mangled name for the decl.
> +StringArgument<"Label">,
> +
> +// IsLiteralLabel specifies whether the label is literal (i.e. suppresses
> +// the global C symbol prefix) or not. If not, the mangle-suppression 
> prefix
> +// ('\01') is omitted from the decl name at the LLVM IR level.
> +//
> +// Non-literal labels are used by some external AST sources like LLDB.
> +BoolArgument<"IsLiteralLabel", /*optional=*/0, /*fake=*/1>
> +  ];
>let SemaHandler = 0;
> -  let Documentation = [Undocumented];
> +  let Documentation = [AsmLabelDocs];
> +  let AdditionalMembers =
> +[{
> +bool isEquivalent(AsmLabelAttr *Other) const {
> +  return getLabel() == Other->getLabel() && getIsLiteralLabel() == 
> Other->getIsLiteralLabel();
> +}
> +}];
>  }
>
>  def Availability : InheritableAttr {
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=372903=372902=372903=diff
> ==
> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed Sep 25 11:00:31 2019
> @@ -2558,6 +2558,30 @@ manipulating bits of the enumerator when
>}];
>  }
>
> +def AsmLabelDocs : Documentation {
> +  let Category = DocCatDecl;
> +  let Content = [{
> +This attribute can be used on a function or variable to specify its symbol 
> name.
> +
> +On some targets, all C symbols are prefixed by default with a single 
> character, typically ``_``.  This was done historically to distinguish them 
> from symbols used by other languages.  (This prefix is also added to the 
> standard Itanium C++ ABI prefix on "mangled" symbol names, so that e.g. on 
> such targets the true symbol name for a C++ variable declared as ``int 
> cppvar;`` would be ``__Z6cppvar``; note the two underscores.)  This prefix is 
> *not* added to the symbol names specified by the ``asm`` attribute; 
> programmers wishing to match a C symbol name must compensate for this.
> +
> +For example, consider the following C code:
> +
> +.. code-block:: c
> +
> +  int var1 asm("altvar") = 1;  // "altvar" in symbol table.
> +  int var2 = 1; // "_var2" in symbol table.
> +
> +  void func1(void) asm("altfunc");
> +  void func1(void) {} // "altfunc" in symbol table.
> +  void func2(void) {} // "_func2" in symbol table.
> +
> +Clang's implementation of this attribute is compatible with GCC's, 
> `documented here `_.
> +
> +While it is possible to use this attribute to name a special symbol used 
> internally by the compiler, such as an LLVM intrinsic, this is neither 
> recommended nor supported and may cause the compiler to crash or miscompile.  
> Users who wish to gain access to intrinsic behavior are strongly encouraged 
> to request new builtin functions.
> +  }];
> +}
> +
>  def EnumExtensibilityDocs : Documentation {
>let Category = DocCatDecl;
>let Content = [{
>
> Modified: cfe/trunk/lib/AST/Mangle.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Mangle.cpp?rev=372903=372902=372903=diff
> ==
> --- cfe/trunk/lib/AST/Mangle.cpp (original)
> +++ cfe/trunk/lib/AST/Mangle.cpp Wed Sep 25 11:00:31 2019
> @@ -122,15 +122,21 @@ void MangleContext::mangleName(const Nam
>if (const AsmLabelAttr *ALA = D->getAttr()) {
>   

Re: r366123 - ARM MTE stack sanitizer.

2019-07-16 Thread Evgenii Stepanov via cfe-commits
I could not reproduce this on Linux nor on Mac.
I wonder if triggering a clean build would help? I don't see a way to
do that though.

On Tue, Jul 16, 2019 at 10:50 AM Evgenii Stepanov
 wrote:
>
> Hi,
>
> thanks for letting me know! Is this reproducible on Linux? It is
> possible to extract a reproducer from the bot?
>
> On Mon, Jul 15, 2019 at 9:30 PM Amara Emerson  wrote:
> >
> > Hi Evgeniy,
> >
> > This commit looks like it broke the lldb bot: 
> > http://green.lab.llvm.org/green/job/lldb-cmake/31011/
> >
> > Can you take a look?
> >
> > Amara
> >
> > On Jul 15, 2019, at 1:02 PM, Evgeniy Stepanov via cfe-commits 
> >  wrote:
> >
> > Author: eugenis
> > Date: Mon Jul 15 13:02:23 2019
> > New Revision: 366123
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=366123=rev
> > Log:
> > ARM MTE stack sanitizer.
> >
> > Add "memtag" sanitizer that detects and mitigates stack memory issues
> > using armv8.5 Memory Tagging Extension.
> >
> > It is similar in principle to HWASan, which is a software implementation
> > of the same idea, but there are enough differencies to warrant a new
> > sanitizer type IMHO. It is also expected to have very different
> > performance properties.
> >
> > The new sanitizer does not have a runtime library (it may grow one
> > later, along with a "debugging" mode). Similar to SafeStack and
> > StackProtector, the instrumentation pass (in a follow up change) will be
> > inserted in all cases, but will only affect functions marked with the
> > new sanitize_memtag attribute.
> >
> > Reviewers: pcc, hctim, vitalybuka, ostannard
> >
> > Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, 
> > cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits
> >
> > Tags: #clang, #llvm
> >
> > Differential Revision: https://reviews.llvm.org/D64169
> >
> > Added:
> >cfe/trunk/test/CodeGen/memtag-attr.cpp
> >cfe/trunk/test/Lexer/has_feature_memtag_sanitizer.cpp
> > Modified:
> >cfe/trunk/include/clang/Basic/Features.def
> >cfe/trunk/include/clang/Basic/Sanitizers.def
> >cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> >cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
> >cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> >cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
> >cfe/trunk/lib/Driver/SanitizerArgs.cpp
> >cfe/trunk/lib/Driver/ToolChains/Linux.cpp
> >cfe/trunk/test/Driver/fsanitize.c
> >cfe/trunk/test/SemaCXX/attr-no-sanitize.cpp
> >
> > Modified: cfe/trunk/include/clang/Basic/Features.def
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=366123=366122=366123=diff
> > ==
> > --- cfe/trunk/include/clang/Basic/Features.def (original)
> > +++ cfe/trunk/include/clang/Basic/Features.def Mon Jul 15 13:02:23 2019
> > @@ -42,6 +42,7 @@ FEATURE(address_sanitizer,
> > FEATURE(hwaddress_sanitizer,
> > LangOpts.Sanitize.hasOneOf(SanitizerKind::HWAddress |
> >SanitizerKind::KernelHWAddress))
> > +FEATURE(memtag_sanitizer, LangOpts.Sanitize.has(SanitizerKind::MemTag))
> > FEATURE(xray_instrument, LangOpts.XRayInstrument)
> > FEATURE(undefined_behavior_sanitizer,
> > LangOpts.Sanitize.hasOneOf(SanitizerKind::Undefined))
> >
> > Modified: cfe/trunk/include/clang/Basic/Sanitizers.def
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Sanitizers.def?rev=366123=366122=366123=diff
> > ==
> > --- cfe/trunk/include/clang/Basic/Sanitizers.def (original)
> > +++ cfe/trunk/include/clang/Basic/Sanitizers.def Mon Jul 15 13:02:23 2019
> > @@ -55,6 +55,9 @@ SANITIZER("hwaddress", HWAddress)
> > // Kernel Hardware-assisted AddressSanitizer (KHWASan)
> > SANITIZER("kernel-hwaddress", KernelHWAddress)
> >
> > +// A variant of AddressSanitizer using AArch64 MTE extension.
> > +SANITIZER("memtag", MemTag)
> > +
> > // MemorySanitizer
> > SANITIZER("memory", Memory)
> >
> >
> > Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=366123=366122=366123=diff
> > ==
> > --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon Jul 15 13:02:23 2019
> > @@ -369,6 +369,10 @@ llvm::Function *CodeGenModule::CreateGlo
> >   !isInSanitizerBlacklist(SanitizerKind::KernelHWAddress, Fn, Loc))
> > Fn->addFnAttr(llvm::Attribute::SanitizeHWAddress);
> >
> > +  if (getLangOpts().Sanitize.has(SanitizerKind::MemTag) &&
> > +  !isInSanitizerBlacklist(SanitizerKind::MemTag, Fn, Loc))
> > +Fn->addFnAttr(llvm::Attribute::SanitizeMemTag);
> > +
> >   if (getLangOpts().Sanitize.has(SanitizerKind::Thread) &&
> >   !isInSanitizerBlacklist(SanitizerKind::Thread, Fn, Loc))
> > 

Re: r366123 - ARM MTE stack sanitizer.

2019-07-16 Thread Evgenii Stepanov via cfe-commits
Hi,

thanks for letting me know! Is this reproducible on Linux? It is
possible to extract a reproducer from the bot?

On Mon, Jul 15, 2019 at 9:30 PM Amara Emerson  wrote:
>
> Hi Evgeniy,
>
> This commit looks like it broke the lldb bot: 
> http://green.lab.llvm.org/green/job/lldb-cmake/31011/
>
> Can you take a look?
>
> Amara
>
> On Jul 15, 2019, at 1:02 PM, Evgeniy Stepanov via cfe-commits 
>  wrote:
>
> Author: eugenis
> Date: Mon Jul 15 13:02:23 2019
> New Revision: 366123
>
> URL: http://llvm.org/viewvc/llvm-project?rev=366123=rev
> Log:
> ARM MTE stack sanitizer.
>
> Add "memtag" sanitizer that detects and mitigates stack memory issues
> using armv8.5 Memory Tagging Extension.
>
> It is similar in principle to HWASan, which is a software implementation
> of the same idea, but there are enough differencies to warrant a new
> sanitizer type IMHO. It is also expected to have very different
> performance properties.
>
> The new sanitizer does not have a runtime library (it may grow one
> later, along with a "debugging" mode). Similar to SafeStack and
> StackProtector, the instrumentation pass (in a follow up change) will be
> inserted in all cases, but will only affect functions marked with the
> new sanitize_memtag attribute.
>
> Reviewers: pcc, hctim, vitalybuka, ostannard
>
> Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, 
> cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits
>
> Tags: #clang, #llvm
>
> Differential Revision: https://reviews.llvm.org/D64169
>
> Added:
>cfe/trunk/test/CodeGen/memtag-attr.cpp
>cfe/trunk/test/Lexer/has_feature_memtag_sanitizer.cpp
> Modified:
>cfe/trunk/include/clang/Basic/Features.def
>cfe/trunk/include/clang/Basic/Sanitizers.def
>cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
>cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
>cfe/trunk/lib/Driver/SanitizerArgs.cpp
>cfe/trunk/lib/Driver/ToolChains/Linux.cpp
>cfe/trunk/test/Driver/fsanitize.c
>cfe/trunk/test/SemaCXX/attr-no-sanitize.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Features.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=366123=366122=366123=diff
> ==
> --- cfe/trunk/include/clang/Basic/Features.def (original)
> +++ cfe/trunk/include/clang/Basic/Features.def Mon Jul 15 13:02:23 2019
> @@ -42,6 +42,7 @@ FEATURE(address_sanitizer,
> FEATURE(hwaddress_sanitizer,
> LangOpts.Sanitize.hasOneOf(SanitizerKind::HWAddress |
>SanitizerKind::KernelHWAddress))
> +FEATURE(memtag_sanitizer, LangOpts.Sanitize.has(SanitizerKind::MemTag))
> FEATURE(xray_instrument, LangOpts.XRayInstrument)
> FEATURE(undefined_behavior_sanitizer,
> LangOpts.Sanitize.hasOneOf(SanitizerKind::Undefined))
>
> Modified: cfe/trunk/include/clang/Basic/Sanitizers.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Sanitizers.def?rev=366123=366122=366123=diff
> ==
> --- cfe/trunk/include/clang/Basic/Sanitizers.def (original)
> +++ cfe/trunk/include/clang/Basic/Sanitizers.def Mon Jul 15 13:02:23 2019
> @@ -55,6 +55,9 @@ SANITIZER("hwaddress", HWAddress)
> // Kernel Hardware-assisted AddressSanitizer (KHWASan)
> SANITIZER("kernel-hwaddress", KernelHWAddress)
>
> +// A variant of AddressSanitizer using AArch64 MTE extension.
> +SANITIZER("memtag", MemTag)
> +
> // MemorySanitizer
> SANITIZER("memory", Memory)
>
>
> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=366123=366122=366123=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon Jul 15 13:02:23 2019
> @@ -369,6 +369,10 @@ llvm::Function *CodeGenModule::CreateGlo
>   !isInSanitizerBlacklist(SanitizerKind::KernelHWAddress, Fn, Loc))
> Fn->addFnAttr(llvm::Attribute::SanitizeHWAddress);
>
> +  if (getLangOpts().Sanitize.has(SanitizerKind::MemTag) &&
> +  !isInSanitizerBlacklist(SanitizerKind::MemTag, Fn, Loc))
> +Fn->addFnAttr(llvm::Attribute::SanitizeMemTag);
> +
>   if (getLangOpts().Sanitize.has(SanitizerKind::Thread) &&
>   !isInSanitizerBlacklist(SanitizerKind::Thread, Fn, Loc))
> Fn->addFnAttr(llvm::Attribute::SanitizeThread);
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=366123=366122=366123=diff
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Mon Jul 15 13:02:23 2019
> @@ -696,6 +696,8 @@ void 

Re: r349054 - Make -Wstring-plus-int warns even if when the result is not out of bounds

2018-12-13 Thread Evgenii Stepanov via cfe-commits
Hi,

this broke Clang :: SemaCXX/constant-expression-cxx1y.cpp:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/9144

error: 'warning' diagnostics seen but not expected:
  File 
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/tools/clang/test/SemaCXX/constant-expression-cxx1y.cpp
Line 447: adding 'int' to a string does not append to the string
error: 'note' diagnostics seen but not expected:
  File 
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/tools/clang/test/SemaCXX/constant-expression-cxx1y.cpp
Line 447: use array indexing to silence this warning
2 errors generated.

On Thu, Dec 13, 2018 at 8:09 AM Sylvestre Ledru via cfe-commits
 wrote:
>
> Author: sylvestre
> Date: Thu Dec 13 08:06:23 2018
> New Revision: 349054
>
> URL: http://llvm.org/viewvc/llvm-project?rev=349054=rev
> Log:
> Make -Wstring-plus-int warns even if when the result is not out of bounds
>
> Summary: Patch by Arnaud Bienner
>
> Reviewers: sylvestre.ledru, thakis
>
> Reviewed By: thakis
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D55382
>
> Modified:
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/test/SemaCXX/string-plus-int.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=349054=349053=349054=diff
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu Dec 13 08:06:23 2018
> @@ -9135,16 +9135,6 @@ static void diagnoseStringPlusInt(Sema &
>if (!IsStringPlusInt || IndexExpr->isValueDependent())
>  return;
>
> -  Expr::EvalResult Result;
> -  if (IndexExpr->EvaluateAsInt(Result, Self.getASTContext())) {
> -llvm::APSInt index = Result.Val.getInt();
> -unsigned StrLenWithNull = StrExpr->getLength() + 1;
> -if (index.isNonNegative() &&
> -index <= llvm::APSInt(llvm::APInt(index.getBitWidth(), 
> StrLenWithNull),
> -  index.isUnsigned()))
> -  return;
> -  }
> -
>SourceRange DiagRange(LHSExpr->getBeginLoc(), RHSExpr->getEndLoc());
>Self.Diag(OpLoc, diag::warn_string_plus_int)
><< DiagRange << IndexExpr->IgnoreImpCasts()->getType();
>
> Modified: cfe/trunk/test/SemaCXX/string-plus-int.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/string-plus-int.cpp?rev=349054=349053=349054=diff
> ==
> --- cfe/trunk/test/SemaCXX/string-plus-int.cpp (original)
> +++ cfe/trunk/test/SemaCXX/string-plus-int.cpp Thu Dec 13 08:06:23 2018
> @@ -31,37 +31,36 @@ void f(int index) {
>consume("foo" + 5);  // expected-warning {{adding 'int' to a string does 
> not append to the string}} expected-note {{use array indexing to silence this 
> warning}}
>consume("foo" + index);  // expected-warning {{adding 'int' to a string 
> does not append to the string}} expected-note {{use array indexing to silence 
> this warning}}
>consume("foo" + kMyEnum);  // expected-warning {{adding 'MyEnum' to a 
> string does not append to the string}} expected-note {{use array indexing to 
> silence this warning}}
> +  consume("foo" + kMySmallEnum); // expected-warning {{adding 'MyEnum' to a 
> string does not append to the string}} expected-note {{use array indexing to 
> silence this warning}}
>
>consume(5 + "foo");  // expected-warning {{adding 'int' to a string does 
> not append to the string}} expected-note {{use array indexing to silence this 
> warning}}
>consume(index + "foo");  // expected-warning {{adding 'int' to a string 
> does not append to the string}} expected-note {{use array indexing to silence 
> this warning}}
>consume(kMyEnum + "foo");  // expected-warning {{adding 'MyEnum' to a 
> string does not append to the string}} expected-note {{use array indexing to 
> silence this warning}}
> +  consume(kMySmallEnum + "foo"); // expected-warning {{adding 'MyEnum' to a 
> string does not append to the string}} expected-note {{use array indexing to 
> silence this warning}}
>
>// FIXME: suggest replacing with "foo"[5]
>consumeChar(*("foo" + 5));  // expected-warning {{adding 'int' to a string 
> does not append to the string}} expected-note {{use array indexing to silence 
> this warning}}
>consumeChar(*(5 + "foo"));  // expected-warning {{adding 'int' to a string 
> does not append to the string}} expected-note {{use array indexing to silence 
> this warning}}
>
>consume(L"foo" + 5);  // expected-warning {{adding 'int' to a string does 
> not append to the string}} expected-note {{use array indexing to silence this 
> warning}}
> +  consume(L"foo" + 2); // expected-warning {{adding 'int' to a string does 
> not append to the string}} expected-note {{use array indexing to silence this 
> warning}}
> +
> +  consume("foo" + 3);  // expected-warning {{adding 'int' to a string does 
> not 

Re: r336590 - [libclang] evalute compound statement cursors before trying to evaluate

2018-07-10 Thread Evgenii Stepanov via cfe-commits
Reverting...

On Mon, Jul 9, 2018 at 8:18 PM, Vlad Tsyrklevich  wrote:
> The ASan bot is failing with a LeakSanitizer failure that appears related to
> one of your libclang changes:
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/6282/steps/check-clang%20asan/logs/stdio
>
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x52c638 in operator new(unsigned long)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:106
> #1 0x7fd236783b89 in make_unique
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1057:29
> #2 0x7fd236783b89 in evaluateExpr
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:3755
> #3 0x7fd236783b89 in clang_Cursor_Evaluate
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:3917
> #4 0x54e743 in operator()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/libclang/LibclangTest.cpp:487:39
> #5 0x54e743 in
> LibclangParseTest_EvaluateChildExpression_Test::TestBody()::$_0::operator()(CXCursor,
> CXCursor, void*) const::'lambda'(CXCursor, CXCursor,
> void*)::__invoke(CXCursor, CXCursor, void*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/libclang/LibclangTest.cpp:482
> #6 0x7fd23677de00 in
> clang::cxcursor::CursorVisitor::RunVisitorWorkList(llvm::SmallVector 10u>&)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:3019:17
> #7 0x7fd23675c3a8 in clang::cxcursor::CursorVisitor::Visit(clang::Stmt
> const*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:3164:17
> #8 0x7fd236755d2f in
> clang::cxcursor::CursorVisitor::VisitChildren(CXCursor)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp
> #9 0x7fd236754e5d in clang::cxcursor::CursorVisitor::Visit(CXCursor,
> bool)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:225:16
> #10 0x7fd23676487c in
> clang::cxcursor::CursorVisitor::VisitFunctionDecl(clang::FunctionDecl*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:889:9
> #11 0x7fd236759e24 in
> clang::declvisitor::Base clang::cxcursor::CursorVisitor, bool>::Visit(clang::Decl*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/include/clang/AST/DeclVisitor.h
> #12 0x7fd236755c17 in
> clang::cxcursor::CursorVisitor::VisitChildren(CXCursor)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:506:34
> #13 0x7fd23678a558 in clang_visitChildren
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:4352:20
> #14 0x54e024 in operator()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/libclang/LibclangTest.cpp:480:11
> #15 0x54e024 in
> LibclangParseTest_EvaluateChildExpression_Test::TestBody()::$_0::__invoke(CXCursor,
> CXCursor, void*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/libclang/LibclangTest.cpp:476
> #16 0x7fd236754d49 in clang::cxcursor::CursorVisitor::Visit(CXCursor,
> bool)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:217:11
> #17 0x7fd23675cb87 in
> clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:674:7
> #18 0x7fd23675cefe in
> clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:635:30
> #19 0x7fd236756399 in
> clang::cxcursor::CursorVisitor::VisitChildren(CXCursor)
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:540:20
> #20 0x7fd23678a558 in clang_visitChildren
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/tools/libclang/CIndex.cpp:4352:20
> #21 0x537fa1 in
> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/libclang/LibclangTest.cpp:474:3
> #22 0x5cae31 in testing::Test::Run()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
> #23 0x5cd068 in testing::TestInfo::Run()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
> #24 0x5ce430 in testing::TestCase::Run()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
> #25 0x5ec1d4 in testing::internal::UnitTestImpl::RunAllTests()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
> #26 0x5eb380 in testing::UnitTest::Run()
> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
> #27 0x5b3983 in 

Re: r334650 - Implement constexpr __builtin_*_overflow

2018-07-03 Thread Evgenii Stepanov via cfe-commits
Discovered by MemorySanitizer, btw.

On Tue, Jul 3, 2018 at 12:59 PM, Evgenii Stepanov  wrote:

> Hi,
>
> with this change, the following compiles to "ret i32 undef":
>
> int main(int argc, char **argv) {
>
>   constexpr int x = 1;
>
>   constexpr int y = 2;
>
>   int z;
>
>
>
>   __builtin_sadd_overflow(x, y, );
>
>   return z;
>
> }
>
>
> On Wed, Jun 13, 2018 at 1:43 PM, Erich Keane via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: erichkeane
>> Date: Wed Jun 13 13:43:27 2018
>> New Revision: 334650
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=334650=rev
>> Log:
>> Implement constexpr __builtin_*_overflow
>>
>> As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633
>> permit the __builtin_*_overflow builtins in constexpr functions.
>>
>> Differential Revision: https://reviews.llvm.org/D48040
>>
>> Modified:
>> cfe/trunk/lib/AST/ExprConstant.cpp
>> cfe/trunk/test/SemaCXX/builtins-overflow.cpp
>>
>> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprCo
>> nstant.cpp?rev=334650=334649=334650=diff
>> 
>> ==
>> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
>> +++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Jun 13 13:43:27 2018
>> @@ -8155,6 +8155,124 @@ bool IntExprEvaluator::VisitBuiltinCallE
>>case Builtin::BIomp_is_initial_device:
>>  // We can decide statically which value the runtime would return if
>> called.
>>  return Success(Info.getLangOpts().OpenMPIsDevice ? 0 : 1, E);
>> +  case Builtin::BI__builtin_add_overflow:
>> +  case Builtin::BI__builtin_sub_overflow:
>> +  case Builtin::BI__builtin_mul_overflow:
>> +  case Builtin::BI__builtin_sadd_overflow:
>> +  case Builtin::BI__builtin_uadd_overflow:
>> +  case Builtin::BI__builtin_uaddl_overflow:
>> +  case Builtin::BI__builtin_uaddll_overflow:
>> +  case Builtin::BI__builtin_usub_overflow:
>> +  case Builtin::BI__builtin_usubl_overflow:
>> +  case Builtin::BI__builtin_usubll_overflow:
>> +  case Builtin::BI__builtin_umul_overflow:
>> +  case Builtin::BI__builtin_umull_overflow:
>> +  case Builtin::BI__builtin_umulll_overflow:
>> +  case Builtin::BI__builtin_saddl_overflow:
>> +  case Builtin::BI__builtin_saddll_overflow:
>> +  case Builtin::BI__builtin_ssub_overflow:
>> +  case Builtin::BI__builtin_ssubl_overflow:
>> +  case Builtin::BI__builtin_ssubll_overflow:
>> +  case Builtin::BI__builtin_smul_overflow:
>> +  case Builtin::BI__builtin_smull_overflow:
>> +  case Builtin::BI__builtin_smulll_overflow: {
>> +LValue ResultLValue;
>> +APSInt LHS, RHS;
>> +
>> +QualType ResultType = E->getArg(2)->getType()->getPointeeType();
>> +if (!EvaluateInteger(E->getArg(0), LHS, Info) ||
>> +!EvaluateInteger(E->getArg(1), RHS, Info) ||
>> +!EvaluatePointer(E->getArg(2), ResultLValue, Info))
>> +  return false;
>> +
>> +APSInt Result;
>> +bool DidOverflow = false;
>> +
>> +// If the types don't have to match, enlarge all 3 to the largest of
>> them.
>> +if (BuiltinOp == Builtin::BI__builtin_add_overflow ||
>> +BuiltinOp == Builtin::BI__builtin_sub_overflow ||
>> +BuiltinOp == Builtin::BI__builtin_mul_overflow) {
>> +  bool IsSigned = LHS.isSigned() || RHS.isSigned() ||
>> +  ResultType->isSignedIntegerOrEnumerationType();
>> +  bool AllSigned = LHS.isSigned() && RHS.isSigned() &&
>> +  ResultType->isSignedIntegerOrEnumerationType();
>> +  uint64_t LHSSize = LHS.getBitWidth();
>> +  uint64_t RHSSize = RHS.getBitWidth();
>> +  uint64_t ResultSize = Info.Ctx.getTypeSize(ResultType);
>> +  uint64_t MaxBits = std::max(std::max(LHSSize, RHSSize),
>> ResultSize);
>> +
>> +  // Add an additional bit if the signedness isn't uniformly agreed
>> to. We
>> +  // could do this ONLY if there is a signed and an unsigned that
>> both have
>> +  // MaxBits, but the code to check that is pretty nasty.  The issue
>> will be
>> +  // caught in the shrink-to-result later anyway.
>> +  if (IsSigned && !AllSigned)
>> +++MaxBits;
>> +
>> +  LHS = APSInt(IsSigned ? LHS.sextOrSelf(MaxBits) :
>> LHS.zextOrSelf(MaxBits),
>> +   !IsSigned);
>> +  RHS = APSInt(IsSigned ? RHS.sextOrSelf(MaxBits) :
>> RHS.zextOrSelf(MaxBits),
>> +   !IsSigned);
>> +  Result = APSInt(MaxBits, !IsSigned);
>> +}
>> +
>> +// Find largest int.
>> +switch (BuiltinOp) {
>> +default:
>> +  llvm_unreachable("Invalid value for BuiltinOp");
>> +case Builtin::BI__builtin_add_overflow:
>> +case Builtin::BI__builtin_sadd_overflow:
>> +case Builtin::BI__builtin_saddl_overflow:
>> +case Builtin::BI__builtin_saddll_overflow:
>> +case Builtin::BI__builtin_uadd_overflow:
>> +case Builtin::BI__builtin_uaddl_overflow:
>> +case Builtin::BI__builtin_uaddll_overflow:
>> +  Result = LHS.isSigned() ? 

Re: r334650 - Implement constexpr __builtin_*_overflow

2018-07-03 Thread Evgenii Stepanov via cfe-commits
Hi,

with this change, the following compiles to "ret i32 undef":

int main(int argc, char **argv) {

  constexpr int x = 1;

  constexpr int y = 2;

  int z;



  __builtin_sadd_overflow(x, y, );

  return z;

}


On Wed, Jun 13, 2018 at 1:43 PM, Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Wed Jun 13 13:43:27 2018
> New Revision: 334650
>
> URL: http://llvm.org/viewvc/llvm-project?rev=334650=rev
> Log:
> Implement constexpr __builtin_*_overflow
>
> As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633
> permit the __builtin_*_overflow builtins in constexpr functions.
>
> Differential Revision: https://reviews.llvm.org/D48040
>
> Modified:
> cfe/trunk/lib/AST/ExprConstant.cpp
> cfe/trunk/test/SemaCXX/builtins-overflow.cpp
>
> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
> ExprConstant.cpp?rev=334650=334649=334650=diff
> 
> ==
> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> +++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Jun 13 13:43:27 2018
> @@ -8155,6 +8155,124 @@ bool IntExprEvaluator::VisitBuiltinCallE
>case Builtin::BIomp_is_initial_device:
>  // We can decide statically which value the runtime would return if
> called.
>  return Success(Info.getLangOpts().OpenMPIsDevice ? 0 : 1, E);
> +  case Builtin::BI__builtin_add_overflow:
> +  case Builtin::BI__builtin_sub_overflow:
> +  case Builtin::BI__builtin_mul_overflow:
> +  case Builtin::BI__builtin_sadd_overflow:
> +  case Builtin::BI__builtin_uadd_overflow:
> +  case Builtin::BI__builtin_uaddl_overflow:
> +  case Builtin::BI__builtin_uaddll_overflow:
> +  case Builtin::BI__builtin_usub_overflow:
> +  case Builtin::BI__builtin_usubl_overflow:
> +  case Builtin::BI__builtin_usubll_overflow:
> +  case Builtin::BI__builtin_umul_overflow:
> +  case Builtin::BI__builtin_umull_overflow:
> +  case Builtin::BI__builtin_umulll_overflow:
> +  case Builtin::BI__builtin_saddl_overflow:
> +  case Builtin::BI__builtin_saddll_overflow:
> +  case Builtin::BI__builtin_ssub_overflow:
> +  case Builtin::BI__builtin_ssubl_overflow:
> +  case Builtin::BI__builtin_ssubll_overflow:
> +  case Builtin::BI__builtin_smul_overflow:
> +  case Builtin::BI__builtin_smull_overflow:
> +  case Builtin::BI__builtin_smulll_overflow: {
> +LValue ResultLValue;
> +APSInt LHS, RHS;
> +
> +QualType ResultType = E->getArg(2)->getType()->getPointeeType();
> +if (!EvaluateInteger(E->getArg(0), LHS, Info) ||
> +!EvaluateInteger(E->getArg(1), RHS, Info) ||
> +!EvaluatePointer(E->getArg(2), ResultLValue, Info))
> +  return false;
> +
> +APSInt Result;
> +bool DidOverflow = false;
> +
> +// If the types don't have to match, enlarge all 3 to the largest of
> them.
> +if (BuiltinOp == Builtin::BI__builtin_add_overflow ||
> +BuiltinOp == Builtin::BI__builtin_sub_overflow ||
> +BuiltinOp == Builtin::BI__builtin_mul_overflow) {
> +  bool IsSigned = LHS.isSigned() || RHS.isSigned() ||
> +  ResultType->isSignedIntegerOrEnumerationType();
> +  bool AllSigned = LHS.isSigned() && RHS.isSigned() &&
> +  ResultType->isSignedIntegerOrEnumerationType();
> +  uint64_t LHSSize = LHS.getBitWidth();
> +  uint64_t RHSSize = RHS.getBitWidth();
> +  uint64_t ResultSize = Info.Ctx.getTypeSize(ResultType);
> +  uint64_t MaxBits = std::max(std::max(LHSSize, RHSSize), ResultSize);
> +
> +  // Add an additional bit if the signedness isn't uniformly agreed
> to. We
> +  // could do this ONLY if there is a signed and an unsigned that
> both have
> +  // MaxBits, but the code to check that is pretty nasty.  The issue
> will be
> +  // caught in the shrink-to-result later anyway.
> +  if (IsSigned && !AllSigned)
> +++MaxBits;
> +
> +  LHS = APSInt(IsSigned ? LHS.sextOrSelf(MaxBits) :
> LHS.zextOrSelf(MaxBits),
> +   !IsSigned);
> +  RHS = APSInt(IsSigned ? RHS.sextOrSelf(MaxBits) :
> RHS.zextOrSelf(MaxBits),
> +   !IsSigned);
> +  Result = APSInt(MaxBits, !IsSigned);
> +}
> +
> +// Find largest int.
> +switch (BuiltinOp) {
> +default:
> +  llvm_unreachable("Invalid value for BuiltinOp");
> +case Builtin::BI__builtin_add_overflow:
> +case Builtin::BI__builtin_sadd_overflow:
> +case Builtin::BI__builtin_saddl_overflow:
> +case Builtin::BI__builtin_saddll_overflow:
> +case Builtin::BI__builtin_uadd_overflow:
> +case Builtin::BI__builtin_uaddl_overflow:
> +case Builtin::BI__builtin_uaddll_overflow:
> +  Result = LHS.isSigned() ? LHS.sadd_ov(RHS, DidOverflow)
> +  : LHS.uadd_ov(RHS, DidOverflow);
> +  break;
> +case Builtin::BI__builtin_sub_overflow:
> +case Builtin::BI__builtin_ssub_overflow:
> +case 

Re: [clang-tools-extra] r331905 - [tools] Updating PPCallbacks::InclusionDirective calls

2018-05-09 Thread Evgenii Stepanov via cfe-commits
HI,

ASan says there is a use-after-free after this change:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/5410/steps/check-clang%20asan/logs/stdio

MSan also sees a problem, but ASan's is likely closer to the root cause:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/4529/steps/check-clang%20msan/logs/stdio

On Wed, May 9, 2018 at 11:27 AM, Julie Hockett via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: juliehockett
> Date: Wed May  9 11:27:37 2018
> New Revision: 331905
>
> URL: http://llvm.org/viewvc/llvm-project?rev=331905=rev
> Log:
> [tools] Updating PPCallbacks::InclusionDirective calls
>
> [revision] added SrcMgr::CharacteristicKind to the InclusionDirective
> callback, this revision updates instances of it in clang-tools-extra.
>
> Differential Revision: https://reviews.llvm.org/D46615
>
> Modified:
> clang-tools-extra/trunk/clang-move/ClangMove.cpp
> clang-tools-extra/trunk/clang-tidy/llvm/IncludeOrderCheck.cpp
> clang-tools-extra/trunk/clang-tidy/modernize/
> DeprecatedHeadersCheck.cpp
> clang-tools-extra/trunk/clang-tidy/utils/IncludeInserter.cpp
> clang-tools-extra/trunk/clangd/ClangdUnit.cpp
> clang-tools-extra/trunk/clangd/Headers.cpp
> clang-tools-extra/trunk/modularize/CoverageChecker.cpp
> clang-tools-extra/trunk/modularize/PreprocessorTracker.cpp
> clang-tools-extra/trunk/pp-trace/PPCallbacksTracker.cpp
> clang-tools-extra/trunk/pp-trace/PPCallbacksTracker.h
>
> Modified: clang-tools-extra/trunk/clang-move/ClangMove.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clang-move/ClangMove.cpp?rev=331905=331904=331905=diff
> 
> ==
> --- clang-tools-extra/trunk/clang-move/ClangMove.cpp (original)
> +++ clang-tools-extra/trunk/clang-move/ClangMove.cpp Wed May  9 11:27:37
> 2018
> @@ -131,7 +131,8 @@ public:
>clang::CharSourceRange FilenameRange,
>const clang::FileEntry * /*File*/,
>StringRef SearchPath, StringRef
> /*RelativePath*/,
> -  const clang::Module * /*Imported*/) override {
> +  const clang::Module * /*Imported*/,
> +  SrcMgr::CharacteristicKind /*FileType*/)
> override {
>  if (const auto *FileEntry = SM.getFileEntryForID(SM.
> getFileID(HashLoc)))
>MoveTool->addIncludes(FileName, IsAngled, SearchPath,
>  FileEntry->getName(), FilenameRange, SM);
>
> Modified: clang-tools-extra/trunk/clang-tidy/llvm/IncludeOrderCheck.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clang-tidy/llvm/IncludeOrderCheck.cpp?rev=
> 331905=331904=331905=diff
> 
> ==
> --- clang-tools-extra/trunk/clang-tidy/llvm/IncludeOrderCheck.cpp
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/llvm/IncludeOrderCheck.cpp Wed
> May  9 11:27:37 2018
> @@ -28,7 +28,8 @@ public:
>StringRef FileName, bool IsAngled,
>CharSourceRange FilenameRange, const FileEntry
> *File,
>StringRef SearchPath, StringRef RelativePath,
> -  const Module *Imported) override;
> +  const Module *Imported,
> +  SrcMgr::CharacteristicKind FileType) override;
>void EndOfMainFile() override;
>
>  private:
> @@ -76,7 +77,8 @@ static int getPriority(StringRef Filenam
>  void IncludeOrderPPCallbacks::InclusionDirective(
>  SourceLocation HashLoc, const Token , StringRef FileName,
>  bool IsAngled, CharSourceRange FilenameRange, const FileEntry *File,
> -StringRef SearchPath, StringRef RelativePath, const Module *Imported)
> {
> +StringRef SearchPath, StringRef RelativePath, const Module *Imported,
> +SrcMgr::CharacteristicKind FileType) {
>// We recognize the first include as a special main module header and
> want
>// to leave it in the top position.
>IncludeDirective ID = {HashLoc, FilenameRange, FileName, IsAngled,
> false};
>
> Modified: clang-tools-extra/trunk/clang-tidy/modernize/
> DeprecatedHeadersCheck.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clang-tidy/modernize/DeprecatedHeadersCheck.cpp?
> rev=331905=331904=331905=diff
> 
> ==
> --- clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedHeadersCheck.cpp
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedHeadersCheck.cpp
> Wed May  9 11:27:37 2018
> @@ -30,7 +30,8 @@ public:
>StringRef FileName, bool IsAngled,
>CharSourceRange FilenameRange, const FileEntry
> *File,
>StringRef 

Re: [clang-tools-extra] r320486 - [clangd] Introduce a "Symbol" class.

2017-12-12 Thread Evgenii Stepanov via cfe-commits
Hi,

this does not compile for me because of a tag mismatch:
clang-tools-extra/clangd/index/Index.h:52:10: error: class
'DenseMapInfo' was previously declared as a struct
[-Werror,-Wmismatched-tags]
  friend class llvm::DenseMapInfo;

On Tue, Dec 12, 2017 at 7:42 AM, Haojian Wu via cfe-commits
 wrote:
> Author: hokein
> Date: Tue Dec 12 07:42:10 2017
> New Revision: 320486
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320486=rev
> Log:
> [clangd] Introduce a "Symbol" class.
>
> Summary:
> * The "Symbol" class represents a C++ symbol in the codebase, containing all 
> the
>   information of a C++ symbol needed by clangd. clangd will use it in clangd's
>   AST/dynamic index and global/static index (code completion and code
>   navigation).
> * The SymbolCollector (another IndexAction) will be used to recollect the
>   symbols when the source file is changed (for ASTIndex), or to generate
>   all C++ symbols for the whole project.
>
> In the long term (when index-while-building is ready), clangd should share a
> same "Symbol" structure and IndexAction with index-while-building, but
> for now we want to have some stuff working in clangd.
>
> Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
>
> Reviewed By: sammccall
>
> Subscribers: malaperle, klimek, mgorny, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D40897
>
> Added:
> clang-tools-extra/trunk/clangd/index/
> clang-tools-extra/trunk/clangd/index/Index.cpp
> clang-tools-extra/trunk/clangd/index/Index.h
> clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
> clang-tools-extra/trunk/clangd/index/SymbolCollector.h
> clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
> Modified:
> clang-tools-extra/trunk/clangd/CMakeLists.txt
> clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt
>
> Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=320486=320485=320486=diff
> ==
> --- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Dec 12 07:42:10 2017
> @@ -19,6 +19,8 @@ add_clang_library(clangDaemon
>Protocol.cpp
>ProtocolHandlers.cpp
>Trace.cpp
> +  index/Index.cpp
> +  index/SymbolCollector.cpp
>
>LINK_LIBS
>clangAST
>
> Added: clang-tools-extra/trunk/clangd/index/Index.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Index.cpp?rev=320486=auto
> ==
> --- clang-tools-extra/trunk/clangd/index/Index.cpp (added)
> +++ clang-tools-extra/trunk/clangd/index/Index.cpp Tue Dec 12 07:42:10 2017
> @@ -0,0 +1,49 @@
> +//===--- Index.cpp ---*- 
> C++-*-===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--===//
> +
> +#include "Index.h"
> +
> +#include "llvm/Support/SHA1.h"
> +
> +namespace clang {
> +namespace clangd {
> +
> +namespace {
> +ArrayRef toArrayRef(StringRef S) {
> +  return {reinterpret_cast(S.data()), S.size()};
> +}
> +} // namespace
> +
> +SymbolID::SymbolID(llvm::StringRef USR)
> +: HashValue(llvm::SHA1::hash(toArrayRef(USR))) {}
> +
> +SymbolSlab::const_iterator SymbolSlab::begin() const {
> +  return Symbols.begin();
> +}
> +
> +SymbolSlab::const_iterator SymbolSlab::end() const {
> +  return Symbols.end();
> +}
> +
> +SymbolSlab::const_iterator SymbolSlab::find(const SymbolID& SymID) const {
> +  return Symbols.find(SymID);
> +}
> +
> +void SymbolSlab::freeze() {
> +  Frozen = true;
> +}
> +
> +void SymbolSlab::insert(Symbol S) {
> +  assert(!Frozen &&
> + "Can't insert a symbol after the slab has been frozen!");
> +  Symbols[S.ID] = std::move(S);
> +}
> +
> +} // namespace clangd
> +} // namespace clang
>
> Added: clang-tools-extra/trunk/clangd/index/Index.h
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Index.h?rev=320486=auto
> ==
> --- clang-tools-extra/trunk/clangd/index/Index.h (added)
> +++ clang-tools-extra/trunk/clangd/index/Index.h Tue Dec 12 07:42:10 2017
> @@ -0,0 +1,136 @@
> +//===--- Symbol.h ---*- 
> C++-*-===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===-===//
> +
> +#ifndef 

Re: r312467 - Implement Itanium name mangling support for C++ Modules TS.

2017-09-05 Thread Evgenii Stepanov via cfe-commits
Hi Richard,

this change has triggered a bunch of leak reports on the sanitizer bots:

Direct leak of 1824 byte(s) in 1 object(s) allocated from:
#0 0xb48430 in operator new(unsigned long)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:82
#1 0xadfd119 in
clang::ModuleMap::createGlobalModuleForInterfaceUnit(clang::SourceLocation)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Lex/ModuleMap.cpp:750:18
#2 0x860e9be in clang::Sema::ActOnStartOfTranslationUnit()
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Sema/Sema.cpp:775:30
#3 0x7d27209 in
clang::Parser::ParseFirstTopLevelDecl(clang::OpaquePtr&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/Parser.cpp:529:11
#4 0x7d158fe in clang::ParseAST(clang::Sema&, bool, bool)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseAST.cpp:146:23
#5 0x618926e in clang::FrontendAction::Execute()
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:902:8
#6 0x6090664 in
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:986:11
#7 0x637eb45 in
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:252:25
#8 0xb5b13f in cc1_main(llvm::ArrayRef, char const*,
void*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/tools/driver/cc1_main.cpp:221:13
#9 0xb53d33 in ExecuteCC1Tool
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/tools/driver/driver.cpp:302:12
#10 0xb53d33 in main
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/tools/driver/driver.cpp:381
#11 0x7fc921b0b82f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

Failing Tests (16):
Clang :: CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
Clang :: CXX/modules-ts/basic/basic.def.odr/p4/user.cpp
Clang :: CXX/modules-ts/basic/basic.link/module-declaration.cpp
Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp
Clang :: CXX/modules-ts/basic/basic.link/p2/other.cpp
Clang :: CXX/modules-ts/basic/basic.search/module-import.cpp
Clang :: CXX/modules-ts/codegen-basics.cppm
Clang :: CXX/modules-ts/dcl.dcl/dcl.module/dcl.module.import/p1.cpp
Clang :: CXX/modules-ts/dcl.dcl/dcl.module/dcl.module.interface/p1.cpp
Clang :: CXX/modules-ts/dcl.dcl/dcl.module/p5.cpp
Clang :: Driver/modules-ts.cpp
Clang :: Lexer/modules-ts.cpp
Clang :: Modules/diag-flags.cpp
Clang :: Modules/diag-pragma.cpp
Clang :: Modules/import-syntax.c
Clang :: SemaCXX/modules-ts.cppm

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7630

On Sun, Sep 3, 2017 at 10:37 PM, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Sun Sep  3 22:37:53 2017
> New Revision: 312467
>
> URL: http://llvm.org/viewvc/llvm-project?rev=312467=rev
> Log:
> Implement Itanium name mangling support for C++ Modules TS.
>
> This follows the scheme agreed with Nathan Sidwell, which can be found here:
>
>   https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile
>
> This will be proposed to the itanium-cxx-abi list once we have some experience
> with how well it works; the ABI for this TS should be considered unstable 
> until
> it is part of the Itanium C++ ABI.
>
> Modified:
> cfe/trunk/include/clang/AST/Decl.h
> cfe/trunk/include/clang/AST/DeclBase.h
> cfe/trunk/include/clang/Basic/Module.h
> cfe/trunk/include/clang/Lex/ModuleMap.h
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/AST/ItaniumMangle.cpp
> cfe/trunk/lib/Lex/ModuleMap.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cppm
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/user.cpp
> cfe/trunk/test/CXX/modules-ts/codegen-basics.cppm
> cfe/trunk/test/SemaCXX/modules-ts.cppm
>
> Modified: cfe/trunk/include/clang/AST/Decl.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=312467=312466=312467=diff
> ==
> --- cfe/trunk/include/clang/AST/Decl.h (original)
> +++ cfe/trunk/include/clang/AST/Decl.h Sun Sep  3 22:37:53 2017
> @@ -372,6 +372,10 @@ public:
>  return hasCachedLinkage();
>}
>
> +  /// Get the module that owns this declaration 

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

2017-08-22 Thread Evgenii Stepanov via cfe-commits
No. I don't have a easy way of reproducing this.

On Tue, Aug 22, 2017 at 11:10 AM, Hans Wennborg  wrote:
> Is there a bug filed? Since this was merged to 5.0.0, I'd like to know
> if we broke something and if that is something that needs to be fixed.
>
> On Tue, Aug 22, 2017 at 10:46 AM, Evgenii Stepanov
>  wrote:
>> As I understand, using compiler-rt as libgcc replacement on ARM is
>> currently broken because of this change, but I have not looked since
>> my last message.
>>
>> On Mon, Aug 21, 2017 at 4:56 PM, Hans Wennborg  wrote:
>>> Is there something we need for 5.0.0 here?
>>>
>>> On Sat, Aug 12, 2017 at 9:58 PM, Saleem Abdulrasool
>>>  wrote:
 Yeah, we should adjust that.  Technically, it is `_Unwind_Control_Block on
 ARM EHABI.  However, _Unwind_Exception is aliased to that, which is why we
 can use that in the personality routine.  We should adjust the sources for
 the personality routine.

 On Fri, Aug 11, 2017 at 1:12 PM, Evgenii Stepanov
  wrote:
>
> Hi,
>
> I've noticed that the code in
> compiler-rt/lib/builtins/gcc_personality_v0.c refers to
> _Unwind_Exception as "struct _Unwind_Exception". With this change, it
> is not a struct anymore on ARM. Should that code be fixed, or is it a
> problem in this change?
>
> compiler-rt/lib/builtins/gcc_personality_v0.c:153:23: error:
> declaration of 'struct _Unwind_Exception' will not be visible outside
> of this function [-Werror,-Wvisibility]
> continueUnwind(struct _Unwind_Exception *exceptionObject,
>
> On Thu, Jul 27, 2017 at 9:46 AM, Hans Wennborg via cfe-commits
>  wrote:
> > Merged to 5.0 in r309290.
> >
> > On Wed, Jul 26, 2017 at 3:55 PM, Saleem Abdulrasool via cfe-commits
> >  wrote:
> >> Author: compnerd
> >> Date: Wed Jul 26 15:55:23 2017
> >> New Revision: 309226
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=309226=rev
> >> Log:
> >> Headers: improve ARM EHABI coverage of unwind.h
> >>
> >> Ensure that we define the `_Unwind_Control_Block` structure used on ARM
> >> EHABI targets.  This is needed for building libc++abi with the unwind.h
> >> from the resource dir.  A minor fallout of this is that we needed to
> >> create a typedef for _Unwind_Exception to work across ARM EHABI and
> >> non-EHABI targets.  The structure definitions here are based originally
> >> on the documentation from ARM under the "Exception Handling ABI for the
> >> ARM® Architecture" Section 7.2.  They are then adjusted to more closely
> >> reflect the definition in libunwind from LLVM.  Those changes are
> >> compatible in layout but permit easier use in libc++abi and help
> >> maintain compatibility between libunwind and the compiler provided
> >> definition.
> >>
> >> Modified:
> >> cfe/trunk/lib/Headers/unwind.h
> >>
> >> Modified: cfe/trunk/lib/Headers/unwind.h
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/unwind.h?rev=309226=309225=309226=diff
> >>
> >> ==
> >> --- cfe/trunk/lib/Headers/unwind.h (original)
> >> +++ cfe/trunk/lib/Headers/unwind.h Wed Jul 26 15:55:23 2017
> >> @@ -76,7 +76,13 @@ typedef intptr_t _sleb128_t;
> >>  typedef uintptr_t _uleb128_t;
> >>
> >>  struct _Unwind_Context;
> >> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) ||
> >> defined(__ARM_DWARF_EH___))
> >> +struct _Unwind_Control_Block;
> >> +typedef struct _Unwind_Control_Block _Unwind_Exception; /* Alias */
> >> +#else
> >>  struct _Unwind_Exception;
> >> +typedef struct _Unwind_Exception _Unwind_Exception;
> >> +#endif
> >>  typedef enum {
> >>_URC_NO_REASON = 0,
> >>  #if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) && \
> >> @@ -109,8 +115,42 @@ typedef enum {
> >>  } _Unwind_Action;
> >>
> >>  typedef void (*_Unwind_Exception_Cleanup_Fn)(_Unwind_Reason_Code,
> >> - struct _Unwind_Exception
> >> *);
> >> + _Unwind_Exception *);
> >>
> >> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) ||
> >> defined(__ARM_DWARF_EH___))
> >> +typedef struct _Unwind_Control_Block _Unwind_Control_Block;
> >> +typedef uint32_t _Unwind_EHT_Header;
> >> +
> >> +struct _Unwind_Control_Block {
> >> +  uint64_t exception_class;
> >> +  void (*exception_cleanup)(_Unwind_Reason_Code, _Unwind_Control_Block
> >> *);
> >> +  /* unwinder cache (private fields for the unwinder's use) */
> >> +  struct {
> >> +uint32_t reserved1; /* 

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

2017-08-22 Thread Evgenii Stepanov via cfe-commits
As I understand, using compiler-rt as libgcc replacement on ARM is
currently broken because of this change, but I have not looked since
my last message.

On Mon, Aug 21, 2017 at 4:56 PM, Hans Wennborg  wrote:
> Is there something we need for 5.0.0 here?
>
> On Sat, Aug 12, 2017 at 9:58 PM, Saleem Abdulrasool
>  wrote:
>> Yeah, we should adjust that.  Technically, it is `_Unwind_Control_Block on
>> ARM EHABI.  However, _Unwind_Exception is aliased to that, which is why we
>> can use that in the personality routine.  We should adjust the sources for
>> the personality routine.
>>
>> On Fri, Aug 11, 2017 at 1:12 PM, Evgenii Stepanov
>>  wrote:
>>>
>>> Hi,
>>>
>>> I've noticed that the code in
>>> compiler-rt/lib/builtins/gcc_personality_v0.c refers to
>>> _Unwind_Exception as "struct _Unwind_Exception". With this change, it
>>> is not a struct anymore on ARM. Should that code be fixed, or is it a
>>> problem in this change?
>>>
>>> compiler-rt/lib/builtins/gcc_personality_v0.c:153:23: error:
>>> declaration of 'struct _Unwind_Exception' will not be visible outside
>>> of this function [-Werror,-Wvisibility]
>>> continueUnwind(struct _Unwind_Exception *exceptionObject,
>>>
>>> On Thu, Jul 27, 2017 at 9:46 AM, Hans Wennborg via cfe-commits
>>>  wrote:
>>> > Merged to 5.0 in r309290.
>>> >
>>> > On Wed, Jul 26, 2017 at 3:55 PM, Saleem Abdulrasool via cfe-commits
>>> >  wrote:
>>> >> Author: compnerd
>>> >> Date: Wed Jul 26 15:55:23 2017
>>> >> New Revision: 309226
>>> >>
>>> >> URL: http://llvm.org/viewvc/llvm-project?rev=309226=rev
>>> >> Log:
>>> >> Headers: improve ARM EHABI coverage of unwind.h
>>> >>
>>> >> Ensure that we define the `_Unwind_Control_Block` structure used on ARM
>>> >> EHABI targets.  This is needed for building libc++abi with the unwind.h
>>> >> from the resource dir.  A minor fallout of this is that we needed to
>>> >> create a typedef for _Unwind_Exception to work across ARM EHABI and
>>> >> non-EHABI targets.  The structure definitions here are based originally
>>> >> on the documentation from ARM under the "Exception Handling ABI for the
>>> >> ARM® Architecture" Section 7.2.  They are then adjusted to more closely
>>> >> reflect the definition in libunwind from LLVM.  Those changes are
>>> >> compatible in layout but permit easier use in libc++abi and help
>>> >> maintain compatibility between libunwind and the compiler provided
>>> >> definition.
>>> >>
>>> >> Modified:
>>> >> cfe/trunk/lib/Headers/unwind.h
>>> >>
>>> >> Modified: cfe/trunk/lib/Headers/unwind.h
>>> >> URL:
>>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/unwind.h?rev=309226=309225=309226=diff
>>> >>
>>> >> ==
>>> >> --- cfe/trunk/lib/Headers/unwind.h (original)
>>> >> +++ cfe/trunk/lib/Headers/unwind.h Wed Jul 26 15:55:23 2017
>>> >> @@ -76,7 +76,13 @@ typedef intptr_t _sleb128_t;
>>> >>  typedef uintptr_t _uleb128_t;
>>> >>
>>> >>  struct _Unwind_Context;
>>> >> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) ||
>>> >> defined(__ARM_DWARF_EH___))
>>> >> +struct _Unwind_Control_Block;
>>> >> +typedef struct _Unwind_Control_Block _Unwind_Exception; /* Alias */
>>> >> +#else
>>> >>  struct _Unwind_Exception;
>>> >> +typedef struct _Unwind_Exception _Unwind_Exception;
>>> >> +#endif
>>> >>  typedef enum {
>>> >>_URC_NO_REASON = 0,
>>> >>  #if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) && \
>>> >> @@ -109,8 +115,42 @@ typedef enum {
>>> >>  } _Unwind_Action;
>>> >>
>>> >>  typedef void (*_Unwind_Exception_Cleanup_Fn)(_Unwind_Reason_Code,
>>> >> - struct _Unwind_Exception
>>> >> *);
>>> >> + _Unwind_Exception *);
>>> >>
>>> >> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) ||
>>> >> defined(__ARM_DWARF_EH___))
>>> >> +typedef struct _Unwind_Control_Block _Unwind_Control_Block;
>>> >> +typedef uint32_t _Unwind_EHT_Header;
>>> >> +
>>> >> +struct _Unwind_Control_Block {
>>> >> +  uint64_t exception_class;
>>> >> +  void (*exception_cleanup)(_Unwind_Reason_Code, _Unwind_Control_Block
>>> >> *);
>>> >> +  /* unwinder cache (private fields for the unwinder's use) */
>>> >> +  struct {
>>> >> +uint32_t reserved1; /* forced unwind stop function, 0 if not
>>> >> forced */
>>> >> +uint32_t reserved2; /* personality routine */
>>> >> +uint32_t reserved3; /* callsite */
>>> >> +uint32_t reserved4; /* forced unwind stop argument */
>>> >> +uint32_t reserved5;
>>> >> +  } unwinder_cache;
>>> >> +  /* propagation barrier cache (valid after phase 1) */
>>> >> +  struct {
>>> >> +uint32_t sp;
>>> >> +uint32_t bitpattern[5];
>>> >> +  } barrier_cache;
>>> >> +  /* cleanup cache (preserved over cleanup) */
>>> >> +  struct {
>>> >> +uint32_t bitpattern[4];
>>> 

Re: [clang-tools-extra] r311020 - [clang-tidy] Use CloexecCheck as base class.

2017-08-16 Thread Evgenii Stepanov via cfe-commits
Hi,

this change breaks build:
clang-tools-extra/clang-tidy/android/CloexecSocketCheck.cpp:20:30:
error: unused variable 'SOCK_CLOEXEC'
[-Werror,-Wunused-const-variable]
static constexpr const char *SOCK_CLOEXEC = "SOCK_CLOEXEC";

Please test with LLVM_ENABLE_WERROR=ON before submitting!


On Wed, Aug 16, 2017 at 9:59 AM, Chih-Hung Hsieh via cfe-commits
 wrote:
> Author: chh
> Date: Wed Aug 16 09:59:26 2017
> New Revision: 311020
>
> URL: http://llvm.org/viewvc/llvm-project?rev=311020=rev
> Log:
> [clang-tidy] Use CloexecCheck as base class.
>
> Summary:
> Simplify registerMatchers and check functions in CloexecCreatCheck,
> CloexecSocketCheck, CloexecFopenCheck, and CloexecOpenCheck.
>
> Differential Revision: https://reviews.llvm.org/D36761
>
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
> clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
> clang-tools-extra/trunk/clang-tidy/android/CloexecCreatCheck.cpp
> clang-tools-extra/trunk/clang-tidy/android/CloexecCreatCheck.h
> clang-tools-extra/trunk/clang-tidy/android/CloexecFopenCheck.cpp
> clang-tools-extra/trunk/clang-tidy/android/CloexecFopenCheck.h
> clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.cpp
> clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.h
> clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.cpp
> clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.h
>
> Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp?rev=311020=311019=311020=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp (original)
> +++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp Wed Aug 16 
> 09:59:26 2017
> @@ -20,10 +20,6 @@ namespace tidy {
>  namespace android {
>
>  namespace {
> -
> -const char *const FuncDeclBindingStr = "funcDecl";
> -const char *const FuncBindingStr = "func";
> -
>  // Helper function to form the correct string mode for Type3.
>  // Build the replace text. If it's string constant, add  directly in 
> the
>  // end of the string. Else, add .
> @@ -41,6 +37,10 @@ std::string buildFixMsgForStringFlag(con
>  }
>  } // namespace
>
> +constexpr char CloexecCheck::FuncDeclBindingStr[];
> +
> +constexpr char CloexecCheck::FuncBindingStr[];
> +
>  void CloexecCheck::registerMatchersImpl(
>  MatchFinder *Finder, internal::Matcher Function) {
>// We assume all the checked APIs are C functions.
>
> Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h?rev=311020=311019=311020=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h (original)
> +++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h Wed Aug 16 
> 09:59:26 2017
> @@ -90,6 +90,12 @@ protected:
>/// Helper function to get the spelling of a particular argument.
>StringRef getSpellingArg(const ast_matchers::MatchFinder::MatchResult 
> ,
> int N) const;
> +
> +  /// Binding name of the FuncDecl of a function call.
> +  static constexpr char FuncDeclBindingStr[] = "funcDecl";
> +
> +  /// Binding name of the function call expression.
> +  static constexpr char FuncBindingStr[] = "func";
>  };
>
>  } // namespace android
>
> Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecCreatCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCreatCheck.cpp?rev=311020=311019=311020=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/android/CloexecCreatCheck.cpp 
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/android/CloexecCreatCheck.cpp Wed Aug 
> 16 09:59:26 2017
> @@ -10,7 +10,6 @@
>  #include "CloexecCreatCheck.h"
>  #include "clang/AST/ASTContext.h"
>  #include "clang/ASTMatchers/ASTMatchFinder.h"
> -#include "clang/Lex/Lexer.h"
>
>  using namespace clang::ast_matchers;
>
> @@ -21,37 +20,22 @@ namespace android {
>  void CloexecCreatCheck::registerMatchers(MatchFinder *Finder) {
>auto CharPointerType = hasType(pointerType(pointee(isAnyCharacter(;
>auto MODETType = hasType(namedDecl(hasName("mode_t")));
> -
> -  Finder->addMatcher(
> -  callExpr(callee(functionDecl(isExternC(), returns(isInteger()),
> -   hasName("creat"),
> -   hasParameter(0, CharPointerType),
> -   hasParameter(1, MODETType))
> -  .bind("funcDecl")))
> -  .bind("creatFn"),
> -  this);
> +  registerMatchersImpl(Finder,

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

2017-08-11 Thread Evgenii Stepanov via cfe-commits
Hi,

I've noticed that the code in
compiler-rt/lib/builtins/gcc_personality_v0.c refers to
_Unwind_Exception as "struct _Unwind_Exception". With this change, it
is not a struct anymore on ARM. Should that code be fixed, or is it a
problem in this change?

compiler-rt/lib/builtins/gcc_personality_v0.c:153:23: error:
declaration of 'struct _Unwind_Exception' will not be visible outside
of this function [-Werror,-Wvisibility]
continueUnwind(struct _Unwind_Exception *exceptionObject,

On Thu, Jul 27, 2017 at 9:46 AM, Hans Wennborg via cfe-commits
 wrote:
> Merged to 5.0 in r309290.
>
> On Wed, Jul 26, 2017 at 3:55 PM, Saleem Abdulrasool via cfe-commits
>  wrote:
>> Author: compnerd
>> Date: Wed Jul 26 15:55:23 2017
>> New Revision: 309226
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=309226=rev
>> Log:
>> Headers: improve ARM EHABI coverage of unwind.h
>>
>> Ensure that we define the `_Unwind_Control_Block` structure used on ARM
>> EHABI targets.  This is needed for building libc++abi with the unwind.h
>> from the resource dir.  A minor fallout of this is that we needed to
>> create a typedef for _Unwind_Exception to work across ARM EHABI and
>> non-EHABI targets.  The structure definitions here are based originally
>> on the documentation from ARM under the "Exception Handling ABI for the
>> ARM® Architecture" Section 7.2.  They are then adjusted to more closely
>> reflect the definition in libunwind from LLVM.  Those changes are
>> compatible in layout but permit easier use in libc++abi and help
>> maintain compatibility between libunwind and the compiler provided
>> definition.
>>
>> Modified:
>> cfe/trunk/lib/Headers/unwind.h
>>
>> Modified: cfe/trunk/lib/Headers/unwind.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/unwind.h?rev=309226=309225=309226=diff
>> ==
>> --- cfe/trunk/lib/Headers/unwind.h (original)
>> +++ cfe/trunk/lib/Headers/unwind.h Wed Jul 26 15:55:23 2017
>> @@ -76,7 +76,13 @@ typedef intptr_t _sleb128_t;
>>  typedef uintptr_t _uleb128_t;
>>
>>  struct _Unwind_Context;
>> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) || 
>> defined(__ARM_DWARF_EH___))
>> +struct _Unwind_Control_Block;
>> +typedef struct _Unwind_Control_Block _Unwind_Exception; /* Alias */
>> +#else
>>  struct _Unwind_Exception;
>> +typedef struct _Unwind_Exception _Unwind_Exception;
>> +#endif
>>  typedef enum {
>>_URC_NO_REASON = 0,
>>  #if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) && \
>> @@ -109,8 +115,42 @@ typedef enum {
>>  } _Unwind_Action;
>>
>>  typedef void (*_Unwind_Exception_Cleanup_Fn)(_Unwind_Reason_Code,
>> - struct _Unwind_Exception *);
>> + _Unwind_Exception *);
>>
>> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) || 
>> defined(__ARM_DWARF_EH___))
>> +typedef struct _Unwind_Control_Block _Unwind_Control_Block;
>> +typedef uint32_t _Unwind_EHT_Header;
>> +
>> +struct _Unwind_Control_Block {
>> +  uint64_t exception_class;
>> +  void (*exception_cleanup)(_Unwind_Reason_Code, _Unwind_Control_Block *);
>> +  /* unwinder cache (private fields for the unwinder's use) */
>> +  struct {
>> +uint32_t reserved1; /* forced unwind stop function, 0 if not forced */
>> +uint32_t reserved2; /* personality routine */
>> +uint32_t reserved3; /* callsite */
>> +uint32_t reserved4; /* forced unwind stop argument */
>> +uint32_t reserved5;
>> +  } unwinder_cache;
>> +  /* propagation barrier cache (valid after phase 1) */
>> +  struct {
>> +uint32_t sp;
>> +uint32_t bitpattern[5];
>> +  } barrier_cache;
>> +  /* cleanup cache (preserved over cleanup) */
>> +  struct {
>> +uint32_t bitpattern[4];
>> +  } cleanup_cache;
>> +  /* personality cache (for personality's benefit) */
>> +  struct {
>> +uint32_t fnstart; /* function start address */
>> +_Unwind_EHT_Header *ehtp; /* pointer to EHT entry header word */
>> +uint32_t additional;  /* additional data */
>> +uint32_t reserved1;
>> +  } pr_cache;
>> +  long long int : 0; /* force alignment of next item to 8-byte boundary */
>> +};
>> +#else
>>  struct _Unwind_Exception {
>>_Unwind_Exception_Class exception_class;
>>_Unwind_Exception_Cleanup_Fn exception_cleanup;
>> @@ -120,16 +160,18 @@ struct _Unwind_Exception {
>> * aligned".  GCC has interpreted this to mean "use the maximum useful
>> * alignment for the target"; so do we. */
>>  } __attribute__((__aligned__));
>> +#endif
>>
>>  typedef _Unwind_Reason_Code (*_Unwind_Stop_Fn)(int, _Unwind_Action,
>> _Unwind_Exception_Class,
>> -   struct _Unwind_Exception *,
>> +   _Unwind_Exception *,
>> 

Re: r306692 - Initialize variable and silence potentially uninitialized warning.

2017-06-29 Thread Evgenii Stepanov via cfe-commits
This change broke clang/ubsan bot.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6047/steps/check-clang%20ubsan/logs/stdio

It looks like the value you are initializing SavedAK with may itself be
uninitialized? I see a few constructors that do not mention it.


On Thu, Jun 29, 2017 at 9:08 AM, Vassil Vassilev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: vvassilev
> Date: Thu Jun 29 09:08:10 2017
> New Revision: 306692
>
> URL: http://llvm.org/viewvc/llvm-project?rev=306692=rev
> Log:
> Initialize variable and silence potentially uninitialized warning.
>
> Patch by Liza Sakellari!
>
> Modified:
> cfe/trunk/include/clang/Sema/Lookup.h
>
> Modified: cfe/trunk/include/clang/Sema/Lookup.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Lookup.h?rev=306692=306691=306692=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/Lookup.h (original)
> +++ cfe/trunk/include/clang/Sema/Lookup.h Thu Jun 29 09:08:10 2017
> @@ -465,10 +465,9 @@ public:
>  Paths = nullptr;
>}
>  } else {
> -  AmbiguityKind SavedAK;
> +  AmbiguityKind SavedAK = Ambiguity;
>bool WasAmbiguous = false;
>if (ResultKind == Ambiguous) {
> -SavedAK = Ambiguity;
>  WasAmbiguous = true;
>}
>ResultKind = Found;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r305087 - support operator keywords used in Windows SDK

2017-06-09 Thread Evgenii Stepanov via cfe-commits
Hi,

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5571/steps/check-clang%20ubsan/logs/stdio

tools/clang/lib/Parse/ParseExprCXX.cpp:383:26: runtime error:
reference binding to null pointer of type 'clang::IdentifierInfo'
#0 0x5313046 in
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr, bool, bool*, bool,
clang::IdentifierInfo**, bool)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:383:21
#1 0x52d3dc7 in
clang::Parser::ParseDirectDeclarator(clang::Declarator&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:5433:7
#2 0x52d349d in
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&))
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:5254:7
#3 0x52ee74c in
clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&,
clang::VirtSpecifiers&, clang::ActionResult&,
clang::Parser::LateParsedAttrList&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2248:5
#4 0x52efaef in
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2619:7
#5 0x52f147a in
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3079:12
#6 0x52ed276 in
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&,
unsigned int, clang::Decl*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3250:7
#7 0x52eb9ad in
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1910:7
#8 0x52c8c41 in
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3588:7
#9 0x52ef702 in
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2550:3
#10 0x52f147a in
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3079:12
#11 0x52ed276 in
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&,
unsigned int, clang::Decl*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3250:7
#12 0x52eb9ad in
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1910:7
#13 0x52c8c41 in
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3588:7
#14 0x52a89c6 in
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/Parser.cpp:912:3
#15 0x52a8542 in
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/Parser.cpp:993:12
#16 0x52a7b5f in

Re: r304935 - Revert r304929 [mips] Add runtime options to enable/disable madd/sub.fmt

2017-06-07 Thread Evgenii Stepanov via cfe-commits
You've left an empty file in test/CodeGen/mips-madd4.c

On Wed, Jun 7, 2017 at 11:57 AM, Petar Jovanovic via cfe-commits
 wrote:
> Author: petarj
> Date: Wed Jun  7 13:57:56 2017
> New Revision: 304935
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304935=rev
> Log:
> Revert r304929 [mips] Add runtime options to enable/disable madd/sub.fmt
>
> Revert r304929 since the test broke buildbots.
>
> Original commit:
>
>   [mips] Add runtime options to enable/disable madd.fmt and msub.fmt
>
>   Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
>   generation of madd.fmt and similar instructions respectively, as per GCC.
>
>   Patch by Stefan Maksimovic.
>
> Modified:
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
> cfe/trunk/test/CodeGen/mips-madd4.c
> cfe/trunk/test/Preprocessor/init.c
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=304935=304934=304935=diff
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Wed Jun  7 13:57:56 2017
> @@ -2001,10 +2001,6 @@ def mdspr2 : Flag<["-"], "mdspr2">, Grou
>  def mno_dspr2 : Flag<["-"], "mno-dspr2">, Group;
>  def msingle_float : Flag<["-"], "msingle-float">, Group;
>  def mdouble_float : Flag<["-"], "mdouble-float">, Group;
> -def mmadd4 : Flag<["-"], "mmadd4">, Group,
> -  HelpText<"Enable the generation of 4-operand madd.s, madd.d and related 
> instructions.">;
> -def mno_madd4 : Flag<["-"], "mno-madd4">, Group,
> -  HelpText<"Disable the generation of 4-operand madd.s, madd.d and related 
> instructions.">;
>  def mmsa : Flag<["-"], "mmsa">, Group,
>HelpText<"Enable MSA ASE (MIPS only)">;
>  def mno_msa : Flag<["-"], "mno-msa">, Group,
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=304935=304934=304935=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Wed Jun  7 13:57:56 2017
> @@ -7737,7 +7737,6 @@ class MipsTargetInfo : public TargetInfo
>  NoDSP, DSP1, DSP2
>} DspRev;
>bool HasMSA;
> -  bool DisableMadd4;
>
>  protected:
>bool HasFP64;
> @@ -7748,7 +7747,7 @@ public:
>: TargetInfo(Triple), IsMips16(false), IsMicromips(false),
>  IsNan2008(false), IsSingleFloat(false), IsNoABICalls(false),
>  CanUseBSDABICalls(false), FloatABI(HardFloat), DspRev(NoDSP),
> -HasMSA(false), DisableMadd4(false), HasFP64(false) {
> +HasMSA(false), HasFP64(false) {
>  TheCXXABI.set(TargetCXXABI::GenericMIPS);
>
>  setABI((getTriple().getArch() == llvm::Triple::mips ||
> @@ -7994,9 +7993,6 @@ public:
>  if (HasMSA)
>Builder.defineMacro("__mips_msa", Twine(1));
>
> -if (DisableMadd4)
> -  Builder.defineMacro("__mips_no_madd4", Twine(1));
> -
>  Builder.defineMacro("_MIPS_SZPTR", Twine(getPointerWidth(0)));
>  Builder.defineMacro("_MIPS_SZINT", Twine(getIntWidth()));
>  Builder.defineMacro("_MIPS_SZLONG", Twine(getLongWidth()));
> @@ -8159,8 +8155,6 @@ public:
>  DspRev = std::max(DspRev, DSP2);
>else if (Feature == "+msa")
>  HasMSA = true;
> -  else if (Feature == "+nomadd4")
> -DisableMadd4 = true;
>else if (Feature == "+fp64")
>  HasFP64 = true;
>else if (Feature == "-fp64")
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp?rev=304935=304934=304935=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp Wed Jun  7 13:57:56 2017
> @@ -298,13 +298,6 @@ void mips::getMIPSTargetFeatures(const D
>
>AddTargetFeature(Args, Features, options::OPT_mno_odd_spreg,
> options::OPT_modd_spreg, "nooddspreg");
> -
> -  if (Arg *A = Args.getLastArg(options::OPT_mmadd4, options::OPT_mno_madd4)) 
> {
> -if (A->getOption().matches(options::OPT_mmadd4))
> -  Features.push_back("-nomadd4");
> -else
> -  Features.push_back("+nomadd4");
> -  }
>  }
>
>  mips::NanEncoding mips::getSupportedNanEncoding(StringRef ) {
>
> Modified: cfe/trunk/test/CodeGen/mips-madd4.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/mips-madd4.c?rev=304935=304934=304935=diff
> ==
> --- cfe/trunk/test/CodeGen/mips-madd4.c (original)
> +++ cfe/trunk/test/CodeGen/mips-madd4.c Wed Jun  7 13:57:56 2017
> @@ -1,86 +0,0 

Re: r304726 - Rather than rejecting attempts to run preprocessor-only actions on AST files,

2017-06-05 Thread Evgenii Stepanov via cfe-commits
This change leaks memory:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5453/steps/check-clang%20asan/logs/stdio

On Mon, Jun 5, 2017 at 11:10 AM, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Mon Jun  5 13:10:11 2017
> New Revision: 304726
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304726=rev
> Log:
> Rather than rejecting attempts to run preprocessor-only actions on AST files,
> replay the steps taken to create the AST file with the preprocessor-only 
> action
> installed to produce preprocessed output.
>
> This can be used to produce the preprocessed text for an existing .pch or .pcm
> file.
>
> Modified:
> cfe/trunk/include/clang/Basic/LangOptions.h
> cfe/trunk/include/clang/Basic/SourceManager.h
> cfe/trunk/include/clang/Frontend/ASTUnit.h
> cfe/trunk/include/clang/Frontend/FrontendAction.h
> cfe/trunk/lib/Basic/SourceManager.cpp
> cfe/trunk/lib/Frontend/ASTUnit.cpp
> cfe/trunk/lib/Frontend/FrontendAction.cpp
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/test/Modules/preprocess-module.cpp
>
> Modified: cfe/trunk/include/clang/Basic/LangOptions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.h?rev=304726=304725=304726=diff
> ==
> --- cfe/trunk/include/clang/Basic/LangOptions.h (original)
> +++ cfe/trunk/include/clang/Basic/LangOptions.h Mon Jun  5 13:10:11 2017
> @@ -58,6 +58,7 @@ public:
>  SOB_Trapping// -ftrapv
>};
>
> +  // FIXME: Unify with TUKind.
>enum CompilingModuleKind {
>  CMK_None,   ///< Not compiling a module interface at all.
>  CMK_ModuleMap,  ///< Compiling a module from a module map.
>
> Modified: cfe/trunk/include/clang/Basic/SourceManager.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/SourceManager.h?rev=304726=304725=304726=diff
> ==
> --- cfe/trunk/include/clang/Basic/SourceManager.h (original)
> +++ cfe/trunk/include/clang/Basic/SourceManager.h Mon Jun  5 13:10:11 2017
> @@ -722,6 +722,10 @@ public:
>
>void clearIDTables();
>
> +  /// Initialize this source manager suitably to replay the compilation
> +  /// described by \p Old. Requires that \p Old outlive \p *this.
> +  void initializeForReplay(const SourceManager );
> +
>DiagnosticsEngine () const { return Diag; }
>
>FileManager () const { return FileMgr; }
>
> Modified: cfe/trunk/include/clang/Frontend/ASTUnit.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/ASTUnit.h?rev=304726=304725=304726=diff
> ==
> --- cfe/trunk/include/clang/Frontend/ASTUnit.h (original)
> +++ cfe/trunk/include/clang/Frontend/ASTUnit.h Mon Jun  5 13:10:11 2017
> @@ -51,6 +51,7 @@ class DiagnosticsEngine;
>  class FileEntry;
>  class FileManager;
>  class HeaderSearch;
> +class InputKind;
>  class MemoryBufferCache;
>  class Preprocessor;
>  class PCHContainerOperations;
> @@ -305,9 +306,6 @@ private:
>/// (likely to change while trying to use them).
>bool UserFilesAreVolatile : 1;
>
> -  /// \brief The language options used when we load an AST file.
> -  LangOptions ASTFileLangOpts;
> -
>static void ConfigureDiags(IntrusiveRefCntPtr Diags,
>   ASTUnit , bool CaptureDiagnostics);
>
> @@ -702,6 +700,9 @@ public:
>/// \brief Determine what kind of translation unit this AST represents.
>TranslationUnitKind getTranslationUnitKind() const { return TUKind; }
>
> +  /// \brief Determine the input kind this AST unit represents.
> +  InputKind getInputKind() const;
> +
>/// \brief A mapping from a file name to the memory buffer that stores the
>/// remapped contents of that file.
>typedef std::pair RemappedFile;
>
> Modified: cfe/trunk/include/clang/Frontend/FrontendAction.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendAction.h?rev=304726=304725=304726=diff
> ==
> --- cfe/trunk/include/clang/Frontend/FrontendAction.h (original)
> +++ cfe/trunk/include/clang/Frontend/FrontendAction.h Mon Jun  5 13:10:11 2017
> @@ -176,10 +176,10 @@ public:
>virtual TranslationUnitKind getTranslationUnitKind() { return TU_Complete; 
> }
>
>/// \brief Does this action support use with PCH?
> -  virtual bool hasPCHSupport() const { return !usesPreprocessorOnly(); }
> +  virtual bool hasPCHSupport() const { return true; }
>
>/// \brief Does this action support use with AST files?
> -  virtual bool hasASTFileSupport() const { return !usesPreprocessorOnly(); }
> +  virtual bool hasASTFileSupport() const { return true; }
>
>/// \brief Does this action support use with 

Re: r304017 - CodeGen: Define Swift's legal vector types for AArch64, ARM

2017-05-26 Thread Evgenii Stepanov via cfe-commits
But I do not even have this change in my local checkout. Must be something else.

On Fri, May 26, 2017 at 2:33 PM, Evgenii Stepanov
 wrote:
> I've got the same failure locally w/o MSan, in a regular
> release+assertions build on linux x86_64.
>
> On Fri, May 26, 2017 at 2:15 PM, Vitaly Buka via cfe-commits
>  wrote:
>> Could this be the patch
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5228/steps/check-llvm%20msan/logs/stdio
>>
>> FAIL: LLVM :: CodeGen/ARM/arm-shrink-wrapping.ll (5392 of 20818)
>>  TEST 'LLVM :: CodeGen/ARM/arm-shrink-wrapping.ll'
>> FAILED 
>> Script:
>> --
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> -o - -enable-shrink-wrap=true -ifcvt-fn-start=1 -ifcvt-fn-stop=0
>> -mtriple=armv7-apple-ios   |
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> --check-prefix=CHECK --check-prefix=ARM --check-prefix=ENABLE
>> --check-prefix=ARM-ENABLE
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> -o - -enable-shrink-wrap=false -ifcvt-fn-start=1 -ifcvt-fn-stop=0
>> -mtriple=armv7-apple-ios   |
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> --check-prefix=CHECK --check-prefix=ARM --check-prefix=DISABLE
>> --check-prefix=ARM-DISABLE
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> -o - -enable-shrink-wrap=true -ifcvt-fn-start=1 -ifcvt-fn-stop=0
>> -mtriple=thumbv7-apple-ios   |
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> --check-prefix=CHECK --check-prefix=THUMB --check-prefix=ENABLE
>> --check-prefix=THUMB-ENABLE
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> -o - -enable-shrink-wrap=false -ifcvt-fn-start=1 -ifcvt-fn-stop=0
>> -mtriple=thumbv7-apple-ios   |
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
>> --check-prefix=CHECK --check-prefix=THUMB --check-prefix=DISABLE
>> --check-prefix=THUMB-DISABLE
>> --
>> Exit Code: 1
>>
>> Command Output (stderr):
>> --
>> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll:659:10:
>> error: expected string not found in input
>> ; CHECK: bl
>>  ^
>> :375:7: note: scanning from here
>>  vldr s0, LCPI12_0
>>   ^
>> :377:2: note: possible intended match here
>>  bx lr
>>  ^
>>
>>
>>
>> On Fri, May 26, 2017 at 11:11 AM, Arnold Schwaighofer via cfe-commits
>>  wrote:
>>>
>>> Author: arnolds
>>> Date: Fri May 26 13:11:54 2017
>>> New Revision: 304017
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=304017=rev
>>> Log:
>>> CodeGen: Define Swift's legal vector types for AArch64, ARM
>>>
>>> rdar://32401301
>>>
>>> Modified:
>>> cfe/trunk/lib/CodeGen/TargetInfo.cpp
>>> cfe/trunk/test/CodeGen/64bit-swiftcall.c
>>> cfe/trunk/test/CodeGen/arm-swiftcall.c
>>>
>>> Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=304017=304016=304017=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
>>> +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri May 26 13:11:54 2017
>>> @@ -4821,6 +4821,9 @@ private:
>>>bool isSwiftErrorInRegister() const override {
>>>  return true;
>>>}
>>> +
>>> +  bool isLegalVectorTypeForSwift(CharUnits totalSize, llvm::Type *eltTy,
>>> + unsigned elts) const override;
>>>  };
>>>
>>>  class AArch64TargetCodeGenInfo : public TargetCodeGenInfo {
>>> @@ -4994,6 +4997,17 @@ bool AArch64ABIInfo::isIllegalVectorType
>>>return false;
>>>  }
>>>
>>> +bool AArch64ABIInfo::isLegalVectorTypeForSwift(CharUnits totalSize,
>>> +   

Re: r304017 - CodeGen: Define Swift's legal vector types for AArch64, ARM

2017-05-26 Thread Evgenii Stepanov via cfe-commits
I've got the same failure locally w/o MSan, in a regular
release+assertions build on linux x86_64.

On Fri, May 26, 2017 at 2:15 PM, Vitaly Buka via cfe-commits
 wrote:
> Could this be the patch
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5228/steps/check-llvm%20msan/logs/stdio
>
> FAIL: LLVM :: CodeGen/ARM/arm-shrink-wrapping.ll (5392 of 20818)
>  TEST 'LLVM :: CodeGen/ARM/arm-shrink-wrapping.ll'
> FAILED 
> Script:
> --
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> -o - -enable-shrink-wrap=true -ifcvt-fn-start=1 -ifcvt-fn-stop=0
> -mtriple=armv7-apple-ios   |
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> --check-prefix=CHECK --check-prefix=ARM --check-prefix=ENABLE
> --check-prefix=ARM-ENABLE
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> -o - -enable-shrink-wrap=false -ifcvt-fn-start=1 -ifcvt-fn-stop=0
> -mtriple=armv7-apple-ios   |
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> --check-prefix=CHECK --check-prefix=ARM --check-prefix=DISABLE
> --check-prefix=ARM-DISABLE
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> -o - -enable-shrink-wrap=true -ifcvt-fn-start=1 -ifcvt-fn-stop=0
> -mtriple=thumbv7-apple-ios   |
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> --check-prefix=CHECK --check-prefix=THUMB --check-prefix=ENABLE
> --check-prefix=THUMB-ENABLE
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/llc
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> -o - -enable-shrink-wrap=false -ifcvt-fn-start=1 -ifcvt-fn-stop=0
> -mtriple=thumbv7-apple-ios   |
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll
> --check-prefix=CHECK --check-prefix=THUMB --check-prefix=DISABLE
> --check-prefix=THUMB-DISABLE
> --
> Exit Code: 1
>
> Command Output (stderr):
> --
> /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/test/CodeGen/ARM/arm-shrink-wrapping.ll:659:10:
> error: expected string not found in input
> ; CHECK: bl
>  ^
> :375:7: note: scanning from here
>  vldr s0, LCPI12_0
>   ^
> :377:2: note: possible intended match here
>  bx lr
>  ^
>
>
>
> On Fri, May 26, 2017 at 11:11 AM, Arnold Schwaighofer via cfe-commits
>  wrote:
>>
>> Author: arnolds
>> Date: Fri May 26 13:11:54 2017
>> New Revision: 304017
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=304017=rev
>> Log:
>> CodeGen: Define Swift's legal vector types for AArch64, ARM
>>
>> rdar://32401301
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> cfe/trunk/test/CodeGen/64bit-swiftcall.c
>> cfe/trunk/test/CodeGen/arm-swiftcall.c
>>
>> Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=304017=304016=304017=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri May 26 13:11:54 2017
>> @@ -4821,6 +4821,9 @@ private:
>>bool isSwiftErrorInRegister() const override {
>>  return true;
>>}
>> +
>> +  bool isLegalVectorTypeForSwift(CharUnits totalSize, llvm::Type *eltTy,
>> + unsigned elts) const override;
>>  };
>>
>>  class AArch64TargetCodeGenInfo : public TargetCodeGenInfo {
>> @@ -4994,6 +4997,17 @@ bool AArch64ABIInfo::isIllegalVectorType
>>return false;
>>  }
>>
>> +bool AArch64ABIInfo::isLegalVectorTypeForSwift(CharUnits totalSize,
>> +   llvm::Type *eltTy,
>> +   unsigned elts) const {
>> +  if (!llvm::isPowerOf2_32(elts))
>> +return false;
>> +  if (totalSize.getQuantity() != 8 &&
>> +  (totalSize.getQuantity() != 16 || elts == 1))
>> +return false;
>> + 

Re: [libcxx] r302723 - XFAIL is_trivially_copyable test for compilers that don't implement Core 2094

2017-05-19 Thread Evgenii Stepanov via cfe-commits
No, sorry, this is not ToT. This is r298531, which already self
identifies as clang-5.0, but, apparently, does not implement Core
2094. I'll just upgrade.


On Fri, May 19, 2017 at 1:27 PM, Evgenii Stepanov
 wrote:
> Hi,
>
> this test is failing for me with ToT clang (clang -cc1 version 5.0.0
> based upon LLVM 5.0.0svn). All the failing static_assert's mention
> volatile one way or the other.
>
>
>
> On Wed, May 10, 2017 at 1:19 PM, Eric Fiselier via cfe-commits
>  wrote:
>> Author: ericwf
>> Date: Wed May 10 15:19:35 2017
>> New Revision: 302723
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=302723=rev
>> Log:
>> XFAIL is_trivially_copyable test for compilers that don't implement Core 2094
>>
>> Modified:
>> 
>> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>>
>> Modified: 
>> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp?rev=302723=302722=302723=diff
>> ==
>> --- 
>> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>>  (original)
>> +++ 
>> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>>  Wed May 10 15:19:35 2017
>> @@ -11,7 +11,9 @@
>>
>>  // is_trivially_copyable
>>
>> -// XFAIL: gcc-4.9
>> +// These compilers have not implemented Core 2094 which makes volatile
>> +// qualified types trivially copyable.
>> +// XFAIL: clang-3, clang-4, apple-clang, gcc
>>
>>  #include 
>>  #include 
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxx] r302723 - XFAIL is_trivially_copyable test for compilers that don't implement Core 2094

2017-05-19 Thread Evgenii Stepanov via cfe-commits
Hi,

this test is failing for me with ToT clang (clang -cc1 version 5.0.0
based upon LLVM 5.0.0svn). All the failing static_assert's mention
volatile one way or the other.



On Wed, May 10, 2017 at 1:19 PM, Eric Fiselier via cfe-commits
 wrote:
> Author: ericwf
> Date: Wed May 10 15:19:35 2017
> New Revision: 302723
>
> URL: http://llvm.org/viewvc/llvm-project?rev=302723=rev
> Log:
> XFAIL is_trivially_copyable test for compilers that don't implement Core 2094
>
> Modified:
> 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>
> Modified: 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp?rev=302723=302722=302723=diff
> ==
> --- 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>  (original)
> +++ 
> libcxx/trunk/test/std/utilities/meta/meta.unary/meta.unary.prop/is_trivially_copyable.pass.cpp
>  Wed May 10 15:19:35 2017
> @@ -11,7 +11,9 @@
>
>  // is_trivially_copyable
>
> -// XFAIL: gcc-4.9
> +// These compilers have not implemented Core 2094 which makes volatile
> +// qualified types trivially copyable.
> +// XFAIL: clang-3, clang-4, apple-clang, gcc
>
>  #include 
>  #include 
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r301449 - PPCallbacks::MacroUndefined, change signature and add test.

2017-04-26 Thread Evgenii Stepanov via cfe-commits
Please change the signature of all overriding definitions as well.

/code/llvm/tools/clang/lib/CodeGen/MacroPPCallbacks.h:114:50: error:
non-virtual member function marked 'override' hides virtual member
function
  const MacroDefinition ) override;
 ^
/code/llvm/tools/clang/include/clang/Lex/PPCallbacks.h:255:16: note:
hidden overloaded virtual function
'clang::PPCallbacks::MacroUndefined' declared here: different number
of parameters (3 vs 2)
  virtual void MacroUndefined(const Token ,

On Wed, Apr 26, 2017 at 12:47 PM, Frederich Munch via cfe-commits
 wrote:
> Author: marsupial
> Date: Wed Apr 26 14:47:31 2017
> New Revision: 301449
>
> URL: http://llvm.org/viewvc/llvm-project?rev=301449=rev
> Log:
> PPCallbacks::MacroUndefined, change signature and add test.
>
> Summary:
> The PPCallbacks::MacroUndefined callback is currently insufficient for 
> clients that need to track the MacroDirectives.
> This patch adds an additional argument to PPCallbacks::MacroUndefined that is 
> the undef MacroDirective.
>
> Reviewers: bruno, manmanren
>
> Reviewed By: bruno
>
> Subscribers: nemanjai, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D29923
>
> Modified:
> cfe/trunk/include/clang/Lex/PPCallbacks.h
> cfe/trunk/include/clang/Lex/PreprocessingRecord.h
> cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
> cfe/trunk/lib/Lex/PPDirectives.cpp
> cfe/trunk/lib/Lex/PreprocessingRecord.cpp
> cfe/trunk/tools/libclang/Indexing.cpp
> cfe/trunk/unittests/Basic/SourceManagerTest.cpp
>
> Modified: cfe/trunk/include/clang/Lex/PPCallbacks.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/PPCallbacks.h?rev=301449=301448=301449=diff
> ==
> --- cfe/trunk/include/clang/Lex/PPCallbacks.h (original)
> +++ cfe/trunk/include/clang/Lex/PPCallbacks.h Wed Apr 26 14:47:31 2017
> @@ -247,10 +247,14 @@ public:
>}
>
>/// \brief Hook called whenever a macro \#undef is seen.
> +  /// \param Token The active Token
> +  /// \param MD A MacroDefinition for the named macro.
> +  /// \param Undef New MacroDirective if the macro was defined, null 
> otherwise.
>///
>/// MD is released immediately following this callback.
>virtual void MacroUndefined(const Token ,
> -  const MacroDefinition ) {
> +  const MacroDefinition ,
> +  const MacroDirective *Undef) {
>}
>
>/// \brief Hook called whenever the 'defined' operator is seen.
> @@ -439,15 +443,17 @@ public:
>  Second->MacroExpands(MacroNameTok, MD, Range, Args);
>}
>
> -  void MacroDefined(const Token , const MacroDirective *MD) 
> override {
> +  void MacroDefined(const Token ,
> +const MacroDirective *MD) override {
>  First->MacroDefined(MacroNameTok, MD);
>  Second->MacroDefined(MacroNameTok, MD);
>}
>
>void MacroUndefined(const Token ,
> -  const MacroDefinition ) override {
> -First->MacroUndefined(MacroNameTok, MD);
> -Second->MacroUndefined(MacroNameTok, MD);
> +  const MacroDefinition ,
> +  const MacroDirective *Undef) override {
> +First->MacroUndefined(MacroNameTok, MD, Undef);
> +Second->MacroUndefined(MacroNameTok, MD, Undef);
>}
>
>void Defined(const Token , const MacroDefinition ,
>
> Modified: cfe/trunk/include/clang/Lex/PreprocessingRecord.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/PreprocessingRecord.h?rev=301449=301448=301449=diff
> ==
> --- cfe/trunk/include/clang/Lex/PreprocessingRecord.h (original)
> +++ cfe/trunk/include/clang/Lex/PreprocessingRecord.h Wed Apr 26 14:47:31 2017
> @@ -488,7 +488,8 @@ namespace clang {
>  void MacroExpands(const Token , const MacroDefinition ,
>SourceRange Range, const MacroArgs *Args) override;
>  void MacroDefined(const Token , const MacroDirective *MD) override;
> -void MacroUndefined(const Token , const MacroDefinition ) override;
> +void MacroUndefined(const Token , const MacroDefinition ,
> +const MacroDirective *Undef) override;
>  void InclusionDirective(SourceLocation HashLoc, const Token ,
>  StringRef FileName, bool IsAngled,
>  CharSourceRange FilenameRange,
>
> Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=301449=301448=301449=diff
> ==
> --- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
> +++ 

Re: r297298 - [ubsan] Detect UB loads from bitfields

2017-03-08 Thread Evgenii Stepanov via cfe-commits
Thank you, that was quick!

On Wed, Mar 8, 2017 at 4:31 PM, Vedant Kumar  wrote:
> Reverted in r297331.
>
> vedant
>
>> On Mar 8, 2017, at 4:25 PM, Evgenii Stepanov  
>> wrote:
>>
>> This is crashing ubsan bootstrap:
>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio
>>
>> clang-5.0: 
>> /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Instructions.h:1110:
>> void llvm::ICmpInst::AssertOK(): Assertion `getOperand(0)->getType()
>> == getOperand(1)->getType() && "Both operands to ICmp instruction are
>> not of the same type!"' failed.
>> #0 0x01f571ba llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x1f571ba)
>> #1 0x01f54e5e llvm::sys::RunSignalHandlers()
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x1f54e5e)
>> #2 0x01f54fd2 SignalHandler(int)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x1f54fd2)
>> #3 0x7f7decc81390 __restore_rt
>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
>> #4 0x7f7debc0e428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428)
>> #5 0x7f7debc1002a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a)
>> #6 0x7f7debc06bd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7)
>> #7 0x7f7debc06c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
>> #8 0x02155ded llvm::IRBuilder> clang::CodeGen::CGBuilderInserter>::CreateICmp(llvm::CmpInst::Predicate,
>> llvm::Value*, llvm::Value*, llvm::Twine const&)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x2155ded)
>> #9 0x022ade21
>> clang::CodeGen::CodeGenFunction::EmitScalarRangeCheck(llvm::Value*,
>> clang::QualType, clang::SourceLocation)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22ade21)
>> #10 0x022af0ce
>> clang::CodeGen::CodeGenFunction::EmitLoadOfBitfieldLValue(clang::CodeGen::LValue,
>> clang::SourceLocation)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22af0ce)
>> #11 0x022af48f
>> clang::CodeGen::CodeGenFunction::EmitLoadOfLValue(clang::CodeGen::LValue,
>> clang::SourceLocation)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22af48f)
>> #12 0x022df2ab (anonymous
>> namespace)::ScalarExprEmitter::EmitLoadOfLValue(clang::Expr const*)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22df2ab)
>> #13 0x00870194 (anonymous
>> namespace)::ScalarExprEmitter::VisitMemberExpr(clang::MemberExpr*)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x870194)
>> #14 0x022dd7a4 (anonymous
>> namespace)::ScalarExprEmitter::Visit(clang::Expr*)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22dd7a4)
>> #15 0x00870973 (anonymous
>> namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x870973)
>> #16 0x022ddad0 (anonymous
>> namespace)::ScalarExprEmitter::Visit(clang::Expr*)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22ddad0)
>> #17 0x022de763
>> clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*,
>> bool) 
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22de763)
>> #18 0x022a023d
>> clang::CodeGen::CodeGenFunction::EvaluateExprAsBool(clang::Expr
>> const*) 
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22a023d)
>> #19 0x0217f789
>> clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr
>> const*, llvm::BasicBlock*, llvm::BasicBlock*, unsigned long)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x217f789)
>> #20 0x0217fdaf
>> clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr
>> const*, llvm::BasicBlock*, llvm::BasicBlock*, unsigned long)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x217fdaf)
>> #21 0x02148c63
>> clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x2148c63)
>> #22 0x02147b57
>> clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*)
>> (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x2147b57)
>> #23 0x021485ef
>> 

Re: r297298 - [ubsan] Detect UB loads from bitfields

2017-03-08 Thread Evgenii Stepanov via cfe-commits
This is crashing ubsan bootstrap:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio

clang-5.0: 
/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Instructions.h:1110:
void llvm::ICmpInst::AssertOK(): Assertion `getOperand(0)->getType()
== getOperand(1)->getType() && "Both operands to ICmp instruction are
not of the same type!"' failed.
#0 0x01f571ba llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x1f571ba)
#1 0x01f54e5e llvm::sys::RunSignalHandlers()
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x1f54e5e)
#2 0x01f54fd2 SignalHandler(int)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x1f54fd2)
#3 0x7f7decc81390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f7debc0e428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428)
#5 0x7f7debc1002a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a)
#6 0x7f7debc06bd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7)
#7 0x7f7debc06c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x02155ded llvm::IRBuilder::CreateICmp(llvm::CmpInst::Predicate,
llvm::Value*, llvm::Value*, llvm::Twine const&)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x2155ded)
#9 0x022ade21
clang::CodeGen::CodeGenFunction::EmitScalarRangeCheck(llvm::Value*,
clang::QualType, clang::SourceLocation)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22ade21)
#10 0x022af0ce
clang::CodeGen::CodeGenFunction::EmitLoadOfBitfieldLValue(clang::CodeGen::LValue,
clang::SourceLocation)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22af0ce)
#11 0x022af48f
clang::CodeGen::CodeGenFunction::EmitLoadOfLValue(clang::CodeGen::LValue,
clang::SourceLocation)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22af48f)
#12 0x022df2ab (anonymous
namespace)::ScalarExprEmitter::EmitLoadOfLValue(clang::Expr const*)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22df2ab)
#13 0x00870194 (anonymous
namespace)::ScalarExprEmitter::VisitMemberExpr(clang::MemberExpr*)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x870194)
#14 0x022dd7a4 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22dd7a4)
#15 0x00870973 (anonymous
namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x870973)
#16 0x022ddad0 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22ddad0)
#17 0x022de763
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*,
bool) 
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22de763)
#18 0x022a023d
clang::CodeGen::CodeGenFunction::EvaluateExprAsBool(clang::Expr
const*) 
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x22a023d)
#19 0x0217f789
clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr
const*, llvm::BasicBlock*, llvm::BasicBlock*, unsigned long)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x217f789)
#20 0x0217fdaf
clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr
const*, llvm::BasicBlock*, llvm::BasicBlock*, unsigned long)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x217fdaf)
#21 0x02148c63
clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x2148c63)
#22 0x02147b57
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x2147b57)
#23 0x021485ef
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)
(/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang-5.0+0x21485ef)
#24 0x021488f7
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)

Re: [libunwind] r292721 - DWARF: convert error logs to _LIBUNWIND_LOG

2017-01-26 Thread Evgenii Stepanov via cfe-commits
Actually, the bot has been red since Jan 21 with this exact error.

On Thu, Jan 26, 2017 at 2:27 PM, Evgenii Stepanov
 wrote:
> Hi,
>
> I'm not sure why we only see this now, but this change is breaking
> llvm bootstrap with -Werror:
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/732/steps/bootstrap%20clang/logs/stdio
>
> llvm/projects/libunwind/src/config.h:90:41: error: token pasting of
> ',' and __VA_ARGS__ is a GNU extension
> [-Werror,-Wgnu-zero-variadic-macro-arguments]
>   fprintf(stderr, "libunwind: " msg "\n", ##__VA_ARGS__)
>
> On Sat, Jan 21, 2017 at 8:22 AM, Saleem Abdulrasool via cfe-commits
>  wrote:
>> Author: compnerd
>> Date: Sat Jan 21 10:22:55 2017
>> New Revision: 292721
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292721=rev
>> Log:
>> DWARF: convert error logs to _LIBUNWIND_LOG
>>
>> Use the `_LIBUNWIND_LOG` macro instead of the explicit `fprintf` call.
>> NFC.
>>
>> Modified:
>> libunwind/trunk/src/DwarfParser.hpp
>> libunwind/trunk/src/config.h
>>
>> Modified: libunwind/trunk/src/DwarfParser.hpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/DwarfParser.hpp?rev=292721=292720=292721=diff
>> ==
>> --- libunwind/trunk/src/DwarfParser.hpp (original)
>> +++ libunwind/trunk/src/DwarfParser.hpp Sat Jan 21 10:22:55 2017
>> @@ -421,8 +421,7 @@ bool CFI_Parser::parseInstructions(A
>>offset = (int64_t)addressSpace.getULEB128(p, instructionsEnd)
>>* cieInfo.dataAlignFactor;
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(stderr,
>> -"malformed DW_CFA_offset_extended DWARF unwind, reg too 
>> big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_offset_extended, reg too 
>> big");
>>  return false;
>>}
>>results->savedRegisters[reg].location = kRegisterInCFA;
>> @@ -436,9 +435,7 @@ bool CFI_Parser::parseInstructions(A
>>reg = addressSpace.getULEB128(p, instructionsEnd);
>>;
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(
>> -stderr,
>> -"malformed DW_CFA_restore_extended DWARF unwind, reg too 
>> big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_restore_extended, reg too 
>> big");
>>  return false;
>>}
>>results->savedRegisters[reg] = initialState.savedRegisters[reg];
>> @@ -448,8 +445,7 @@ bool CFI_Parser::parseInstructions(A
>>  case DW_CFA_undefined:
>>reg = addressSpace.getULEB128(p, instructionsEnd);
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(stderr,
>> -"malformed DW_CFA_undefined DWARF unwind, reg too big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_undefined, reg too big");
>>  return false;
>>}
>>results->savedRegisters[reg].location = kRegisterUnused;
>> @@ -459,8 +455,7 @@ bool CFI_Parser::parseInstructions(A
>>  case DW_CFA_same_value:
>>reg = addressSpace.getULEB128(p, instructionsEnd);
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(stderr,
>> -"malformed DW_CFA_same_value DWARF unwind, reg too big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_same_value, reg too big");
>>  return false;
>>}
>>//  DW_CFA_same_value unsupported
>> @@ -477,13 +472,11 @@ bool CFI_Parser::parseInstructions(A
>>reg = addressSpace.getULEB128(p, instructionsEnd);
>>reg2 = addressSpace.getULEB128(p, instructionsEnd);
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(stderr,
>> -"malformed DW_CFA_register DWARF unwind, reg too big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_register, reg too big");
>>  return false;
>>}
>>if (reg2 > kMaxRegisterNumber) {
>> -fprintf(stderr,
>> -"malformed DW_CFA_register DWARF unwind, reg2 too big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_register, reg2 too big");
>>  return false;
>>}
>>results->savedRegisters[reg].location = kRegisterInRegister;
>> @@ -525,7 +518,7 @@ bool CFI_Parser::parseInstructions(A
>>reg = addressSpace.getULEB128(p, instructionsEnd);
>>offset = (int64_t)addressSpace.getULEB128(p, instructionsEnd);
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(stderr, "malformed DW_CFA_def_cfa DWARF unwind, reg too 
>> big\n");
>> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_def_cfa, reg too big");
>>  return false;
>>}
>>results->cfaRegister = (uint32_t)reg;
>> @@ -537,9 +530,7 @@ bool CFI_Parser::parseInstructions(A
>>  case DW_CFA_def_cfa_register:
>>reg = addressSpace.getULEB128(p, instructionsEnd);
>>if (reg > kMaxRegisterNumber) {
>> -fprintf(
>> -stderr,
>> -"malformed 

Re: [libunwind] r292721 - DWARF: convert error logs to _LIBUNWIND_LOG

2017-01-26 Thread Evgenii Stepanov via cfe-commits
Hi,

I'm not sure why we only see this now, but this change is breaking
llvm bootstrap with -Werror:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/732/steps/bootstrap%20clang/logs/stdio

llvm/projects/libunwind/src/config.h:90:41: error: token pasting of
',' and __VA_ARGS__ is a GNU extension
[-Werror,-Wgnu-zero-variadic-macro-arguments]
  fprintf(stderr, "libunwind: " msg "\n", ##__VA_ARGS__)

On Sat, Jan 21, 2017 at 8:22 AM, Saleem Abdulrasool via cfe-commits
 wrote:
> Author: compnerd
> Date: Sat Jan 21 10:22:55 2017
> New Revision: 292721
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292721=rev
> Log:
> DWARF: convert error logs to _LIBUNWIND_LOG
>
> Use the `_LIBUNWIND_LOG` macro instead of the explicit `fprintf` call.
> NFC.
>
> Modified:
> libunwind/trunk/src/DwarfParser.hpp
> libunwind/trunk/src/config.h
>
> Modified: libunwind/trunk/src/DwarfParser.hpp
> URL: 
> http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/DwarfParser.hpp?rev=292721=292720=292721=diff
> ==
> --- libunwind/trunk/src/DwarfParser.hpp (original)
> +++ libunwind/trunk/src/DwarfParser.hpp Sat Jan 21 10:22:55 2017
> @@ -421,8 +421,7 @@ bool CFI_Parser::parseInstructions(A
>offset = (int64_t)addressSpace.getULEB128(p, instructionsEnd)
>* cieInfo.dataAlignFactor;
>if (reg > kMaxRegisterNumber) {
> -fprintf(stderr,
> -"malformed DW_CFA_offset_extended DWARF unwind, reg too 
> big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_offset_extended, reg too 
> big");
>  return false;
>}
>results->savedRegisters[reg].location = kRegisterInCFA;
> @@ -436,9 +435,7 @@ bool CFI_Parser::parseInstructions(A
>reg = addressSpace.getULEB128(p, instructionsEnd);
>;
>if (reg > kMaxRegisterNumber) {
> -fprintf(
> -stderr,
> -"malformed DW_CFA_restore_extended DWARF unwind, reg too big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_restore_extended, reg too 
> big");
>  return false;
>}
>results->savedRegisters[reg] = initialState.savedRegisters[reg];
> @@ -448,8 +445,7 @@ bool CFI_Parser::parseInstructions(A
>  case DW_CFA_undefined:
>reg = addressSpace.getULEB128(p, instructionsEnd);
>if (reg > kMaxRegisterNumber) {
> -fprintf(stderr,
> -"malformed DW_CFA_undefined DWARF unwind, reg too big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_undefined, reg too big");
>  return false;
>}
>results->savedRegisters[reg].location = kRegisterUnused;
> @@ -459,8 +455,7 @@ bool CFI_Parser::parseInstructions(A
>  case DW_CFA_same_value:
>reg = addressSpace.getULEB128(p, instructionsEnd);
>if (reg > kMaxRegisterNumber) {
> -fprintf(stderr,
> -"malformed DW_CFA_same_value DWARF unwind, reg too big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_same_value, reg too big");
>  return false;
>}
>//  DW_CFA_same_value unsupported
> @@ -477,13 +472,11 @@ bool CFI_Parser::parseInstructions(A
>reg = addressSpace.getULEB128(p, instructionsEnd);
>reg2 = addressSpace.getULEB128(p, instructionsEnd);
>if (reg > kMaxRegisterNumber) {
> -fprintf(stderr,
> -"malformed DW_CFA_register DWARF unwind, reg too big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_register, reg too big");
>  return false;
>}
>if (reg2 > kMaxRegisterNumber) {
> -fprintf(stderr,
> -"malformed DW_CFA_register DWARF unwind, reg2 too big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_register, reg2 too big");
>  return false;
>}
>results->savedRegisters[reg].location = kRegisterInRegister;
> @@ -525,7 +518,7 @@ bool CFI_Parser::parseInstructions(A
>reg = addressSpace.getULEB128(p, instructionsEnd);
>offset = (int64_t)addressSpace.getULEB128(p, instructionsEnd);
>if (reg > kMaxRegisterNumber) {
> -fprintf(stderr, "malformed DW_CFA_def_cfa DWARF unwind, reg too 
> big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_def_cfa, reg too big");
>  return false;
>}
>results->cfaRegister = (uint32_t)reg;
> @@ -537,9 +530,7 @@ bool CFI_Parser::parseInstructions(A
>  case DW_CFA_def_cfa_register:
>reg = addressSpace.getULEB128(p, instructionsEnd);
>if (reg > kMaxRegisterNumber) {
> -fprintf(
> -stderr,
> -"malformed DW_CFA_def_cfa_register DWARF unwind, reg too big\n");
> +_LIBUNWIND_LOG("malformed DWARF DW_CFA_def_cfa_register, reg too 
> big");
>  return false;
>}
>results->cfaRegister = (uint32_t)reg;
> @@ -567,8 +558,7 @@ bool 

Re: r291179 - Add vec_insert4b and vec_extract4b functions to altivec.h

2017-01-05 Thread Evgenii Stepanov via cfe-commits
Tests on linux/x86_64 are failing with:
fatal error: error in backend: Cannot select: intrinsic %llvm.ppc.vsx.xxinsertw

On Thu, Jan 5, 2017 at 1:43 PM, Sean Fertile via cfe-commits
 wrote:
> Author: sfertile
> Date: Thu Jan  5 15:43:30 2017
> New Revision: 291179
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291179=rev
> Log:
> Add vec_insert4b and vec_extract4b functions to altivec.h
>
> Add builtins for the functions and custom codegen mapping the builtins to 
> their
> corresponding intrinsics and handling the endian related swapping.
>
> https://reviews.llvm.org/D26546
>
> Added:
> cfe/trunk/test/CodeGen/builtins-ppc-error.c
> cfe/trunk/test/CodeGen/builtins-ppc-extractword-error.c
> cfe/trunk/test/CodeGen/builtins-ppc-insertword-error.c
> Modified:
> cfe/trunk/include/clang/Basic/BuiltinsPPC.def
> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> cfe/trunk/lib/Headers/altivec.h
> cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c
>
> Modified: cfe/trunk/include/clang/Basic/BuiltinsPPC.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsPPC.def?rev=291179=291178=291179=diff
> ==
> --- cfe/trunk/include/clang/Basic/BuiltinsPPC.def (original)
> +++ cfe/trunk/include/clang/Basic/BuiltinsPPC.def Thu Jan  5 15:43:30 2017
> @@ -417,6 +417,9 @@ BUILTIN(__builtin_vsx_xvcvhpsp, "V4fV8Us
>  BUILTIN(__builtin_vsx_xvtstdcdp, "V2ULLiV2dIi", "")
>  BUILTIN(__builtin_vsx_xvtstdcsp, "V4UiV4fIi", "")
>
> +BUILTIN(__builtin_vsx_insertword, "V16UcV4UiV16UcIi", "")
> +BUILTIN(__builtin_vsx_extractuword, "V2ULLiV16UcIi", "")
> +
>  // HTM builtins
>  BUILTIN(__builtin_tbegin, "UiUIi", "")
>  BUILTIN(__builtin_tend, "UiUIi", "")
>
> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=291179=291178=291179=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Jan  5 15:43:30 2017
> @@ -35,6 +35,11 @@ using namespace clang;
>  using namespace CodeGen;
>  using namespace llvm;
>
> +static
> +int64_t clamp(int64_t Value, int64_t Low, int64_t High) {
> +  return std::min(High, std::max(Low, Value));
> +}
> +
>  /// getBuiltinLibFunction - Given a builtin id for a function like
>  /// "__builtin_fabsf", return a Function* for "fabsf".
>  llvm::Constant *CodeGenModule::getBuiltinLibFunction(const FunctionDecl *FD,
> @@ -8191,6 +8196,85 @@ Value *CodeGenFunction::EmitPPCBuiltinEx
>  llvm_unreachable("Unknown FMA operation");
>  return nullptr; // Suppress no-return warning
>}
> +
> +  case PPC::BI__builtin_vsx_insertword: {
> +llvm::Function *F = CGM.getIntrinsic(Intrinsic::ppc_vsx_xxinsertw);
> +
> +// Third argument is a compile time constant int. It must be clamped to
> +// to the range [0, 12].
> +ConstantInt *ArgCI = dyn_cast(Ops[2]);
> +assert(ArgCI &&
> +   "Third arg to xxinsertw intrinsic must be constant integer");
> +const int64_t MaxIndex = 12;
> +int64_t Index = clamp(ArgCI->getSExtValue(), 0, MaxIndex);
> +
> +// The builtin semantics don't exactly match the xxinsertw instructions
> +// semantics (which ppc_vsx_xxinsertw follows). The builtin extracts the
> +// word from the first argument, and inserts it in the second argument. 
> The
> +// instruction extracts the word from its second input register and 
> inserts
> +// it into its first input register, so swap the first and second 
> arguments.
> +std::swap(Ops[0], Ops[1]);
> +
> +// Need to cast the second argument from a vector of unsigned int to a
> +// vector of long long.
> +Ops[1] = Builder.CreateBitCast(Ops[1], llvm::VectorType::get(Int64Ty, 
> 2));
> +
> +if (getTarget().isLittleEndian()) {
> +  // Create a shuffle mask of (1, 0)
> +  Constant *ShuffleElts[2] = { ConstantInt::get(Int32Ty, 1),
> +   ConstantInt::get(Int32Ty, 0)
> + };
> +  Constant *ShuffleMask = llvm::ConstantVector::get(ShuffleElts);
> +
> +  // Reverse the double words in the vector we will extract from.
> +  Ops[0] = Builder.CreateBitCast(Ops[0], llvm::VectorType::get(Int64Ty, 
> 2));
> +  Ops[0] = Builder.CreateShuffleVector(Ops[0], Ops[0], ShuffleMask);
> +
> +  // Reverse the index.
> +  Index = MaxIndex - Index;
> +}
> +
> +// Intrinsic expects the first arg to be a vector of int.
> +Ops[0] = Builder.CreateBitCast(Ops[0], llvm::VectorType::get(Int32Ty, 
> 4));
> +Ops[2] = ConstantInt::getSigned(Int32Ty, Index);
> +return Builder.CreateCall(F, Ops);
> +  }
> +
> +  case PPC::BI__builtin_vsx_extractuword: {
> +llvm::Function *F = CGM.getIntrinsic(Intrinsic::ppc_vsx_xxextractuw);
> +
> +// Intrinsic expects the first 

Re: [libcxx] r289963 - [CMake] Put headers relative to clang

2016-12-16 Thread Evgenii Stepanov via cfe-commits
FTR,

buildbot logs:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/2585/steps/test%20tsan%20in%20debug%20compiler-rt%20build/logs/stdio

External project cmake error log:

CMake Error at include/CMakeLists.txt:15 (file):
  file COPY cannot make directory "/include/c++/v1/.": No such file or
  directory


On Fri, Dec 16, 2016 at 5:56 PM, Evgenii Stepanov
 wrote:
> Hi,
>
> this is using LLVM_BINARY_DIR when NOT LIBCXX_USING_INSTALLED_LLVM.
>
> HandleOutOfTreeLLVM.cmake defines LLVM_BINARY_DIR only when
> LIBCXX_USING_INSTALLED_LLVM. Is it supposed to come from the user
> cmake arguments?
>
> This broke sanitizer tests on Linux (check-tsan, check-msan). See
> add_custom_libcxx() in compiler-rt cmake scripts.
>
> On Fri, Dec 16, 2016 at 9:30 AM, Chris Bieneman via cfe-commits
>  wrote:
>> Author: cbieneman
>> Date: Fri Dec 16 11:30:51 2016
>> New Revision: 289963
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=289963=rev
>> Log:
>> [CMake] Put headers relative to clang
>>
>> When libcxx isn't building with an installed LLVM we copy the libcxx headers 
>> into the LLVM build directory so that a clang in that build tree can find 
>> the headers relative to itself.
>>
>> This is only important in situations where you don't have headers installed 
>> under /, which is common these days on Darwin.
>>
>> Modified:
>> libcxx/trunk/include/CMakeLists.txt
>>
>> Modified: libcxx/trunk/include/CMakeLists.txt
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=289963=289962=289963=diff
>> ==
>> --- libcxx/trunk/include/CMakeLists.txt (original)
>> +++ libcxx/trunk/include/CMakeLists.txt Fri Dec 16 11:30:51 2016
>> @@ -10,18 +10,14 @@ set(LIBCXX_HEADER_PATTERN
>>${LIBCXX_SUPPORT_HEADER_PATTERN}
>>)
>>
>> -if (LIBCXX_STANDALONE_BUILD)
>> -  set(LIBCXX_BUILD_ROOT "${LIBCXX_BINARY_DIR}")
>> -else()
>> -  set(LIBCXX_BUILD_ROOT "${LLVM_BINARY_DIR}")
>> +if(NOT LIBCXX_USING_INSTALLED_LLVM)
>> +  file(COPY .
>> +DESTINATION "${LLVM_BINARY_DIR}/include/c++/v1"
>> +FILES_MATCHING
>> +${LIBCXX_HEADER_PATTERN}
>> +)
>>  endif()
>>
>> -file(COPY .
>> -  DESTINATION "${LIBCXX_BUILD_ROOT}/include/c++/v1"
>> -  FILES_MATCHING
>> -  ${LIBCXX_HEADER_PATTERN}
>> -)
>> -
>>  if (LIBCXX_INSTALL_HEADERS)
>>install(DIRECTORY .
>>  DESTINATION include/c++/v1
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxx] r289963 - [CMake] Put headers relative to clang

2016-12-16 Thread Evgenii Stepanov via cfe-commits
Hi,

this is using LLVM_BINARY_DIR when NOT LIBCXX_USING_INSTALLED_LLVM.

HandleOutOfTreeLLVM.cmake defines LLVM_BINARY_DIR only when
LIBCXX_USING_INSTALLED_LLVM. Is it supposed to come from the user
cmake arguments?

This broke sanitizer tests on Linux (check-tsan, check-msan). See
add_custom_libcxx() in compiler-rt cmake scripts.

On Fri, Dec 16, 2016 at 9:30 AM, Chris Bieneman via cfe-commits
 wrote:
> Author: cbieneman
> Date: Fri Dec 16 11:30:51 2016
> New Revision: 289963
>
> URL: http://llvm.org/viewvc/llvm-project?rev=289963=rev
> Log:
> [CMake] Put headers relative to clang
>
> When libcxx isn't building with an installed LLVM we copy the libcxx headers 
> into the LLVM build directory so that a clang in that build tree can find the 
> headers relative to itself.
>
> This is only important in situations where you don't have headers installed 
> under /, which is common these days on Darwin.
>
> Modified:
> libcxx/trunk/include/CMakeLists.txt
>
> Modified: libcxx/trunk/include/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=289963=289962=289963=diff
> ==
> --- libcxx/trunk/include/CMakeLists.txt (original)
> +++ libcxx/trunk/include/CMakeLists.txt Fri Dec 16 11:30:51 2016
> @@ -10,18 +10,14 @@ set(LIBCXX_HEADER_PATTERN
>${LIBCXX_SUPPORT_HEADER_PATTERN}
>)
>
> -if (LIBCXX_STANDALONE_BUILD)
> -  set(LIBCXX_BUILD_ROOT "${LIBCXX_BINARY_DIR}")
> -else()
> -  set(LIBCXX_BUILD_ROOT "${LLVM_BINARY_DIR}")
> +if(NOT LIBCXX_USING_INSTALLED_LLVM)
> +  file(COPY .
> +DESTINATION "${LLVM_BINARY_DIR}/include/c++/v1"
> +FILES_MATCHING
> +${LIBCXX_HEADER_PATTERN}
> +)
>  endif()
>
> -file(COPY .
> -  DESTINATION "${LIBCXX_BUILD_ROOT}/include/c++/v1"
> -  FILES_MATCHING
> -  ${LIBCXX_HEADER_PATTERN}
> -)
> -
>  if (LIBCXX_INSTALL_HEADERS)
>install(DIRECTORY .
>  DESTINATION include/c++/v1
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D26422: Revert "Define __ANDROID_API__ for all Android builds."

2016-11-08 Thread Evgenii Stepanov via cfe-commits
Yes, some bots don't build all the targets.
I think the test should go into Preprocessor/init.c.


On Tue, Nov 8, 2016 at 2:07 PM, Stephen Hines  wrote:
> srhines added a comment.
>
> Reverted because this broke builds:
>
> clang-hexagon-elf
> llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
> clang-ppc64be-linux-multistage
> llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
>
> It isn't clear from the logs why these builds failed, since I did a general 
> build, but perhaps there is something that is stripping out Android-specific 
> targets there.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D26422
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r284960 - [analyzer] Add StdLibraryFunctions checker.

2016-10-24 Thread Evgenii Stepanov via cfe-commits
This code also fails with UBSan:

tools/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:285:62:
runtime error: signed integer overflow: 9223372036854775807 + 1 cannot
be represented in type 'long'
#0 0x5e1642f in (anonymous
namespace)::StdLibraryFunctionsChecker::ValueRange::applyAsWithinRange(llvm::IntrusiveRefCntPtr, clang::ento::CallEvent const&, (anonymous
namespace)::StdLibraryFunctionsChecker::FunctionSummaryTy const&)
const 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:285:62
#1 0x5e0f4c3 in (anonymous
namespace)::StdLibraryFunctionsChecker::ValueRange::apply(llvm::IntrusiveRefCntPtr, clang::ento::CallEvent const&, (anonymous
namespace)::StdLibraryFunctionsChecker::FunctionSummaryTy const&)
const 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:149:16
#2 0x5e0eb00 in (anonymous
namespace)::StdLibraryFunctionsChecker::checkPostCall(clang::ento::CallEvent
const&, clang::ento::CheckerContext&) const
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:350:21


http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/18/steps/check-clang%20ubsan/logs/stdio


On Mon, Oct 24, 2016 at 6:23 AM, Renato Golin via cfe-commits
 wrote:
> On 24 October 2016 at 14:09, Artem Dergachev  wrote:
>> Strange, i'm not receiving any buildbot emails again. Will look through bots
>> manually next time, that doesn't sound too hard. Pushed a hotfix in r284969.
>
> The buildmaster was restarted this weekend and got all old builds data wiped.
>
> I only know because I have a monitoring page.
>
> Galina,
>
> Any info on the server migration and the email configuration?
>
> Thanks!
> --renato
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D20561: Warn when taking address of packed member

2016-06-13 Thread Evgenii Stepanov via cfe-commits
On Mon, Jun 13, 2016 at 4:12 PM, Aaron Ballman  wrote:
> On Mon, Jun 13, 2016 at 6:30 PM, Evgeniy Stepanov  wrote:
>> eugenis added a subscriber: eugenis.
>> eugenis added a comment.
>>
>> In http://reviews.llvm.org/D20561#446031, @aaron.ballman wrote:
>>
>>> In http://reviews.llvm.org/D20561#445824, @rogfer01 wrote:
>>>
>>> > I think I wasn't clear with the purpose of the fix-it: there are a few 
>>> > cases where getting the address of an unaligned pointer is safe (i.e. 
>>> > false positives).
>>> >
>>> > For instance, when I checked Firefox and Chromium there are cases where 
>>> > getting the address of an unaligned pointer is fine. For the particular 
>>> > case of these two browsers, they both use a library (usrsctp) that 
>>> > represents protocol data as packed structs. That library passes addresses 
>>> > of packed fields to `memcpy` and `memmove` which is OK.
>>>
>>>
>>> I think this is a false-positive that should be fixed.
>>
>>
>> This patch was committed without fixing the false positive case, why?
>
> Can you give some more code context, like perhaps a test case we can
> add to the suite? I believe the current behavior should be essentially
> false-positive-free because it only triggers the diagnostic when the
> alignments actually differ, so if there are other false-positives, I
> agree that we should determine a disposition for them.

This is actually the same library the comment above is talking about:
https://bugs.chromium.org/p/chromium/issues/detail?id=619640

>> Could this warning be excluded from -Wall?
>
> Would you like the warning to be excluded from -Wall even if the
> false-positive is fixed?

No, the warning seems useful if the false positive is fixed.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r270039 - [Sema] Allow an external sema source to handle delayed typo corrections.

2016-05-19 Thread Evgenii Stepanov via cfe-commits
Looks like this commit broke the bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-
bootstrap/builds/11738/steps/check-clang%20ubsan/logs/stdio

On Thu, May 19, 2016 at 3:52 AM, Benjamin Kramer via cfe-commits
 wrote:
> Author: d0k
> Date: Thu May 19 05:46:10 2016
> New Revision: 270039
>
> URL: http://llvm.org/viewvc/llvm-project?rev=270039=rev
> Log:
> [Sema] Allow an external sema source to handle delayed typo corrections.
>
> This probably isn't perfectly perfect but allows correcting function calls
> again.
>
> Modified:
> cfe/trunk/lib/Sema/SemaLookup.cpp
> cfe/trunk/unittests/Sema/ExternalSemaSourceTest.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaLookup.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLookup.cpp?rev=270039=270038=270039=diff
> ==
> --- cfe/trunk/lib/Sema/SemaLookup.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaLookup.cpp Thu May 19 05:46:10 2016
> @@ -4781,11 +4781,19 @@ TypoExpr *Sema::CorrectTypoDelayed(
>  const ObjCObjectPointerType *OPT) {
>assert(CCC && "CorrectTypoDelayed requires a CorrectionCandidateCallback");
>
> -  TypoCorrection Empty;
>auto Consumer = makeTypoCorrectionConsumer(
>TypoName, LookupKind, S, SS, std::move(CCC), MemberContext,
>EnteringContext, OPT, Mode == CTK_ErrorRecovery);
>
> +  // Give the external sema source a chance to correct the typo.
> +  TypoCorrection ExternalTypo;
> +  if (ExternalSource && Consumer) {
> +ExternalTypo = ExternalSource->CorrectTypo(
> +TypoName, LookupKind, S, SS, *CCC, MemberContext, EnteringContext, 
> OPT);
> +if (ExternalTypo)
> +  Consumer->addCorrection(ExternalTypo);
> +  }
> +
>if (!Consumer || Consumer->empty())
>  return nullptr;
>
> @@ -4793,7 +4801,7 @@ TypoExpr *Sema::CorrectTypoDelayed(
>// is not more that about a third of the length of the typo's identifier.
>unsigned ED = Consumer->getBestEditDistance(true);
>IdentifierInfo *Typo = TypoName.getName().getAsIdentifierInfo();
> -  if (ED > 0 && Typo->getName().size() / ED < 3)
> +  if (!ExternalTypo && ED > 0 && Typo->getName().size() / ED < 3)
>  return nullptr;
>
>ExprEvalContexts.back().NumTypos++;
>
> Modified: cfe/trunk/unittests/Sema/ExternalSemaSourceTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Sema/ExternalSemaSourceTest.cpp?rev=270039=270038=270039=diff
> ==
> --- cfe/trunk/unittests/Sema/ExternalSemaSourceTest.cpp (original)
> +++ cfe/trunk/unittests/Sema/ExternalSemaSourceTest.cpp Thu May 19 05:46:10 
> 2016
> @@ -39,19 +39,18 @@ public:
>bool Result;
>  };
>
> -// \brief Counts the number of err_using_directive_member_suggest diagnostics
> -// correcting from one namespace to another while still passing all 
> diagnostics
> -// along a chain of consumers.
> -class NamespaceDiagnosticWatcher : public clang::DiagnosticConsumer {
> +/// Counts the number of typo-correcting diagnostics correcting from one 
> name to
> +/// another while still passing all diagnostics along a chain of consumers.
> +class DiagnosticWatcher : public clang::DiagnosticConsumer {
>DiagnosticConsumer *Chained;
> -  std::string FromNS;
> -  std::string ToNS;
> +  std::string FromName;
> +  std::string ToName;
>
>  public:
> -  NamespaceDiagnosticWatcher(StringRef From, StringRef To)
> -  : Chained(nullptr), FromNS(From), ToNS("'"), SeenCount(0) {
> -ToNS.append(To);
> -ToNS.append("'");
> +  DiagnosticWatcher(StringRef From, StringRef To)
> +  : Chained(nullptr), FromName(From), ToName("'"), SeenCount(0) {
> +ToName.append(To);
> +ToName.append("'");
>}
>
>void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
> @@ -61,7 +60,12 @@ public:
>  if (Info.getID() - 1 == diag::err_using_directive_member_suggest) {
>const IdentifierInfo *Ident = Info.getArgIdentifier(0);
>const std::string  = Info.getArgStdStr(1);
> -  if (Ident->getName() == FromNS && CorrectedQuotedStr == ToNS)
> +  if (Ident->getName() == FromName && CorrectedQuotedStr == ToName)
> +++SeenCount;
> +} else if (Info.getID() == diag::err_no_member_suggest) {
> +  auto Ident = DeclarationName::getFromOpaqueInteger(Info.getRawArg(0));
> +  const std::string  = Info.getArgStdStr(3);
> +  if (Ident.getAsString() == FromName && CorrectedQuotedStr == ToName)
>  ++SeenCount;
>  }
>}
> @@ -78,7 +82,7 @@ public:
>  return false;
>}
>
> -  NamespaceDiagnosticWatcher *Chain(DiagnosticConsumer *ToChain) {
> +  DiagnosticWatcher *Chain(DiagnosticConsumer *ToChain) {
>  Chained = ToChain;
>  return this;
>}
> @@ -130,11 +134,53 @@ public:
>int CallCount;
>  };
>
> -// \brief Chains together a vector of NamespaceDiagnosticWatchers and
> +class FunctionTypoProvider : public 

Re: r266005 - Allow simultaneous safestack and stackprotector attributes.

2016-04-12 Thread Evgenii Stepanov via cfe-commits
Thanks, fixed in r266095

On Tue, Apr 12, 2016 at 10:15 AM, Robinson, Paul
 wrote:
>
>
>> -Original Message-
>> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
>> Evgeniy Stepanov via cfe-commits
>> Sent: Monday, April 11, 2016 3:28 PM
>> To: cfe-commits@lists.llvm.org
>> Subject: r266005 - Allow simultaneous safestack and stackprotector
>> attributes.
>>
>> Author: eugenis
>> Date: Mon Apr 11 17:27:55 2016
>> New Revision: 266005
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=266005=rev
>> Log:
>> Allow simultaneous safestack and stackprotector attributes.
>>
>> This is the clang part of http://reviews.llvm.org/D18846.
>> SafeStack instrumentation pass adds stack protector canaries if both
>> attributes are present on a function. StackProtector pass will step
>> back if the function has a safestack attribute.
>>
>> Modified:
>> cfe/trunk/lib/Driver/Tools.cpp
>> cfe/trunk/test/CodeGen/stack-protector.c
>> cfe/trunk/test/Driver/fsanitize.c
>>
>> Modified: cfe/trunk/lib/Driver/Tools.cpp
>> URL: http://llvm.org/viewvc/llvm-
>> project/cfe/trunk/lib/Driver/Tools.cpp?rev=266005=266004=266005
>> =diff
>> ==
>> 
>> --- cfe/trunk/lib/Driver/Tools.cpp (original)
>> +++ cfe/trunk/lib/Driver/Tools.cpp Mon Apr 11 17:27:55 2016
>> @@ -4878,15 +4878,10 @@ void Clang::ConstructJob(Compilation ,
>>
>>// -stack-protector=0 is default.
>>unsigned StackProtectorLevel = 0;
>> -  if (getToolChain().getSanitizerArgs().needsSafeStackRt()) {
>> -Args.ClaimAllArgs(options::OPT_fno_stack_protector);
>> -Args.ClaimAllArgs(options::OPT_fstack_protector_all);
>> -Args.ClaimAllArgs(options::OPT_fstack_protector_strong);
>> -Args.ClaimAllArgs(options::OPT_fstack_protector);
>> -  } else if (Arg *A = Args.getLastArg(options::OPT_fno_stack_protector,
>> -  options::OPT_fstack_protector_all,
>> -
>> options::OPT_fstack_protector_strong,
>> -  options::OPT_fstack_protector)) {
>> +  if (Arg *A = Args.getLastArg(options::OPT_fno_stack_protector,
>> +   options::OPT_fstack_protector_all,
>> +   options::OPT_fstack_protector_strong,
>> +   options::OPT_fstack_protector)) {
>>  if (A->getOption().matches(options::OPT_fstack_protector)) {
>>StackProtectorLevel = std::max(
>>LangOptions::SSPOn,
>>
>> Modified: cfe/trunk/test/CodeGen/stack-protector.c
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/stack-
>> protector.c?rev=266005=266004=266005=diff
>> ==
>> 
>> --- cfe/trunk/test/CodeGen/stack-protector.c (original)
>> +++ cfe/trunk/test/CodeGen/stack-protector.c Mon Apr 11 17:27:55 2016
>> @@ -1,13 +1,13 @@
>> -// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 0 | FileCheck -
>> check-prefix=NOSSP %s
>> -// NOSSP: define {{.*}}void @test1(i8* %msg) #0 {
>> -// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 1 | FileCheck -
>> check-prefix=WITHSSP %s
>> -// WITHSSP: define {{.*}}void @test1(i8* %msg) #0 {
>> -// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 2 | FileCheck -
>> check-prefix=SSPSTRONG %s
>> -// SSPSTRONG: define {{.*}}void @test1(i8* %msg) #0 {
>> -// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 3 | FileCheck -
>> check-prefix=SSPREQ %s
>> -// SSPREQ: define {{.*}}void @test1(i8* %msg) #0 {
>> -// RUN: %clang_cc1 -emit-llvm -o - %s -fsanitize=safe-stack | FileCheck -
>> check-prefix=SAFESTACK %s
>> -// SAFESTACK: define {{.*}}void @test1(i8* %msg) #0 {
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 0 | FileCheck -
>> check-prefix=DEF -check-prefix=NOSSP %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 1 | FileCheck -
>> check-prefix=DEF -check-prefix=SSP %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 2 | FileCheck -
>> check-prefix=DEF -check-prefix=SSPSTRONG %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -stack-protector 3 | FileCheck -
>> check-prefix=DEF -check-prefix=SSPREQ %s
>> +
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -fsanitize=safe-stack | FileCheck -
>> check-prefix=DEF -check-prefix=SAFESTACK-NOSSP %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -fsanitize=safe-stack -stack-
>> protector 0 | FileCheck -check-prefix=DEF -check-prefix=SAFESTACK-NOSSP %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -fsanitize=safe-stack -stack-
>> protector 1 | FileCheck -check-prefix=DEF -check-prefix=SAFESTACK-SSP %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -fsanitize=safe-stack -stack-
>> protector 2 | FileCheck -check-prefix=DEF -check-prefix=SAFESTACK-
>> SSPSTRONG %s
>> +// RUN: %clang_cc1 -emit-llvm -o - %s -fsanitize=safe-stack -stack-
>> protector 3 | FileCheck -check-prefix=DEF -check-prefix=SAFESTACK-SSPREQ
>> %s
>>
>>  

Re: r263429 - [Frontend] Disable value name discarding for all sanitizers.

2016-03-14 Thread Evgenii Stepanov via cfe-commits
On Mon, Mar 14, 2016 at 8:48 AM, Benjamin Kramer  wrote:
> On Mon, Mar 14, 2016 at 3:59 PM, David Blaikie  wrote:
>> Yeah - how are they relying on them in a non-asserts build anyway? (were we
>> naming certain things regardless of +/-Asserts? (well, I know we were naming
>> some things, but mostly down in LLVM, I thought Clang generally used the
>> IRBuilder & thus didn't name things in non-Asserts builds))
>
> Allocas used to always have names as a debugging feature, see r246991.
>
>> On Mon, Mar 14, 2016 at 6:36 AM, Chandler Carruth via cfe-commits
>>  wrote:
>>>
>>> A long time ago I argued that the sanitizers should be using debug info
>>> instead of alloca names for this, and I really thought that they had
>>> implemented this... Is that not the case?
>>>
>>> It is really bad that the sanitizers are relying on this stuff...

We've never implemented this though I think Alexey looked into it at
one point. We'd need to refactor the handling of debug options
(-g/-gline-tables-only) so that debug metadata is emitted with ASan
even without -g and then discarded in the backend.

>>>
>>> On Mon, Mar 14, 2016 at 2:28 PM Benjamin Kramer via cfe-commits
>>>  wrote:

 Author: d0k
 Date: Mon Mar 14 08:23:58 2016
 New Revision: 263429

 URL: http://llvm.org/viewvc/llvm-project?rev=263429=rev
 Log:
 [Frontend] Disable value name discarding for all sanitizers.

 ASan also relies on names on allocas and will emit unhelpful output if
 they're not present. Just force-enable value names for now. Should
 unbreak release builds of asan.

 Modified:
 cfe/trunk/lib/Frontend/CompilerInvocation.cpp

 Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=263429=263428=263429=diff

 ==
 --- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
 +++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Mon Mar 14 08:23:58
 2016
 @@ -541,6 +541,7 @@ static bool ParseCodeGenArgs(CodeGenOpti
Opts.DisableFPElim =
(Args.hasArg(OPT_mdisable_fp_elim) || Args.hasArg(OPT_pg));
Opts.DisableFree = Args.hasArg(OPT_disable_free);
 +  Opts.DiscardValueNames = Args.hasArg(OPT_discard_value_names);
Opts.DisableTailCalls = Args.hasArg(OPT_mdisable_tail_calls);
Opts.FloatABI = Args.getLastArgValue(OPT_mfloat_abi);
if (Arg *A = Args.getLastArg(OPT_meabi)) {
 @@ -793,12 +794,6 @@ static bool ParseCodeGenArgs(CodeGenOpti
Opts.CudaGpuBinaryFileNames =
Args.getAllArgValues(OPT_fcuda_include_gpubinary);

 -  // DiscardValueNames is set here so that it can depend (perhaps
 temporarily)
 -  // on other options.
 -  // We check SanitizeMemoryTrackOrigins here because the backend pass
 depends
 -  // on the name of the alloca in order to print out names.
 -  Opts.DiscardValueNames =
 -  Args.hasArg(OPT_discard_value_names) &&
 !Opts.SanitizeMemoryTrackOrigins;
return Success;
  }

 @@ -2158,6 +2153,12 @@ bool CompilerInvocation::CreateFromArgs(
  if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
Res.getLangOpts()->ObjCExceptions = 1;
}
 +
 +  // FIXME: Override value name discarding when sanitizers are used
 because the
 +  // backend passes depend on the name of the alloca in order to print
 out
 +  // names.
 +  Res.getCodeGenOpts().DiscardValueNames &=
 Res.getLangOpts()->Sanitize.empty();
 +
// FIXME: ParsePreprocessorArgs uses the FileManager to read the
 contents of
// PCH file and find the original header name. Remove the need to do
 that in
// ParsePreprocessorArgs and remove the FileManager


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


Re: [libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

2016-02-17 Thread Evgenii Stepanov via cfe-commits
Thank you!

On Wed, Feb 17, 2016 at 9:23 PM, Eric Fiselier  wrote:
> Hopefully fixed in r261180.
>
> On Sat, Feb 13, 2016 at 2:08 PM, Evgenii Stepanov
>  wrote:
>>
>> Hi,
>>
>> this is my error message:
>>
>> In file included from z.cc:1:
>> /code/build-llvm/bin/../include/c++/v1/ext/hash_map:213:5: warning:
>> Use of the header  is deprecated. Migrate to
>>  [-W#warnings]
>> #   warning Use of the header  is deprecated.  Migrate
>> to 
>> ^
>> /code/build-llvm/bin/../include/c++/v1/ext/hash_map:432:57: error:
>> '__non_const_iterator' is a private member of
>>
>> 'std::__1::__hash_const_iterator> int>, void *> *>'
>> __hash_map_iterator> _HashIterator::__non_const_iterator> __i)
>> ^
>> /code/build-llvm/bin/../include/c++/v1/ext/hash_map:659:16: note: in
>> instantiation of template class
>>
>> '__gnu_cxx::__hash_map_const_iterator> int>, void *> *> >' requested here
>> insert(__u.begin(), __u.end());
>>^
>> z.cc:4:16: note: in instantiation of member function
>> '__gnu_cxx::hash_map> std::__1::equal_to, std::__1::allocator   int, int> > >::hash_map' requested here
>> template class hash_map;
>>^
>> /code/build-llvm/bin/../include/c++/v1/__hash_table:383:39: note:
>> implicitly declared private here
>> typedef __hash_iterator<_NodePtr> __non_const_iterator;
>>   ^
>> 1 warning and 1 error generated.
>>
>>
>> and this is my test case:
>>
>> #include 
>>
>> namespace __gnu_cxx {
>> template class hash_map;
>> }
>>
>>
>> On Sat, Feb 13, 2016 at 12:17 AM, Eric Fiselier  wrote:
>> >> The "hash_map" part of the name means they belong to "",
>> >> and the actual type is defined in that header.
>> >
>> > Woops, Sorry I guess the name is used in both "std::__1::" in
>> > unordered_map
>> > and "__gnu_cxx::" in . My intention in the changes was to
>> > forward declare "std::__1::__hash_map_iterator".
>> >
>> > On Sat, Feb 13, 2016 at 1:11 AM, Eric Fiselier  wrote:
>> >>
>> >> > hash_map still looks broken to me.
>> >>
>> >> Uh oh, Sorry :-S. The original breakage was caused by the removal of a
>> >> typedef "hash_map" used, but I'm sure I fixed that.
>> >>
>> >> > should not they be prefixed with __gnu_cxx:: ?
>> >>
>> >> No, they are in the correct namespace. The "hash_map" part of the name
>> >> means they belong to "", and the actual type is defined
>> >> in
>> >> that header.
>> >>
>> >> Could you give me more information about the breakage your seeing? The
>> >> actual compiler diagnostics if possible? I also committed other sizable
>> >> changes to <__hash_table> in r260513 so that may be related.
>> >>
>> >> Let me know if you need this reverted. If possible I would like to hold
>> >> off, at least until more is known.
>> >>
>> >> /Eric
>> >>
>> >> On Fri, Feb 12, 2016 at 1:31 PM, Evgenii Stepanov
>> >>  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> hash_map still looks broken to me.
>> >>> I don't have a simple reproducer, but these declarations in
>> >>> __hash_table:
>> >>>
>> >>> template  class _LIBCPP_TYPE_VIS_ONLY
>> >>> __hash_map_iterator;
>> >>>  template  class _LIBCPP_TYPE_VIS_ONLY
>> >>> __hash_map_const_iterator;
>> >>>
>> >>> should not they be prefixed with __gnu_cxx:: ?
>> >>>
>> >>> Clang says that std::__1::__hash_const_iterator and
>> >>> __gnu_cxx::__hash_map_const_iterator are not friends and
>> >>> __non_const_iterator at ext/hash_map:432 is private.
>> >>>
>> >>>
>> >>> On Wed, Feb 10, 2016 at 12:46 PM, Eric Fiselier via cfe-commits
>> >>>  wrote:
>> >>> > Author: ericwf
>> >>> > Date: Wed Feb 10 14:46:23 2016
>> >>> > New Revision: 260431
>> >>> >
>> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=260431=rev
>> >>> > Log:
>> >>> > Recommit r260012 - Cleanup node-type handling in the unordered
>> >>> > containers.
>> >>> >
>> >>> > This time I kept  working!
>> >>> >
>> >>> > This patch is the first in a series of patches that's meant to
>> >>> > better
>> >>> > support unordered_map. unordered_map has a special "value_type" that
>> >>> > differs from pair. In order to meet the
>> >>> > EmplaceConstructible
>> >>> > and CopyInsertable requirements we need to teach __hash_table about
>> >>> > this
>> >>> > special value_type.
>> >>> >
>> >>> > This patch creates a "__hash_node_types" traits class that contains
>> >>> > all of the typedefs needed by the unordered containers and it's
>> >>> > iterators.
>> >>> > These typedefs include ones for each node type and  node pointer
>> >>> > type,
>> >>> > as well as special typedefs for "unordered_map"'s value type.
>> >>> >
>> >>> > As a result of this change all of the unordered containers 

Re: [libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

2016-02-13 Thread Evgenii Stepanov via cfe-commits
Hi,

this is my error message:

In file included from z.cc:1:
/code/build-llvm/bin/../include/c++/v1/ext/hash_map:213:5: warning:
Use of the header  is deprecated. Migrate to
 [-W#warnings]
#   warning Use of the header  is deprecated.  Migrate
to 
^
/code/build-llvm/bin/../include/c++/v1/ext/hash_map:432:57: error:
'__non_const_iterator' is a private member of
  'std::__1::__hash_const_iterator, void *> *>'
__hash_map_iterator __i)
^
/code/build-llvm/bin/../include/c++/v1/ext/hash_map:659:16: note: in
instantiation of template class
  
'__gnu_cxx::__hash_map_const_iterator, void *> *> >' requested here
insert(__u.begin(), __u.end());
   ^
z.cc:4:16: note: in instantiation of member function
'__gnu_cxx::hash_map >::hash_map' requested here
template class hash_map;
   ^
/code/build-llvm/bin/../include/c++/v1/__hash_table:383:39: note:
implicitly declared private here
typedef __hash_iterator<_NodePtr> __non_const_iterator;
  ^
1 warning and 1 error generated.


and this is my test case:

#include 

namespace __gnu_cxx {
template class hash_map;
}


On Sat, Feb 13, 2016 at 12:17 AM, Eric Fiselier  wrote:
>> The "hash_map" part of the name means they belong to "",
>> and the actual type is defined in that header.
>
> Woops, Sorry I guess the name is used in both "std::__1::" in unordered_map
> and "__gnu_cxx::" in . My intention in the changes was to
> forward declare "std::__1::__hash_map_iterator".
>
> On Sat, Feb 13, 2016 at 1:11 AM, Eric Fiselier  wrote:
>>
>> > hash_map still looks broken to me.
>>
>> Uh oh, Sorry :-S. The original breakage was caused by the removal of a
>> typedef "hash_map" used, but I'm sure I fixed that.
>>
>> > should not they be prefixed with __gnu_cxx:: ?
>>
>> No, they are in the correct namespace. The "hash_map" part of the name
>> means they belong to "", and the actual type is defined in
>> that header.
>>
>> Could you give me more information about the breakage your seeing? The
>> actual compiler diagnostics if possible? I also committed other sizable
>> changes to <__hash_table> in r260513 so that may be related.
>>
>> Let me know if you need this reverted. If possible I would like to hold
>> off, at least until more is known.
>>
>> /Eric
>>
>> On Fri, Feb 12, 2016 at 1:31 PM, Evgenii Stepanov
>>  wrote:
>>>
>>> Hi,
>>>
>>> hash_map still looks broken to me.
>>> I don't have a simple reproducer, but these declarations in __hash_table:
>>>
>>> template  class _LIBCPP_TYPE_VIS_ONLY
>>> __hash_map_iterator;
>>>  template  class _LIBCPP_TYPE_VIS_ONLY
>>> __hash_map_const_iterator;
>>>
>>> should not they be prefixed with __gnu_cxx:: ?
>>>
>>> Clang says that std::__1::__hash_const_iterator and
>>> __gnu_cxx::__hash_map_const_iterator are not friends and
>>> __non_const_iterator at ext/hash_map:432 is private.
>>>
>>>
>>> On Wed, Feb 10, 2016 at 12:46 PM, Eric Fiselier via cfe-commits
>>>  wrote:
>>> > Author: ericwf
>>> > Date: Wed Feb 10 14:46:23 2016
>>> > New Revision: 260431
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=260431=rev
>>> > Log:
>>> > Recommit r260012 - Cleanup node-type handling in the unordered
>>> > containers.
>>> >
>>> > This time I kept  working!
>>> >
>>> > This patch is the first in a series of patches that's meant to better
>>> > support unordered_map. unordered_map has a special "value_type" that
>>> > differs from pair. In order to meet the
>>> > EmplaceConstructible
>>> > and CopyInsertable requirements we need to teach __hash_table about
>>> > this
>>> > special value_type.
>>> >
>>> > This patch creates a "__hash_node_types" traits class that contains
>>> > all of the typedefs needed by the unordered containers and it's
>>> > iterators.
>>> > These typedefs include ones for each node type and  node pointer type,
>>> > as well as special typedefs for "unordered_map"'s value type.
>>> >
>>> > As a result of this change all of the unordered containers now all
>>> > support
>>> > incomplete types.
>>> >
>>> > As a drive-by fix I changed the difference_type in __hash_table to
>>> > always
>>> > be ptrdiff_t. There is a corresponding change to size_type but it
>>> > cannot
>>> > take affect until an ABI break.
>>> >
>>> > This patch will be followed up shortly with fixes for various
>>> > unordered_map
>>> > bugs and problems.
>>> >
>>> > Added:
>>> > libcxx/trunk/test/libcxx/containers/unord/key_value_traits.pass.cpp
>>> >
>>> > libcxx/trunk/test/std/containers/unord/iterator_difference_type.pass.cpp
>>> >
>>> > libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp

Re: [libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

2016-02-12 Thread Evgenii Stepanov via cfe-commits
Hi,

hash_map still looks broken to me.
I don't have a simple reproducer, but these declarations in __hash_table:

template  class _LIBCPP_TYPE_VIS_ONLY __hash_map_iterator;
 template  class _LIBCPP_TYPE_VIS_ONLY
__hash_map_const_iterator;

should not they be prefixed with __gnu_cxx:: ?

Clang says that std::__1::__hash_const_iterator and
__gnu_cxx::__hash_map_const_iterator are not friends and
__non_const_iterator at ext/hash_map:432 is private.


On Wed, Feb 10, 2016 at 12:46 PM, Eric Fiselier via cfe-commits
 wrote:
> Author: ericwf
> Date: Wed Feb 10 14:46:23 2016
> New Revision: 260431
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260431=rev
> Log:
> Recommit r260012 - Cleanup node-type handling in the unordered containers.
>
> This time I kept  working!
>
> This patch is the first in a series of patches that's meant to better
> support unordered_map. unordered_map has a special "value_type" that
> differs from pair. In order to meet the EmplaceConstructible
> and CopyInsertable requirements we need to teach __hash_table about this
> special value_type.
>
> This patch creates a "__hash_node_types" traits class that contains
> all of the typedefs needed by the unordered containers and it's iterators.
> These typedefs include ones for each node type and  node pointer type,
> as well as special typedefs for "unordered_map"'s value type.
>
> As a result of this change all of the unordered containers now all support
> incomplete types.
>
> As a drive-by fix I changed the difference_type in __hash_table to always
> be ptrdiff_t. There is a corresponding change to size_type but it cannot
> take affect until an ABI break.
>
> This patch will be followed up shortly with fixes for various unordered_map
> bugs and problems.
>
> Added:
> libcxx/trunk/test/libcxx/containers/unord/key_value_traits.pass.cpp
> libcxx/trunk/test/std/containers/unord/iterator_difference_type.pass.cpp
> libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp
> libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp
> libcxx/trunk/test/std/containers/unord/unord.multiset/incomplete.pass.cpp
> libcxx/trunk/test/std/containers/unord/unord.set/incomplete.pass.cpp
> Modified:
> libcxx/trunk/include/__config
> libcxx/trunk/include/__hash_table
> libcxx/trunk/include/ext/hash_map
> libcxx/trunk/include/unordered_map
>
> Modified: libcxx/trunk/include/__config
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=260431=260430=260431=diff
> ==
> --- libcxx/trunk/include/__config (original)
> +++ libcxx/trunk/include/__config Wed Feb 10 14:46:23 2016
> @@ -42,6 +42,7 @@
>  // Fix undefined behavior in how std::list stores it's linked nodes.
>  #define _LIBCPP_ABI_LIST_REMOVE_NODE_POINTER_UB
>  #define _LIBCPP_ABI_FORWARD_LIST_REMOVE_NODE_POINTER_UB
> +#define _LIBCPP_ABI_FIX_UNORDERED_CONTAINER_SIZE_TYPE
>  #endif
>
>  #define _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_X##_LIBCPP_Y
>
> Modified: libcxx/trunk/include/__hash_table
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=260431=260430=260431=diff
> ==
> --- libcxx/trunk/include/__hash_table (original)
> +++ libcxx/trunk/include/__hash_table Wed Feb 10 14:46:23 2016
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include <__undef_min_max>
>  #include <__undef___deallocate>
> @@ -49,10 +50,10 @@ struct __hash_node
>   typename __rebind_pointer<_VoidPtr, __hash_node<_Tp, 
> _VoidPtr> >::type
>   >
>  {
> -typedef _Tp value_type;
> +typedef _Tp __node_value_type;
>
>  size_t __hash_;
> -value_type __value_;
> +__node_value_type __value_;
>  };
>
>  inline _LIBCPP_INLINE_VISIBILITY
> @@ -77,23 +78,126 @@ __next_hash_pow2(size_t __n)
>  }
>
>  template  class 
> __hash_table;
> +
> +template   class _LIBCPP_TYPE_VIS_ONLY __hash_iterator;
>  template  class _LIBCPP_TYPE_VIS_ONLY 
> __hash_const_iterator;
> +template   class _LIBCPP_TYPE_VIS_ONLY 
> __hash_local_iterator;
> +template  class _LIBCPP_TYPE_VIS_ONLY 
> __hash_const_local_iterator;
>  template  class _LIBCPP_TYPE_VIS_ONLY 
> __hash_map_iterator;
>  template  class _LIBCPP_TYPE_VIS_ONLY 
> __hash_map_const_iterator;
>
> +#if __cplusplus >= 201103L
> +template 
> +union __hash_value_type;
> +#else
> +template 
> +struct __hash_value_type;
> +#endif
> +
> +template 
> +struct __key_value_types {
> +  static_assert(!is_reference<_Tp>::value && !is_const<_Tp>::value, "");
> +  typedef _Tp key_type;
> +  typedef _Tp __node_value_type;
> +  typedef _Tp __container_value_type;
> +  static const bool __is_map = false;
> +};
> +
> +template 
> +struct __key_value_types<__hash_value_type<_Key, _Tp> > {
> +  typedef _Key   

Re: r258128 - Add -Wexpansion-to-undefined: warn when using `defined` in a macro definition.

2016-01-19 Thread Evgenii Stepanov via cfe-commits
This broke all WERROR bots. Sounds like this warning should be
disabled by default.

On Tue, Jan 19, 2016 at 8:15 AM, Krzysztof Parzyszek via cfe-commits
 wrote:
> This generates hundreds of warnings when doing check-all.
>
> Here's the offending code:
>
>
> utils/unittest/googletest/include/gtest/internal/gtest-port.h
>
> // Cygwin 1.7 and below doesn't support ::std::wstring.
> // Solaris' libc++ doesn't support it either.  Android has
> // no support for it at least as recent as Froyo (2.2).
> // Minix currently doesn't support it either.
> # define GTEST_HAS_STD_WSTRING \
> (!(GTEST_OS_LINUX_ANDROID || GTEST_OS_CYGWIN || GTEST_OS_SOLARIS ||
> GTEST_OS_HAIKU || defined(_MINIX)))
>
>
> -Krzysztof
>
>
>
>
> On 1/19/2016 9:15 AM, Nico Weber via cfe-commits wrote:
>>
>> Author: nico
>> Date: Tue Jan 19 09:15:31 2016
>> New Revision: 258128
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=258128=rev
>> Log:
>> Add -Wexpansion-to-undefined: warn when using `defined` in a macro
>> definition.
>>
>> [cpp.cond]p4:
>>Prior to evaluation, macro invocations in the list of preprocessing
>>tokens that will become the controlling constant expression are
>> replaced
>>(except for those macro names modified by the 'defined' unary
>> operator),
>>just as in normal text. If the token 'defined' is generated as a result
>>of this replacement process or use of the 'defined' unary operator does
>>not match one of the two specified forms prior to macro replacement,
>> the
>>behavior is undefined.
>>
>> This isn't an idle threat, consider this program:
>>#define FOO
>>#define BAR defined(FOO)
>>#if BAR
>>...
>>#else
>>...
>>#endif
>> clang and gcc will pick the #if branch while Visual Studio will take the
>> #else branch.  Emit a warning about this undefined behavior.
>>
>> One problem is that this also applies to function-like macros. While the
>> example above can be written like
>>
>>  #if defined(FOO) && defined(BAR)
>>  #defined HAVE_FOO 1
>>  #else
>>  #define HAVE_FOO 0
>>  #endif
>>
>> there is no easy way to rewrite a function-like macro like `#define FOO(x)
>> (defined __foo_##x && __foo_##x)`.  Function-like macros like this are
>> used in
>> practice, and compilers seem to not have differing behavior in that case.
>> So
>> this a default-on warning only for object-like macros. For function-like
>> macros, it is an extension warning that only shows up with `-pedantic`.
>> (But it's undefined behavior in both cases.)
>>
>> Modified:
>>  cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>>  cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
>>  cfe/trunk/lib/Lex/PPExpressions.cpp
>>  cfe/trunk/test/Lexer/cxx-features.cpp
>>  cfe/trunk/test/Preprocessor/expr_define_expansion.c
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=258128=258127=258128=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Jan 19 09:15:31
>> 2016
>> @@ -204,6 +204,7 @@ def OverloadedShiftOpParentheses: DiagGr
>>   def DanglingElse: DiagGroup<"dangling-else">;
>>   def DanglingField : DiagGroup<"dangling-field">;
>>   def DistributedObjectModifiers :
>> DiagGroup<"distributed-object-modifiers">;
>> +def ExpansionToUndefined : DiagGroup<"expansion-to-undefined">;
>>   def FlagEnum : DiagGroup<"flag-enum">;
>>   def IncrementBool : DiagGroup<"increment-bool",
>> [DeprecatedIncrementBool]>;
>>   def InfiniteRecursion : DiagGroup<"infinite-recursion">;
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=258128=258127=258128=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Tue Jan 19
>> 09:15:31 2016
>> @@ -658,6 +658,13 @@ def warn_header_guard : Warning<
>>   def note_header_guard : Note<
>> "%0 is defined here; did you mean %1?">;
>>
>> +def warn_defined_in_object_type_macro : Warning<
>> +  "macro expansion producing 'defined' has undefined behavior">,
>> +  InGroup;
>> +def warn_defined_in_function_type_macro : Extension<
>> +  "macro expansion producing 'defined' has undefined behavior">,
>> +  InGroup;
>> +
>>   let CategoryName = "Nullability Issue" in {
>>
>>   def err_pp_assume_nonnull_syntax : Error<"expected 'begin' or 'end'">;
>>
>> Modified: cfe/trunk/lib/Lex/PPExpressions.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPExpressions.cpp?rev=258128=258127=258128=diff
>>
>> 

Re: [libcxx] r255177 - Remove visibility attributes from out-of-class method definitions in iostreams.

2016-01-08 Thread Evgenii Stepanov via cfe-commits
Reverted in r257193.

On Fri, Jan 8, 2016 at 11:12 AM, Evgenii Stepanov
 wrote:
> On Fri, Jan 8, 2016 at 11:02 AM, Duncan P. N. Exon Smith
>  wrote:
>>
>>> On 2016-Jan-08, at 10:49, Nico Weber via cfe-commits 
>>>  wrote:
>>>
>>> On OS X 10.8, __ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc 
>>> (and others) are a hidden symbol in libc++.1.dylib. This means:
>>>
>>> * If I use streambuf::sputc() and link against the 10.8 SDK, and the 
>>> compiler decides to not inline the call, I will get linker errors.
>>> * If I do the same with the 10.10 SDK when targeting 10.8, then (even 
>>> worse) the link will silently succeed (since it links against the 10.10 
>>> libc++ which does have a public symbol for this -- the SDK assumes that 
>>> libc++ is abi-compatible with itself) but it will then fail to run on a 
>>> 10.8 system.
>>>
>>> I don't see a way to save this change -- I think this needs to be reverted.
>>
>> FWIW, we're working on a plan to add availability markup to libc++
>> (it shouldn't be too intrusive (since you can annotate blocks of
>> API); had some initial talks with Marshall at the dev meeting).  I
>> plan to send out an RFC soon.
>>
>> I didn't think there'd be interest in having the availability
>> attributes themselves in open source (just some placeholder macros),
>> but it would be an option.
>>
>> Anyway, until that's done, I agree this needs to be reverted.
>>
>>> Have you made similar changes elsewhere? These probably need to be reverted 
>>> too.
>>
>> I agree.
>
> This is the only one of my changes that removes attributes. I'll revert.
>
>>> On Wed, Dec 9, 2015 at 6:42 PM, Evgeniy Stepanov via cfe-commits 
>>>  wrote:
>>> Author: eugenis
>>> Date: Wed Dec  9 17:42:30 2015
>>> New Revision: 255177
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=255177=rev
>>> Log:
>>> Remove visibility attributes from out-of-class method definitions in 
>>> iostreams.
>>>
>>> No point in pretending that these methods are hidden - they are
>>> actually exported from libc++.so. Extern template declarations make
>>> them part of libc++ ABI.
>>>
>>> This patch does not change libc++.so export list (at least on Linux).
>>>
>>> Modified:
>>> libcxx/trunk/include/istream
>>> libcxx/trunk/include/ostream
>>> libcxx/trunk/include/sstream
>>> libcxx/trunk/include/streambuf
>>>
>>> Modified: libcxx/trunk/include/istream
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/istream?rev=255177=255176=255177=diff
>>> ==
>>> --- libcxx/trunk/include/istream (original)
>>> +++ libcxx/trunk/include/istream Wed Dec  9 17:42:30 2015
>>> @@ -304,7 +304,7 @@ basic_istream<_CharT, _Traits>::sentry::
>>>  }
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream<_CharT, _Traits>::basic_istream(basic_streambuf>> traits_type>* __sb)
>>>  : __gc_(0)
>>>  {
>>> @@ -314,7 +314,7 @@ basic_istream<_CharT, _Traits>::basic_is
>>>  #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream<_CharT, _Traits>::basic_istream(basic_istream&& __rhs)
>>>  : __gc_(__rhs.__gc_)
>>>  {
>>> @@ -323,7 +323,7 @@ basic_istream<_CharT, _Traits>::basic_is
>>>  }
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream<_CharT, _Traits>&
>>>  basic_istream<_CharT, _Traits>::operator=(basic_istream&& __rhs)
>>>  {
>>> @@ -339,7 +339,7 @@ basic_istream<_CharT, _Traits>::~basic_i
>>>  }
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  void
>>>  basic_istream<_CharT, _Traits>::swap(basic_istream& __rhs)
>>>  {
>>> @@ -725,7 +725,7 @@ basic_istream<_CharT, _Traits>::operator
>>>  }
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream<_CharT, _Traits>&
>>>  basic_istream<_CharT, _Traits>::operator>>(basic_istream& 
>>> (*__pf)(basic_istream&))
>>>  {
>>> @@ -733,7 +733,7 @@ basic_istream<_CharT, _Traits>::operator
>>>  }
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream<_CharT, _Traits>&
>>>  basic_istream<_CharT, _Traits>::operator>>(basic_ios>> traits_type>&
>>> (*__pf)(basic_ios>> traits_type>&))
>>> @@ -743,7 +743,7 @@ basic_istream<_CharT, _Traits>::operator
>>>  }
>>>
>>>  template 
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream<_CharT, _Traits>&
>>>  basic_istream<_CharT, _Traits>::operator>>(ios_base& (*__pf)(ios_base&))
>>>  {
>>> @@ -800,7 +800,7 @@ operator>>(basic_istream<_CharT, _Traits
>>>  }
>>>
>>>  template
>>> -inline _LIBCPP_INLINE_VISIBILITY
>>> +inline
>>>  basic_istream&
>>>  operator>>(basic_istream& __is, unsigned char* __s)
>>>  {
>>> @@ 

Re: [libcxx] r255177 - Remove visibility attributes from out-of-class method definitions in iostreams.

2016-01-08 Thread Evgenii Stepanov via cfe-commits
On Fri, Jan 8, 2016 at 11:02 AM, Duncan P. N. Exon Smith
 wrote:
>
>> On 2016-Jan-08, at 10:49, Nico Weber via cfe-commits 
>>  wrote:
>>
>> On OS X 10.8, __ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc 
>> (and others) are a hidden symbol in libc++.1.dylib. This means:
>>
>> * If I use streambuf::sputc() and link against the 10.8 SDK, and the 
>> compiler decides to not inline the call, I will get linker errors.
>> * If I do the same with the 10.10 SDK when targeting 10.8, then (even worse) 
>> the link will silently succeed (since it links against the 10.10 libc++ 
>> which does have a public symbol for this -- the SDK assumes that libc++ is 
>> abi-compatible with itself) but it will then fail to run on a 10.8 system.
>>
>> I don't see a way to save this change -- I think this needs to be reverted.
>
> FWIW, we're working on a plan to add availability markup to libc++
> (it shouldn't be too intrusive (since you can annotate blocks of
> API); had some initial talks with Marshall at the dev meeting).  I
> plan to send out an RFC soon.
>
> I didn't think there'd be interest in having the availability
> attributes themselves in open source (just some placeholder macros),
> but it would be an option.
>
> Anyway, until that's done, I agree this needs to be reverted.
>
>> Have you made similar changes elsewhere? These probably need to be reverted 
>> too.
>
> I agree.

This is the only one of my changes that removes attributes. I'll revert.

>> On Wed, Dec 9, 2015 at 6:42 PM, Evgeniy Stepanov via cfe-commits 
>>  wrote:
>> Author: eugenis
>> Date: Wed Dec  9 17:42:30 2015
>> New Revision: 255177
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=255177=rev
>> Log:
>> Remove visibility attributes from out-of-class method definitions in 
>> iostreams.
>>
>> No point in pretending that these methods are hidden - they are
>> actually exported from libc++.so. Extern template declarations make
>> them part of libc++ ABI.
>>
>> This patch does not change libc++.so export list (at least on Linux).
>>
>> Modified:
>> libcxx/trunk/include/istream
>> libcxx/trunk/include/ostream
>> libcxx/trunk/include/sstream
>> libcxx/trunk/include/streambuf
>>
>> Modified: libcxx/trunk/include/istream
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/istream?rev=255177=255176=255177=diff
>> ==
>> --- libcxx/trunk/include/istream (original)
>> +++ libcxx/trunk/include/istream Wed Dec  9 17:42:30 2015
>> @@ -304,7 +304,7 @@ basic_istream<_CharT, _Traits>::sentry::
>>  }
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream<_CharT, _Traits>::basic_istream(basic_streambuf> traits_type>* __sb)
>>  : __gc_(0)
>>  {
>> @@ -314,7 +314,7 @@ basic_istream<_CharT, _Traits>::basic_is
>>  #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream<_CharT, _Traits>::basic_istream(basic_istream&& __rhs)
>>  : __gc_(__rhs.__gc_)
>>  {
>> @@ -323,7 +323,7 @@ basic_istream<_CharT, _Traits>::basic_is
>>  }
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream<_CharT, _Traits>&
>>  basic_istream<_CharT, _Traits>::operator=(basic_istream&& __rhs)
>>  {
>> @@ -339,7 +339,7 @@ basic_istream<_CharT, _Traits>::~basic_i
>>  }
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  void
>>  basic_istream<_CharT, _Traits>::swap(basic_istream& __rhs)
>>  {
>> @@ -725,7 +725,7 @@ basic_istream<_CharT, _Traits>::operator
>>  }
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream<_CharT, _Traits>&
>>  basic_istream<_CharT, _Traits>::operator>>(basic_istream& 
>> (*__pf)(basic_istream&))
>>  {
>> @@ -733,7 +733,7 @@ basic_istream<_CharT, _Traits>::operator
>>  }
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream<_CharT, _Traits>&
>>  basic_istream<_CharT, _Traits>::operator>>(basic_ios> traits_type>&
>> (*__pf)(basic_ios> traits_type>&))
>> @@ -743,7 +743,7 @@ basic_istream<_CharT, _Traits>::operator
>>  }
>>
>>  template 
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream<_CharT, _Traits>&
>>  basic_istream<_CharT, _Traits>::operator>>(ios_base& (*__pf)(ios_base&))
>>  {
>> @@ -800,7 +800,7 @@ operator>>(basic_istream<_CharT, _Traits
>>  }
>>
>>  template
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream&
>>  operator>>(basic_istream& __is, unsigned char* __s)
>>  {
>> @@ -808,7 +808,7 @@ operator>>(basic_istream&
>>  }
>>
>>  template
>> -inline _LIBCPP_INLINE_VISIBILITY
>> +inline
>>  basic_istream&
>>  operator>>(basic_istream& __is, signed char* __s)
>>  {
>> @@ -843,7 +843,7 

Re: Some buildbot statistics for the last week

2015-11-18 Thread Evgenii Stepanov via cfe-commits
Permanently failing bots are way better that 50/50 flaky bots, but
still not good.
As for the sanitizer-x86_64-linux-bootstrap, it shows some legitimate
failures in different parts of llvm that no one bothered to fix.
That's kinda understandable because MSan failures are hard to
reproduce locally (one needs to do a full bootstrap, including
libc++/libc++abi built w/ MSan), and FileCheck tends to show only part
of the report.


On Wed, Nov 18, 2015 at 10:43 AM, Aaron Ballman via llvm-commits
 wrote:
> On Wed, Nov 18, 2015 at 1:40 PM, Galina Kistanova via cfe-commits
>  wrote:
>> Hello everyone,
>>
>> Here are some buildbot statistics you may found interesting. I will be
>> adding more statistics.
>> My goal is to publish metrics to help with keeping the buildbot
>> infrastructure healthy and improving it.
>
> Thank you for tracking and reporting this information, that's fantastic!
>
>>
>> All the numbers are for the week of 11/8/2015 - 11/14/2015.
>>
>> Thanks
>>
>> Galina
>>
>>
>>
>> Number of commits by project:
>>
>>  project  |   commits
>>  -
>>  llvm |   286
>>  cfe  |   109
>>  lldb |76
>>  compiler-rt  |71
>>  polly|42
>>  lld  |38
>>  libcxx   |10
>>  openmp   | 9
>>  clang-tools-extra| 7
>>  clang-tests-external | 2
>>  libunwind| 1
>>  -
>>   651
>>
>>
>> Number of completed builds, failed builds and average build time for
>> successful builds per active builder:
>>
>>  buildername   | completed  |
>> failed | time
>> -
>>  clang-aarch64-lnt | 57 |
>> 3 | 02:30:12
>>  clang-atom-d525-fedora| 18 |
>> | 08:28:15
>>  clang-atom-d525-fedora-rel| 83 |
>> 5 | 01:29:55
>>  clang-bpf-build   |310 |
>> 31 | 00:02:53
>>  clang-cmake-aarch64-42vma |278 |
>> 49 | 00:16:47
>>  clang-cmake-aarch64-quick |209 |
>> 29 | 00:23:46
>>  clang-cmake-armv7-a15 |189 |
>> 8 | 00:25:27
>>  clang-cmake-armv7-a15-full|154 |
>> 38 | 00:45:32
>>  clang-cmake-armv7-a15-selfhost| 58 |
>> 24 | 03:00:19
>>  clang-cmake-armv7-a15-selfhost-neon   | 45 |
>> 22 | 04:26:31
>>  clang-cmake-mips  |186 |
>> 38 | 00:28:52
>>  clang-cmake-thumbv7-a15   |178 |
>> 7 | 00:28:30
>>  clang-cmake-thumbv7-a15-full-sh   | 32 |
>> 23 | 06:03:05
>>  clang-hexagon-elf |169 |
>> 23 | 00:24:42
>>  clang-native-aarch64-full | 24 |
>> 8 | 05:53:35
>>  clang-native-arm-lnt  | 90 |
>> 3 | 01:06:01
>>  clang-native-arm-lnt-perf | 14 |
>> | 08:57:04
>>  clang-ppc64-elf-linux |120 |
>> 6 | 01:01:02
>>  clang-ppc64-elf-linux2| 89 |
>> 24 | 01:29:49
>>  clang-sphinx-docs |113 |
>> | 00:00:20
>>  clang-x64-ninja-win7  |285 |
>> 58 | 00:09:49
>>  clang-x86-win2008-selfhost|268 |
>> 46 | 00:12:10
>>  clang-x86_64-darwin13-cross-arm   |232 |
>> 1 | 00:19:45
>>  clang-x86_64-darwin13-cross-mingw32   |217 |
>> 12 | 00:23:20
>>  clang-x86_64-debian-fast  |147 |
>> 12 | 00:11:37
>>  clang-x86_64-linux-abi-test   |314 |
>> 1 | 00:18:39
>>  clang-x86_64-linux-selfhost-modules   |261 |
>> 25 | 00:15:02
>>  clang-x86_64-ubuntu-gdb-75|124 |
>> 62 | 00:53:12
>>  libcxx-libcxxabi-arm-linux|  8 |
>> | 01:05:10
>>  libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   | 11 |
>> 2 | 00:08:50
>>  libcxx-libcxxabi-x86_64-linux-debian  | 11 |
>> 4 | 00:09:43
>>  

Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

2015-10-15 Thread Evgenii Stepanov via cfe-commits
Guess what this does to the -Wno-pedantic flag added by MSan? :)

On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits
 wrote:
> Author: ericwf
> Date: Tue Oct 13 18:56:33 2015
> New Revision: 250256
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
> Log:
> Workaround -pedantic flag added by LLVM
>
> Modified:
> libcxx/trunk/CMakeLists.txt
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
> ==
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
> @@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
>  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
>   -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
>
> +# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
> +# Remove the -pedantic flag provided by LLVM.
> +remove_flags(-pedantic)
> +
>  # Required flags 
> ==
>  add_compile_flags_if_supported(-std=c++11)
>  if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

2015-10-15 Thread Evgenii Stepanov via cfe-commits
It looks like, since libc++ removes -pedantic, we don't need to add
-Wno-pedantic, so I can just fix it in MSan. It would probably make
sense for libc++ to remove -Wno-pedantic before removing -pedantic.

On Thu, Oct 15, 2015 at 12:57 PM, Evgenii Stepanov
 wrote:
> Transforms it to -Wno.
>
> On Thu, Oct 15, 2015 at 12:56 PM, Eric Fiselier  wrote:
>> Removes it because "-Wno-pedantic" incorrectly matches -pedantic? If my
>> guess is correct, whoops :-(
>>
>> On Thu, Oct 15, 2015 at 1:51 PM, Evgenii Stepanov
>>  wrote:
>>>
>>> Guess what this does to the -Wno-pedantic flag added by MSan? :)
>>>
>>> On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits
>>>  wrote:
>>> > Author: ericwf
>>> > Date: Tue Oct 13 18:56:33 2015
>>> > New Revision: 250256
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
>>> > Log:
>>> > Workaround -pedantic flag added by LLVM
>>> >
>>> > Modified:
>>> > libcxx/trunk/CMakeLists.txt
>>> >
>>> > Modified: libcxx/trunk/CMakeLists.txt
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
>>> >
>>> > ==
>>> > --- libcxx/trunk/CMakeLists.txt (original)
>>> > +++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
>>> > @@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
>>> >  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
>>> >   -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
>>> >
>>> > +# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
>>> > +# Remove the -pedantic flag provided by LLVM.
>>> > +remove_flags(-pedantic)
>>> > +
>>> >  # Required flags
>>> > ==
>>> >  add_compile_flags_if_supported(-std=c++11)
>>> >  if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
>>> >
>>> >
>>> > ___
>>> > cfe-commits mailing list
>>> > cfe-commits@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r247494 - Always_inline codegen rewrite.

2015-09-14 Thread Evgenii Stepanov via cfe-commits
Thanks!

On Mon, Sep 14, 2015 at 10:50 AM, Samuel F Antao  wrote:
> Hi Evgeniy,
>
> I commit a small change to one of the regression tests to allow a signext to
> be generated: http://reviews.llvm.org/rL247584.
>
> It was causing an error in Power8 targets. In my view is an harmless change
> but you may want to take a look and see if that is fine by you.
>
> Thanks!
> Samuel
>
> 2015-09-11 21:07 GMT-04:00 Evgeniy Stepanov via cfe-commits
> :
>>
>> Author: eugenis
>> Date: Fri Sep 11 20:07:37 2015
>> New Revision: 247494
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=247494=rev
>> Log:
>> Always_inline codegen rewrite.
>>
>> Current implementation may end up emitting an undefined reference for
>> an "inline __attribute__((always_inline))" function by generating an
>> "available_externally alwaysinline" IR function for it and then failing to
>> inline all the calls. This happens when a call to such function is in dead
>> code. As the inliner is an SCC pass, it does not process dead code.
>>
>> Libc++ relies on the compiler never emitting such undefined reference.
>>
>> With this patch, we emit a pair of
>> 1. internal alwaysinline definition (called F.alwaysinline)
>> 2a. A stub F() { musttail call F.alwaysinline }
>>   -- or, depending on the linkage --
>> 2b. A declaration of F.
>>
>> The frontend ensures that F.inlinefunction is only used for direct
>> calls, and the stub is used for everything else (taking the address of
>> the function, really). Declaration (2b) is emitted in the case when
>> "inline" is meant for inlining only (like __gnu_inline__ and some
>> other cases).
>>
>> This approach, among other nice properties, ensures that alwaysinline
>> functions are always internal, making it impossible for a direct call
>> to such function to produce an undefined symbol reference.
>>
>> This patch is based on ideas by Chandler Carruth and Richard Smith.
>>
>> Added:
>> cfe/trunk/test/CodeGen/always_inline-unused.c
>> cfe/trunk/test/CodeGen/always_inline-wrappers.c
>> cfe/trunk/test/CodeGenCXX/alwaysinline.cpp
>> Modified:
>> cfe/trunk/lib/CodeGen/CGCXX.cpp
>> cfe/trunk/lib/CodeGen/CGClass.cpp
>> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.h
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/test/CodeGen/always-inline.c
>> cfe/trunk/test/CodeGen/always_inline.c
>> cfe/trunk/test/CodeGen/function-attributes.c
>> cfe/trunk/test/CodeGen/pr9614.c
>> cfe/trunk/test/Frontend/optimization-remark-line-directive.c
>> cfe/trunk/test/Frontend/optimization-remark.c
>> cfe/trunk/test/Modules/cxx-irgen.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGCXX.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXX.cpp?rev=247494=247493=247494=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGCXX.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGCXX.cpp Fri Sep 11 20:07:37 2015
>> @@ -109,6 +109,9 @@ bool CodeGenModule::TryEmitBaseDestructo
>>D->getType()->getAs()->getCallConv())
>>  return true;
>>
>> +  if (BaseD->hasAttr())
>> +return true;
>> +
>>return TryEmitDefinitionAsAlias(GlobalDecl(D, Dtor_Base),
>>GlobalDecl(BaseD, Dtor_Base),
>>false);
>> @@ -161,14 +164,7 @@ bool CodeGenModule::TryEmitDefinitionAsA
>>
>>// Instead of creating as alias to a linkonce_odr, replace all of the
>> uses
>>// of the aliasee.
>> -  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage) &&
>> - (TargetLinkage != llvm::GlobalValue::AvailableExternallyLinkage ||
>> -  !TargetDecl.getDecl()->hasAttr())) {
>> -// FIXME: An extern template instantiation will create functions with
>> -// linkage "AvailableExternally". In libc++, some classes also define
>> -// members with attribute "AlwaysInline" and expect no reference to
>> -// be generated. It is desirable to reenable this optimisation after
>> -// corresponding LLVM changes.
>> +  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage)) {
>>  Replacements[MangledName] = Aliasee;
>>  return false;
>>}
>>
>> Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=247494=247493=247494=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGClass.cpp Fri Sep 11 20:07:37 2015
>> @@ -1557,7 +1557,7 @@ void CodeGenFunction::EmitDestructorBody
>>  // -fapple-kext must inline any call to this dtor into
>>  // the caller's body.
>>  if (getLangOpts().AppleKext)
>> -  CurFn->addFnAttr(llvm::Attribute::AlwaysInline);
>> +  CGM.AddAlwaysInlineFunction(CurFn);
>>
>>  break;

Re: [PATCH] D12087: always_inline codegen rewrite

2015-09-11 Thread Evgenii Stepanov via cfe-commits
Thanks. I just reproduced it on release w/o asserts build and fixed locally.
The other problem is fixed as well, I'll try re-landing now. I'll keep
an eye on the bot later today and will revert again if necessary.


On Fri, Sep 11, 2015 at 6:02 PM, H.J. Lu  wrote:
> On Fri, Sep 11, 2015 at 4:45 PM, Evgenii Stepanov  wrote:
>> Does it say that there is no entry basic block? I.e. the output
>> apparently looks like
>>
>> define void @h() #1 {
>>   store void ()* @f1, void ()** @p, align 8
>>
>> Could you confirm it? Never seen this behavior.
>>
>> I'm going to revert the change due to this and also one broken gdb
>> test (something wrong with debug info in the code that has been
>> always-inlined twice).
>
> I got
>
> [hjl@gnu-mic-2 llvm-clang]$
> /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang  -target
> x86_64-pc-linux-gnu -mllvm -disable-llvm-optzns -emit-llvm -S -o -
> /export/gnu/import/git/llvm/tools/clang/test/CodeGen/always_inline.c
> ; ModuleID = 
> '/export/gnu/import/git/llvm/tools/clang/test/CodeGen/always_inline.c'
> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-pc-linux-gnu"
>
> ; Function Attrs: nounwind uwtable
> define i32 @f1() #0 {
>   %1 = call i32 @f0.alwaysinline()
>   ret i32 %1
> }
>
> ; Function Attrs: alwaysinline inlinehint nounwind uwtable
> define internal i32 @f2.alwaysinline() #1 {
>   ret i32 7
> }
>
> ; Function Attrs: inlinehint nounwind uwtable
> define i32 @f2() #2 {
> entry:
>   %0 = musttail call i32 @f2.alwaysinline() #2
>   ret i32 %0
> }
>
> ; Function Attrs: nounwind uwtable
> define i32 @f3() #0 {
>   %1 = call i32 @f2.alwaysinline()
>   ret i32 %1
> }
>
> ; Function Attrs: alwaysinline nounwind uwtable
> define internal i32 @f0.alwaysinline() #3 {
>   ret i32 1
> }
>
> attributes #0 = { nounwind uwtable "disable-tail-calls"="false"
> "less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
> "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false"
> "no-nans-fp-math"="false" "stack-protector-buffer-size"="8"
> "target-cpu"="x86-64" "target-features"="+sse,+sse2"
> "unsafe-fp-math"="false" "use-soft-float"="false" }
> attributes #1 = { alwaysinline inlinehint nounwind uwtable
> "disable-tail-calls"="false" "less-precise-fpmad"="false"
> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
> "no-infs-fp-math"="false" "no-nans-fp-math"="false"
> "stack-protector-buffer-size"="8" "target-cpu"="x86-64"
> "target-features"="+sse,+sse2" "unsafe-fp-math"="false"
> "use-soft-float"="false" }
> attributes #2 = { inlinehint nounwind uwtable
> "disable-tail-calls"="false" "less-precise-fpmad"="false"
> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
> "no-infs-fp-math"="false" "no-nans-fp-math"="false"
> "stack-protector-buffer-size"="8" "target-cpu"="x86-64"
> "target-features"="+sse,+sse2" "unsafe-fp-math"="false"
> "use-soft-float"="false" }
> attributes #3 = { alwaysinline nounwind uwtable
> "disable-tail-calls"="false" "less-precise-fpmad"="false"
> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
> "no-infs-fp-math"="false" "no-nans-fp-math"="false"
> "stack-protector-buffer-size"="8" "target-cpu"="x86-64"
> "target-features"="+sse,+sse2" "unsafe-fp-math"="false"
> "use-soft-float"="false" }
>
> !llvm.ident = !{!0}
>
> !0 = !{!"clang version 3.8.0 (http://llvm.org/git/clang.git
> 4c682cf50f928f82e286df97d10a3d1fcf68e1a1)
> (http://llvm.org/git/llvm.git
> 125be70dbf9784ef4fab69633afa067c1cceffc9)"}
> [hjl@gnu-mic-2 llvm-clang]$
> [hjl@gnu-mic-2 llvm-clang]$
> /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang  -target
> x86_64-pc-linux-gnu -mllvm -disable-llvm-optzns -emit-llvm -S -o -
> /export/gnu/import/git/llvm/tools/clang/test/CodeGen/always_inline.c |
> /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/FileCheck
> /export/gnu/import/git/llvm/tools/clang/test/CodeGen/always_inline.c
> --check-prefix=CHECK-NO-OPTZNS
> /export/gnu/import/git/llvm/tools/clang/test/CodeGen/always_inline.c:26:26:
> error: expected string not found in input
> // CHECK-NO-OPTZNS-NEXT: entry:
>  ^
> :24:18: note: scanning from here
> define i32 @f3() #0 {
>  ^
> :29:12: note: possible intended match here
> ; Function Attrs: alwaysinline nounwind uwtable
>^
> [hjl@gnu-mic-2 llvm-clang]$
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits