r259302 - assert(false) -> llvm_unreachable().

[Davide Italiano via cfe-commits]

Author: davide
Date: Sat Jan 30 02:03:54 2016
New Revision: 259302

URL: http://llvm.org/viewvc/llvm-project?rev=259302&view=rev
Log:
assert(false) -> llvm_unreachable().

Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=259302&r1=259301&r2=259302&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Sat Jan 30 02:03:54 2016
@@ -985,7 +985,7 @@ void StringLiteral::setString(const ASTC
   break;
 }
 default:
-  assert(false && "unsupported CharByteWidth");
+  llvm_unreachable("unsupported CharByteWidth");
   }
 }
 

Modified: cfe/trunk/lib/AST/StmtPrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/StmtPrinter.cpp?rev=259302&r1=259301&r2=259302&view=diff
==
--- cfe/trunk/lib/AST/StmtPrinter.cpp (original)
+++ cfe/trunk/lib/AST/StmtPrinter.cpp Sat Jan 30 02:03:54 2016
@@ -2462,7 +2462,7 @@ void StmtPrinter::VisitOpaqueValueExpr(O
 
 void StmtPrinter::VisitTypoExpr(TypoExpr *Node) {
   // TODO: Print something reasonable for a TypoExpr, if necessary.
-  assert(false && "Cannot print TypoExpr nodes");
+  llvm_unreachable("Cannot print TypoExpr nodes");
 }
 
 void StmtPrinter::VisitAsTypeExpr(AsTypeExpr *Node) {

Modified: cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterStmt.cpp?rev=259302&r1=259301&r2=259302&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriterStmt.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriterStmt.cpp Sat Jan 30 02:03:54 2016
@@ -1652,7 +1652,7 @@ void ASTStmtWriter::VisitOpaqueValueExpr
 void ASTStmtWriter::VisitTypoExpr(TypoExpr *E) {
   VisitExpr(E);
   // TODO: Figure out sane writer behavior for a TypoExpr, if necessary
-  assert(false && "Cannot write TypoExpr nodes");
+  llvm_unreachable("Cannot write TypoExpr nodes");
 }
 
 
//===--===//


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

r259304 - [AST] Pull simple method inline.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Sat Jan 30 06:16:23 2016
New Revision: 259304

URL: http://llvm.org/viewvc/llvm-project?rev=259304&view=rev
Log:
[AST] Pull simple method inline.

Modified:
cfe/trunk/include/clang/AST/ASTTypeTraits.h
cfe/trunk/lib/AST/ASTTypeTraits.cpp

Modified: cfe/trunk/include/clang/AST/ASTTypeTraits.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTTypeTraits.h?rev=259304&r1=259303&r2=259304&view=diff
==
--- cfe/trunk/include/clang/AST/ASTTypeTraits.h (original)
+++ cfe/trunk/include/clang/AST/ASTTypeTraits.h Sat Jan 30 06:16:23 2016
@@ -62,7 +62,9 @@ public:
   /// \}
 
   /// \brief Returns \c true if \c this and \c Other represent the same kind.
-  bool isSame(ASTNodeKind Other) const;
+  bool isSame(ASTNodeKind Other) const {
+return KindId != NKI_None && KindId == Other.KindId;
+  }
 
   /// \brief Returns \c true only for the default \c ASTNodeKind()
   bool isNone() const { return KindId == NKI_None; }

Modified: cfe/trunk/lib/AST/ASTTypeTraits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTTypeTraits.cpp?rev=259304&r1=259303&r2=259304&view=diff
==
--- cfe/trunk/lib/AST/ASTTypeTraits.cpp (original)
+++ cfe/trunk/lib/AST/ASTTypeTraits.cpp Sat Jan 30 06:16:23 2016
@@ -43,10 +43,6 @@ bool ASTNodeKind::isBaseOf(ASTNodeKind O
   return isBaseOf(KindId, Other.KindId, Distance);
 }
 
-bool ASTNodeKind::isSame(ASTNodeKind Other) const {
-  return KindId != NKI_None && KindId == Other.KindId;
-}
-
 bool ASTNodeKind::isBaseOf(NodeKindId Base, NodeKindId Derived,
unsigned *Distance) {
   if (Base == NKI_None || Derived == NKI_None) return false;


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

Re: [PATCH] D16264: For FreeBSD, use _p variants of libraries for linking C++ programs

[Dimitry Andric via cfe-commits]

dim added a comment.

Ping.


http://reviews.llvm.org/D16264



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov added inline comments.


Comment at: test/SemaOpenCL/implicit-typedef.cl:2
@@ +1,2 @@
+// RUN: %clang_cc1 "-cc1" "-emit-llvm" "-D" "cl_khr_fp64" "-D" 
"cl_khr_int64_base_atomics" "-fno-dwarf-directory-asm" "-fmessage-length" "205" 
"-fdiagnostics-show-option" "-cl-std=CL2.0" "-x" "cl" "%s" 
"-fcolor-diagnostics" -o -
+typedef atomic_int atomic_flag;

Not necessary. Removed.


Repository:
  rL LLVM

http://reviews.llvm.org/D16351



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

BugZilla page:
https://llvm.org/bugs/show_bug.cgi?id=25404


Repository:
  rL LLVM

http://reviews.llvm.org/D16351



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

BugZilla page: https://llvm.org/bugs/show_bug.cgi?id=25404

Please review and submit this bug.



Comment at: test/SemaOpenCL/implicit-typedef.cl:2
@@ +1,2 @@
+// RUN: %clang_cc1 "-cc1" "-emit-llvm" "-D" "cl_khr_fp64" "-D" 
"cl_khr_int64_base_atomics" "-fno-dwarf-directory-asm" "-fmessage-length" "205" 
"-fdiagnostics-show-option" "-cl-std=CL2.0" "-x" "cl" "%s" 
"-fcolor-diagnostics" -o -
+typedef atomic_int atomic_flag;

ichesnokov wrote:
> Not necessary. Removed.
-main-file-name is not necessary. Removed.


Repository:
  rL LLVM

http://reviews.llvm.org/D16351



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov set the repository for this revision to rL LLVM.
ichesnokov updated this revision to Diff 46470.
ichesnokov added a comment.

Removed unuseful patch code.


Repository:
  rL LLVM

http://reviews.llvm.org/D16351

Files:
  lib/Sema/SemaDecl.cpp
  test/SemaOpenCL/implicit-typedef.cl

Index: test/SemaOpenCL/implicit-typedef.cl
===
--- test/SemaOpenCL/implicit-typedef.cl
+++ test/SemaOpenCL/implicit-typedef.cl
@@ -0,0 +1,2 @@
+// RUN: %clang_cc1 "-cc1" "-emit-llvm" "-D" "cl_khr_fp64" "-D" 
"cl_khr_int64_base_atomics" "-fno-dwarf-directory-asm" "-fmessage-length" "205" 
"-fdiagnostics-show-option" "-cl-std=CL2.0" "-x" "cl" "%s" 
"-fcolor-diagnostics" -o -
+typedef atomic_int atomic_flag;
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -2033,6 +2033,12 @@
   if (getLangOpts().Modules || getLangOpts().C11)
 return;
   
+  // Added isImplicit() check, because implicit TypeDecl::getLocation()
+  // returns 0. The're many implicit typedefs in OpenCL, e.g. atomic_flag.
+  if (Old->isImplicit() || New->isImplicit()) {
+return;
+  }
+
   // If we have a redefinition of a typedef in C, emit a warning.  This warning
   // is normally mapped to an error, but can be controlled with
   // -Wtypedef-redefinition.  If either the original or the redefinition is


Index: test/SemaOpenCL/implicit-typedef.cl
===
--- test/SemaOpenCL/implicit-typedef.cl
+++ test/SemaOpenCL/implicit-typedef.cl
@@ -0,0 +1,2 @@
+// RUN: %clang_cc1 "-cc1" "-emit-llvm" "-D" "cl_khr_fp64" "-D" "cl_khr_int64_base_atomics" "-fno-dwarf-directory-asm" "-fmessage-length" "205" "-fdiagnostics-show-option" "-cl-std=CL2.0" "-x" "cl" "%s" "-fcolor-diagnostics" -o -
+typedef atomic_int atomic_flag;
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -2033,6 +2033,12 @@
   if (getLangOpts().Modules || getLangOpts().C11)
 return;
   
+  // Added isImplicit() check, because implicit TypeDecl::getLocation()
+  // returns 0. The're many implicit typedefs in OpenCL, e.g. atomic_flag.
+  if (Old->isImplicit() || New->isImplicit()) {
+return;
+  }
+
   // If we have a redefinition of a typedef in C, emit a warning.  This warning
   // is normally mapped to an error, but can be controlled with
   // -Wtypedef-redefinition.  If either the original or the redefinition is
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

Please review and commit.


Repository:
  rL LLVM

http://reviews.llvm.org/D16351



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

Re: r259271 - Improve -Wconstant-conversion

[Nico Weber via cfe-commits]

Shouldn't the new case be in -Wc++11-narrowing instead? This is warning in
similar places where that warning used to warn.

In practice, char arrays seem to be often used for storing binary blobs in
header files, and those are usually initialized with numbers 0...255
instead of -128...127 (why not make the array uint8_t then? Because maybe
the function you want to pass the data from wants a char* array, and having
to reinterpret_cast from uint8_t to char is annoying). Maybe this shouldn't
fire for char arrays?

On Fri, Jan 29, 2016 at 6:51 PM, Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Fri Jan 29 17:51:16 2016
> New Revision: 259271
>
> URL: http://llvm.org/viewvc/llvm-project?rev=259271&view=rev
> Log:
> Improve -Wconstant-conversion
>
> Switch the evaluation from isIntegerConstantExpr to EvaluateAsInt.
> EvaluateAsInt will evaluate more types of expressions than
> isIntegerConstantExpr.
>
> Move one case from -Wsign-conversion to -Wconstant-conversion.  The case
> is:
> 1) Source and target types are signed
> 2) Source type is wider than the target type
> 3) The source constant value is positive
> 4) The conversion will store the value as negative in the target.
>
> Modified:
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp
> cfe/trunk/test/Sema/constant-conversion.c
>
> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=259271&r1=259270&r2=259271&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Fri Jan 29 17:51:16 2016
> @@ -7578,7 +7578,7 @@ void CheckImplicitConversion(Sema &S, Ex
>  // If the source is a constant, use a default-on diagnostic.
>  // TODO: this should happen for bitfield stores, too.
>  llvm::APSInt Value(32);
> -if (E->isIntegerConstantExpr(Value, S.Context)) {
> +if (E->EvaluateAsInt(Value, S.Context, Expr::SE_AllowSideEffects)) {
>if (S.SourceMgr.isInSystemMacro(CC))
>  return;
>
> @@ -7603,6 +7603,42 @@ void CheckImplicitConversion(Sema &S, Ex
>  return DiagnoseImpCast(S, E, T, CC,
> diag::warn_impcast_integer_precision);
>}
>
> +  if (TargetRange.Width == SourceRange.Width && !TargetRange.NonNegative
> &&
> +  SourceRange.NonNegative && Source->isSignedIntegerType()) {
> +// Warn when doing a signed to signed conversion, warn if the positive
> +// source value is exactly the width of the target type, which will
> +// cause a negative value to be stored.
> +
> +llvm::APSInt Value;
> +if (E->EvaluateAsInt(Value, S.Context, Expr::SE_AllowSideEffects)) {
> +  if (!S.SourceMgr.isInSystemMacro(CC)) {
> +
> +IntegerLiteral *IntLit =
> +dyn_cast(E->IgnoreParenImpCasts());
> +
> +// If initializing from a constant, and the constant starts with
> '0',
> +// then it is a binary, octal, or hexadecimal.  Allow these
> constants
> +// to fill all the bits, even if there is a sign change.
> +if (!IntLit ||
> +
> *(S.getSourceManager().getCharacterData(IntLit->getLocStart())) !=
> +'0') {
> +
> +  std::string PrettySourceValue = Value.toString(10);
> +  std::string PrettyTargetValue =
> +  PrettyPrintInRange(Value, TargetRange);
> +
> +  S.DiagRuntimeBehavior(
> +  E->getExprLoc(), E,
> +  S.PDiag(diag::warn_impcast_integer_precision_constant)
> +  << PrettySourceValue << PrettyTargetValue <<
> E->getType() << T
> +  << E->getSourceRange() << clang::SourceRange(CC));
> +  return;
> +}
> +  }
> +}
> +// Fall through for non-constants to give a sign conversion warning.
> +  }
> +
>if ((TargetRange.NonNegative && !SourceRange.NonNegative) ||
>(!TargetRange.NonNegative && SourceRange.NonNegative &&
> SourceRange.Width == TargetRange.Width)) {
>
> Modified: cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp?rev=259271&r1=259270&r2=259271&view=diff
>
> ==
> --- cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp (original)
> +++ cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp Fri Jan 29 17:51:16 2016
> @@ -242,8 +242,8 @@ namespace UndefinedBehavior {
>  constexpr int n13 = n5 + n5; // expected-error {{constant
> expression}} expected-note {{value -4294967296 is outside the range of }}
>  constexpr int n14 = n3 - n5; // expected-error {{constant
> expression}} expected-note {{value 4294967295 is outside the range of }}
>  constexpr int n15 = n5 * n5; // expected-error {{constant
> expression}} expected-note {{value 4611686018427387904 is outside the range
> 

[PATCH][modules][PR26237]

[Vassil Vassilev via cfe-commits]

Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=26237

Please review.

Many thanks!
--Vassil
From da6b27875042ee23afaf898f189e410f177311ad Mon Sep 17 00:00:00 2001
From: Vassil Vassilev 
Date: Sat, 30 Jan 2016 14:50:06 +0100
Subject: [PATCH] [modules] Writing out template specializations might trigger
 deserialization.

Rebuilding a redecl chain of template (partial) specialization might be trigger
deserialization. If the container's capacity is exceeded the relocation
invalidates the iterators and at best causes a crash. Force deserialization by
copying the collections before iterating.

Fixes PR26237 (https://llvm.org/bugs/show_bug.cgi?id=26237)

I haven't been successful in reducing a reasonable testcase. It should contain
multimodule setup and at least 8 specializations being deserializaed in a very
specific way.
---
 lib/Serialization/ASTWriterDecl.cpp | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/lib/Serialization/ASTWriterDecl.cpp 
b/lib/Serialization/ASTWriterDecl.cpp
index cc67b17..bcf863c 100644
--- a/lib/Serialization/ASTWriterDecl.cpp
+++ b/lib/Serialization/ASTWriterDecl.cpp
@@ -191,8 +191,8 @@ namespace clang {
   return None;
 }
 
-template
-void AddTemplateSpecializations(Decl *D) {
+template
+void AddTemplateSpecializations(DeclTy *D) {
   auto *Common = D->getCommonPtr();
 
   // If we have any lazy specializations, and the external AST source is
@@ -204,8 +204,6 @@ namespace clang {
 assert(!Common->LazySpecializations);
   }
 
-  auto &Specializations = Common->Specializations;
-  auto &&PartialSpecializations = getPartialSpecializations(Common);
   ArrayRef LazySpecializations;
   if (auto *LS = Common->LazySpecializations)
 LazySpecializations = llvm::makeArrayRef(LS + 1, LS[0]);
@@ -214,6 +212,19 @@ namespace clang {
   unsigned I = Record.size();
   Record.push_back(0);
 
+  auto &Specializations = Common->Specializations;
+  auto &&PartialSpecializations = getPartialSpecializations(Common);
+
+  // AddFirstDeclFromEachModule might trigger deserialization, invalidating
+  // *Specializations iterators. Force the deserialization in advance.
+  llvm::SmallVector Specs;
+  for (auto &Entry : Specializations)
+   Specs.push_back(getSpecializationDecl(Entry));
+  for (auto &Entry : PartialSpecializations)
+   Specs.push_back(getSpecializationDecl(Entry));
+  for (auto *D : Specs)
+   D->getMostRecentDecl();
+
   for (auto &Entry : Specializations) {
 auto *D = getSpecializationDecl(Entry);
 assert(D->isCanonicalDecl() && "non-canonical decl in set");
-- 
1.9.1

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

Re: [PATCH][modules][PR26237]

[David Blaikie via cfe-commits]

It might be handy to give an overview of the issue in the review (&
certainly in the commit) message rather than only citing the bug number
On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=26237
>
> Please review.
>
> Many thanks!
> --Vassil
>
> ___
> 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][modules][PR26237]

[Vassil Vassilev via cfe-commits]

Sorry.

Our module builds choke on merging several modules, containing 
declarations from STL (we are using libc++, no modulemaps).


When writing a new module containing the definition of a STL 
reverse_iterator, it collects all its template specializations. Some of 
the specializations need to be deserialized from a third module. This 
triggers an iterator invalidation bug because of the deserialization 
happening when iterating the specializations container itself. This 
happens only when the container's capacity is exceeded and the 
relocation invalidates the iterators and at best causes a crash (see 
valgrind reports in the bug report). Unfortunately I haven't been able 
to make the reproducer independent on STL.


--Vassil

On 30/01/16 17:08, David Blaikie wrote:


It might be handy to give an overview of the issue in the review (& 
certainly in the commit) message rather than only citing the bug number


On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits" 
mailto:cfe-commits@lists.llvm.org>> wrote:


Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=26237

Please review.

Many thanks!
--Vassil

___
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][modules][PR26237]

[David Blaikie via cfe-commits]

Yeah, it's good to have a reproduction, but I wouldn't actually commit one
- unless you have a checked stl to test against that always fails on
possibly-invalidating sequences of operations, then you'd have a fairly
simple reproduction
On Jan 30, 2016 8:23 AM, "Vassil Vassilev"  wrote:

> Sorry.
>
> Our module builds choke on merging several modules, containing
> declarations from STL (we are using libc++, no modulemaps).
>
> When writing a new module containing the definition of a STL
> reverse_iterator, it collects all its template specializations. Some of the
> specializations need to be deserialized from a third module. This triggers
> an iterator invalidation bug because of the deserialization happening when
> iterating the specializations container itself. This happens only when the
> container's capacity is exceeded and the relocation invalidates the
> iterators and at best causes a crash (see valgrind reports in the bug
> report). Unfortunately I haven't been able to make the reproducer
> independent on STL.
>
> --Vassil
>
> On 30/01/16 17:08, David Blaikie wrote:
>
> It might be handy to give an overview of the issue in the review (&
> certainly in the commit) message rather than only citing the bug number
> On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=26237
>>
>> Please review.
>>
>> Many thanks!
>> --Vassil
>>
>> ___
>> 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

[PATCH] D16750: Bug 15685 - OpenCL 'char' is not signed

[Igor Chesnokov via cfe-commits]

ichesnokov created this revision.
ichesnokov added reviewers: asl, kraiskil.
ichesnokov added a subscriber: cfe-commits.
ichesnokov set the repository for this revision to rL LLVM.

A simple patch to ensure that char is signed. Check assumed for OpenCL only.

Repository:
  rL LLVM

http://reviews.llvm.org/D16750

Files:
  test/SemaOpenCL/ocl-char-is-not-signed.cl

Index: test/SemaOpenCL/ocl-char-is-not-signed.cl
===
--- test/SemaOpenCL/ocl-char-is-not-signed.cl
+++ test/SemaOpenCL/ocl-char-is-not-signed.cl
@@ -0,0 +1,3 @@
+// RUN: %clang_cc1 %s
+
+constant int CHECK = (char)(0xFFu) < 0 ? 0 : 1/0;


Index: test/SemaOpenCL/ocl-char-is-not-signed.cl
===
--- test/SemaOpenCL/ocl-char-is-not-signed.cl
+++ test/SemaOpenCL/ocl-char-is-not-signed.cl
@@ -0,0 +1,3 @@
+// RUN: %clang_cc1 %s
+
+constant int CHECK = (char)(0xFFu) < 0 ? 0 : 1/0;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16750: Bug 15685 - OpenCL 'char' is not signed

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

Please review and commit.


Repository:
  rL LLVM

http://reviews.llvm.org/D16750



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

Re: [PATCH][modules][PR26237]

[Vassil Vassilev via cfe-commits]

AFAICT the making a test case independent on STL is the hard part. I 
think it will be always failing due to the relocation of the memory 
region of the underlying SmallVector.

On 30/01/16 17:37, David Blaikie wrote:


Yeah, it's good to have a reproduction, but I wouldn't actually commit 
one - unless you have a checked stl to test against that always fails 
on possibly-invalidating sequences of operations, then you'd have a 
fairly simple reproduction


On Jan 30, 2016 8:23 AM, "Vassil Vassilev" > wrote:


Sorry.

Our module builds choke on merging several modules, containing
declarations from STL (we are using libc++, no modulemaps).

When writing a new module containing the definition of a STL
reverse_iterator, it collects all its template specializations.
Some of the specializations need to be deserialized from a third
module. This triggers an iterator invalidation bug because of the
deserialization happening when iterating the specializations
container itself. This happens only when the container's capacity
is exceeded and the relocation invalidates the iterators and at
best causes a crash (see valgrind reports in the bug report).
Unfortunately I haven't been able to make the reproducer
independent on STL.

--Vassil

On 30/01/16 17:08, David Blaikie wrote:


It might be handy to give an overview of the issue in the review
(& certainly in the commit) message rather than only citing the
bug number

On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits"
mailto:cfe-commits@lists.llvm.org>>
wrote:

Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=26237

Please review.

Many thanks!
--Vassil

___
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] D16750: Bug 15685 - OpenCL 'char' is not signed

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

BugZilla page: https://llvm.org/bugs/show_bug.cgi?id=15685


Repository:
  rL LLVM

http://reviews.llvm.org/D16750



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

Re: [PATCH][modules][PR26237]

[David Blaikie via cfe-commits]

On Sat, Jan 30, 2016 at 9:00 AM, Vassil Vassilev 
wrote:

> AFAICT the making a test case independent on STL is the hard part. I think
> it will be always failing due to the relocation of the memory region of the
> underlying SmallVector.
>

Sorry, I think I didn't explain myself well. What I mean is - due to the
instability of test cases for UB (especially library UB), we don't usually
commit test cases for them - we just fix them without tests. About the only
time I think committing a test is helpful for UB (especially library UB) is
if we have a reliable way to test/catch the UB (eg: the sanitizers or a
checking STL that fails fast on validation violations). So, while it would
be good to provide/demonstrate your test case, I would not commit the test
case unless it's a minimal reproduction in the presence of one of those
tools (sanitizers or checking STL) - and would just commit the fix without
a test case, usually.

(I'm not actually reviewing this patch - I don't know much about the
modules code, but just providing a bit of context and first-pass-review)


>
> On 30/01/16 17:37, David Blaikie wrote:
>
> Yeah, it's good to have a reproduction, but I wouldn't actually commit one
> - unless you have a checked stl to test against that always fails on
> possibly-invalidating sequences of operations, then you'd have a fairly
> simple reproduction
> On Jan 30, 2016 8:23 AM, "Vassil Vassilev"  wrote:
>
>> Sorry.
>>
>> Our module builds choke on merging several modules, containing
>> declarations from STL (we are using libc++, no modulemaps).
>>
>> When writing a new module containing the definition of a STL
>> reverse_iterator, it collects all its template specializations. Some of the
>> specializations need to be deserialized from a third module. This triggers
>> an iterator invalidation bug because of the deserialization happening when
>> iterating the specializations container itself. This happens only when the
>> container's capacity is exceeded and the relocation invalidates the
>> iterators and at best causes a crash (see valgrind reports in the bug
>> report). Unfortunately I haven't been able to make the reproducer
>> independent on STL.
>>
>> --Vassil
>>
>> On 30/01/16 17:08, David Blaikie wrote:
>>
>> It might be handy to give an overview of the issue in the review (&
>> certainly in the commit) message rather than only citing the bug number
>> On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits" <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=26237
>>>
>>> Please review.
>>>
>>> Many thanks!
>>> --Vassil
>>>
>>> ___
>>> 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] D16574: Bug 15685 - OpenCL 'char' is not signed

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

BugZilla page: https://llvm.org/bugs/show_bug.cgi?id=15685


Repository:
  rL LLVM

http://reviews.llvm.org/D16574



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[David Majnemer via cfe-commits]

Why isn't this logic buried in GetArgumentVector so that other tools may
take advantage of it?

On Saturday, January 30, 2016, Igor Chesnokov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> ichesnokov added a comment.
>
> Please review and commit.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D16351
>
>
>
> ___
> 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][modules][PR26237]

[Vassil Vassilev via cfe-commits]

On 30/01/16 18:36, David Blaikie wrote:



On Sat, Jan 30, 2016 at 9:00 AM, Vassil Vassilev 
mailto:v.g.vassi...@gmail.com>> wrote:


AFAICT the making a test case independent on STL is the hard part.
I think it will be always failing due to the relocation of the
memory region of the underlying SmallVector.


Sorry, I think I didn't explain myself well. What I mean is - due to 
the instability of test cases for UB (especially library UB), we don't 
usually commit test cases for them - we just fix them without tests. 
About the only time I think committing a test is helpful for UB 
(especially library UB) is if we have a reliable way to test/catch the 
UB (eg: the sanitizers or a checking STL that fails fast on validation 
violations). So, while it would be good to provide/demonstrate your 
test case, I would not commit the test case unless it's a minimal 
reproduction in the presence of one of those tools (sanitizers or 
checking STL) - and would just commit the fix without a test case, 
usually.


(I'm not actually reviewing this patch - I don't know much about the 
modules code, but just providing a bit of context and first-pass-review)

Got it. Thanks!
--Vassil



On 30/01/16 17:37, David Blaikie wrote:


Yeah, it's good to have a reproduction, but I wouldn't actually
commit one - unless you have a checked stl to test against that
always fails on possibly-invalidating sequences of operations,
then you'd have a fairly simple reproduction

On Jan 30, 2016 8:23 AM, "Vassil Vassilev"
mailto:v.g.vassi...@gmail.com>> wrote:

Sorry.

Our module builds choke on merging several modules,
containing declarations from STL (we are using libc++, no
modulemaps).

When writing a new module containing the definition of a STL
reverse_iterator, it collects all its template
specializations. Some of the specializations need to be
deserialized from a third module. This triggers an iterator
invalidation bug because of the deserialization happening
when iterating the specializations container itself. This
happens only when the container's capacity is exceeded and
the relocation invalidates the iterators and at best causes a
crash (see valgrind reports in the bug report). Unfortunately
I haven't been able to make the reproducer independent on STL.

--Vassil

On 30/01/16 17:08, David Blaikie wrote:


It might be handy to give an overview of the issue in the
review (& certainly in the commit) message rather than only
citing the bug number

On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits"
mailto:cfe-commits@lists.llvm.org>> wrote:

Attaching a fix to
https://llvm.org/bugs/show_bug.cgi?id=26237

Please review.

Many thanks!
--Vassil

___
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] D16264: For FreeBSD, use _p variants of libraries for linking C++ programs

[Saleem Abdulrasool via cfe-commits]

compnerd added a comment.

`-p` or `-pg` also effects the math library.  Please adjust the tests and the 
driver to reflect that.


http://reviews.llvm.org/D16264



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

Re: [PATCH] D16264: For FreeBSD, use _p variants of libraries for linking C++ programs

[Dimitry Andric via cfe-commits]

dim added a comment.

In http://reviews.llvm.org/D16264#340131, @compnerd wrote:

> `-p` or `-pg` also effects the math library.  Please adjust the tests and the 
> driver to reflect that.


This is already handled in `lib/Driver/Tools.cpp`, in 
`freebsd::Linker::ConstructJob()`:

  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
if (D.CCCIsCXX()) {
  getToolChain().AddCXXStdlibLibArgs(Args, CmdArgs);
  if (Args.hasArg(options::OPT_pg))
CmdArgs.push_back("-lm_p");
  else
CmdArgs.push_back("-lm");
}


http://reviews.llvm.org/D16264



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

Re: [PATCH] D16748: Cleanup MemRegion.cpp/MemRegion.h

[Devin Coughlin via cfe-commits]

dcoughlin added a subscriber: cfe-commits.
dcoughlin added a comment.

Also adding cfe-commits as a subscriber. (See 
http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface).


http://reviews.llvm.org/D16748



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

r259310 - No need to use utostr when putting integers into a raw_ostream. NFC

[Craig Topper via cfe-commits]

Author: ctopper
Date: Sat Jan 30 18:20:26 2016
New Revision: 259310

URL: http://llvm.org/viewvc/llvm-project?rev=259310&view=rev
Log:
No need to use utostr when putting integers into a raw_ostream. NFC

Modified:
cfe/trunk/utils/TableGen/NeonEmitter.cpp

Modified: cfe/trunk/utils/TableGen/NeonEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/NeonEmitter.cpp?rev=259310&r1=259309&r2=259310&view=diff
==
--- cfe/trunk/utils/TableGen/NeonEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/NeonEmitter.cpp Sat Jan 30 18:20:26 2016
@@ -1195,12 +1195,12 @@ void Intrinsic::emitReverseVariable(Vari
 emitNewLine();
 
 for (unsigned K = 0; K < Dest.getType().getNumVectors(); ++K) {
-  OS << "  " << Dest.getName() << ".val[" << utostr(K) << "] = "
+  OS << "  " << Dest.getName() << ".val[" << K << "] = "
  << "__builtin_shufflevector("
- << Src.getName() << ".val[" << utostr(K) << "], "
- << Src.getName() << ".val[" << utostr(K) << "]";
+ << Src.getName() << ".val[" << K << "], "
+ << Src.getName() << ".val[" << K << "]";
   for (int J = Dest.getType().getNumElements() - 1; J >= 0; --J)
-OS << ", " << utostr(J);
+OS << ", " << J;
   OS << ");";
   emitNewLine();
 }
@@ -1208,7 +1208,7 @@ void Intrinsic::emitReverseVariable(Vari
 OS << "  " << Dest.getName()
<< " = __builtin_shufflevector(" << Src.getName() << ", " << 
Src.getName();
 for (int J = Dest.getType().getNumElements() - 1; J >= 0; --J)
-  OS << ", " << utostr(J);
+  OS << ", " << J;
 OS << ");";
 emitNewLine();
   }


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

r259309 - Convert an unsigned to Twine instead of using utostr since we're already building a Twine. NFC

[Craig Topper via cfe-commits]

Author: ctopper
Date: Sat Jan 30 18:20:24 2016
New Revision: 259309

URL: http://llvm.org/viewvc/llvm-project?rev=259309&view=rev
Log:
Convert an unsigned to Twine instead of using utostr since we're already 
building a Twine. NFC

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/IssueHash.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/IssueHash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/IssueHash.cpp?rev=259309&r1=259308&r2=259309&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/IssueHash.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/IssueHash.cpp Sat Jan 30 18:20:24 2016
@@ -180,7 +180,7 @@ std::string clang::GetIssueString(const
 
   return (llvm::Twine(CheckerName) + Delimiter +
   GetEnclosingDeclContextSignature(D) + Delimiter +
-  llvm::utostr(IssueLoc.getExpansionColumnNumber()) + Delimiter +
+  Twine(IssueLoc.getExpansionColumnNumber()) + Delimiter +
   NormalizeLine(SM, IssueLoc, LangOpts) + Delimiter + BugType)
   .str();
 }


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

r259311 - [Parser] Update CachedTokens while parsing ObjectiveC template argument list

[Bruno Cardoso Lopes via cfe-commits]

Author: bruno
Date: Sat Jan 30 18:47:51 2016
New Revision: 259311

URL: http://llvm.org/viewvc/llvm-project?rev=259311&view=rev
Log:
[Parser] Update CachedTokens while parsing ObjectiveC template argument list

Consider the following ObjC++ snippet:

--
@protocol PA;
@protocol PB;

@class NSArray;
typedef int some_t;

id FA(NSArray> *h, some_t group);
--

This would hit an assertion in the parser after generating an annotation token
while trying to update the token cache:

Assertion failed: (CachedTokens[CachedLexPos-1].getLastLoc() == 
Tok.getAnnotationEndLoc() && "The annotation should be until the most recent 
cached token")
...
7 clang::Preprocessor::AnnotatePreviousCachedTokens(clang::Token const&) + 494
8 clang::Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec(bool, bool, 
clang::CXXScopeSpec&, bool) + 1163
9 clang::Parser::TryAnnotateTypeOrScopeToken(bool, bool) + 361
10 clang::Parser::isCXXDeclarationSpecifier(clang::Parser::TPResult, bool*) + 
598
...

The cached preprocessor token in this case is:

greatergreater '>>' Loc=

while the annotation ("NSArray>") ends at "testcase.mm:7:25", hence the
assertion.

Properly update the CachedTokens during template parsing to contain
two greater tokens instead of a greatergreater.

Differential Revision: http://reviews.llvm.org/D15173

rdar://problem/23494277

Modified:
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/lib/Lex/PPCaching.cpp
cfe/trunk/lib/Parse/ParseTemplate.cpp
cfe/trunk/test/Parser/objcxx11-protocol-in-template.mm

Modified: cfe/trunk/include/clang/Lex/Preprocessor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/Preprocessor.h?rev=259311&r1=259310&r2=259311&view=diff
==
--- cfe/trunk/include/clang/Lex/Preprocessor.h (original)
+++ cfe/trunk/include/clang/Lex/Preprocessor.h Sat Jan 30 18:47:51 2016
@@ -1185,6 +1185,17 @@ public:
 return CachedTokens[CachedLexPos-1].getLastLoc();
   }
 
+  /// \brief Whether \p Tok is the most recent token (`CachedLexPos - 1`) in
+  /// CachedTokens.
+  bool IsPreviousCachedToken(const Token &Tok) const;
+
+  /// \brief Replace token in `CachedLexPos - 1` in CachedTokens by the tokens
+  /// in \p NewToks.
+  ///
+  /// Useful when a token needs to be split in smaller ones and CachedTokens
+  /// most recent token must to be updated to reflect that.
+  void ReplacePreviousCachedToken(ArrayRef NewToks);
+
   /// \brief Replace the last token with an annotation token.
   ///
   /// Like AnnotateCachedTokens(), this routine replaces an

Modified: cfe/trunk/lib/Lex/PPCaching.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPCaching.cpp?rev=259311&r1=259310&r2=259311&view=diff
==
--- cfe/trunk/lib/Lex/PPCaching.cpp (original)
+++ cfe/trunk/lib/Lex/PPCaching.cpp Sat Jan 30 18:47:51 2016
@@ -116,3 +116,29 @@ void Preprocessor::AnnotatePreviousCache
 }
   }
 }
+
+bool Preprocessor::IsPreviousCachedToken(const Token &Tok) const {
+  // There's currently no cached token...
+  if (!CachedLexPos)
+return false;
+
+  const Token LastCachedTok = CachedTokens[CachedLexPos - 1];
+  if (LastCachedTok.getKind() != Tok.getKind())
+return false;
+
+  int RelOffset = 0;
+  if ((!getSourceManager().isInSameSLocAddrSpace(
+  Tok.getLocation(), getLastCachedTokenLocation(), &RelOffset)) ||
+  RelOffset)
+return false;
+
+  return true;
+}
+
+void Preprocessor::ReplacePreviousCachedToken(ArrayRef NewToks) {
+  assert(CachedLexPos != 0 && "Expected to have some cached tokens");
+  CachedTokens.insert(CachedTokens.begin() + CachedLexPos - 1, NewToks.begin(),
+  NewToks.end());
+  CachedTokens.erase(CachedTokens.begin() + CachedLexPos - 1 + NewToks.size());
+  CachedLexPos += NewToks.size() - 1;
+}

Modified: cfe/trunk/lib/Parse/ParseTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTemplate.cpp?rev=259311&r1=259310&r2=259311&view=diff
==
--- cfe/trunk/lib/Parse/ParseTemplate.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTemplate.cpp Sat Jan 30 18:47:51 2016
@@ -831,6 +831,7 @@ bool Parser::ParseGreaterThanInTemplateL
   }
 
   // Strip the initial '>' from the token.
+  Token PrevTok = Tok;
   if (RemainingToken == tok::equal && Next.is(tok::equal) &&
   areTokensAdjacent(Tok, Next)) {
 // Join two adjacent '=' tokens into one, for cases like:
@@ -847,6 +848,17 @@ bool Parser::ParseGreaterThanInTemplateL
  PP.getSourceManager(),
  getLangOpts()));
 
+  // The advance from '>>' to '>' in a ObjectiveC template argument list needs
+  // to be properly reflected in the token cache to allow correct interaction
+  // between annotation and backtracking.
+  if (ObjCGenericList &

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

[Bruno Cardoso Lopes via cfe-commits]

bruno accepted this revision.
bruno added a reviewer: bruno.
bruno added a comment.

Thanks,

Committed r259311!


http://reviews.llvm.org/D15173



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

Re: [PATCH] D16738: Fix invalid casts in .

[Eric Fiselier via cfe-commits]

EricWF added a comment.

> This also could be fixed in a different way by replacing C-style

>  casts with reinterpret_cast<>, which, from my reading of the

>  standard, is allowed in this context.


I agree that using `void*` to represent raw memory is the better approach than 
`reinterpret_cast<>()`.
However I'm concerned that changing the signature (and mangling) of `virtual 
void __clone(...)` could cause ABI problems.
I *think* this should be "safe" because the VTable's mangled name doesn't 
change. but if I'm wrong we must use `reinterpret_cast<>` for calls to 
`__clone(...)`.

The parts of the patch that don't affect `__clone(...)` LGTM. You can commit 
them separably if you want.

> That would not help with CFI

>  though, which still flags such casts as invalid (yes, it is stricter that 
> the standard).


I'm sure there are alternative ways to make CFI shut up. Perhaps we could do 
the `Buffer* -> Base*` conversion inside a blacklisted function (akin to 
std::launder)?
It would also be nice to have "`__attribute__((__no_sanitize__("cfi")))`.



Comment at: include/functional:1443
@@ -1442,3 +1442,3 @@
 virtual __base* __clone() const = 0;
-virtual void __clone(__base*) const = 0;
+virtual void __clone(void*) const = 0;
 virtual void destroy() _NOEXCEPT = 0;

Doesn't this break the ABI because it changes the mangling of a virtual 
function? I understand the vtable should remain layout compatible but I suspect 
the mangling change is an issue.


Comment at: include/functional:1739
@@ -1738,2 +1738,3 @@
 {
+::new (&__buf_) _FF(_VSTD::move(__f));
 __f_ = (__base*)&__buf_;

`__f_ = ::new((void*)&__buf_) _FF(_VSTD::move(__f));`


Repository:
  rL LLVM

http://reviews.llvm.org/D16738



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

r259316 - Replace usage of llvm::utostr_32 with just llvm::utostr. While this is less efficient, its unclear that the one place using the _32 version was doing so for efficiency.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Sat Jan 30 22:20:03 2016
New Revision: 259316

URL: http://llvm.org/viewvc/llvm-project?rev=259316&view=rev
Log:
Replace usage of llvm::utostr_32 with just llvm::utostr. While this is less 
efficient, its unclear that the one place using the _32 version was doing so 
for efficiency.

Modified:
cfe/trunk/lib/AST/ItaniumMangle.cpp

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=259316&r1=259315&r2=259316&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Sat Jan 30 22:20:03 2016
@@ -1788,7 +1788,7 @@ void CXXNameMangler::mangleQualifiers(Qu
 if (Context.getASTContext().addressSpaceMapManglingFor(AS)) {
   //   ::= "AS" 
   unsigned TargetAS = Context.getASTContext().getTargetAddressSpace(AS);
-  ASString = "AS" + llvm::utostr_32(TargetAS);
+  ASString = "AS" + llvm::utostr(TargetAS);
 } else {
   switch (AS) {
   default: llvm_unreachable("Not a language specific address space");


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